Subject: draft minutes

From: Stephen Kent <[email-masked]>
Date: Wed, 23 Jul 2003 19:56:40 -0400

Please provide feedback by August 1st.

Steve
-------

PKIX WG Meeting 7/17/03

Edited by Steve Kent

Chairs: Stephen Kent <[email-masked]>, Tim Polk <[email-masked]>

The PKIX WG met once during the 57th IETF. A total of approximately 
75 individuals participated in the meeting.

Agenda review and document status - Tim Polk (NIST)
	There are about XX WG documents in various stages in the 
process, some of which fell through the cracks due to process 
glitches. [slides]

WG Focus and Direction - Russ Housley
	The working group has received direction from the IESG that 
will limit the types of new specifications accepted as PKIX work 
products. Thus the WG is not accepting new work items.  New WGs will 
be formed, as needed, to address PKI issues, or individual drafts can 
be submitted and subject to IETF-wide last call if the work described 
in them is mature and non-controversial. [no slides]

Document Status Review - Tim Polk (NIST)
	The working group has a fair number of Internet-Drafts in 
various stages of processing, but since the last meeting considerable 
progress has been made. Several IDs are in or have recently completed 
last call. [slides]

PKIX WG Specifications

	Simple Certificate Validation Protocol - Trevor Freeman (Microsoft)
The current draft of SCVP is in WG Last Call, and is believed to be in
full compliance with RFC 3379. This presentation discussed changes 
since the previous (version 11) draft. Plan is to progress to WG last 
call very soon. [slides]

RFC 3280 Progression - Tim Polk (NIST)
	NIST is currently performing the interoperability testing for RFC 3280.
This presentation updated the WG on NIST's progress, projected 
completion date, and issues identified to date. Primary focus is on 
the RFC 3280 path validation test suite developed jointly by NIST, 
DigitalNet, and NSA. Discussion of the problem of UTF-8 string 
matching, which has been addressed in the DNS context (RFC 3454), but 
is addressed only minimally in 3280. Plan is to stick with the 
current 3280 spec for progression to DRAFT, but to create a separate 
document to specify what CAs should do, to ensure that the simple, 
binary comparison will work in path building. [slides]

LDAP Documents: - David Chadwick (Univ of Salford) & Peter Gietz (DAASI)
      The WG has a suite of LDAP-PKIX drafts forming a comprehensive solution
for LDAP based PKI information distribution.  New drafts on PKC 
certificate       schema, CRL schema and on Attribute Certificate 
schema have been published      since the 56th IETF.  The authors 
presented the changes in these documents and discussed the timeline 
for document completion. Biggest issue on the table for the schema 
document is that Microsoft says it will not support multi-valued 
attributes (e.g., a terminal RDN that is a set consisting of a common 
name and a serial number). Direction from WG chairs is to maintain 
this requirement, and to discuss with MS why they believe this is not 
a necessary feature. Plan is to proceed to last call immediately 
after this IETF meeting. Still have to deal with the "; binary" issue 
for transfer of LDAP data. [slides]

Qualified Certificates  - Stefan Santesson (Microsoft)
       This presentation proposed a path for the evolution of the QC 
document. The intent is to relax some current QC profile constraints 
(e.g., re setting the NR bit), consistent with activities within 
ETSI, which uses this document as a basis for EU standards with 
regard to qualified certificates. Also need to bring this RFC into 
alignment with RFC 3280. [slides]

Certification Path Building  - Matt Cooper (Orion Security)
       This document, intended to become an informational RFC, was 
written to provide guidance and recommendations to developers 
building X.509 public-key certification paths within their 
applications, based on experience gained in several contexts. The 
document describes different PKI structures, considerations for 
forward vs. reverse path construction, tree pruning, etc. emphasis on 
value of disallowing repeated name/key combination in a path. Need to 
reword the introductory/overview text to make clear that the material 
presented is advisory, not mandatory, and to acknowledge that 
overall, we are still in early stages of gaining experience in this 
area. Also, if this is to be a PKIX document, then need to clarify 
that some of the "rules" deal with accommodation of non-complaint 
certificates. [slides]

RSA Public Key Algorithms - Jim Schaad (Soaring Hawk)
	New member of editorial team for this document. Discussed 
open questions of OID use (encryption vs. signature) and parameters 
use. New draft will be issued soon. [no slides]

Related Specifications
	The following personal drafts address topics of interest to 
the PKIX WG, and are presented to highlight the availability of the 
drafts and encourage input from the WG.

Russian Cryptographic Algorithms for PKIX - Grigory Chudov (Crypto-Pro)
	This personal draft documents the use of Russian national cryptography
