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 hours, during the 72nd IETF. A
total of approximately 65 individuals participated in the
meeting.
Document Status Review - Stefan Santesson
(Microsoft)
Four PKIX RFCs have
been published (5280, 5272-74) since the March meeting, and there are eight
documents in process. Half of these are standards track, two informational, and
two experimental.
(Slides)
PKIX WG Documents
RFC
3279/4055 update for ECC – Sean Turner (IECA)
The RFC 4055 update is
done with WGLC and will be forwarded to the IESG in August. There have been
three new versions of the 3279 update since the March meeting, thanks to
comments from various WG members. Most recently, a normative appendix was added
to explain how to perform random number generation in an acceptable fashion
(based on ANSI documents). The only remaining issue is whether this document
should make use of the 2002 version of ASN.1, consistent with the ongoing
effort by Jim Schaad and Paul Hoffman on that topic. Tim Polk suggests that we
stick with the old ASN.1 module spec here for now, even though the text in this
document uses the 2002 ASN.1 terminology. This will require further discussion
with Tim Polk to decide how to proceed. (Slides)
New ASN.1 Modules
- Jim Schaad (Soaring Hawk)
Jim has made
considerable progress in developing this document since the March meeting. His
slides list the new classes and class tags. Jim's slides provide examples of
object class examples, and examples of how algorithms and their parameters are
represented in the new syntax. The compiler does not yet generate correct C
code from ASN.1, for all of the new ASN.1 features. Jim expects to have these
bugs fixed soon and will release a new version of his complier then. Jim
solicits reviews from all interested parties. He would like to go to WGLC prior
to the San Francisco meeting in March of 2009. Jim asks whether we will
continue to update "core" PKIX algorithm RFCs when we add new algorithms, or
will we publish new algorithms in new RFCs? The former strategy will require
this document to make provisions for extensibility, that will not be required
if the latter strategy is adopted. Finally, the WG needs to decide which ASN.1
modules from PKIX standards need to be included in this document.
(Slides)
Trust Anchor
Management Requirements – Carl Wallace (Orion)
Carl discussed the
outline of the new requirements I-D, which was posted about a month ago. He
examined PKIX documents that include discussion of TA management and/or
representation, to see how they stack up against the requirements in this I-D.
The documents include SCVP, CMP, and CMC. They also looked at the TAMP I-D (not
a PKIX document). His slides examined these protocols and, not too
surprisingly, the TAMP spec matches the requirements most closely, since the
two documents were developed in close coordination. Carl's plan is to receive
WG feedback on the requirements and protocols vs. requirements analysis, and
then publish it as an informational RFC. He notes that there are topics not yet
addressed, e.g., support for multiple trust anchor stores, and how the TA info
is used in path validation. One open question is whether we need to define a TA
format as part of TAMP, or whether it should be a separate document. Stefan argues in favor two separate
documents, to allow folks to make use of a TA format standard even if they
don't want to make us of TAMP itself. Tim suggests that the WG chairs execute a
straw poll to get the WG to approve or revise the requirements document prior
to Minneapolis. He also would like to see a second iteration of a protocol spec
in progress by that time (a challenge to the document author). Steve Kent notes
that the SIDR WG is also working on a TA representation format, and we should
be aware of their format and model since this is also ongoing IETF activity.
(Slides)
Traceable
Anonymous Certificates Protocol – SangHwan Park
(KISA)
This proposal has now
been adopted as a WG item, targeted toward an Experimental RFC. It describes an
architecture that allows a way to use X.509 certificates to provide "traceable
anonymity" for certificate users, employing standard X.509 certificate format
and certificate request formats. Traceability here means that a pair of
parties, in a split RA/CA model, can cooperate to disclose he real identity of
a user, but neither can do so unilaterally. The slides describe the steps
involved in TAC issuance and in disclosing a user identity, in response to
claimed abuse of anonymity by the user. The design uses both a threshold
signature scheme and a blind signature scheme, to provide cryptographic
enforcement of the split between the RA and CA functions. However, the use of
these crypto mechanisms is not visible to relying parties. In response to
suggestions provided by Denis Pinkas, changes were made to add an explicit
timeout value to the UserKey data structure. The security considerations
section also was amended to note that there are other data sources associated
with user communication that can undermine the privacy offered by TAC use, as
noted by Stephen Ferrell. Comments from WG members were solicited especially
with producing a normative appendix detailing use of CRMF for certificate
requests, and the CMS package that is used to protect the UserKey data. It was
suggested that the Security Considerations section include a mention of the
fact that multiple TACs need to be employed by a user to avoid RP being able to
link the same (anonymous) user to multiple sessions.
(Slides)
PKI Resource
Query Protocol (PRQP) - Massimiliano Pala (Dartmouth)
This is a WG item
targeted toward experimental status. Since the march meeting, Max added and
re-organized OIDs, but still has more work to do. Max will provide additional
documentation about the semantics for the OIDs and he will add more OIDs, e.g.
for SCVP as a service. Max's slides listed the OIDs that are now part of the
document. These should be reviewed and commented upon by WG members. Max also
reported an effort to make use of PRQP at Dartmouth, which maintains a database
for the TACAR project (which has several academic program partners). Max
described a two phase deployment plan for using PRQP in this context he also
envisions moving forward with a P2P application . (Slides)
Other
Certificates Extension – Stephen Farrell (Univ. of Dublin, Trinity
College)
This is a new WG item
targeted as an experimental RFC. It was adopted since the March meeting. It is
a proposal is to let a CA put a pointer (a hash) in a new certificate, to point
to a previously issued certificate that represent the same subject. The major
benefit here is to enable such transitions when the original certificate issuer
did not anticipate the need to provide such linkage when the (initial)
certificate was issued. Steve Kent suggested that the Security Considerations
section needs to call out possible problems that may arise due to use of this
extension. (Slides).
Related Specifications Presentations
OCSP Algorithm
Agility - Phillip Hallam-Baker (Verisign)
Phil observed that the
OCSP RFC does not impose constraints on the (signing) algorithms used in signed
requests vs. replies vs. in the certificates being checked. He also notes that
in a large system, the OCSP signer may likely be separate from the CA issuing
the certificates being checked, and that the OCSP verifier and the relying
party application may be developed independently and use different algorithms.
Clarifying the unarticulated assumptions would be helpful. Then one can also
develop a concrete spec to enable algorithm agility for OCSP. The WG chairs
agree to conduct a straw poll on the WG list to decide if this will become a WG
item. Phil will send a message to the WG chairs declaring what status
(standards
track, experimental, or informational) he seeks for the work, if adopted.
(Slides)
Clearance
Extension and Authority Clearance Constraints – Sean Turner
(IECA)
This draft received
minimal discussion at the March meeting, due to time limitations. The work
encompasses 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 or AAs who issue certificates containing the clearance
extension. Several changes were
made since the march meeting, based on comments received after that brief
presentation. Sean will send a message to the WG chairs, declaring what status
(standards track, experimental, or informational) he seeks for the work, if
adopted. Then a straw poll will be conducted to determine if this will become a
WG item. (Slides)
During the open mic
interval, it was asked if a CRLDP URI must resolve directly to the location of
the CRL, or whether an HTTP redirect is allowed? The concern is that
if a redirect
is used, a simple URL processor in a certificate evaluation engine will not
fetch the CRL successfully.