PKIX WG Meeting 12-03-07

 

Edited by Steve Kent

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

 

The PKIX WG met once for two hours, during the 70th IETF. A total of approximately 100 individuals participated in the meeting.

 

 

Document Status Review - Stefan Santesson (Microsoft)

     SCVP has been approved and will be published very soon an as RFC (in AUTH48 now). 3280bis is in IETF last call, and will require a few minor modifications. The three CMC documents also are in IETF last call. Tim Polk has requested that the PKIX WG re-affirm that it is still comfortable with these revised documents, and a WG last call is in progress on that. ECDSA is still in process in the WG, as is the ECC algorithm   representation I-D. We expect both to progress early next year, if the WG adopts the design team recommendations presented later. (Slides)

 

 

PKIX WG Specifications

 

3280bis - David Cooper (NIST)

The only major task now is to revise the definition of URIs as alternative names, and how the Name Constraints extension applies to URIs that appear in alternative names, when there is no authority component in the URI. There is proposed text for a fix, which is likely to be adopted as a response to this IETF last call comments, after the WG has a chance to review and comment on the text. (no slides)

 

CMC Status – Jim Schaad (Soaring Hawk)

     There were numerous revisions to make these documents more readable and to make the terminology consistent. Hash algorithm agility has been added for Identity Proof and for an RA to act as a proof of possession witness. See the three revised I-Ds just published for more details. (Slides)

 

Subject public key info resolution for ECC - Tim Polk (NIST)

 The design team has been addressing the question of how to represent algorithm info for ECCs, not just curve info but also ways to restrict use of the key, e.g., for Elliptic Curve Diffie-Hellman vs. ECMQV. The proposal (second pass) is to be able to express only a very basic constraint, i.e., whether a key is to be restricted to ONLY Elliptic Curve Diffie-Hellman or ONLY ECMQV. Thus, the existing ecPublicKey OID will be interpreted as allowing the pubic key to be used with either of these algorithms, and two new OIDs will be assigned to represent these other two cases. This is consistent with the RSA-context solution adopted in RFC 4055. It is also compliant with a subset of the X9.62 standards. Also, a suggested change to RFC 4055, to say that KDF restrictions MUST NOT (vs. SHOULD NOT) appear in certificates, i.e., these restrictions are the provenance of applications. The outcome is that the design team will submit a new I-D that will update 3279 and obsolete 4055, but will not adversely affect extant implementations, based on the data gathered by the team. Steve Kent will formally ask the WG to confirm that there is no objection to adopting this as a PKIX work item. (Slides)

 

OCSP Algorithm agility - Phillip Hallam-Baker (Verisign)

     OCSP needs a way to address the general hash algorithm agility requirement that has been imposed on all IETF security protocols. The protocol spec is ambiguous in this regard, both for hash and public key algorithm use. One might assume that an OCSP client should be able to verify a signature using the same algorithm (pair) that was used in the certificate being checked. However, even this ÒobviousÓ rule may be problematic, since there are realistic (relay) scenarios that might violate this rule. PhilÕs proposal is to define a very simple, optional extension to OCSP to allow negotiation of the hash algorithm. It is incumbent on PKIX to address this problem. A straw poll conducted during the meeting showed strong support, and no objections, to initiating a work item based on PhilÕs proposal. The WG lsit will be queried to verify this. (Slides)

 

 

Related Specifications Presentations

 

ITU Liaison Statements - Stefan Santesson (Microsoft)

     Two liaison issues: removing the upper bound on X.520 attributes that are used in DNs (hence in Subject and Issuer Names), and the DR320 statement that noted that DNs may not be unique. The first issue arises because extant PKIX specs all incorporate the original upper bounds, but the LDAP WG is supportive of removing these upper bounds. If we retain the upper bounds we may be have interoperability problems with LDAP, but if we change to the new, unbounded interpretations of these strings, we not only need to change documents, but we also may introduce vulnerabilities re bounds checking in a lot of code. All of the speakers at the mic thought this would be a bad idea, and a straw poll confirmed the sense of the room in this regard. We need to get LDAP folks to explain why they are supportive of this, and we need to send a response to the ITU-T expressing our opinion. The second issue is easier, i.e., we will respond that PKIX agrees that the DR 320 comments cited in the liaison message are accurate, and that the IETF has no plans to create a clearing house for CA names, nor to create standards that will recommend checks for CA name uniqueness. (Slides)

 

Trust Anchor Management – Raksha Reddy (DoD) and Carl Wallace (Orion)

     This presentation began by describing the prior work in a problem  statement for trust anchor management, that preceded and followed the BoF on this topic at IETF 69. There is no IETF standard for TA management, despite the fact that all PKI-based protocols use TAs. A solution would define a protocol for remote management of TAs (after initial, out-of-band installation), supporting add/remove and status query re TA store status. The protocol should support both online and staged delivery transport. There is also a need for a privilege management capability to constrain the operations performed by the entities represented by TAs. A specific trust anchor management protocol (TAMP)  proposal was described. It is ASN.1-based and uses CMS to wrap TAMP payloads, offering both signature and encryption functions, as needed. TAMP defines three types of TAs, and a privilege management capability (based on CMS content IDs). It also includes five request/response message pair types, plus an error message type. There is also an authorization mechanism based on content type markings in CMS (signed) objects, and an extension for certificates. It was not clear whether this mechanism is needed to support hierarchic, multi-TA contexts, or whether the mechanism is needed primarily for the signed code management feature that is part of the TAMP model. The question for PKIX is whether the WG should adopt this as a new work item. There were only two objections to such adoption; both agreed that the work should be pursued, but would prefer a new WG for that purpose. Tim Polk indicated that his analysis of the BoF and subsequent list discussion did not convince him that there was sufficient interest to warrant creating a new WG. A straw poll will be taken on the list to determine if PKIX will adopt this as a standards track work item. (Slides)

 

ASN.1 Update Paul Hoffman (VPNC) and Jim Schaad (Soaring Hawk)

Move to 1998/2002 ASN.1 (from 1988 ASN.1) removes support for ANY. Need to revise extant specs, even though no bits on he wire should change. However, Tobias Gondrom said that LTANS WG had a problem keeping bits-on-the-wire the same between versions when they made this change. Two I-Ds providing revised ASN.1 specs for PKIX and CMS modules are being submitted. These can be pursued as WG items in PKIX or S/MIME, OR can be individual submissions. In either case, review from PKIX WG members is solicited. (Slides)

 

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

     Max presented this proposal at the previous PKIX WG meeting, but several changes have been made since then. The intent is to enable a client to learn about new PKI services, or changes to hosting of services, in open PKI contexts. The proposed mechanism adds a level of indirection to the current AIA mechanism. This allows a CA to make new services available, or to change the access points (URLs) for existing services, without having to issue new certificates to users. A new extension is defined to hold a URL that is a pointer to a server that provides the URL for all the services offered by the CA that issued the certificate. A straw poll will be conducted on the list to determine if PKIX should adopt this as a new work item, targeted to become an Experimental RFC. The candidate I-D is draft-pala-prqp-01.txt (Slides)