standards (GOST) in the PKIX context. It was developed within the 
"Russian Cryptographic Software Compatibility Agreement", and signed 
by major Russian cryptographic software vendors. This agreement 
specifies parameters not nailed down in basic Russian Government 
standards. [slides]

Memorandum for multi-domain PKI Interoperability - Masaki SHIMAOKA (SECOM)
	This personal draft documents known issues and considerations 
for multi-domain PKI, and provides guidelines for multi-domain PKI 
interoperability as a best current practice. The scope of this 
specification is the establishment of trust relationships and 
interoperability among multiple PKI domains. This specification is a 
follow on to the JNSA Challenge PKI 2002 and Multi-Domain PKI Test 
Suite. [slides]

Liaison/Related Projects

The following specifications will update the WG on related EU activities.

European Open Standards for Electronic Signatures: the EESSI - 
Riccardo Genghini, EESSI Chair (SG&A)
	The European Electronic Signature Standardization Initiative 
(EESSI) is an industry initiative in Support of the European 
Directive on Electronic      Signatures. This presentation described 
the status of the ESESI's current and
recent work, which has just been published. This presentation was an 
update to the status report provided at the 56th IETF. [slides]

OpenEvidence Project - Peter Sylvester (EdelWeb)
	The EU IST project OpenEvidence is an Open source project 
concerning technologies for establishing the long term validity 
(integrity, time of posting, Š) of documents. The presentation 
addressed the goals and the current status of the implementations. 
Plan to update RFCs 3161 and 3029 to reflect additional experience 
gained in this project. [slides]

---

From: Michael Ströder <[email-masked]>
Date: Thu, 24 Jul 2003 11:47:54 +0200

Stephen Kent wrote:
> 
> LDAP Documents:
 > [..]
> Biggest issue on the table for the schema document is that 
> Microsoft says it will not support multi-valued attributes (e.g., a 
> terminal RDN that is a set consisting of a common name and a serial 
> number).

Could someone please elaborate on this?

One of my customers is planning to use exactly this naming scheme with 
multi-valued RDNs in a rather large PKI deployment and so we're scared about 
interoperability issues.

Ciao, Michael.

---

From: Michael Ströder <[email-masked]>
Date: Thu, 24 Jul 2003 18:56:30 +0200

[email-masked] wrote:
> DST has been useing a multivalued RDN in EndEntity certificates for a number
> of PKIs and since 1999 when we started issuing certificates.  We only do
> this for End Entities not servers.  Basically the certificate SubDN looks
> like the following.
> 
> 0.9.2342.19200300.100.1.1 = D01E473E000000F58FE3DDDC00000709,E =
> [email-masked], CN = Russel F Weiser,O = TrustID personal
> certificate,C = US

Maybe I'm missing something but this is not a multi-valued RDN.

An example in RFC2253 string notation would be:

cn=Michael Stroeder+serialNumber=12345, ...

Note the '+'.

Ciao, Michael.

---

From: [email-masked]
Date: Thu, 24 Jul 2003 10:15:25 -0600

Stephen Kent,

We have used this with numerous and integrated with many applications.
So is the issue that microsoft Active Directory will not support multivalued
RDNs  or that there Applications don't ?? I'm just trying to understand the
issue more clearly.

---

From: [email-masked]
Date: Thu, 24 Jul 2003 12:53:22 -0600

Ah but it is on the directory side of things when we create the directory
entry the 0.9.2342.19200300.100.1.1 = D01E473E000000F58FE3DDDC00000709 is a
multi name attribute.  I can either search for Russel F Weiser and get
multiple entries for Russel F Weiser. Or if I formulation the LDAP search as
0.9.2342.19200300.100.1.1 = D01E473E000000F58FE3DDDC00000709+CN = Russel F
Weiser
I will get that exact entry only.
I am just trying to understand what the discussion was about.
Several years ago when I was looking at all this I tried to get CAs to
create DNs that were Mutlivalued RDNs but none of the CAs would do this. So
I just made the directory do it when we published the certificate into the
directory.
This allowed me to perform name uniqueness without searching the directory
prior to signing a certificate.
cheers
RFW

---

From: [email-masked]
Date: Thu, 24 Jul 2003 12:53:22 -0600

---

From: [email-masked]
Date: Thu, 24 Jul 2003 10:15:25 -0600

Stephen Kent,

---

From: Stephen Kent <[email-masked]>
Date: Thu, 24 Jul 2003 17:17:20 -0400

>prior to signing a certificate.

The discussion is not about multiple names for a directory entry, but 
multiple attributes within a SET within a DN, especially the terminal 
RDN.

Steve

---

From: [email-masked]
Date: Thu, 24 Jul 2003 16:57:31 -0600

Steve,
I was just trying to understand things, It wasn't clear form the minute what
was the issue give that I wasn't at the meeting.
cheers
RFW