Re: meeting minutes

[Denis Pinkas <[e-mail]>]

Michael,

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

> Stephen Kent wrote:
> [snip]
> >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.
>
> 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
> [e-mail]
> 1-831-438-7811