PKIX WG Meeting July 25, 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 81st IETF. A total of approximately 41 individuals participated in the meeting.

 

 

Document Status Review – Steve Kent (BBN Technologies)

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

-   2 new RFCs published since Prague (6170 & 6277)

-   0 documents in the RFC EditorÕs queue: certificate-image & OCSP agility

-   0 documents in IESG processing

-   7 I-Ds in process in the WG: CMC Updates (WGLC done, awaiting security considerations review, 5280 clarifications, OCSP Update, Transport Protocols for CMP, Internet mail addresses in X.509, S/MIME Capabilities for public keys, CAA

-   1 non-WG document to be discussed: EST (certificate Enrollment over Secure Transport)

(Slides)

 

PKIX WG Documents

 

DNS Certification Authority Authorization (CAA) Resource Record- Phillip Hallam-Baker (Comodo)

The I-D is intended to address the problem that arises due to the potential for an arbitrary CA (among the set of trust anchors embedded in many browsers, and OSes), to issue a certificate for any arbitrary web site. The proposed means of addressing this problem is to augment the DNS RR for a web site with info identifying the CA that has been authorized to issue an X.509 certificate for the web site in question. The current draft does not address issues such as CA accountability, of client (RP) validation of this info. The principle rationale for this added DNS data is to enable the major public CAs to detect when a ÒrogueÓ CA issues a certificate inappropriately.  (PHB says that the major public CA players regularly scan the DNS and would detect such behavior.) There are a number of details still to be worked out, which are noted in the slides.  At the microphone, suggestions were offered for improving the readability of the document, and asking why RPs are explicitly warned to not make use of this record. There is a sense that the document needs to be extensively re-written, to better present the rationale for this work, and explain why web site users (and the public TA set) would be motivated to make use of this technology. There is agreement that DNSSEC is not strictly required for these records, although it would be helpful, e.g., for accountability. (Slides)

 

 

Comments on CAA – Paul Hoffman (VPN Consortium)

PaulÕs slides address two issues in the CAA draft. He wants to see the RP text be removed, period.  His other concern is how a CA is identified in the CAA record. Paul suggests use of free form text (in UTF8) to identify the CA. This is very flexible, and accommodates the various types of IDs that Phillip noted.  This approach is potentially ambiguous, complicates checking by CAs, but does make life easier for DNS administrators/users. Paul explicitly wants to make life easier for the latter class, because it is much, much bigger. At the microphone, comments were against adopting only the free text form of CA ID, worries about use of UTF8, etc. Also, given the extensive use of RAs, under various TAs, there is potential for a lot of confusion and ambiguity that may undermine some of the security guarantees. All of this is viewed as useful input to the next version of the CAA document. (slides)

 

 

Presentations on non-WG Topics (seeking WG adoption)

 

Enrollment Over Secure Transport- Max Pritkin (Cisco)

This document proposes a new, simplified certificate issuance protocol, based on the simple CMC message formats. The protocol relies on messages being carried over TLS to achieve security between the client and a CA (or RA). The current version contains a requirements section that can be moved to a separate document. One of the principle changes in the most recent version of EST is inclusion of a PoP capability. The PoP method adopted here is based on channel-binding derived from the TLS session. This requires access to the TLS layer, to acquire this data. This method requires a CA to rely on an RA to have verified the PoP data, and pass it on to te CA, if the client does not establish a direct TLS connection to the CA. Also, the ÒattestedÓ method of PoP is included here to enable a device to use a manufacturer-issued certificate to be a basis for issuance of another certificate. A straw poll of attendees showed most were in favor of adopting EST as WG item, with no one objecting.  Steve said he would ask for adoption on the PKIX list.

(Slides)

 

CMC Extensions: Server Side Key Generation & Key Escrow– Sean Turner (IECA)

This document is a resurrection of an old draft that Jim wrote long ago. It is intended to support environments where clients are not viewed as having good key generation capabilities (e.g., poor RNG or not enough computational power to do key gen and check in a reasonable time). Also, some environments (e.g., some government and commercial contexts) do want key escrow, which is easy to provide if a CA (or RA) generate a key pair for the client. The WG needs to decide if it wants to adopt this document, given that the previous version died (for lack of interest). There are some other open issues, as discussed on the slides. At the microphone, several folks voiced support for adopting this work. (Slides)