Subject: meeting minutes

From: Stephen Kent <[email-masked]>
Date: Mon, 21 Sep 1998 12:20:00 -0400

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:
[email-masked].

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.

---

From: Denis Pinkas <[email-masked]>
Date: Thu, 24 Sep 1998 11:28:15 -0700

Michael,

As you say it, the minutes from the meeting are correct.

> Stephen Kent wrote:
> [snip]
> >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.
>
> This is what occurred during the PKIX sessions at the 42nd IETF meeting
> with regards to timestamping; however the above is not the whole story.
>
> Between sessions at the IETF meeting I talked with various people about
> the new Internet-Draft (authored by Dave Mills, Todd Glassey, and me)
> which extends the NTP protocol towards serving as a vehicle for PKI
> certified and secured time ("ephemeral" time; "what time is it *now*?"
> time), as well as also providing for *timestamps* of data -- within the
> same protocol, essentially as gravy (a different usage, I admit).

From your short description,  people might think that the two drafts are
equivalent. Let me highlight some of the main differences:

Let us call:

"draft 1", the draft:
ftp://ietf.org/internet-drafts/draft-adams-time-stamp-02.txt and
"draft 2", the draft:
ftp://ietf.org/internet-drafts/draft-mills-ntp-auth-coexist-01.txt

Draft 1 is all in ASN1, as the rest of the other messages supported by PKIX,
e.g. CMP. So it is in the spirit of the other documents. On the contrary,
Draft 2 is supporting 32 bits words and is much more compact (unless that
advantage will be lost by many extensions !)

The time formats are different between draft 1 and 2. Draft 1 is using the
same time format as the rest of the PKIX documents, while draft 2 is using a
32 bits time representation.

Draft 1 supports the time stamping of an imprint and as a side effect, may
provide a trusted time when using the optional nonces.

Draft 2 is unclear about time stamping, in particular the indication of the
hash function used for the imprint and its protection. It allows various
extension fields and so the minimum format to be supported is left
undefined. It is also unclear about the replay protection when only the time
is returned (unless that information is present is some other documents ?).

> I spoke with Jeff Schiller about this.  After he'd had a chance to look
> over the Internet-Draft (i.e., <draft-mills-ntp-auth-coexist-01.txt>),
> we spoke again, very near the end of the IETF meeting.  Jeff at that
> time suggested that since it was now apparent to him that the issue of
> PKI and time goes well beyond the question of timestamps to the issue of
> how secure *time itself* can be conveyed over an insecure network, he
> thought that perhaps the PKIX working group was not equipped to properly
> address this expanded issue -- or at least Jeff thought the IESG ought
> to be consulted first on the question before the issue of PKIX handling
> it or a separate "time" working group being set up is laid to rest.

From what is above, "draft 2" would not be usable in a PKIX environment,
where the compactness of the messages is not the issue, since the Time Stamp
will be used mostly either in a store and forward environment or in a local
environment.

However, there may be some good reasons to have a 32 bits oriented and more
compact protocol for acquiring a secure time for other environments and
therefore it can make sense to have two protocols.

> Thus the issue stands as far as I know.  I've addressed two e-mails to
> Jeff since the IETF meeting (on 8 and 21 September) but so far have not
> received a reply (I assume it takes time to poll the IESG membership).
> I have no particular stake in which way the decision goes (except I
> think *some* working group needs to address time *and* timestamping),

I am not sure that a *single* working group needs to address both time and
timestamping. As a good example, we have already have the PKIX and the SPKI
working groups: PKIX is using ASN.1, while SPKI does not. A similar
parallelism ! :-)

Regards,

Denis

> but wished to alert you that despite the outcome of the PKIX sessions,
> the question of whether PKIX handles it appears not quite settled.
>
> Regards,
> Michael McNeil
> GMT
> [email-masked]
> 1-831-438-7811

---

From: Michael McNeil <[email-masked]>
Date: Thu, 24 Sep 1998 08:05:20 -0700

