final version of PKIX minutes

[Stephen Kent <[e-mail]>]

Edited by Steve Kent

Chairs: Stephen Kent <[e-mail]>, Tim Polk <[e-mail]>

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]