PKIX WG Meeting 3-23-09

Edited by Steve Kent

Co-Chairs: Stephen Kent <kent@bbn.com>

Stefan Santesson <stefans@aaa-sec.com>

The PKIX WG met once for 2.5 hours, during the 74th IETF. A total of approximately 47 individuals participated in the meeting.

Document Status Review - Stefan Santesson (AAA-sec)

One new RFC (5480, ECC Subject Publick Key Info) published since the prior meeting. One document (TSAES-OAEP Algorithm Parameters) in the RFC editor’s queue. No documents are now with the IESG and we have 11 I-D’s in progress. (Slides)

PKIX WG Documents

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

This is a WG item targeted toward experimental status. Max made minor editorial changes since the prior IETF meeting. The IANA considerations section was updated to request assignments for various DHCP (v4/v6) options, and DHCP (v4/v6) and DNS SRV record material appears in an appendix. Max provided a status update on deployment plans for PRQP in the TACAR testbed, which is delayed for a few months. (Participants in the testbed include EuGridPMA, IGTF, EduGain, etc. which covers over 50 CAs) Max also reported that the U.S. federal Bridge CA, and one large commercial CA, have has expressed some interest in deploying PRQP. Max also noted that he plans to integrate PRQP into the OpenCA software, maybe as soon as the June 2009 release. Max will issue version 03 soon and requested WGLC at that time. If deployment experience is good, Max would like PKIX to consider changing the status of the document to standards track from experimental. (Slides)

Traceable Anonymous Certificates Protocol – SangHwan Park (KISA)

The authors made numerous changes in response to comments from David Cooper (NIST), and documented these changes in two long messages to the list in February and March. Among the more significant changes were

- change the ASN. Syntax to use ContentInfo for the Token, rather than nested SignedData constructs

- specify use of OCSP or CRLs but not SCVP by the AI

- clarified mandatory vs. optional PKCS #10 and CMC attributes

- defer specification of how to use DSA (vs. RSA) for split signing by AI and BI

Since then no other comments have been received. Version 03 will be posted after this meeting, and Mr. Park requested that this I-D move to WGLC after publication of that version. Several folks at the microphone suggested that additional references to how to do threshold crypto should be provided if/when this document progresses to standards track. David Cooper argued that it is not clear that the complexity that arises from the use of split key technology and blind signatures is warranted. Steve Kent argued why he believed that these mechanism made it easier

(Slides)

Trust Anchor Management Documents – Carl Wallace (Orion)

In response to on and off-list discussions, the documents were significantly reorganized. The requirements document passed WGLC and is viewed as a stable reference for the other document, although there are no plans to publish it as an RFC at this time. A new, brief, trust anchor format draft is ready for WGLC. This format is will be used by the TA I-D in the SIDR WG, when it is next revised. A revised TAMP spec, minus the CMS content constraints (CCC) material, is available and Carl is looking for more list comments. (The CCC material that was removed is now an individual submission.) The scope of TAMP is now limited to push-based protocols, and use of constraints in certificate path validation has been removed. Numerous edits were made to align with the revised requirements doc, the removal of the CCC text, etc. Stefan suggested that Carl look at a European spec (TSL) for TA info dissemination, although it appears to have a different focus, and it XML-based. (Slides)

OCSP Algorithm Agility - Stefan Santesson (AAA-sec) for Phillip Hallam-Baker (Verisign)

Phil was unable to attend so Stefan presented the slides on Phil’s behalf. Phil produced an initial, brief I-D characterizing describing some OCSP agility algorithm problems, describing the default behavior of OCSP (which is not present in that RFC), and a proposed solution to the problem in the case when a certificate does not exist. However, SHA-1 is hardwired into the OCSP spec, and Phil’s proposal does not address this issue. Phil suggests that this problem needs to be addressed before OCSP progresses to STANDARD, but such a change will be very significant. Russ Housley (VigilSec) argued that the SHA-1 dependence needs to be fixed sooner, not later, despite the impact on the protocol. Paul Hoffman (VPNC) suggested that we explore using a different protocol or port number to get the required agility, as a way of allowing co-existence and moving to other algorithms. Several other folks

Phil also identified an issue for archival applications, but maybe this can be dealt with in LTANS. (Slides)

RFC 3161 (Time-Stamp Protocol) Update Stefan Santesson (AAA-sec) for Denis Pinkas (Bull SAS)

