PKIX WG Meeting March 28, 2011

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 80th IETF. A total of approximately 47 individuals participated in the meeting.

Document Status Review - Stefan Santesson (3xA Security)

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

- 0 new RFCs published since Beijing

- 2 documents in the RFC Editor’s queue: certificate-image & OCSP agility

- 0 documents in IESG processing

- 5 I-Ds in process in the WG: CMC Updates, 5280 clarifications, OCSP Update, Transport Protoclls for CMP, Internet mail addresses in X.509, S/MIME Capabilities for public keys

- 1 non-WG document to be discussed: future PKIX certificate enrollment protocols

(Slides)

PKIX WG Documents

S/MIME Capabilities for Public Key Definitions - Jim Schaad (Soaring Hawk Consulting)

The same data structure is used for several RSA variants, another one for ECC, another one for DSA and DH, and yet one more for RSASSA-PSS signature. Jim thinks that this document is ready for WGLC. The question is whether the OCSP algorithm agility document, which is in the RFC editor queue, ought to be changed to use the S/MIME capability data structures instead of the Algorithm ID data structure. Options are to issue an update later, pull the document back and process again, or leave it as is. Note there is no on-the-wire change for anything by but the RSASSA-PSS case. Stefan like Algorithm ID, as it is used everywhere else in PKIX data structures, but recognizes the added flexibility of the S/MIME capability. Jim also notes that there is a subtle difference between the S/MIME structure, (which expresses a capability), vs. the Algorithm ID (which says what is carried in a structure). Tim Polk suggested that we could change this w/o starting over, if the WG wants. The chairs agree to execute a one-week WGLC on this change and let Sean know how the WG wants to proceed. (Slides)

Updates to OCSP Agility – Stefan Santesson (3xA Security)

There were a few minor changes in response to IESG comments, in the security considerations sections and a minor change to the ASN.1 syntax, to add the S/MIME capability syntax as an optional, second element. (Slides)

Internationalized Email Addresses in X.509 Certificates – Alexey Melnikov

The EAI WG (application area) is completing a revision RFC 5335bis and RFC 5336bis. These changes will allow UTF-8 characters on both sides of the “@” in an e-mail address. RFC 5280 defines an RFC822 address as an SAN, but does not define addresses relative to UTF-8 encoding. There is also a desire to support multiple aliases for both sides of the e-mail address (user name and domain name). This could result in a very big certificate, if the cross product of both sets of aliases have to be represented individually in a certificate. So, there are two issues: updating 5280 to support IDNA2008 in DNS and e-mail SANs, and how to accommodate aliases in e-mail SANs (in a space-efficient fashion). Win the past we have had a lack of widespread vendor support for UTF-8 in certificates. Most recently it appeared that few RPs supported the matching rules that 5280 defines, in lieu of the simple, binary matching rules that were defined in 3280. This may argue for a return to the older, simple rules, if we want to support UTF-8 in these two SANs Paul argued that the alias issue is a red herring, since we may already have this problem, .e.g., foo.com and foo.net. So, we can bring to the list the topic of an update to 5280 that makes UTF-8 support a SHOULD in DNS and e-mail address SANs, and to revert to the simpler matching rules. (Slides)

Certificate Management over CMS (CMC) Updates - Jim Schaad (Soaring Hawk Consulting)

The document is blocked, awaiting a reference to a document written by Sean Turner. Unless something surprising arises in Sean’s document, Jim’s document is ready to go. (no slides)

Presentations on non-WG Topics (seeking WG adoption)

The European standardization mandate and activities in ETSI - Stefan Santesson (3xA Security)

Stefan provided a brief overview of activities in ETSI related to digital signatures, motivated by a new EC mandate (M460). Two of these activities are relevant to PKIX: fixes to qualified certificates and a profile for certificates issued to people. The fixes being pursued include: associating semantics with name data types, indicating the security afforded to a private key (corresponding to a public key in a certificate), and policy expressions relative to a qualified certificate. Sean noted that the second issue usually be addressed via policy OIDs. Stefan agreed that he would work to avoid creating a new extension (for example) to deal with this issue. Stefan believes that the last issue might affect PKIX, because of CAs making errors in certificate policy inclusion in intermediate CA certificates vs. EE certificates. (Slides)

The Future of PKIX Certificate Enrollment Protocols– Joe Salowey for Max Pritkin (Cisco)

This is an initial discussion on the topic of pursuing development of a new, lightweight certificate enrollment protocol, as an alternative to the full-featured certificate management protocols that are extant PKIX standards (CMC and CMP). A fundamental observation is that the extant PKIX standards are transport independent. This makes evaluation of the security of the protocols easier, because one does not have to rely on the security of an underlying transport protocol. This proposal (EST) calls for implementing a subset of CMC, and relying on a secure transport, i.e., TLS/HTTPS. Goals for EST would be support for enrollment and re-key, and algorithm agility, e.g., ECC support. Tim Polk asked whether revocation ought to be include as well? Paul Hoffman suggests that we try to avoid function creep in order to make progress initially. Sean would like to move CMC and CMP to historic, but Steve Kent notes that we need to offer sufficient functionality in EST before we retire the other protocols, and we have to keep the 3GPP folks (who use CMPv2). PHB expressed skepticism that this effort would yield a simpler protocol that will be more widely deployed. Stefan noted the need to employ some form of channel binding mechanism, to avoid MITM attacks against a TLS session. Several folks noted the importance of making the target audience clearly defined. Steve Kent observed that TLS/HTTPS are actually very poorly specified in IETF standards, relative to PKI details. Thus we need to be careful that we do not inherit any ambiguities or vulnerabilities of TLS/HTTPS. (Slides)