PKIX WG Meeting 7-29-09

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

Document Status Review - Stefan Santesson (AAA-sec)

There has been significant progress in document status since the previous meeting. TAC (Experimental), RSAES-OAEP (4055bis), and Attribute Certificate Profile (3281bis) are in the RFC Editor’s queue.

(4055bis and is waiting for 3281bis before publication). The Other Certificates I-D has been approved by the IESG. Authority Clearance Constraints is entering IETF last call. The Trust Anchor Format document is slated for the August 13 telechat. New ASN.1 has just completed WG last call and is being forwarded to the IESG very soon. About seven other document are being worked on in the WG, at various levels of maturity. (Slides)

PKIX WG Documents

Trust Anchor Management Documents – Carl Wallace (Orion)

The documents in question are draft-ietf-pkix-ta-mgmt-reqs-03.txt, draft-ietf-pkix-tamp-02.txt, draft-ietf-pkix-ta-format-03.txt. Trust anchor format is in IETF last call, may have one additional technical change made as a result of IETF last call. TAMP is being revised to make a couple of technical changes. Software is being developed to support TAF, TAMP, CCC, and UTAC and will probably be released under GPL in a few months. Hoping to initiate WGLC in a few weeks, and re-submit the TAMP requirements document (Informational) for WGLC at the same time. (Slides)

OCSP Algorithm Agility - Stefan Santesson (AAA-sec)

Phil will not be able to devote adequate time to this effort (due to his employment status change) so Stefan is taking over as editor of the document (draft-ietf-pkix-ocspagility-00). An extension will be added to OCSP to enable a client to specify a sequence of algorithms in order of preference. An algorithm defining how to chose the appropriate algorithm to use to sign an OCSP response will also part of the revised OCSP spec. We may be ready for WGLC soon, but we are waiting to hear from Phil, who may have some other additions. (Slides)

Time-Stamp Protocol (RFC 3161) Update Stefan Santesson (AAA-sec)

There is a need to update this RFC to accommodate version 2 Extended Security Services (RFC 5035). The update is needed to allow use of hash functions other than SHA-1 as a pointer to the right TSA certificate to use. This is consistent with IETF mandates for algorithm agility and is needed to maintain compatibility with current ETSI efforts. Denis Pinkas proposed a very extensive set of changes to the terminology in 3161, to better align with the his Informational RFC (3628) which introduced more precise terminology in the context of time stamping policies. Based on the extensive discussion of this topic on the list in March, and some discussions on how to proceed in July, Steve Kent has determined that there is not WG consensus to make the more extensive changes proposed by Denis. Instead, if Denis wishes, he can revised 3628 to provide a mapping of the new terminology to 3161(bis). (Slides)

Visual Certificate-based eID - Stefan Santesson (AAA-sec)

This is a new work item, represented by draft-ietf-pkix-certimage-00. The intent is to allow a certificate to convey an image with a certificate, to improve the ability of a (human) user to make value judgment with respect to certificate acceptance. The technical approach proposed is to define new image formats that can be used with RFC 3709, to convey the image. Candidates include PDF/A, SVG Tiny, and PNG. A open issue is whether to allow optional inclusion of the image in a certificate, which is not consistent with 3709, but which would be desirable for offline validation.

(Slides)

Algorithms and Identifiers for DSA & ECDSA – Tim Polk (NIST)

A new version (07) is ready, but was not ready in time to be posted before this IETF. This version also needs to have some boilerplate updated before it can be posted, a problem that should be remedied very soon. (no slides)

Related Specifications Presentations

Certificate Information Expression in the EU - Stefan Santesson (AAA-sec)

There is an EU directive mandating an open flow of information and electronic services. However, the use of vastly different ways to express identity in different countries runs counter to this directive. Federated identity management systems are the current means of addressing this problem, and SAML is the technical basis for much of this infrastructure. This approach does not translate to signature verification, which may often take place when the user is not present. Also, there is not the complex authorization determination that is usually a part of what SAML was design to support. In the context of certificates, there is a lack of uniform semantics for many attributes that are commonly employed, e.g., Organization, Country, and SerialNumber. One way to help with this problem is to associate metadata with certificates to allow expression of the semantics. This might be effected via extensions to certificates, or by (signed) data posted to a directory system by certificate issuers, etc. The Information Card Foundation “claims catalog” may provide a starting point for this sort of metadata. ETSI has approved a standards task to enhance identity information expression in certificates, so the question before PKIX is whether

(Slides)

Relying Party Management of Trust Anchors for the RPKI (and PKIs in general) – Stephen Kent (BBN Technologies)

Steve Kent described the need to allow a relying party (RP) to locally control the adoption of CAs as trust anchors. This need arises in PKIs in general, but it is especially critical in the RPKI context (see SIDR WG documents). The mechanism Steve described allows an RP to transform certificates put forth by putative CAs, making them subordinate certificates under the RP acting as the ONLY TA for his context. The transformations can all be performed unilaterally by the RP. This approach allows an RP to directly certify CAs (and associated attributes) when the RP has external knowledge of the attribute bindings. In the RPKI, the relevant attributes are RFC 3779 extensions, but in PKIs in general the attributes could be name constraints, policies, etc. Steve will be briefing this proposal in the SIDR WG on Thursday. (Slides)