The PKIX Working Group met twice. The primary focus of the meetings were status reports on the six PKIX documents. Additional discussion focused on the topic of choosing default cryptographic algorithms.
Part 1 (X.509 Profile from Tim Polk, NIST) is now ready to go after a few minor editing changes for clarification; they pPlan to go to last call in September. Part 3 (Management Protocols from Carlisle Adams, Entrust) was presented, and argued 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. There were also some ambiguities with regard to how to map certificate management messages into the PKCS 7 format. It was agreed to move the discussion of the use of PKCS 7 and 10 to a new standards track document, 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. Part 4 (Policy Framework by Warwick Ford) is not a standards track document, but rather an Informational or BCP RFC. This document will be ready for last call after next revision, with minor changes, next month.
Part 2 (Operational Protocols, form Sharon Boeyen, Entrust) has incorporated major recent changes including LDAP modification profile, HTTP mechanisms (not complete), and e-mail (very new, not complete). Other refinements include several OCSP changes and additions. There are a number of outstanding issues. The document is rather big, and still has the following problens:
There were to recent additions to the set. Part 5 (Time Stamping) and Part 6 (Notary Protocols) both from Robert Zuccherato of Entrust; both were presented. Concern expressed over possible patents in the time-stamping area, e.g., by Pitney-Bowes and Fischer International; these must be resolved. 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. The notary protocols document was considered not so well defined as TSA document (Part 5). In the digital signature and security literature, the notarisation 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 submitter and, possibly, vouching for validity or truth of the data submitted for notarisation. Thus this function entails signature and certificate path validation by the notary, including CRLs and ARLs; it 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.
There was considerable discussion of the Certificate Management Protocol: (Tim Polk, NIST). 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. It was agreed that KEA, because it is a classified algorithm, is not part of the base specs and will be covered by a separate Informational RFC.
There was considerable discussion on a Default algorithm suite. 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, most of the deployed certificate technology is RSA-based, making this deployed 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). The ISOC attorneys will be asked 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. The Area Director (Geoff Schiller from MIT) stated 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, though it is not clear 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.
The Internet Public Key Infrastructure (IPKI) is very keen on completing its work. They agreed to progress all four of their main documents: Part 1 Profiles, Part 2 Operational Protocols, Part 3 Management and Part 4 Policy to Last Call. Part 3 is going to be divided into several pieces. Everyone was in a considerable hurry to get this happening before the next meeting.
One aspect that came up is that the Internet Engineering Steering Group wishes to approve Standards only if they involve unencumbered algorithms - if this is at all possible. They also wanted to make mandatory at least one set of algorithms to allow interoperability testing. This raised an interesting set of questions; the algorithm for Public Key in the widest use is RSA - but PKP patents cover this until the year 2000 in the US. Their preferred solution to use Diffie-Hellman for key exchange, and DSA-1 for digital signature; this may, however, be covered in Europe by the Schnorr patents. There is no way out of this dilemma, and the Secure Transactions WG and the secure HTTP ones have both agreed to use DSA-1, SHA-1 for secure hash, and triple DES for symmetric encryption. These are the algorithms that will be used in the end for IPKI also - and I will ensure that the same is used for secure SAP. One impact of this is the decision to split up the PKIX Part 2 so that the algorithm parts are kept separate.