PKIX WG Minutes Approximately 360 attendees participated in the two PKIX WG session at the 40th IETF. Several of the PKIX I-Ds have been through working group last call and have moved on to the IESG for review, but a few issues remain and must be resolved prior to IESG approval and IETF last call. Part 1 (Certificate/CRL Profile) This draft completed WG last call, but a few issues remain to be resolved. Issues relating to use of algorithm OIDs and some ASN.1 errors have been resolved, and the authors have avoided inclusion of some legal language that was previously proposed. Unresolved issues: - There is disagreement about wildcarding in names (e.g., DNS and RFC 822). A small group met to resolve this issue after the (2nd) meeting. That group suggested disallowing use of asterisks in these name forms as a means of conveying the notion that the name was a place-holder for a set of names. Instead, a new document will be created to describe name form conventions, on a per-application context basis, with explicitly declared semantics, in support of the requirements that motivated use of wildcard name forms. - We are using '88 ASN.1, but BMP string is a new ASN.1 construct, so this is a technical matter (but does not affect bit on the wire format). - There is a related issue is use of UTF8, a new ('98 ASN.1) character set encoding, an alternative to BMP. This appears to be an issue at the IESG last call level of approval, but is not an issue among PKIX members. - For key usage, we propose to stay with what X.509 says, despite disagreements over whether it is the "right" interpretation. - Should CRLDistributionPoint be critical, non-critical, or at the discretion of the CA? Currently, it cannot be marked critical, but this can cause problems. The concern is that if marked critical, then a client without support for this would reject the certificate, even if the user was willing to ignore this extension, as required by X.509. Not resolved. Part 2 (split into LDAP, FTP, HTTP, OCSP) No problems with FTP or HTTP. LDAP v2 profile completed both last calls and is to be forwarded to IESG for approval. We agree to add a new work item to deal with v3, since current LDAP use in PKIX is based on v2. There was a suggestion to add a work item to develop a minimal schema for PKIX use of LDAP. This is a possible overlap with the LDAP WG, so coordination is required. Later during the week the LDAP WG chairwas contacted and it was determined that creation of a schema for use with PKIX was within the purview of the PKIX WG. See slides for additional details. Part 3 (Certificate Management Protocol) No issues here other than the character set concerns raised under Part 1. Certificate Request Syntax (PKCS7/10 focus) A proposal was made to move work on this to S/MIME WG, and Schiller and Housley (S/MIME WG chair) have no objections. However, this work is not S/MIME-specific and several PKIX and S/MIME WG members believe that this work item should remain in PKIX, as it is more general. The fundamental question is whether CRS is a completely separate protocol, focused on S/MIME, or if it is a profile for Part 3. This was subsequently resolved [see below]. A straw poll of attendees showed a plurality of attendees in favor of keeping the work item in this WG, and only a single vote in favor of moving it to S/MIME. The S/MIME WG, meeting two days later, concurred with this and did not recommend adoption of CRS within that WG, assuming that PKIX would reconcile CRS/CMP differences and include a specification for securely transporting commonly-agreed certificate management messages over CMS (i.e., son of PKCS 7). At the second PKIX WG meeting, a compromise approach was announced, aimed at reconciling differences between CRS and CMP. In essence, a common certificate request message syntax was agreed upon, and CMP will adopt this syntax as the certificate request payload type within that protocol (replacing the current certificate request payload format). CRS also will be revised to reference that syntax. This new, harmonized certificate request format will appear as a separate RFC. It is not anticipated that this will delay the progression of CMP to proposed standard, since it is simply a protocol syntax change for alignment purposes, plus a splitting of one document into two in the interest of facilitating future developments. CRS will continue to progress, specifying the mapping of certificate management messages onto CMS and providing the vehicle for producing and RFC (or RFCs) that document agreed common formats for other certificate management messages (i.e., messages other than certificate request). Time-Stamping and Notary Protocols These are new, potential work items, discussed on a preliminary basis in Munich. Two presentations: Rob Zuccherato (Entrust) on time stamping and notary functions, and Stuart Haber (Surety) on time stamping. See slides for additional details. Entrust- Time stamping service described here deals exclusively with establishing existence of data (really a hash of data) at a point in time. Basic notary service for data demonstrates that a requester posses data (not just a hash of the data) at a given time. A certificate notary service requires validation of a certificate chain for the requester, including CRLs and ARLs. There is also a fancy data notarization service, encompassing data validity, and a combined service of data possession and validity. Some folks note that validation of data (and certificates) is outside the scope of what real world notaries do in the U.S. (but Latin Notaires do have broader functions). Surety- Stuart provided an overview of time stamping problem and solution space, with a focus on the hash tree technology developed (patented) and offered by Surety as a service. The current Surety service offers a 1 second granularity, At least one WG member argued that the notary and time stamping functions are not completely PKI-specific, and we should try to avoid duplication of efforts like the PKIX/SPKI situation. Another member noted that there is a new I-D for time stamping via NTP, that raises possible overlap concerns as well. One possible outcome is a split of time stamping vs. notary functions. Certificate path validation, a part of the described notary service, does make sense for PKIX, consistent with X.509 validation procedures. A straw poll during the second PKIX meeting showed a strong sentiment that this WG amend its charter to include development of a standard for time stamping, but there was not strong support for adding a work item to develop notary functions (other than certificate path validation). Thus an extension of the WG charter will be proposed to the IESG in order to address time stamping. OCSP Mike Myers provided a status review for this I-D, and responded to comments that have appeared on the WG list over the last few weeks. A number of modifications will be made as a result of these comments Mike described a schedule for revisions and (new) comments to bring OCSP to WG last call in time for the next (LA) IETF meeting. Included in the revisions will be a better characterization of the contexts in which OCSP are expected to operate, since that range of environments has grown since OCSP was initially designed. To better accommodate this diversity, a document structure was proposed that establishes a base OCSP document and syntax and one or more supplementary texts that build upon the base syntax, as noted above.