PKIX WG Minutes

Approximately 360 attendees participated in the two PKIX WG session at

the 40th IETF.  Several of the PKIX I-Ds have been through working

group last call and have moved on to the IESG for review, but a few

issues remain and must be resolved prior to IESG approval and IETF

last call.


Part 1 (Certificate/CRL Profile)


This draft completed WG last call, but a few issues remain to be

resolved.  Issues relating to use of algorithm OIDs and some ASN.1

errors have been resolved, and the authors have avoided inclusion of

some legal language that was previously proposed.


Unresolved issues:

	- There is disagreement about wildcarding in names (e.g., DNS

and RFC 822).  A small group met to resolve this issue after the (2nd)

meeting.  That group suggested disallowing use of asterisks in these

name forms as a means of conveying the notion that the name was a

place-holder for a set of names.  Instead, a new document will be

created to describe name form conventions, on a per-application

context basis, with explicitly declared semantics, in support of the

requirements that motivated use of wildcard name forms.

	- We are using '88 ASN.1, but BMP string is a new ASN.1

construct, so this is a technical matter (but does not affect bit on

the wire format).

	- There is a related issue is use of UTF8, a new ('98 ASN.1)

character set encoding, an alternative to BMP.  This appears to be an

issue at the IESG last call level of approval, but is not an issue

among PKIX members.

	- For key usage, we propose to stay with what X.509 says,

despite disagreements over whether it is the "right" interpretation.

	- Should CRLDistributionPoint be critical, non-critical, or at

the discretion of the CA?  Currently, it cannot be marked critical,

but this can cause problems.  The concern is that if marked critical,

then a client without support for this would reject the certificate,

even if the user was willing to ignore this extension, as required by

X.509. Not resolved.


Part 2 (split into LDAP, FTP, HTTP, OCSP)


No problems with FTP or HTTP. LDAP v2 profile completed both

last calls and is to be forwarded to IESG for approval.  We agree to
add 

a new work item to deal with v3, since current LDAP use in PKIX is
based 

on v2.  There was a suggestion to add a work item to develop a minimal


schema for PKIX use of LDAP.  This is a possible overlap with the LDAP


WG, so coordination is required.  Later during the week the LDAP WG
chairwas contacted and it was determined that creation of a schema for use
with PKIX was within the purview of the PKIX WG. See slides for additional
details.



Part 3 (Certificate Management Protocol)


No issues here other than the character set concerns raised under Part
1.



Certificate Request Syntax (PKCS7/10 focus)


A proposal was made to move work on this to S/MIME WG, and Schiller

and Housley (S/MIME WG chair) have no objections.  However, this work

is not S/MIME-specific and several PKIX and S/MIME WG members believe

that this work item should remain in PKIX, as it is more general.  The

fundamental question is whether CRS is a completely separate protocol,

focused on S/MIME, or if it is a profile for Part 3.  This was
subsequently

resolved [see below]. A straw poll of attendees showed a plurality of
attendees 

in favor of keeping the work item in this WG, and only a single vote in
favor of

moving it to S/MIME.  The S/MIME WG, meeting two days later, concurred

with this and did not recommend adoption of CRS within that WG,
assuming that

PKIX would reconcile CRS/CMP differences and include a specification
for

securely transporting commonly-agreed certificate management messages
over

CMS (i.e., son of PKCS 7).


At the second PKIX WG meeting, a compromise approach was announced,

aimed at reconciling differences between CRS and CMP.  In essence, a

common certificate request message syntax was agreed upon, and CMP
will

adopt this syntax as the certificate request payload type within that
protocol

(replacing the current certificate request payload format).  CRS also
will be

revised to reference that syntax.  This new, harmonized certificate
request 

format will appear as a separate RFC.  It is not anticipated that

this will delay the progression of CMP to proposed standard, since it
is

simply a protocol syntax change for alignment purposes, plus a
splitting of

one document into two in the interest of facilitating future
developments.

CRS will continue to progress, specifying the mapping of certificate

management messages onto CMS and providing the vehicle for producing

and RFC (or RFCs) that document agreed common formats for other
certificate management messages (i.e., messages other than certificate
request).



Time-Stamping and Notary Protocols


These are new, potential work items, discussed on a preliminary basis

in Munich.  Two presentations: Rob Zuccherato (Entrust) on time

stamping and notary functions, and Stuart Haber (Surety) on time

stamping. See slides for additional details.


Entrust- Time stamping service described here deals exclusively with

establishing existence of data (really a hash of data) at a point in

time.  Basic notary service for data demonstrates that a requester

posses data (not just a hash of the data) at a given time.  A

certificate notary service requires validation of a certificate chain

for the requester, including CRLs and ARLs.  There is also a fancy

data notarization service, encompassing data validity, and a combined

service of data possession and validity.  Some folks note that

validation of data (and certificates) is outside the scope of what

real world notaries do in the U.S. (but Latin Notaires do have broader

functions).


Surety- Stuart provided an overview of time stamping problem and

solution space, with a focus on the hash tree technology developed

(patented) and offered by Surety as a service.  The current Surety

service offers a 1 second granularity, 


At least one WG member argued that the notary and time stamping

functions are not completely PKI-specific, and we should try to avoid

duplication of efforts like the PKIX/SPKI situation.  Another member

noted that there is a new I-D for time stamping via NTP, that raises

possible overlap concerns as well.  One possible outcome is a split of

time stamping vs. notary functions.  Certificate path validation, a

part of the described notary service, does make sense for PKIX,

consistent with X.509 validation procedures.


A straw poll during the second PKIX meeting showed a strong sentiment 

that this WG amend its charter to include development of a standard for


time stamping, but there was not strong support for adding a work item

to develop notary functions (other than certificate path validation).
Thus an 

extension of the WG charter will be proposed to the IESG in order to

address time stamping.



OCSP


Mike Myers provided a status review for this I-D, and responded to

comments that have appeared on the WG list over the last few weeks.  A

number of modifications will be made as a result of these comments

Mike described a schedule for revisions and (new) comments to bring

OCSP to WG last call in time for the next (LA) IETF meeting.  Included

in the revisions will be a better characterization of the contexts in

which OCSP are expected to operate, since that range of environments

has grown since OCSP was initially designed. To better accommodate this


diversity, a document structure was proposed that establishes a base
OCSP 

document and syntax and one or more supplementary texts that build upon


the base syntax, as noted above.