PKIX WG Meeting 7/9/06

Edited by Steve Kent

Chairs: Stephen Kent <kent@bbn.com> & Stefan Santesson <stefans@microsoft.com>

The PKIX WG met twice, for a total of two hours, during the 66th IETF. The second hour was a joint meeting with the SIDR WG. A total of approximately 55 individuals participated in the meeting.

Document status – Stefan Santesson (Microsoft)

RFCs just issued: RFC 4476 AC Policies Extension, RFC 4491 GOST Cryptographic Algorithms

Documents in the RFC editor’s queue: Update to DirectoryString Processing in 3280 (UTF-8)

Documents with the IESG: SIM, SCVP, Lightweight OCSP

Completed WG Last Call: 3280bis, CMC drafts, Service names

Other WG documents in process: ECC Algorithm IDs, ECDSSA and DSA use with SHA-2 family of hash algorithms

(Slides)

PKIX WG Document Presentations

SIM – Tim Polk (NIST)

Resolving comments from an IESG member, before receiving IESG approval. Hope to be resolved by the end of this week. (no slides)

Algorithms IDs for DSA, ECDSA and SHA-2 - Tim Polk (NIST)

A new draft, but using some content from a FIPS in progress (186-3) as well as other PKIX I-Ds. A noteworthy change here is the requirement for CAs to always explicitly specify the hash algorithm with which an ECDSA signature is employed, but allows RPs to accept certificates that do not specify the hash algorithm in this way. (no slides)

OCSP Algorithm Agility – Stefan Santesson (Microsoft)

The PKIX WG chairs have been informed by our cognizant AD (Russ Housley), that the OCSP RFC must be modified to say how to deal with hash algorithm agility, prior to advancement. We need to be able to allow a client to determine which signature algorithms are supported by a server, e.g., via a query/response protocol, or via some alternative means that yields the same results. For example, an OCSP server certificate might indicate its capabilities via the same sort of mechanism that is used for signaling S/MIME user capabilities. Paul Hoffman suggests that we try to pick a solution that is more generally applicable, not just a solution for OCSP. Jim Schaad also observes that the same sort of info for CMC, for clients to learn of CA algorithm capabilities. The chairs solicited a volunteer to lead an effort to address this problem in either the OCSP-specific case or the more general case, but nobody volunteered. (slides)

SCVP - David Cooper (NIST)

David reviewed the minor, editorial changes and clarifications in the document since rev 23. (slides)

3280bis - David Cooper (NIST)

David reviewed changes since rev 2. Most of these are also editorial, but several deal with non-trivial technical issues. For example, there is new text dealing with encoding details in support of name comparisons for name constraints and a warning against usage of https as an access method in CRDDP or AIA/SIA, to avoid the possibility of circular dependencies. Remaining open issues from the last call include

- a question about when a CA MUST NOT impose name constraints

- to what extent should we warn clients re possible circular dependencies in validation, e.g., in revocation status checking

- should we include text about client being “allowed” to skip checks in the validation algorithm, to accommodate non-conforming PKIs!

The WG chairs agree to resolve the first issue on the list via a straw poll. We have been advised by our AD that the second issue should be addressed in a separate document, to avoid delaying 3280bis, so that issue will not be addressed in this rev of the document. Finally, several WG members, and the chairs, agree that an implementation is compliant if it can be configured to support 3280bis exactly, but that does not preclude an implementation from also offering controls that would allow it to operate in a non-compliant fashion as well. (slides)

Algorithms for IDs for Elliptic Curve Cryptography in PKIX – Daniel Brown (Certicom)

This document specifies algorithm IDs for ECC algorithms. It adopts a convention for expressing the notion of with which algorithm the key may be used, by expressing this via the parameters field of subject public key info. This is how the cognizant ANSI standard expresses this info, but it is not consistent with how PKIX has expressed this sort of info in the past.

Related Specifications and Liaison

AIA extension use in Attribute Certificates – David Chadwick (University of Kent)

The AIA extension has been defined by PKIX for PKCs. This proposal asks to redefine the extension to allow the same extension and same OID to be used for ACs as well. They can define a new access method, under the same extension, to avoid any conflict. This should not be construed as endorsement of AC chains, which PKIX otherwise deprecates. (slides)

A PKI for Internet Address Space – Steve Kent (BBN)

This presentation was made jointly for SIDR and PKIX WG members. It began with a review of the motivation for creating a PKI to reflect the allocation of IP address space and AS numbers to the holders of these resources. There was an overview of PKI terminology and a discussion of the certificate extensions proposed for use in the certificate profile for the PKI. The structure of the PKI was illustrated, including how resource holders with allocations from multiple sources require multiple certificates to reflect such allocations. The route origination authorization data structure was described, along with a list of open issue to be resolved before concrete syntax can be defined. The presentation briefly described the proposed repository design, based on rsync. Example scenarios were described for resource requests from a registry or ISP, transition from single homing to multi-homing, etc. A lively discussion followed the presentation, and continued long past the scheduled agenda time. Questions addressed topics such as the ability of relying parties to configure trust anchors locally, how to accommodate ISP subscribers who move and want to take the addresses assigned by their (old) ISP, and other operational topics. (slides)