meeting minutes

[Stephen Kent <kent@xxxxxxx>]

Folks,

I apologize for not having mailed these sooner, for review.  They were done by Friday, of IETF week, but then got lost in an avalanche of travel and e-mail.  Please review and respond to me with corrections by the end of this week.

Thanks,

Steve

-----------------------

PKIX WG Meeting Minutes 8/26-27/98

The PKIX WG met twice during the 42nd IETF and a approximately 190
individuals participated in these meetings.

The meeting began with a review of the status of all of the WG document, presented by 
Warwick Ford, WG co-chair. The following text summarizes the status of the documents:

PKIX Certificate/CRL Profile (draft-ietf-pkix-ipki-part1-09.txt) - IESG Last Call

KEA Algorithm Profile (draft-ietf-pkix-ipki-kea-02.txt) - Close to completion by Editors

HTTP/FTP Operations (draft-ietf-pkix-opp-ftp-http-04.txt) - Ready for WG last call

LDAP V2 Profile (March 98 draft)- At IESG, pending WG delivery of V2 Schema

LDAP V2 Schema (draft-ietf-pkix-ldapv2-schema-01.txt) - In WG last call

OCSP (draft-ietf-pkix-ocsp-05.txt) - In WG last call

CMP (draft-ietf-pkix-ipki3cmp-08.txt) and CRMF (draft-ietf-pkix-crmf-01.txt) - In hands 
of IESG; pending IESG last call

CMMF (draft-ietf-pkix-cmmf-02.txt) and CMC (draft-ietf-pkix-cmc-01.txt) - In WG last 
call

Certificate Policy/Practices Guideline (draft-ietf-pkix-ipki-part4-03.txt) - In SA Director's 
hands, pending publication as Informational RFC


REVIEWS OF ESTABLISHED PROJECTS:


- PKIX Certificate and CRL Profile (Tim Polk)

Ready for IESG ballot, after receipt of minor editorial comments during IETF last call.  
Straw polls used to resolve last few contentious issues, specifically mandating use of DNs 
for all Issuers, and mandating use of strict subtrees for the NameConstraints extension. 
Jeff Schiller noted that the IETF web site has pointers to the Entrust license required for 
inclusion of CRL distribution point within this document.  The license is easy to execute; 
there is a reciprocity clause that requires licensing to Entrust  any intellectual property 
associated with CRL distribution, as a side effect of 


- KEA and ECDS Algorithms (Tim Polk)

Work on these algorithm IDs continues, subject to resolution of some intellectual property 
issues.


- LDAP V2 Schema and Profile (Tim Moses, Dave Horvath, Santosh Chokhani)

Most of the schema are not controversial; outstanding issues is whether all CA certificates 
should appear in the cross certificate directory attribute, or whether certificates that are 
internal to a domain should appear in the CA certificate attribute.  There is consensus that 
any self-signed CA certificates belong in the latter attribute.  The disagreement here 
revolves around alternative certificate validation algorithms; both approaches have been 
implemented and both work, each favoring a different PKI model. The CA certificate 
attribute has been a feature of X.509 for a long while, so the proposal to move all (non-
self-signed) CA certificates to the cross CA certificate attribute represents a non-backward 
compatible change for systems not making use of cross certificates.  Still, this is the 
direction currently being pursued by the X.509 committee in resolving this ambiguity in the 
original standard.

Performance analysis of 6 different approaches, under varying assumptions of PKI 
models, shows that putting all (non-self signed) CA certificates in the cross certificate 
attribute results in worse performance.

We can make a decision now to get this long overdue schema out, or postpone and discuss 
more (since this is a newly discovered issue).  (Although this discussion is taking place in 
the context of LDAP v2, the same issue arises in LDAP v3.  However, v3 has better 
filtering capabilities and this it is believed that the issue would be less of a concern, but this 
is not universally agreed upon.) Work on LDAP v3 is progressing in the IETF, and so if 
we postpone action on this ID, it may be OBE and we will need to focus on v3 instead.