Denis has generated an update to RFC 3161 to provide for signature and hash algorithm agility, in a fashion requested by the ETSI TC ESC (electronic signature committee). A certificate ID optionally added to the response, to allow an RP to know how to select the right certificate to use in verifying the time stamp response. The potential for multiple certificates for the TSA arises in part because a TSA may have multiple time stamping units, each with its own certificate. (There are naming conventions that require the Subject names to be related.) Stefan is not convinced that there is a credible security threat that these changes address, but folks are deploying this feature, and it is an easy addition, he is not too upset about this. Stefan has agreed to provide some text for the security considerations to reflect his concerns. Denis wants to issue a new RFC that supersedes 3161, but an alternative would be to issue an update to 3161, with an informational annex. None of the previous co-editors want to participate in writing a revised RFC. Paul Hoffman suggests that we not replace 3161, but instead issue an informational RFC that adds the new terminology and the optional field, as a way to not adversely affect existing implementations. (Slides)

Advancing RFC 5280 to DRAFT – David Cooper (NIST)

In order for an RFC to advance, one needs to demonstrate at least two interoperable implementations that support all of the MUSTS and it is desirable that all of the normative references are at the same level. David has identified over 300 “features” that need to be verified, and a handful of normative references. A couple of issues have surfaced: AIA is not being used consistently in terms of the MIME type, policy qualifiers using Visible String rather than UTF8 or IA5. Visible String is a subset of IA5, so this is not a big deal in some sense, but the tag is different so we need to address this. A bigger concern is that several “features” do not appear to be in certificates issued by any CAs: Indirect CRLs, Delta-CRLs, Freshest CRL, some SIA and AIA extensions, etc. BUT, this does not mean that CA software is not capable of generating certificates with these features, or that client software cannot process certificates with these features. Steve Kent and Max Pala offered to see if they can generate some certificates for David to assist in this process. (Slides)

New ASN.1 for PKIX – Jim Schaad (Soaring Hawk Consulting)

Document has been revised in response to comments, especially from Alfred. Given the comments, a question is whether the document should be standards track or informational or experimental, e.g., to address the complaint from several folks want the 1988 ASN.1 to not be replaced by this spec. Tim Polk wants the WG to move promptly to WGLC, and agreed that the WG chairs should conduct a straw poll, with the intent of advising him (as the cognizant AD) as to the preferred status of the document (thus removing this topic from the WGLC). (Slides)

DSA ECDSA with SHA2 OIDs – Quynh Dang (NIST)

Now at version 06, blocked waiting for publication of FIPS 186-3. Minor edits from the last version. Authors believe that the doc is ready for WGLC, despite waiting for the FIPS cited above. Steve Kent agrees that WGLC should proceed. (Slides)

Related Specifications Presentations

NSA Suite B Certificate and CRL Profile – Sam Ashmore (NSA) on behalf of Jerry Solinas and Lydia Zieglar (NSA)

This document has been submitted as an individual draft, targeted as an informational RFC. It profiles RFC 5280 and 5480, and provides OIDs for specific Suite B ECC algorithms. The authors are looking for comments from PKIX members. (Slides)

Visual Certificate-based eID - Stefan Santesson (AAA-sec)

This is a successor to the logotype extension that Stefan authored years ago. The intent is to represent the Subject of a certificate in a form that most users can relate to. For many corporate or governmental entities, logos are a common way to convey this info, and for individuals, facial photos perform the same function. There are no common set of attributes to convey this info, and no common semantics for many attributes (e.g., serial number). RFC 3709 tried to address these issues by defining a way to add a URL (and a hash of the URL content) for the issuer and subject organization, but this has not been successful. Stefan noted that 3709 is extensible, and so we can try again! He suggests creating a single image that the subject wants to be displayed as the image of his certificate, period. He suggests using PDF as the image format (and is now an ISO standard), and a hash of that file, ala 3709. One could update 3709 to better accommodate this, use the other logo option in 3709, or create a new RFC for this. Also, some folks have said they would like to be able to embed the PDF in the certificate (but this seems like a local optimization). The national Bank ID organization in Sweden likes this idea. An obvious security concern is that the subject and issuer info do not align with the logo image, but Stefan argues that this form of misbehavior can be prosecuted, since a misbehaving CA will produce evidence of its fraud by signing the bad certificates. Stefan suggested that one might need to be able to determine, through policy or chaining to a highly trusted root, that a certificate can be trusted enough to provide certificate images, which would be displayed in lieu of the usual UI. Max Pala agrees that the problem cited by Stefan is a serious issue, but he thinks we might need to try an XML style sheet approach to displaying certificate contents, instead of images. There was a jabber comment arguing against this proposal as a security feature, vs. other mechanisms. Paul Hoffman suggests that this be a new, experimental track, if done in PKIX. He also notes the need to get browser vendors to display this info in a way that is assured. A VeriSign employee suggests that browser vendors are reluctant to pursue this path because of liability concerns. He also suggests that the CA Browser Forum might be the right to pursue this work. Wes Hardaker (Sparta) also raises concerns about the ability of other folks to cause a browser to display an image of its choice. Charlie Kaufman (MS) asks about details of how “trusted to display an image” would work, and Stefan suggests an EV certificate model. Tim Polk suggests that we get input from application area folks if we pursue this.