final version of PKIX minutes

Edited by Steve Kent

Chairs: Stephen Kent <kent@xxxxxxx>, Tim Polk <tim.polk@xxxxxxxx>

The PKIX WG met once during the 53rd IETF. A total of approximately 185
individuals participated in the meeting.

Tim Polk began with a review of the agenda and document status.
NIST will develop an interoperability test plan for RFC 3279 & 3280, and submit to WG for review. Note 3 documents have now achieved RFC status. DPV/DPD requirements document in IESG last call. Roadmap, OCSP(v1)bis and PI documents in IESG queue. 2527bis ready now. CMP and CRMF have been awaiting documentation of test results for progression to Draft, but we will publish and cycle at Proposed. We still have 19 active IDs, which is a lot, but an improvement! [see slides]

Certificate Validation Protocol - Denis Pinkas (Bull)
A candidate for meeting the DPV (but not DPD) requirements. User specifies validation policy to control path validation by a serverf if no policy specified, server employs local default, and notifies user of the policy (by OID). Allows user control over type of revocation checking to be done, time stamping of returned data, etc. Option for user to provide additional certificates and revocation status data. Optional requestor ID. Extensions permitted, e.g., to support inter-server use as well as client/server support. Facilities are included to support NR use, but do not burden non-NR use. [see slides] http://www.ietf.org/internet-drafts/draft-ietf-pkix-cvp-00.txt

SCVP Protocol - Ambarish Malpani (ValiCert)
Update on SCVP, changes to meet newly adopted requirements document. Uses CMS as basis. SCVP supports both DPD and DPV. Changes include references to policy by OID, references to certificates as alternative to sending certificates, client identifier added, query for client to discover policies supported by server, etc. [see slides] http://www.ietf.org/internet-drafts/draft-ietf-pkix-scvp-08.txt

Tim urges WG to begin examining protocols in detail. In order to be considered for DPV and DPD, any other candidate protocols, (e.g., OCSPv2) will have to be republished with any changes needed to meet requirements we have adopted. Hope is to make a decision before Atlanta IETF meeting, this fall.

Wireless LAN Certificate Extensions - Russ Housley (RSA Security)
IEEE 802.1X is looking at use of EAP-TLS for authentication in wireless LANs. Need extensions to support this application, when a user accesses different WLANs, e.g., home vs. work vs. airport, Š. Proposal defines EKU values for EAP/PPP and EAP/WLAN applications. Want to automate selection of the right certificate for different access points. Each WLAN has one or more service set identifiers (SSIDs). Put a list of SSIDs into a certificate as an extension, to identify the WLAN. [see slides] http://www.ietf.org/internet-drafts/draft-ietf-pkix-wlan-extns-00.txt

Certificate Warranty Extension - Russ Housley (RSA Security) for Spyrus
(The ID author, Alice Sturgeon could not attend, so the presentation was made by Russ.) This extension provides explicit data about warranties provided by the CA, including an explicit declaration of no warranty. It's a non-critical extension; NULL used to express no warranty, and there are provisions for extended warranty data too. Option to point to warranty data via URL. All of this can be gleaned from CP or CPS, but goal here is to make it easy for a machine to process. Subtle issues need to be discussed about why it is appropriate to use this extension, vs. using a policy extension with a specific policy and policy qualifiers to express monetary values. We have to be careful to not start a trend in creating a separate extension for each type of data that might appear in a CP/CPS and which might benefit from automated processing. [see slides] http://www.ietf.org/internet-drafts/draft-ietf-pkix-wlan-extns-00.txt

Attribute Certificate Policies Extension - Denis Pinkas (Bull)
Two extensions, one provides policy info re an attribute certificate and one for locating the AA certificate. The first extension mimics the policy extension from PK certificates (but gets new OID because of wording issues), uses optional policy qualifiers to express freshness of the attribute certificate. Second extension is a URL, and is marked to indicate whether the location of a repository is public or private. Discussion about need for freshness info, possible separation of second extension as it is more general than this AC context, and the need to include policy info explicitly in the AC. [see slides] http://www.ietf.org/internet-drafts/draft-ietf-pkix-acpolicies-extn-00.txt

