PKIX WG Meeting 11/20/02 Edited by Steve Kent Chairs: Stephen Kent , Tim Polk The PKIX WG met once during the 55rd IETF. A total of approximately 97 individuals participated in the meeting. Tim Polk began with a review of the agenda and document status. [see slides] Logotypes in X.509 Certificates - Stefan Santesson (AddTrust) Add specifications to require at least one logotype that fits within specified size ranges, and if audio files are present at least one should be within a specified time duration. Straw poll of attendees supports guidelines for these features, vs. compliance requirements relative to certificate contents. Will confirm this consensus via the list. Another observation is that these may be guidelines for certificate contents, but we ought to impose conformance requirements on the clients that consume certificates, to ensure that they can display logotypes (and play audio files) within some bounds. A suggestion was made that clients should be required to allow users to suppress playing audio files and suppress fetching the files that might be referenced by URIs in this extension, and the authors agreed to incorporate this requirement. [see slides] Discussion of competing protocols to become the standard protocol for DPD/DPV. CVP- Tim Polk (NIST) presenting for Denis Pinkas (Bull) Basically, this protocol is designed to be able to do more than meet the requirements defined in 3279, but Denis (as the author of that RFC) asserts that CVP is complaint with the requirements RFC. The slides compare CVP features with SCVP features. [see slides] SCVP Protocol - Russ Housely (Vigil Security) Now on draft 10, which has been discussed extensively on the list. Presentation addressed open issues raised in on-list discussion. [see slides] OCSP Mike Myers (TraceRoute Security) No slides. Strategy here is to use extension facility to support DPV/DPD requirements, building on OCSP. The document will be refreshed and reposted with the description of extensions to provide this support. DCVS is the fourth candidate. It is RFC 3029, an experimental track RFC. It is designed to provide a wide range of services, including those that we now characterize as DPV/DPD. Proxy Certificates Von Welch (Argonne Labs) Document is also being worked on in Global Grid Forum. The biggest residual problem is that the path validation algorithm rejects these certificates since the end users are not CAs. One suggestion is to validate the path up to but not including the proxy certificate, then invoke path validation only for the proxy certificate, with a temporary trust anchor based on the user certificate that acted as the issuer of the proxy certificate. This would be consistent with the RFC 3280 path validation process, and might be consistent with the need for the application to perform the additional checks specified for a proxy certificate. A possible concern is that one needs to ensure that the trust anchor inserted for this process is not retained and thus might inappropriately affect later path validation invocations. Audience comments support the principle of not modifying the RFC 3280 algorithm, though with varying rationales. The TLS WG chair suggests that this really should be done in the TLS context, i.e., using the IETF standard. [see slides] LDAP Schema - Peter Gietz (DASSI International) LDAP lacks matching rules support to allow selection of certificates and CRLs based on specifying values for fields in these data items (when multiple certificates or CRLs are stored in the same LDAP entry). This approach is a metadata solution; it extracts the data from certificates and CRLs and replicates the data as a set of new attributes in the LDAP database, making them suitable as search parameters. Clients need to be configured with the new schema, to allow searching based on this approach. This is a personal draft; the question is whether it belongs in PKIX? A cited concern here is that this schema approach We will take up the question on the list. [see slides] Attribute Certificate Chris Francis (WebSecure Technologies) A new extension for attribute certificates that explicitly states the policies employed on issuing the certificate, analogous to the certificatePolices extension in public key certificates, and uses similar syntax. Has policy qualifiers to allow an AA to specify that attributes were verified at a time that might be significantly earlier than the issuance date, implying that the attributes were not re-verified at the time of reissuance. (WS chair note: Is this a thing we wish to encourage by providing syntax for it?) Certificate Warranty Extension - Alice Sturgeon (Spyrus) This extension provides explicit data about warranties provided by the CA, including an explicit declaration of no warranty. It's a non-critical extension. This is important, because it allows one to include warranty info that can be ignored, while also putting in critical policy info. This combination of critical and non-critical "policy" info could not otherwise be accommodated. A revised ID will be posted soon. [see slides] OCSPv2 - Mike Myers (TraceRoute Security) Update of v1 document to add additional means of referring to a certificate and offers a means by which a client can provide a pointer to a CRL to check. Subject Identification Method - Park Jong-Wook - (Korean Information Security Agency) Goal is to provide a way to represent a personal ID value (e.g., national ID number) in a certificate in a way that does not disclose its value, for privacy reasons. The proposal also includes a protocol for transferring this data to the CA. The proposed virtual ID (VID), is computed by double hashing the personal ID value with a 160-bit random number (R), and symmetrically encrypting the result, using R as a key. Looking for feedback. [see slides] JNSA Challenge PKI 2002 -- An Approach to a Multi-Domain PKI Test Suite" - Ryu Inada (Japan Network Security Association) This is a report on the interoperability testing activities in Japan, in September. This is not a PKIX activity but the results of testing are of interest, e.g., in terms of uncovering interop/specification problems with PKIX standards. Test environment includes CAs and VAs capable of generating data for test cases, some of which intentionally do not conform to PKIX standards. We are awaiting an English translation of the underlying documents. [see slides]