>>This is what occurred during the PKIX sessions at the 42nd IETF
>>meeting with regards to timestamping; however the above is not
>>the whole story.
>>
>>Between sessions at the IETF meeting I talked with various people
>>about the new Internet-Draft (authored by Dave Mills, Todd Glassey,
>>and me) which extends the NTP protocol towards serving as a vehicle
>>for PKI certified and secured time ("ephemeral" time; "what time is
>>it *now*?" time), as well as also providing for *timestamps* of
>>data -- within the same protocol, essentially as gravy (a different
>>usage, I admit).

>From your short description,  people might think that the two drafts
>are equivalent.

Yes, thank you for pointing that out.  The two sets of drafts are quite
distinct, of course, as we're well aware.  I thought insufficiently of
the readers' perspective in wording the description unfortunately.

>Let me highlight some of the main differences:
>Let us call:
>
>"draft 1", the draft:
>ftp://ietf.org/internet-drafts/draft-adams-time-stamp-02.txt

Et al.

>and "draft 2", the draft:
>Draft 1 is all in ASN1, as the rest of the other messages supported
>by PKIX, e.g. CMP. So it is in the spirit of the other documents. On
>the contrary, Draft 2 is supporting 32 bits words and is much more
>compact (unless that advantage will be lost by many extensions !)

We think not, but good point.

>The time formats are different between draft 1 and 2. Draft 1 is
>using the same time format as the rest of the PKIX documents, while
>draft 2 is using a 32 bits time representation.

NTP actually uses 64 bits of time, with 32 bits of fractional second
information.  The 32-bit seconds count will roll over in 2038; I have
suggested (Dave Mills and I disagree as to the desirability of this)
that 8-bit extensions to the time fields be added in an extension field.

>Draft 1 supports the time stamping of an imprint and as a side
>effect, may provide a trusted time when using the optional nonces.

The question is what would be the quality of the time (ephemeral time)
passed using that protocol.  A heavyweight protocol almost by definition
takes more time to convey than a lightweight one -- and it's the quality
of the time itself that we're interested in here (ignoring timestamps
for the moment).  A longer time to pass the time futzes the precision of
the time.  Moreover, draft 1 lacks the fractional seconds information
NTP maintains, lacks the extra fields NTP possesses which allow it to
communicate the accuracy of the time and the last time that the server's
time was updated from a reliable source.  These last deficiencies can be
fixed, of course, in the draft 1 proposal (though perhaps not the
"heavyweight" issue); any deficiencies in the draft 2 protocol noted
below can also be repaired (except perhaps the "lightweight" issue). ;-)

>Draft 2 is unclear about time stamping, in particular the indication
>of the hash function used for the imprint and its protection. It
>allows various extension fields and so the minimum format to be
>supported is left undefined.

Draft 2 is a work in progress (this last is the second version), and
admittedly is less finished in this regard than draft 1.  We expect to
have another Internet-Draft ready for publication, with details of the
important extensions fields fleshed out, by the 43rd IETF in December.

>It is also unclear about the replay protection when only the time

NTP has inherent replay resistance in that if your time is already
reasonably good, replay attacks are instantly visible as being old. 
Moreover, NTP normally (despite conveying an absolute time) only steers
the time -- it doesn't reset a machine to a radically different time,
appearing out of the blue within an NTP packet.  Even so, additional
authentication is desirable to present spurious NTP attacks; that is the
point of the "draft 2" Internet-Draft.  A more fundamental protection
against replay attacks, from a cryptographic point of view, is to
require that the client as a sanity check do a unicast probe of the
server every now and then, rather than depending on broadcast packets,
including random bits of its own in its request -- which then get echoed
back in the signed NTP reply from the server.  Detecting its bits in the
reply, the client knows it's in response to its own most recent request.

>>I spoke with Jeff Schiller about this.  After he'd had a chance
>>to look over the Internet-Draft (i.e.,
>><draft-mills-ntp-auth-coexist-01.txt>), we spoke again, very near
>>the end of the IETF meeting.  Jeff at that time suggested that
>>since it was now apparent to him that the issue of PKI and time
>>goes well beyond the question of timestamps to the issue of how
>>secure *time itself* can be conveyed over an insecure network, he
>>thought that perhaps the PKIX working group was not equipped to
>>properly address this expanded issue -- or at least Jeff thought
>>the IESG ought to be consulted first on the question before the
>>issue of PKIX handling it or a separate "time" working group
>>being set up is laid to rest.

>From what is above, "draft 2" would not be usable in a PKIX
>environment, where the compactness of the messages is not the
>issue, since the Time Stamp will be used mostly either in a
>store and forward environment or in a local environment.
>
>However, there may be some good reasons to have a 32 bits
>oriented and more compact protocol for acquiring a secure time
>for other environments and therefore it can make sense to have
>two protocols.

I agree.

>>Thus the issue stands as far as I know.  I've addressed two e-mails
>>to Jeff since the IETF meeting (on 8 and 21 September) but so far
>>have not received a reply (I assume it takes time to poll the IESG
>>membership).  I have no particular stake in which way the decision
>>goes (except I think *some* working group needs to address time
>>*and* timestamping),

>I am not sure that a *single* working group needs to address both
>time and timestamping.

Good point.

>As a good example, we have already have the PKIX and the SPKI
>working groups: PKIX is using ASN.1, while SPKI does not.
>A similar parallelism ! :-)

A parallelism I hope doesn't draw a rain of stones and bricks!  ;-)

>>the question of whether PKIX handles it appears not quite settled.

Thank you for your comments, Denis!

Regards,
Michael McNeil
GMT
[email-masked]
1-831-438-7811