PKIX WG Meeting 3-10-08
Edited by Steve Kent
Co-Chairs: Stephen Kent <kent@bbn.com>
Stefan
Santesson <stefans@microsoft.com>
The PKIX WG met once for 2.5 hours, during the 71st IETF. A
total of approximately 60 individuals participated in the meeting.
Document Status Review - Stefan Santesson (Microsoft)
One document approved
since the last WG meeting (3280bis). Three more (CMC trio) are in IESG review, with one issue now being
resolved. [After the PKIX meeting concluded, but during the IETF 71st
meeting week, all three of these documents were approved by the IESG.] There
are five new WG items, on the agenda for this meeting. (Slides)
PKIX WG Specifications
3279bis
and 4055bis – Sean Turner (IECA)
For 3279bis, there have
been various minor fixes, editorial, etc. over three revs. Tim suggests we
stick with 180-2 as a FIPS reference, not 180-3, since the latter may not be
finalized by the time we are ready to publish as an RFC. For 4055bis, only two
paragraphs were changed to make it consistent with the representation
conventions expressed in 3279bis, plus one typo discovered elsewhere. This typo
will also result in an errata against 4055.
ASN.1 Update Paul
Hoffman (VPNC) and Jim Schaad (Soaring Hawk)
The object construct in
the new ASN.1 helps the compiler but does not affect the bits on the wire. They
also allow for declarations that can be use for validation code, rather than
just putting such info into comments. Jim enumerated a list of the different
algorithm types (used in PKIX and SMIME), which can be used to define a set of
objects, parameterized to represent the different cases. The advantage of
adopting this syntax is to allow one defining syntax in ASN.1 to express more
constraints on data, to enable more automated checking, without changing bits
on the wire. Paul and Jim volunteer to do the re-writes of PKIX (and SMIME)
documents, so that the costs to the WGs is in review of the re-writes. It was
noted that crypto APIs like OpenSSL cannot make direct use of the resulting
syntax unless they are modified to take advantage of this. There is agreement
that there will need to be tests using both commercial and the one open source
complier that can deal with the new ASN.1, to verify bits-on-he-wire
compatibility. (Slides)
Trust Anchor
Management – Carl Wallace (Orion)
Comments on the problem
statement received from Denis and
Steve Kent. These comments covered what the target for management is,
terminology, suggestions for broadening the scope of the data associated with a
TA, plus document organization. With regard to the last topic, there is
agreement to transform he current problem statement into a requirements
document, more appropriate for a WG item, vs. BoF approval. CarlŐs slides
enumerate a long list of requirements distilled from the problem statement
document and subsequent on-list discussion. Carl also compared the TA info data
structure to what is defined in SCVP under validation policy. There are a lot
of overlaps, but TA info contains important data that is essential for the TA management
problem. The only benefit of trying to extend the validation policy data
structure to accommodate the additional data that is needed for TA management,
is that one could group policy for multiple TAs. However, it is not clear that
this case will arise or that it will be common enough to warrant an attempt to
reuse he validation policy data structure.
(Slides)
Trust
Anchor Management – Stefan Satnesson (Microsoft)
Stefan argued that some
systems (e.g., Windows) already use a directory-based approach to TA
management, as part of a larger end system security management mechanism.
Stefan notes that there is an overlap in requirements between the two models
(directory-based and request/response protocol-based), and that the
directory-model does not accommodate some of the protocol-based requirements,
e.g., reports from managed devices. It was observed that the MS implementation
of the directory-based model, is nominally platform specific, most browsers
implement an application-specific model, and this proposal aims to be
manager-centric, as an alternative. It also was argued that the protocol-based
model described by Carl is able to manage transitions after an initial
installation, which a directory-based model is less well suited to do. It was
also argued that both models need a common standardized format for trust anchor
information and thus could be developed separately to support both models.
PKI Resource
Query Protocol (PRQP) - Massimiliano Pala (Dartmouth)
Max presented an overview of PRQP. (A straw
poll conducted in December approved this as a WG item, targeted as an
Experimental RFC.) The primary goal of the protocol 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. Max also described a related application
context, P2P networks, which is a separable topic (not as a PKIX WG item). The
protocol for this context is called PEACH. Max is still looking for feedback
and for folks interested in implementing this protocol. (Slides)
Related Specifications Presentations
Wildcards in DNS
Names – Stefan Santesson (Microsoft)
Stefan observes that use
of wildcards in DNS names in certificates arises, i.e., both in terms of
certificates issued by some major CAs (but not VeriSign) and in platforms
processing them, e.g., Windows. Netscape initiated this, but it has never been
acknowledged in PKIX standards. He suggests that either we publish an
informational RFC to describe this, or to amend 3280bis (after publication as
an RFC) to acknowledge this practice. He notes that DNS names containing a mix
of IDN characters and wildcards are not supported in Windows. It was noted that
other certificate consumer software does not allow wildcards in IDNs.
Tim Polk noted that 2818 allows wildcards, but that not in a way
consistent with what Windows does. PHB suggests an informational document to
help standardize how browsers interpret such names. Pasi notes that 2818 should
address the browser issue, so PKIX does not need to address this problem for
browsers, if 2818 were a standard (but itŐs only informational). Also, TLS is
used in many other environments, and these environments can write standards to
address this issue in their context. Steve Kent argues that the ambiguity
regarding support of IDNs also makes this a questionable hack to standardize,
and that the right way to do this would be to follow the approach the in 3779
for IP addresses.
Other
Certificates Extension – Stephen Farrell (Univ. of Dublin, Trinity
College)
This proposal is to let
a CA bundle a pointer to additional certificates that represent the same
subject. Steve Kent argued that this is dangerous if it caused an RP to accept
this assertion, rather than going through the full certificate validation process again for the certificate
pointed to by this. He also argued that the draft needs to specify what an RP
is supposed to do with this, i.e., not make this just a generic way to point to
a set of additional certificates. Scott Rea raises the question of whether it
is legitimate for one CA to assert equivalence of Subject identity for an
entity whose certificate is issued by a different CA. Stephen would like to see
this as experimental, not standards track. We agree to continue the discussion on the list.
Traceable
Anonymous Certificates Protocol – SangHwan Park (KISA)
This proposal is for a
way to use X.509 certificates to provide traceable anonymity. Traceability here
means that a pair of parties, a split RA/CA model, can cooperate to disclose he
real identity of a user, but neither can do so unilaterally. The two elements
of this model are called the Blind Issuer (BI) and the anonymous Issuer
(AI). A certificate issued under
this model would contain a pseudonym as the Subject name, so that an RP would
not know the userŐs real identity. The critical element for this to work,
cryptographically, is to use a threshold signature scheme, which can be done
for RSA or DSA signatures. (However, there are some details of the current
protocol that seem to be RSA-specific.) Also, there needs to be a way for a CA
to reject certificate requests where the user-selected certificate serial
number or subject name collide with certificates already issued by this CA. The
current draft does not address these issues, nor does it provide details for
how to transport the ASN.1 data structures it defines between the user and the
split CA (AI/BI), e.g., because they do not conform to current certificate
request formats. The target of this work is an Informational RFC. A discussion
on the document will be moved to the list.
PKIX
Considerations for Usable Security – Scott Rea (Dartmouth)
The presentation is an
appeal to get PKI experts from the IETF to provide feedback and direction. The
goal of ScottŐs work is how to make use of PKIs ŇsafeÓ for users, e.g.,
usability aspects of PKI for the average user. Steve Kent notes that it is not
accurate to say that PKIX deals only with Ňbits on the wire,Ó e.g., PKIX RFCs
deal with processing (certificate path validation), and semantics (CP &
CPS). Nonetheless, it is fair to say that PKIs are complex, and not user
friendly.
Clearance
Extension and CA Clearance Constraints – Sean Turner (IECA)
This draft proposes two
extensions: one for expressing clearance (or processing authorization) for an
end entity (a user or a device) and one for imposing constraints on CAs who
issue certificates containing the clearance extension. Several objections were
raised on the list, e.g., putting authorization info in certificates, why not
put this into the SDA, etc. Tim Polk raises concerns about this being too US
Government specific, e.g., as indicated in the enumerated clearance levels. But,
Russ Housley notes that this syntax is taken from other IETF documents, e.g.,
RFC 3281, which came from the X.500 attribute certificate format, which is
international in scope. It is also consistent with the SMIME ESS (RFC 3851).