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).