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 73rd 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)