draft minutes

Stephen Kent <kent@bbn.com> Thu, 18 July 2002 01:25 UTC

Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA05544 for <pkix-archive@odin.ietf.org>; Wed, 17 Jul 2002 21:25:31 -0400 (EDT)
Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g6I0udL06555 for ietf-pkix-bks; Wed, 17 Jul 2002 17:56:39 -0700 (PDT)
Received: from gto-mailer1.bbn.com (cam-mailer1.bbn.com [128.33.0.36]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g6I0uMw06544 for <ietf-pkix@imc.org>; Wed, 17 Jul 2002 17:56:37 -0700 (PDT)
Received: from [133.93.73.143] (SSH.BBN.COM [192.1.50.70]) by gto-mailer1.bbn.com (8.9.3+Sun/8.9.3) with ESMTP id UAA15855 for <ietf-pkix@imc.org>; Wed, 17 Jul 2002 20:57:25 -0400 (EDT)
Mime-Version: 1.0
X-Sender: kent@127.0.0.1 (Unverified)
Message-Id: <p05100302b95bb9455978@[128.89.89.100]>
Date: Wed, 17 Jul 2002 20:18:51 -0400
To: Pkix <ietf-pkix@imc.org>
From: Stephen Kent <kent@bbn.com>
Subject: draft minutes
Content-Type: multipart/alternative; boundary="============_-1185168705==_ma============"
Sender: owner-ietf-pkix@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe>

Folks,

Below is the draft version of the meeting minutes for yesterday's PKIX meeting.

Please respond with comments and corrections, by 8/3.

Thanks,

Steve
------

PKIX WG Meeting 7/17/02

Edited by Steve Kent

Chairs: Stephen Kent <kent@bbn.com>, Tim Polk <tim.polk@nist.gov>

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 
&b 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. Other candidates 
(e.g., OCSPv2) should republish 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
	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. First extension copies 
policy extension from PK certificates (but gets new OID because of 
wording issues), uses policy qualifiers to express freshness of the 
attribute certificate. Second extension is a URL, and is marked to 
indicate whether the 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. Hope is to reuse text 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), 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 ;binary when 
interacting with LDAPv3 directories. An LDAPv3 schema has been 
defined for data items relevant to PKIX, to address this issue in the 
long run, and OpenLDAP supports this schema.

"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. [see slides]