PKIX WG Meeting November 10 2009

Edited by Steve Kent

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

Stefan Santesson <stefans@aaa-sec.com>

The PKIX WG met once, for 2 hours, during the 76th IETF. A total of approximately 36 individuals participated in the meeting.

Document Status Review - Stefan Santesson (AAA-sec)

There has been significant progress in document status since the previous meeting.

- Two new RFCs (5636 & 5697)

- Four documents in the RFC Editor’s queue (RSAES-OAEP, 3281bis, DSA and ECDSA and OIDs, and Trust Anchor Format)

- Four documents with the IESG (MIME content type for attribute certificates, new ASN.1 modules, ESSCertIDv2, and clearance attribute and authority clearance constraints)

- seven I-Ds in process in the WG

(Slides)

PKIX WG Documents

Trust Anchor Management Documents – Carl Wallace (Orion)

Two trust anchor management I-Ds are still in process in the WG: the TAMP spec and the requirements document. (The trust anchor format I-D is now with the RFC Editor, as noted above.) Several changes have been made to TAMP based on WGLC comments. There is one outstanding issue, having to do with how to treat EKUs in path processing. Russ Housley and Paul Hoffman both suggested that we proceed with the TAMP document as is, and we can address the more general EKU issue later. Steve Kent will announce this plan on the list, concomitant with closing WGLC. Paul Hoffman also noted a recent meeting on civil aviation communication technology where TAMP was cited as a way to help deal with a complex PKI environment. (Slides)

OCSP Algorithm Agility - Stefan Santesson (AAA-sec)

Since Stockholm, ony a minor update was made, to accommodate specification of signature algorithm parameters (e.g., for EC signatures). This document is in WGLC now. (Slides)

Time-Stamp Protocol (RFC 3161) Update Stefan Santesson (AAA-sec)

The update here also was minor, just adding support for ESSCertIDv2, i.e., enabling hash algorithm agility. The security considerations text was revised after the Stockholm meeting, WGLC completed, and the document is now in IETF last call. (Slides)

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

This document defines a new image type for use with 3709, to enable storing a complete certificate image. The imafe types are PDF/A, SVG Tiny, and PNG (VML was removed). This appears to be ready for WGLC. (Slides)

Related Specifications Presentations

RFC 5280 Implementation Report – Tim Polk (NIST)

David Cooper (NIST) generated this report, as required for progression of 5280 to Draft status. He acquired most of the data from public sources, and engaged in lab data generation only when public data was not available. Primary public data source was signed S/MIME messages sent to PKIX and S/MIME lists. The certificates and CRLs were generated by at least 5 vendor products, and covered most of the feature set in 5280. The primacy omissions were delta CRLs, and generalized time. He used OPenSSL and EJCBA to generate delta CRLs, and Network Security Services (NSS) and OpenSSL to generate certificates with generalized time values. NIST’s PKI test suite includes over 200 path validation tests, and 5 products were validated a few years ago (2005-6). David generated new tests to cover remaining features, having certificates and CRLs consumed by Mozilla Thunderbird, Firefox, and Safari. Two features not supported: internationalized names and policy qualifiers expressed in other than VisibleString. Tim’s proposal to fix this is to issue an errata, but Paul noted that this is NOT an appropriate use of the errata process! So, we really should create 5280bis. There are two options are to put VisibleString back as a depreciated option, or we can just deprecate the qualifier. The document editor (David Cooper) will be asked to submit a revised version of 5280, that adds back VisibleString as a (deprecated) option. WGLC will be initiated as soon as this document is posted. No other changes to 5280 will be considered, since it is being revised expressly to deal with the problem noted above, which stands in the way of document progression. (Slides)

Certificate Information Expression in the EU - Stefan Santesson (AAA-sec)

This proposal was presented to the WG in Stockholm. The motivation is to map certificate attributes to semantics, to reduce the ambiguities that arise because different issuers have used the same attributes to represent different info in different contexts. This proposal would avoid the need for certificate translation, by providing metadata to map from attributes to semantics, either by extending RFC 3739 or through use of a new extension. The Information Card Foundation claims catalog is a possible basis for specifying attribute semantics. Stefan would like to initiate a new WG item for this. Paul Hoffman suggests using OIDs vs. URIs, based on (bad) experiences from AtomPUB. It was also noted that OIDs can be mapped to URNs. Several speakers at the microphone asked to see a document (as an individual submission) that gives more details, in order to evaluate whether this is an appropriate WG item. (Slides)

Attribute Certificates for XMPP – Sean Turner

The problem being addressed here is one of authorization delegation between servers. The servers already have PKCs, so it is possible to issue ACs that link to these PKCs. RFC 3281 is very general, so there is a need to profile that RFC to produce a simple model against which these ACs will be issued. There also is a need to define a suitable attribute for the XMPP application context. The XMPP certificates are typically good for a year, so the plan (for now) is to not support revocation (no ARLs for now). The plan is also to mandate support for SHA-256. These ACs need to be transferred between servers, so for completeness this system aspect will be part of the document. Sean proposes using base64 encoding and XML. This work will be pursued in the XMPP WG. (Slides)

Proxy Architecture on DRM Service – Zhipeng Zhou (Huawei)

This presentation provides an architecture for digital rights management (DRM) in a context that makes use of certificates and CRLs, and that includes proxies between the devices processing DRM-protected objects, and the servers that authorize access to such objects. Paul Hoffman noted that this sort of work is very different from the sort of work that PKIX usually pursues. It is specific to the DRM context, rather that being generic PKI technology. Typically, if an application makes use of signed objects and a PKI, the formats for these objects, and any certificate/CRL profiles, are defined in the WG that is standardizing that application. (Slides)

Server identity checking for TLS – Bob Morgan (University of Washington)

A document has been written in the applications area that describes how to verify the identity asserted by a server against the Subject name (or Subject alt name) contained in a certificate offered by the serer. The goal is to make such identity checks uniform across a wide range of applications that make use of TLS for security. Note that there are lots of types of identities that may be asserted, e.g., DNS name, IP address, URL/URI, etc. One needs different rules for different name types, and this document provides such rules. This presentation was made to PKIX for informational purposes. (Slides)