Technical Activities Group Meeting Minutes
HEPKI-TAG Conference Call

March 27, 2002
Attendees

* Jim Jokl (chair) - Virginia
* Renee Frost - Michigan/Internet2
* Neal McBurnett - Internet2
* Chris Misra - Massachusetts
* Eric Norman - Wisconsin
* Bob Morgan - Washington
* David Wasley - UCOP
* Judith Boettcher - CREN
* Ben Chinowsky (scribe) - Internet2

Discussion

The minutes of the previous meeting were approved without changes. The group reviewed action items:

* [13-March - Judith will use Jim's short introduction to the PKI Lite CP/CPS to seek review of the document on the CREN CA list.] - Done.
* [13-March - John will send out URLs for more information on Papyrus.] - Still to do. There doesn't appear to be any information on Papyrus on the Web yet; Judith sent John's summary of the project to the list on March 13.
* [13-March - All will test the CREN Papyrus CA.] - In process.
* [13-March - David will test the CREN Papyrus CA using a Mac.] - Still to do.
* [13-March - Jim will add a row for self-signed cert capabilities to the S/MIME clients table.] - Done.
* [13-March - In the S/MIME requirements document, Jim will a) add a note explaining when it's OK to violate the 13-month maximum cert lifetime specified in the PKI Lite cert profile, and b) in the "Supported E-Mail Clients" section, separate Mozilla and Netscape, remove their version numbers, and add "(Windows, Unix, and Macintosh)" to each.] - Done.
* [27-February - Jim will work with MACE to find more reviewers for the PKI Lite CP/CPS.] - Still to do.

David noted that section 6 of http://www.ietf.org/internet-drafts/draft-ietf-pkix-new-part1-12.txt "punts" on path discovery, though it goes into great detail on what to do with certs once you find them. He suggested that the AuthorityInformationAccess field could contain a pointer to a repository where the CA cert is stored; this could then be used recursively to find the trust anchor.

[AI] David will draft a document describing how to use AuthorityInformationAccess for path discovery; all are encouraged to provide input. David noted that this would not be a quick solution, because it would require all certs to be reissued with the AuthorityInformationAccess field. On the other hand, the code required is relatively easy; if the idea is well received, Cal could become a testbed for it. Bob Morgan noted that the alternative of deploying directories that contain the certs isn't likely to be much easier. The group noted that using AuthorityInformationAccess would remove one of the major reasons for dc= naming, though others -- finding other things besides certs in directories, providing a general replacement for c= o= naming -- would persist. Bob noted that draft-ietf-pkix-new-part1-12.txt is about to become an RFC, so David's document will be a supplement to it, not part of it.

Bob outlined the discussion of the Grid proxy cert proposal at IETF last week. The main idea is that a cert holder delegates powers by generating a key pair and signing a short-term proxy cert, which the delegate uses much like a Kerberos TGT or an X.509 junk cert. This proposal has been written up as an I-D (http://www.ietf.org/internet-drafts/draft-ietf-pkix-proxy-02.txt) and is being promoted as a standard in PKIX. A key point raised in the discussion at IETF is that allowing end-entity certs to sign other certs discards a fundamental principle of X.509; X.509-compliant software can't validate certs created this way. Bob noted that "the phrase 'sacred cow' was used...the phrase 'hard-to-change international standard' was used in return". Three possibilities were explored:

1. 1. setting the CA bit in end-entity certs (David: "arrggh") and applying policy constraints to those certs to limit what they can sign.
2. 2. setting up a CA specifically to issue the short-term certs, a la KX.509. (Bob inclines toward this option.) The Grid folks don't like the idea of needing another service for this; they prefer to use the user's end system.
3. 3. using authZ certs instead, e.g. with SAML assertions.

David argued that setting the CA bit is "conceptually the wrong thing to do", as -- currently at least -- it implies that the subject is trustworthy. Bob agreed that this is indeed the central question -- Would setting the CA bit give the end-user too much power? --and noted that current Grid policies probably wouldn't permit it. On the other hand, as David pointed out, allowing non-CAs to sign certs would require path processing software to have a whole different branch of logic to establish what the non-CA signing-cert holder would be allowed to do, and thus what the delegation cert holder could do. Because certs not signed by a CA are not asserting identity, David suggested calling such certs "delegation certs" rather than "proxy certs". The group noted that the absence of a distinction between cert-signing and non-cert-signing keys is the main thing that distinguishes SPKI/SDSI from X.509, so maybe the Grid work points in the direction of using SPKI/SDSI.

There was a short discussion of the possible threat to 1024-bit keys entailed by D.J. Bernstein's recent work on factoring methods; see http://www.inet-one.com/cypherpunks/dir.2002.03.18-2002.03.24/msg00560.html and http://www.inet-one.com/cypherpunks/dir.2002.03.18-2002.03.24/msg00583.html While no attempt was made to reach a formal consensus, TAG's overall level of concern about this issue appears to be quite low. The group agreed that the PKI Lite cert profiles are now ready for last call in TAG, after which they will be circulated for review by a wider group. [AI] Jim will a) verify that the cert profiles are clear on the distinction between campus certs and root certs, and b) announce last call for TAG to make changes to the profiles.

