[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
IETF Meeting Minutes
The following text is the first draft of the minutes from the two days of WG meetings that took place at the 39th IETF, in Munich. I'd like attendees to comment on the minutes by Friday, 8/22, so that I can make revisions as appropriate and submit the minutes to the IETF Secretariat.
PKIX WG Meeting Minutes: 8/13-14/97
The PKIX Working Group met twice at the 39th IETF. A total of about 200 IETF attendees participated in these two meetings. The primary focus of the meetings were status reports on the six PKIX documents. (Note that the last two of these are new documents, outside the scope of the original WG charter, and work was initiated on them as a result of discussion at the Memphis meeting. Hence Parts 5 and 6 are trailing the other documents and are not critical to the base set of functions for an Internet PKI.) Additional discussion focused on the topic of choosing default cryptographic algorithms.
Part 1: X.509 Profile (Tim Polk, NIST)
Ready to go after a few minor editing changes for clarification. Plan to go to last call in September.
Part 2: Operational Protocols (Sharon Boeyen, Entrust)
Major changes from Memphis include LDAP modification profile, HTTP mechanisms (not complete), and e-mail (very new, not complete). Other refinements include several OCSP changes and additions.
- e-mail appendix is very new and requires review
- OCSP questions about path validation
- retention of historical CRLs
- OCSP caching
- LDAP responses should be signed, not just SSL protected, but this is not currently supported in LDAP
- need HTTP content type label assignment
- do we still need FTP support, given HTTP availability?
- has the document grown too big?
A suggestion was made to split apart the mechanisms by mechanism, e.g., LDAP, HTTP, OCSP, and FTP. Volunteers available for all the parts, except maybe FTP, so we decide to do this, subject to list approval. Plan to go to last call next month on LDAP. HTTP and OCSP documents not yet ready. We assume that the FTP portion will be ready soon, but need confirmation from author (who was not present). Relative to the recently introduced requirement for default algorithms, some of these documents will have to adopt such algorithms, e.g., OCSP. PowerPoint slides will be available in the IETF on-line minutes.
Part 3: Management Protocols (Carlisle Adams, Entrust)
Carlisle presented an evaluation of the Meyers proposal (discussed below), arguing that the proposal is currently incomplete and that it calls for processing not compatible with deployed PKCS 7/10 implementations. He provided several examples of the incompatibility, e.g., the need to extract a key from within a PKCS 10 structure inside a PKCS 7 envelope, in order to validate the signature on the envelope. Mike Meyers expressed concern that Part 3 contains some ambiguities with regard to how to map certificate management messages into the PKCS 7 format. At lunch after the meeting, Carlisle and Mike, in discussion with the WG co-chairs, agreed to move the discussion of the use of PKCS 7 and 10 to a new standards track document (edited by Mike), and PKIX Part 3 will progress to last call with this modification. Because of the need to define default algorithms (see below), this document also will be amended to define the requisite default algorithms for signatures, hashes, and encryption. PowerPoint slides will be available in the IETF on-line minutes.
Part 4: Policy Framework (Warwick Ford)
Not a standards track document, but rather an Informational or BCP RFC. Document is ready for last call after next revision, with minor changes, next month.
Part 5: Time Stamping (Robert Zuccherato, Entrust)
Brief presentation of what a Time Stamp Authority (TSA) does, and a proposed protocol (format and message flow). See PowerPoint slides in on-line minutes. Concern expressed over possible patents in this area, e.g., by Pitney-Bowes and Fischer International. Need to resolve these concerns. Also, a concern was expressed over the extent to which the proposed protocol is amenable to various techniques that can be employed to protect against the TSA corruption. Suggestion to consider alternative time stamping approaches, e.g., Surety technique, is rejected as out of scope for this WG. Instead, the WG chairs direct the document to explicitly state the intended scope, i.e., time stamping in an X.509 PKI context (hence, using public-key digital signature technology). PowerPoint slides will be available in the IETF on-line minutes.
Part 6: Notary Protocols (Robert Zuccherato, Entrust)
Not so well defined as TSA document (Part 5). In the digital signature and security literature, the notarization function is tightly tied to the time stamping function, and one could easily imagine making the TSA a part of the larger notary function. The distinctions between this function and the TSA function, as presented here, are binding proof of possession of the data to the submittor and, possibly, vouching for validity or truth of the data submitted for notarization. Thus this function entails signature and certificate path validation by the notary, including CRLs and ARLs, and might entail other, more complex assertions about the data. This is clearly not a critical function for general, Internet PKI use, and thus not part of the base PKIX standards. See PowerPoint slides in on-line minutes.
Meyers Certificate Management Protocol: (Tim Polk, NIST)
Discussion lead by Tim, but the submission in question is authored by Meyers et al. (VeriSign). The proposal calls for use of PKCS 7 as security encapsulation protocol and PKCS 10 as certificate management protocol. The current version of PKCS 10 is primarily oriented toward RSA support, which is not consistent with the algorithm independence goals of PKIX, and it does not support the full range of certificate management functions defined in PKIX Part 3. It is argued that future versions of these RSA standards will be capable of supporting all of these requirements, but the current proposal does not address these concerns. Similar concerns arise with regard to PKCS 7 as a secure encapsulation protocol. Moreover, the PKCS series are not under IETF control and thus there are concerns about making the PKIX management protocols too dependent on these standards. Still, there is significant support for use of PKCS 7 and 10 because of the installed base and availability of supporting toolkits. See the discussion of PKIX Part 3 above for further details.
KEA: (Tim Polk, NIST)
KEA, because it is a classified algorithm, is not part of the base specs and will be covered by a separate
Default algorithm suite: (Steve Kent, BBN & Jeff Schiller, MIT)
There is a recent trend by the IESG to encourage WGs to define a default (MUST implement) algorithm suite to enable interoperability. For example, the TLS proto-RFC were rejected by the IESG because of the use of a proprietary encryption algorithm (RC4) and a patented public key algorithm (RSA). The emerging pattern (in TLS and SSH) is to use DSA (vs. RSA) as a public key signature algorithm and to use Diffie-Hellman as a key agreement algorithm, to avoid patent issues.
However, we note that most of the deployed certificate technology is RSA-based, making this deployed this technology non-compliant if we mandate DSA. Also, European attendees expressed concern over the patent status of DSA in Europe (vis a vis Schnoor patent). Jeff will ask the ISOC attorneys to evaluate the patent status of DSA on an international basis, relative to possible adoption of DSA as the default digital signature algorithm for use in some parts of PKIX.
Jeff suggests that the PKIX management protocols WILL need to adopt a default set of algorithms for hash, signature, encryption key management, and encryption. The current trend would be to call for use of DSA for signatures. Jeff is not prepared to state that the IESG will require PKIX to mandate DSA as the default algorithm for certificate signatures. Thus, it would seem that Part 1 need not mandate any signature and hash algorithm, but that Part 3 and some parts of Part 2 will require the addition of such default algorithms.