PKIX WG Meeting 11-20-08

Edited by Steve Kent

Co-Chairs: Stephen Kent <kent@bbn.com>

Stefan Santesson <stefans@microsoft.com>

The PKIX WG met once for 2 hours, during the 73^rd IETF. A total of approximately 47 individuals participated in the meeting.

Document Status Review - Stefan Santesson (Microsoft)

No new RFCs since the prior meeting. Two documents are now with the IESG (ecc-subpubkeyinfo-09 and rfc4055-update-01), and we have 11 I-D’s in progress. (Slides)

PKIX WG Documents

Other Certificates Extension – Stephen Farrell (Univ. of Dublin, Trinity College)

This is a WG item targeted toward experimental status. Stephen Farrell feels this will be ready for WGLC after removing embedded comments. (Slides).

PKI Resource Query Protocol (PRQP) - Massimiliano Pala (Dartmouth)

This is a WG item targeted toward experimental status. Max reviewed editorial changes and new material since the prior IETF meeting. New OIDs were defined, and there is now a discussion of how to provision RQA addresses for clients, e.g., via DHCP or DNS SVR records. (This is being coordinated with DHCP folks, and Paul Hoffman notes that new DNS SRV record uses do not require DNSEXT WG approval.) Max provided a status update on deployment of PRQP in the TACAR (a testbed for distributing CA certificates and CPS’s). He also described possible PRQP/TAM interactions, but it is not clear how closely the PRQP and PKIX TAMP efforts are aligned. (Slides)

RFC 3281 (Attribute Certificate profile) update – Sean Turner (IECA)

This update is needed to incorporate various, verified errata that have been posted over the last few years. The WG chairs agree that the effort should yield 3281bis, not just be a brief document enumerating the changes. There is a sticky problem implied by the fact there are two syntaxes bound to the same OID for clearance info, so this will require a “creative” solution. Sean hopes to be able to progress to WGLC after next version is published. (Slides)

ECC Subject Public Key Information – Sean Turner (IECA)

This I-D was approved by the WG and forwarded to the IESG. Pasi has raised some concerns that Sean is working to resolve. To resolve these comments the implicit curve choice is being deprecated, the hybrid key representation will be removed, and the 2002 ASN.1 will be removed (but will appear in the PKIX new-ASN1 I-D.) A revised version of the document will be posted shortly and be transferred to the IESG, unless WG members object, i.e., we will not conduct a second WGLC unless WG members request it. (Slides)

Traceable Anonymous Certificates Protocol – Stephen Kent (BBN) for SangHwan Park (KISA)

The authors made numerous changes in response to comments from Jim Schaad. No other comments were received. Some additional change will be required, to ensure that there are well-defined ways to transfer the TAC messages over TLS. Steve Kent suggested that this I-D can move to WGLC after these changes are made in the next revision of the I-D. (Slides)

Clearance Attributes and Clearance Constraints – Sean Turner (IECA)

Changes have been made to sections 1,2,4, 5,6, and 7 in response to comments, primarily from Stefan. The remaining major issue is whether the extension should be critical, or optionally critical. Sean provided several examples of how a relying party could process the extensions, depending on whether or not the RP is aware of the specific policies, clearances, and categories represented in these extensions. This document appears to be ready for WGLC. (Slides)

Trust Anchor Management Documents – Carl Wallace (Orion)

As a result of many on and off-list discussions, the documents will be significantly reorganized. The requirements document is being updated to respond to the comments received. (For example, the document will note that the focus of the PKIX effort is push-based TA management, which is a subset of all the ways that one can effect TA management.) The TrustAnchorInfo text will be moved to a separate document (it is now in TAMP), and it will accommodate multiple, alternative TA formats. CMS context constraints will be withdrawn as a PKIX document, and submitted as an individual submission, via the security ADs. The TAMP spec will be simpler and smaller as the CCC and clearance constraints material will be removed. Russ noted that if content constraints are made separate, there appears to be a gap in functionality, as it is necessary to be able to limit the scope of applicability of TAs. Content constraints are one way to do this, the use of multiple TA stores is another way. However, so far, there is insufficient detail on how to associate TAs with TA stores to achieve this alternative way to scope TA use. Also, Stephen Farrell asked that the requirements document move the text from 3.13.1 into the Security Considerations section. There was a debate as to whether PKIX should publish the requirements document as an RFC on the near term, or hold it (after WGLC) to allow for possible revisions if the WG changes it mind during the course of developing the TAM documents. (Slides)

Related Specifications Presentations

OCSP Algorithm Agility - Phillip Hallam-Baker (Verisign)

The WG chairs agreed to conduct a straw poll on the PKIX list to decide if this will become a WG item, after Phil sent a message to the WG chairs declaring what status (standards track, experimental, or informational) he sought for the work. This fell through the cracks. Phil’s presentation described the need to define how an OCSP responder chooses which signature algorithm to employ, in a multi-algorithm context. Phil proposes to issue a standards track I-D describing what the behavior of a responder should be in non-trivial cases. If the WG wants, the base OCSP spec can later be updated to incorporate the changes documented from this I-D. (slides)

RFC 3161 (Time-Stamp Protocol) Update Steve Kent (BBN) for Denis Pinkas (Bull SAS)

Denis proposes to update RFC 3161 to provide for signature and hash algorithm agility, in a fashion requested by the ETSI TC ESC (electronic signature committee). Also, consistent with RFC 3628, 3161 should distinguish between the authority offering the time stamp authority and the time stamping unit (hardware) used by that organizational entity, as well as between the time stamp service being offered and the authority offering that service. Denis plans to update the ASN.1 module to reference the latest, appropriate RFCs, and to add another patent reference. Finally, Denis plans to add several informative references to ISO time stamping standards. Denis seeks permission to make this update a WG item. Several folks objected to inclusion of any patent info in the document, and noted that a reference to the IETF IP web page is the right approach here. (Moreover, it was agreed that the eight patent references from 3161 should be removed during this re-write.) There was agreement that production of 3161bis should include an invitation to all of the editors of 3161 to participate, if they are available to do so. Also, definitions from RFC 3628 should be included in this document, not just cited, because 3628 is informational. The same applies to any definitions from ETSI documents that are used in a normative fashion. (Slides)