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)