Proposed compromise approach is to duplicate intra-domain CA certificates in both 
attributes (#4 in Santosh's analysis posted to the WG list), and which has very good 
overall performance. One objection raised to this is that it can result in added data sent back 
if one retrieves both attribute contents. Straw poll conducted resulted on no clear winner, 
but the two finalists are the proposed compromise and the older, backward compatible 
approach; the WG rejected the proposal from the current LDAP schema.


- OCSP (Tim Myers and Ambrish Malpani)

Various minor, but technically important, edits to many parts of the document, in response 
to comments from the WG list. Changes included a uniform key identifier, optional use of 
TLS/SSL for privacy protection of exchanges, etc. An objection was raised to mandating 
use of a signature, when a lower layer protocol might be used to provide security.  A straw 
poll overwhelmingly supported the mandatory use of signatures of in OCSP.  Thus there 
appears to be no outstanding significant technical issues at this time. A separate OCSP response extensions document will be created to define additional responses 


- CMP and CRMF

In IESG last call. No further status to report.


- CMMF and CMC (Mike Myers)

The CMMF draft has completed WG last call, minor changes have been made in response to comments received during last call, it and will be forwarded to the IESG. CMC also has completed WG last call, and undergone changes in  response to comments received during that process.  Pending approval of secure initialization issues briefed at this meeting, the document will be forwarded to the IESG. The secure initialization requirements for CMC include use of a shared secret in a keyed hash calculation, with this secret distributed via a confidentiality-secure channel.  However, objections were raised to defining this as the only way to achieve secure initialization, e.g., as opposed to use of SecurID cards or S-KEY authentication in the context of an integrity and confidentiality secure channel. It seems likely that additional mechanisms should be allowed, but there is a desire to avoid an explosion of allowed user authentication techniques, which would hinder interoperability or greatly burden CA software.  This issue will be brought to the list for resolution.


- IBM PKIX Software Distribution (Charlie Kaufman)

IBM is implementing PKIX technology and making it available  for use in products, as 
well as in R&D environments.  Code is a mix of C++ software plus Java GUIs. Provided 
facilities include CMP, CRMF, LDAP, basic CA and RA functions, and client certificate 
processing.  No crypto is included in the distribution; the software makes calls to a CAPI. 
The first release relies on the Cylink cyrpto toolkit, which also will be available via this 
web site; later version will also make use of BSAFE. Initial distribution is via an MIT web 
site and is not exportable.  A pointer for a mailing list was provided: imc-pfi@imc.org.



NEW TOPICS:


- Timestamp & Notary proposals (Carlisle Adams)

Several folks continuing work on these topics and have published an independent draft on 
these topics.  The authors received a fair amount of private feedback, and hope to be able to 
bring forward a well-formed proposal. Jeff Schiller gave his permission to bring this into 
the WG, based on the WG having made substantial progress on the other work items. Thus 
we will expand the charter to encompass these topics.


- Web-based Integrated CA services Protocol (Mine Sakurai)

This presentation describes use of HTTP as an underlying communication protocol among CAs, RAs, etc.  The underlying model also defines issuing, validation, and publishing authority modules within the CA.  ICAP has been implemented for use with S/MIME in a medical information system in Japan.  An I-D has been published describing ICAP: draft-ietf-????.  It was noted that the acronym "ICAP" is already in use by a calendar protocol, so another protocol acronym would be appropriate.


- Enhanced CRL Distribution Options (Phillip Hallam-Baker & Warwick Ford)

There is an I-D describing alternatives CRL distribution technique, which was developed in response to the intellectual property problem that temporarily prevented use of the CRL distribution point mechanism. The CRL format can be extended to specify the scope of the CRL, e.g., by serial number range, as an alternative to placing the pointer in the certificate.  To address the CRL location aspect of CRL distribution points, one also can establish CRL managers that are either locally trusted or that represent a separate CRL distribution channel, perhaps serving multiple CAs. By adding two new CRL extensions, one can extend the CRL distribution model in interesting new ways.  These suggestions are being forwarded to ISO for consideration. See the latest I-D, under the PKIX, for more details.


- PKIX Roadmap (Al Arsenault)

The set of PKIX documents has become rather large and potentially confusing.  An outline 
was presented as a basis for a document that would become an informational RFC, to help 
explain the relationships among these documents, and to other efforts, e.g., SPKI.  An 
initial draft is ready and will be made available immediately after this IETF meeting.


- Qualified Certificates (Stefan Santesson)

In EC a legal framework for "qualified certificates" is being developed, referring to individual certificates that will be accepted for legally binding, international transactions, and with legal liability implications for the CAs issuing such certificates.  (These certificates are used only for non-repudiation.) It is analogous to some of the work under UNICTRAL for EDI. For PKIX, the potential work item would be a profile for such certificates, specifying which extensions are mandatory and optional, establishing values and semantics for some of the extensions. For example, one might mandate use of the policy extension with a specific value to identify such certificates, with policy qualifiers to express additional characteristics of policy variants, appropriate key usage flags, naming schema constraints, etc.