Subject: [pkix] minutes, old style

From: Stephen Kent <[email-masked]>
Date: Mon, 25 Jul 2011 17:29:34 -0400

PKIX WG Meeting July 25, 2011

Edited by Steve Kent
Co-Chairs: Stephen Kent <[email-masked]>
  Stefan Santesson <[email-masked]>

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)