RFC 3161bis - Denis Pinkas (Bull)
       Want to move to Draft, but need real interoperability tests to move forward. Will publish a matrix of tests to guide testers. Various minor changes to the document reviewed. [see slides] http://www.ietf.org/internet-drafts/draft-ietf-pkix-rfc3161bis-00.txt

Policy requirements for TSAs - Denis Pinkas (Bull)
      This document is derived from work in ETSI. Changes to terminology to align with 3161bis. This is targeted as an Informational RFC, with ETSI maintaining change control. Question is raised about whether we need a more generic policy requirements document for a wide range of PKI servers, e.g., CAs, AAs, TSAs, OCSP servers, DPD/DPV servers, etc. Although some core material is the same, major differences exist between PKI servers. Some text portions would certainly be re-usable in future policy documents. [see slides] http://www.ietf.org/internet-drafts/draft-ietf-pkix-pr-tsa-01.txt

PKIX Permanent Identifiers - Denis Pinkas (Bull)
      Document is with the IESG. Discussion of matching rule features. [see slides] http://www.ietf.org/internet-drafts/draft-ietf-pkix-pi-05.txt

Logotypes in X.509 Certificates - Stefan Santesson (AddTrust)
   Document now in third draft, and a fourth draft will be issued soon. Now can display logos at different resolutions, B+W vs. color, audio for vision impaired, language-specific logo selection, direct inclusion and indirect reference, etc. Three basic types of logos (community, issuer, client), plus loyalty, Š. [see slides] http://www.ietf.org/internet-drafts/draft-ietf-pkix-logotypes-03.txt

LDAPv3 Issues Relevant to PKIX - David Chadwick (Univ. of Salford)

There was a change from LDAPv2 to LDAPv3 which affects how certificates and related PKI data structures are stored. LDAPv3 added ";binary" as a means of specifying transfer syntax for these objects, which should be transferred in BER form. Now, however, the LDAPv3 WG has decided to remove support for ;binary (which was optional), from the draft standard (due to ambiguities in its specification, and no consensus on how to resolve them) in an effort to progress to Draft, avoiding other problems associated with generic use of this feature. Plan is to reintroduce ;binary as an extension in the future, once the problems that caused it to be removed is resolved. PKIX WG members are requested to respond on the list, noting whether clients and servers make use of LDAPv2 or LDAPv3, and if the latter whether they use ;binary when interacting with LDAPv3 directories. For the first time a native transfer syntax for data items relevant to PKIX has been defined in the PKIX LDAP schema for PKIs and PMIs, and these produce the same bits on the wire as the ;binary transfer syntax. Therefore in the longer term the use of ;binary wont be needed. But there clearly is an immediate problem with the use of ;binary, which is why it is important for people on the list to respond to the imminent questionnaire. OpenLDAP now supports equality matching for certificates, as specified in the latest version of the LDAP schema IDs.

"Specification Problem around Multi PKI domain Experience in Challenge PKI 2001"
- Ryu Inada (Japan Network Security Association)
This is a report on the interoperability testing activities in Japan, not a PKIX activity. Test environment involved root CAs and 9 subordinate CAs, a cross-certification model, and a bridge CA model representative of the Japanese government PKI. Applications included SSL, TLS, and S/MIME. Testing uncovered several areas that required clarification, in path validation and policy mapping. Also uncovered a number of CA non-compliance problems, e.g., mis-encoding of key usage, basic constraints in EE certificates, bad combinations of flags in key usage, etc. They hope to feedback results of tests in multi-domain PKIs to clarify the RFC 3280 issues. When a page in English will be available, it will be advertised on the PKIX mailing list, probably in the September 2002 time frame. [see slides]