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
