PKIX WG Meeting March 22, 2010

Edited by Steve Kent

Co-Chairs: Stephen Kent <kent@bbn.com>

Stefan Santesson <stefans@aaa-sec.com>

The PKIX WG met once, for 2 hours, during the 77th IETF. A total of approximately 53 individuals participated in the meeting.

Document Status Review - Stefan Santesson (3xA Security)

There has been significant progress in document status since the previous meeting.

- 3 RFCs published since Hiroshima: 5755, 5756, & 5758

- 4 document in the RFC Editor’s queue: ESSCertIDv2 update for RFC 3161, MIME Media Type for attribute certificate, new ASN.1 modules for PKIX, and Trust Anchor Format

- 3 documents in IESG processing: OCSP algorithm agility, TAMP, and clearance attribute and authority clearance constraints

- 4 I-Ds in process in the WG: certificate image, TAMP requirements, PRQP, and ASN.1 translation

- 2 non-WG document under consideration: Certificate ID and Key ID, Transport protocols for CMP

(Slides)

PKIX WG Documents

Trust Anchor Management Requirements – Carl Wallace (Orion)

Carl provided a status update on the suite of TAMP documents. The format document is blocked, waiting on the new ASN.1 doc to be approved. Carl reminded the PKIX chairs that the TAM requirements document should be published as informational, now that TAMP has been approved. There are two related, independent IDs related to using TAMP, which are seeking informational status. (Slides)

ASN.1 Translation - Carl Wallace (Orion)

This document has been forwarded to Tim.

Certificate Image - Stefan Santesson (3xA Security)

This document completed WGLC a week ago. Several changes were made in response to comments received during the previous WGLC, and one additional revision of the document is in the I-D publication queue. In this revision, changes were made to the Security Considerations section, to address privacy concerns that were raised on during WGLC. Steve Kent will announce his decision regarding the outcome of the WGLC after the IETF meeting. (Slides)

RFC 5280 Implementation Report – David Cooper (NIST)

David reviewed the implementation test results that Tim presented as the previous meeting. The plan is to publish a 5280bis to address the two issues that were identified last time.

The encoding rules for the explicitText field of the userNotice policy qualifier need to be revised to “redeem” VisibleString (make it a MAY), and deprecate IA5String for a userNotice in a policy qualifier. We will conduct a straw poll on the list to decide whether to make BMPString a MAY here (a co-equal alternative), to accommodate what appears to be common Microsoft CA practice, or leave it as a deprecated alternative. Note that support for UTF8String is the SHOULD here, but no support was found for that capability. David’s report suggests relegating it to MAY status. Tim said that we could probably get an exception for progressing the document despite the lack of support for internationalized names. Paul Hoffman suggested that we check with CAs in Japan that would serve as an example of support for this function. He also offered to generate certificates based on example.com (where the first e in example has an accent). David also identified a lack of support for the string prep processing of internationalized names, especially for domains names in domain component attributes in DNs. Although this has not yet proved to be a significant operational problem, it is an example of a MUST for which we have filed to find implementation support. Stefan Santesson raised the question whether the internationalization could be moved to an informative annex since the fields that contain internationalized characters are opaque with respect to the certificate syntax. This will be investigated. (Slides)

Related Specifications Presentations

Suite B Profile for CMC (Sean Turner – IECA)

This is an informational document, not in PKIX, intended to help complete the set of Suite B crypto RFCs. He is looking to add several additional features that represent changes in how CMC works, e.g., being able to request a certificate where the subject name in the request does not match the name in the certificate associated with the signature on the request. (Slides)

Making X.509 Certificate Revocation more Robust Magnus Nystrom (Microsoft)

The concern Magnus has raised is whether weaknesses in hash functions used in signing certificates should be addressed by defining additional mechanisms for OCSP and for CRLs. For example, an adversary that can exploit hash collisions might issue a certificate with a serial number that conflicts with a valid certificate, so that the CA cannot revoke the invalid certificate without also revoking a valid certificate. Or the adversary might generate a certificate with CRLDP that points to a bad location (where no CRL will be found, or at least a CRL without the rogue certificate’s serial number). He suggested one might add a new extension to a CA certificate to allow it to make an assertions about where to acquire revocation status info for certificates below it, rather than having such info included in the certificates themselves (as is the case for AIA and CRDDP). This is a significant change to the standard PKI model, and ought not be considered lightly, it requires changes to the path validation algorithm. The presentation evoked some comments at the microphone. Magnus noted that this is not a well-formed, complete proposal at this stage. Paul Hoffman raised the question of whether it might not be better to address weak hash functions via other means that are more fundamental, e.g., adding a random # to a signature. Magnus feels that there is a more fundamental issue here re relying on data in a certificate (e.g., CDP) before the certificate is validated. Magnus suggests putting a certificate hash instead of a serial number in CRLs, but this would typically make CRLs bigger unless the hash value is truncated.

Server Identity Checking for TLS – Peter Saint-Andre (Cisco)

A document has been written in the APP area that describes how to verify the identity asserted by a server against the Subject name (or Subject alt name) contained in a certificate offered by the server. The goal is to make such identity checks uniform across a wide range of applications that make use of TLS for security in a client/server model. Note that there are lots of types of identities that may be asserted, e.g., DNS name, IP address, URL/URI, etc. One needs different rules for different name types and applications, and this document provides such rules. This presentation was made to PKIX for informational purposes, and to solicit feedback from PKI experts. Russ Housley suggests that the authors solicit comments from PKIX, TLS, SAAG, and various application WGs. Then submit the document as an individual BCP. (Slides)

Certificate ID Key ID - Sean Leonard (Penango)

This document was inadvertently approved (by Steve) as a WG item; it is not. Sean’s goal is to document one way to refer to another certificate or key. He recognizes that there are various extant ways to do this, e.g., ESSCertID, Certificate ID in OCSP, SCVPCertID. He would like just one, e.g., in new protocols, provided as guidance to authors. Separately, Sean addressed the question of why he wants to define a preferred reference to keys. Russ likes the suggestion of encouraging wider use of ESSCertIDv2 for certificate identification. Stephen Farrell asked why there is a need for public key identifiers, since Sean’s presentation did not provide one. Sean admitted that he did not have one at this time. Russ suggested that having one, preferred way to point to certificates was a good goal for PKIX, and that ESSCertIDv2 was the obvious candidate. There was general agreement on this point. Sean indicated that this would satisfy his goal of having one such method preferred. There was no support for changing the name of the existing data structure. It is not clear if PKIX needs to issue a very, very brief document codifying this decision.

Proxy Architecture on DRM Service – Zhipeng Zhou (Huawei)

This presentation discussed the possible need for an architecture for authorization in the context of a proxy. Digital rights management (DRM), in a context that makes use of certificates and CRLs, has been the primary, motivating example, but Zhipeng feels that the scenario he presented is generic. It was noted that attribute certificates are the extant, standard way to achieve authorization delegation, in the general case, so why is a different solution needed? Also, if one uses attribute certificates, there are various, application-specific ways to communicate them, which raises questions about whether there is a need for a standard protocol for conveyance of ACs. (Slides)