Finally the group discussed possible applications for PKI-Lite S/MIME. Judith suggested survey responses and elections. Eric noted that these applications involve verifying anonymity rather than identity; David noted that protection of anonymity in current non-digital systems is fairly weak, offering a low bar for an electronic substitute to clear. David is writing up a electronic voting scenario; [AI] Bob Morgan will send David references on electronic voting, and cc TAG. Neal pointed the group to an overview of Internet voting issues at http://www.ss.ca.gov/executive/ivote/. Judith suggested homework submission as an S/MIME application. David suggested resume submission, noting that California already receives lots of job applications by email, and that both signing (for the receiver to verify authenticity) and encryption (so the sender's employer doesn't find out that they're looking for another job) would be useful here. [AI] All will continue to brainstorm interoperable end-user applications for S/MIME.
Action Items

1. [AI] 27-March - David will draft a document describing how to use
2. AuthorityInformationAccess for path discovery; all are encouraged to provide input.
3. [AI] 27-March - Jim will a) verify that the cert profiles are clear on the distinction between campus certs and root certs, and b) announce last call for TAG to make changes to the profiles.
4. [AI] 27-March - Bob Morgan will send David references on electronic voting, and cc TAG.
5. [AI] 27-March - All will continue to brainstorm interoperable end-user applications for S/MIME.
6. [AI] 13-March - John will send out URLs for more information on Papyrus.
7. [AI] 13-March - All will test the CREN Papyrus CA.
8. [AI] 13-March - David will test the CREN Papyrus CA using a Mac.
9. [AI] 27-February - Jim will work with MACE to find more reviewers for
10. the PKI Lite CP/CPS.
11. [AI] 27-February - Bill and Ken will pursue getting Michigan's KCA
12. documentation into NMI Release 1.0.
13. [AI] 27-February - All who can help test the KX.509 client on Solaris will
14. contact Bill or Ken.
15. [AI] 13-February - Judith will check with Michelle on the status of the
16. Tumbleweed plugin.
17. [AI] 13-February - Jim will find out what cert store the SSH.com client
18. uses.
19. [AI] 13-February - Jim and Deb will draft a letter to SSH.com, to be signed by as many representatives of higher education as possible, asking that the support for cert-based authentication now present in their commercial version be added to both the server and the client in their free version.
20. [AI] 13-February - All will review the updated PKI Lite S/MIME requirements document and send comments to the list.
21. [AI] 13-February - Updates to the planned S/MIME clients table
22. (http://middleware.internet2.edu/hepki-tag/pki-lite/ hepki-tag-pkilite-smime-clients-3.html)
23. Jim will ask Ed if he will work on Netscape Messenger column
24. Neal will work on Mozilla, putting all the information in one column and noting any Unix/Windows differences
25. Michelle will look at Outlook 2000
26. Eric will look at Eudora/Tumbleweed
27. Jim will try to recruit further contributors to the table
28. [AI] 16-January - Bob Morgan and Eric will try to find out if anyone is planning to add S/MIME to pine.
29. [AI] 2-January - Ken will follow up with the people responsible for testing the fix proposed for the L-Soft signed messages problem.
30. [AI] 19-December - Judith will draft a scenario for using S/MIME for homework submission.
31. [AI] 5-December - Jeff will have lawyers at MIT review the legal language in the draft CPS template.
32. [AI] 5-December - Ed will find out more about Dartmouth's timesheet-signing application, for discussion on the next call.
33. [AI] 5-December - Keith will point Wisconsin's deputy CIO to the posted draft CPS template.
34. [AI] 10-September - Eric will a) investigate and document a problem that Ed has encountered with using PKIUser objects to get certs from LDAP directories (what the user sees in the retrieved cert is only a fingerprint, not cert details), and b) send the list information on his experience with cert retrieval using Internet Explorer.