meeting minutes

[Stephen Kent <[e-mail]>]

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:
[e-mail].



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.