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)