Subject: draft-ietf-pkix-time-stamp-09 comments

From: Russ Housley <[email-masked]>
Date: Wed, 06 Sep 2000 10:23:16 -0400

Here are my comments on draft-ietf-pkix-time-stamp-09.  I have divided them 
into two categories: technical and editorial.  In my view, the technical 
changes are needed.  On the other hand, the editorial changes improve 
readability.

TECHNICAL

Section 2.1, 6th requirement.  I do not understand "hash-function 
OID."  OIDs, when managed correctly, are collision free.  I think we need 
to be discussing the one-way hash function, not its OID.  The selected 
one-way hash function must be uniquely identified by an OID.

Section 2.2, last paragraph.  Is this a SHOULD or a MAY?  The text says 
that the client SHOULD make the check, but that the client MAY elect to 
skip the check.  The checking requirement is either a SHOULD or a MAY, it 
cannot be both.

Section 2.4.1, reqPolicy Discussion.  I do not think that a reference to 
RFC 2459 is adequate.  First, I do not believe that a certification policy 
and a TSA policy are equivalent.  At a minimum, the TSA Policy and TSA 
Practice Statement will have significantly different content.  These 
differences need to be discussed.  Second, I would prefer syntax without 
qualifiers.  What value do they add in the TSA context?

Section 2.4.1, nonce Discussion.  Please replace "shall" with "MUST."

Section 2.4.2, 3rd paragraph.  The text does not match the comments in the 
ASN.1 structure.  I assume that the comments are correct.  Please 
rewrite.  I suggest:
	"When status contains the value zero or one, a Time Stamp Token
	MUST be present.  When status contains a value other than zero or
	one, a Time Stamp Token MUST NOT be present.  One of the following
	values MUST be contained in status:"

Section 2.4.2, 11th paragraph (counting paragraphs is difficult since the 
ASN.1 fragments are not indented).   Please replace "shall" with "MUST."

Section 2.4.2, serialNumber Discussion.  Please reword the last sentence to 
include a MUST.  I suggest: "This property MUST be preserved even after an 
interruption in service (e.g. crash)."

Section 2.4.2, genTime Discussion.  Please replace "shall" with 
"MUST."  There are at least five occurances.

Section 3.1.  How does the MIME type distinguish a time stamp request from 
a time stamp token?  The recipient must either decode a TimeStampReq or a 
ContentInfo, and this does not provide enough information to determine 
which operation to perform.

Section 3.2.  It would be helpful to specify file extensions for a time 
stamp request and a time stamp token.  Such extensions would permit the 
recipient to determine which decode to perform.

Section 3.3.  It would be useful to implementors to include the state 
machine for the TCP-based protocol.

Section 3.4.  How does the MIME type distinguish a time stamp request from 
a time stamp token?  The recipient must either decode a TimeStampReq or a 
ContentInfo, and this does not provide enough information to determine 
which operation to perform.

Section 4, item 4.  Each of the transports specified has different delay 
characteristics.  This should be pointed out.

EDITORIAL

Whole document.  Either add "SHALL" to the list of words that you say are 
defined in RFC 2119, or change "SHALL" to "MUST."

Section 2.2, 2nd paragraph.  Typo.  Please move the comma in the second to 
last sentence.  It should say: "For more details about replay attack 
detection, see the security considerations section (item 6)."

Section 2.4.1, MessageImprint Definition.  I suggest the replacement of 
"hashedMessage" with "MessageHash."  To me, the current name implies the 
full message text rather than a hash of the message text.

Section 2.4.1, certReq Disscussion.  Typo.  Please move the comma.  The 
sentence should read: "If the certReq field is missing or if the certReq 
field is present and set to false, then ..."

Section 2.4.2, id-smime-ct-TSTInfo definiton.  First, the registry calls 
this OID id-ct-TSTInfo. Second, I think that it would be more readable to 
define it as follows:
	id-ct-TSTInfo  OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840)
		 rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) ct(1) 4}

Section 2.4.2, genTime Discussion.  Some require course granularity, others 
require fine granularity.  I suggest that a TSA MUST offer at least 1 
second granularity.  Filling in the genTime structure with "00" as the 
seconds does not meet this requirement.

Section 2.4.2, accuracy Discussion.  I think that a bit more discussion is 
needed.  the syntax permits the seconds and micros fields to be present and 
the millis to be absent.  I am not sure how to add and subtract such a 
structure.

Section 2.4.2, ordering Discussion.  Please replace the last sentence with: 
"... TSA can always be ordered based on the genTime field, regardless of 
the genTime accuracy.

Section 2.4.2, tsa Discussion.  Please change "an hint" to "a hint."

Section 4, item 6.  Please change "(algorithm and)" to "algorithm and."

Appendix A.  First, the registry calls this OID id-aa-timeStampToken. 
Second, I think that it would be more readable to define it as follows:
	id-aa-timeStampToken  OBJECT IDENTIFIER ::= { iso(1) member-body(2)
		us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) aa(2) 14 }

---

From: "todd glassey" <[email-masked]>
Date: Fri, 8 Sep 2000 08:48:07 -0700

Hi all , might as well get this started here.

I have formally filed a request to stop the advancement of the TSP Protocol
to a Standard because it is still incomplete and in a number of senses,
broken.

Please read on.

----- Original Message -----
From: "Russ Housley" <[email-masked]>
To: <[email-masked]>
Sent: Wednesday, September 06, 2000 7:23 AM
Subject: draft-ietf-pkix-time-stamp-09 comments

> changes are needed.

The TSP is still in and of itself incomplete.
------------------------------------------
I  am really concerned that significant changes are needed in the TSP BEFORE
it is advanced, and I have already posted to the IESG saying this as well as
the WG Chairs.

If it is to be used to create "evidentiary marques" then we had damn well
better define what the marques are and how they are used PRIOR to erecting a
standard on the API for how to create them.

New Evidentiary Focus
------------------------
This concern, since the 9.0 draft finally started to talk about "evidentiary
processes" is right on the money. What timestamps are is not simple
processes to verify signatures at a specific time, but rather mechanisms for
memorialiing events in time and space as an evidentiary process.

Poof! The whole world changes.

Now what is important is:
--------------------------
            o-    What Evidentiary Standards the model conforms to (US, UK,
who's else?)
            o-    How is the quality of the data inside the stamp token
assured and how its is obtained. (I.e. the chain of custody and audit trail,
and certification process for the data. BTW - This goes back to my concept
of TRUST ANCHORS)
            o-    The mechanisms through which stamps are made comparable to
each other (and thus made Portable)
            o-    And last but not least a recommendation on how to use the
damn things and a statement as to their limitations i.e. what they can and
cannot do for us with these use models...

> On the other hand, the editorial changes improve
> readability.
>
> TECHNICAL
>

Russ - I agree -  the word SHOULD is specific to a USE MODEL as it is a
recommedation . i.e If you are using this as XYZ then you SHOULD... The word
MAY creates an choice on the part of the user that is separate of the
recommendation. This is one of the confusing things in the "Restricted Word"
definitions. But in this instance since there is no USE MODEL for the TSP
Defined maybe both are appropriate.

---

From: Denis Pinkas <[email-masked]>
Date: Mon, 11 Sep 2000 15:48:13 +0200

Russ,

I have been away from some time and I picked up your message. I fear
that your message, whatever its content is, has been addressed to
the wrong mailing list.

On Monday August 28, the IETF last call was launched by the IESG
with the following E-mail sent to the PKIX mailing list:

"The IESG has received a request from the Public-Key Infrastructure
(X.509) Working Group to consider Internet X.509 Public Key
Infrastructure Time Stamp Protocols (TSP)
<draft-ietf-pkix-time-stamp-09.txt> as a Proposed Standard.

The IESG plans to make a decision in the next few weeks, and
solicits final comments on this action.  Please send any comments to
the [email-masked] or [email-masked] mailing lists by September 8,
2000."

So your mail should have been addressed to the [email-masked] or
[email-masked] mailing lists by September 8, 2000. I hope you did so.

Denis

---

From: Stephen Kent <[email-masked]>
Date: Mon, 11 Sep 2000 18:33:29 -0400

Todd,

<snip>

>The TSP is still in and of itself incomplete.

I think your interpretation of the term "evidence" differs from that 
of the authors.  The term appears 5 times in the document, whereas 
the term "evidentiary marques" does not appear at all. So, we're not 
derelict for not defining the latter term :-). PKIX and the PKI 
literature in general has often used "evidence" in an informal way to 
refer to the body of data that supports non repudiation, e.g., certs, 
CRLs, etc.

Note that PKIX has avoided developing standards that are influenced 
by the various emerging legal criteria for digital signatures in 
different countries, states, etc. Note also the long debate over the 
term "non-repudiation" and the creation of an informational document 
on "Technical Non-Repudiation" by Tom Gindin.  So, in this spirit, I 
do not anticipate that PKIX will treat time stamping differently. We 
will focus on technical TSP mechanisms that yield what would be 
considered evidence in the same spirit as CRLs, OCSP responses, etc.

>New Evidentiary Focus

Not really. Many other aspects of the PKIX work address NR, not just 
TSP. We have adopted a consistent approach to this work, as noted 
above, which is independent of the vagaries of the legal systems that 
are now trying to address these complex issues.

>Now what is important is:

See comments above on technical focus vs. legal focus.  The notion of 
tailoring this work to the legal system of any of the above is not 
going to happen.

>and certification process for the data. BTW - This goes back to my concept

In developing standards, the IETF often chooses to address parts of a 
problem,  rather than all aspects of a problem. TCP moves data 
without regard for the type of data being transported. In the context 
of TSP, we rely on the users of a TSP to do whatever is necessary to 
achieve the desired evidentiary assurance that is appropriate for 
their environment. Thus, some TSPs may be suitable for some contexts, 
but inadequate for others. This is analogous to asking what 
algorithms and key lengths are necessary to ensure that a digital 
signature is valid for a transactions of a given value.  the answer 
will be context dependent and is outside the scope of our work.

>each other (and thus made Portable)

This issue has been addressed on the list, but the document could do 
a better job of clarifying the position it takes. Time stamps from a 
given TSA are ordered, but there is no guarantee that time stamps 
issued by different TSAs are ordered, since different TSAs may employ 
different time bases, offer different accuracy guarantees, etc. On 
can image various scenarios in which two time stamps, issued by two 
TSAs are not comparable. I agree that the document could do a better 
job of discussing this issue.

>cannot do for us with these use models...

We devote little space in other documents to how one might use 
signatures, or certificates in general, so I don't think this 
document is inconsistent with our practice in that regard.

>  > one-way hash function must be uniquely identified by an OID.

yes, this should be reworded to make clear that it is the hash 
function, not the OID, that is collision resistant.

>Defined maybe both are appropriate.

I know that use models are a favorite topic of yours, Todd, but we're 
not going to start adopting them here. Russ's comments address a 
concern over consistency of terminology.  I would assert that it is 
always the case that the client SHOULD check the policy field to 
determine if the time stamp will be useful, in context. The "MAY" 
here should be used differently, e.g., "The client MAY elect to 
ignore the results of this check.' This is not a deep issue, just a 
matter of wording.

We need to review the rest of Russ's comments, and see what changes 
may be necessary, but I don't see any of these as show stoppers.

Steve

---

From: "todd glassey" <[email-masked]>
Date: Mon, 11 Sep 2000 16:37:21 -0700

----- Original Message -----
From: "Stephen Kent" <[email-masked]>
To: "todd glassey" <[email-masked]>
Cc: <[email-masked]>
Sent: Monday, September 11, 2000 3:33 PM
Subject: Re: draft-ietf-pkix-time-stamp-09 comments

> >The TSP is still in and of itself incomplete.

The problem is that the term Evidence pertains to PROOF and that these
proofing models are what we are up to is becoming really clear here.

> different countries, states, etc.

This is becuase PKIX was focusing on the CORE Technologies not the use of
them. Now that the Core Technologies are done the next step is to put
together a set of recommended uses for them.

> Note also the long debate over the
> TSP.

Steve I disagree. What they do is to use the term NR to refer to a wrath of
services that they may offer. But in the context of this group the TERM NR
went through months of hammering out and still does not mean the same thing
to everyone here.

what we maybe might look at is definign the NR process a  suite of methods
to create comparable levels of non-repudiation at the process component
level, but this is another issue all together.

> We have adopted a consistent approach to this work, as noted

Are you saying this as the group's chair or as a member? I am assuming I
just annoyed you by bringing this up again. So I am not offended.

My feeling is that this take dooms  PKIX in that this is what the inustry
and the world needs now.

> problem,  rather than all aspects of a problem.

This attitude may only work for low level core components, when you step
ooutside these domains the requirements change and PKIX is clearly stepping
into areas that need use models and BCP recommendations.

> TCP moves data

Thanks. But what do you think about the idea of reorientating that document
so that it has two major sections before it gets advanced.  The TST's and
their Use Models would be one and the API"s to support them - this would
involve the addition of the AD section on the use and a number of TST
models. All in all it could be easily done and then we could all put the
standard to bed. I

I and the others that are concerned get the evidentiary grades of content we
want in the timestamps and the rest of the world gets what's alreadyin the
draft - This is a workable solution I think

SNIP -

Todd

---

From: Stephen Kent <[email-masked]>
Date: Tue, 12 Sep 2000 11:40:45 -0400

Todd,

>proofing models are what we are up to is becoming really clear here.

The term "evidence" does pertain to proof, but "proof" has different 
meanings in different contexts. Civil trial evidence rules vary from 
one jurisdiction to another. PKIX is NOT going to wait for these 
rules to become uniform, or cater to different sets of rules. This is 
new legal territory and until there are ample case law precedents 
nobody will really know what will be required.  We can get lots of 
opinions from lawyers, and technologists who think they are lawyers, 
but, none of these opinions are authoritative. So, PKIX will continue 
to focus on the technical aspects of PKI and do the best we can to 
provide a solid technical basis for whatever the legal community may 
choose to adopt.

We've seen dramatically different views of various aspects of NR 
arising in different contexts already, e.g., the German digital 
signature model, vs. the EU directive, etc. We're not changing PKIX 
standards to match any of these models.

>together a set of recommended uses for them.

TSP is still a core technology supportive of many uses.

>level, but this is another issue all together.

"Wrath of services?" What dictionary are you using :-)?

You are right that not everyone in the WG agrees on NR definitions 
and mechanisms. But, this is the IETF and we don't require complete 
consensus. However, you could propose a new work item which would try 
to do what you suggest here, i.e., document suites of mechanisms 
that, in concert, provide NR.

>just annoyed you by bringing this up again. So I am not offended.

I'm speaking as chair in this discussion, but I think the rationale 
for my position on this matter is obvious and consistent.

>My feeling is that this take dooms  PKIX in that this is what the inustry

Reasonable men may disagree about what the world needs now, and 
whether a given IETF WG must address that need. (BTW, I thought the 
answer to that question was "love, true love, that's the only thing 
that there's too little of.")

>into areas that need use models and BCP recommendations.

I agree that it may be appropriate to develop BCPs to complement our 
base standards, once there is enough experience to be able to claim 
that something really is a BEST COMMON PRACTICE. But we are not there 
yet for time stamping, and a BCP follows, usually by some significant 
delay, the publication and adoption of a standard that is employed in 
a BCP. So, the order is first, we adopt a standard such as TSP, then 
we gain experience, then we publish a BCP.

>models. All in all it could be easily done and then we could all put the

APIs are very separate from protocol standards.  For many years the 
IETF did not consider APIs as subjects for standardization, as they 
are not relevant to external interoperability. We have softened that 
view a bit, but an API is still secondary to the protocol for which 
it is an interface. If there is a demand for development of an API, 
then we can do so as a separate work item, but it in no way is a 
requirement for this document.

>draft - This is a workable solution I think

I predict that if we were to delay the document to accommodate these 
additional sections, that there would be a long debate over whose use 
models were included, and what API was adopted. The IESG will decide 
whether we need to hold up this document to address the use models 
you want, but my recommendation will be to defer this, and the APIs.

Steve

---

From: "todd glassey" <[email-masked]>
Date: Tue, 12 Sep 2000 18:31:57 -0700

Stephen I replied privately.

----- Original Message -----
From: "Stephen Kent" <[email-masked]>
To: "todd glassey" <[email-masked]>
Cc: <[email-masked]>
Sent: Tuesday, September 12, 2000 8:40 AM
Subject: Re: draft-ietf-pkix-time-stamp-09 comments

> >  > >             o-    What Evidentiary Standards the model conforms to
(US,
> >UK,
> >  > >assured and how its is obtained. (I.e. the chain of custody and
audit
> >trail,

---

From: Russ Housley <[email-masked]>
Date: Wed, 13 Sep 2000 11:05:28 -0400

Steve:

At 06:33 PM 09/11/2000 -0400, Stephen Kent wrote:
>I know that use models are a favorite topic of yours, Todd, but we're not 
>going to start adopting them here. Russ's comments address a concern over 
>consistency of terminology.  I would assert that it is always the case 
>that the client SHOULD check the policy field to determine if the time 
>stamp will be useful, in context. The "MAY" here should be used 
>differently, e.g., "The client MAY elect to ignore the results of this 
>check.' This is not a deep issue, just a matter of wording.
>
>We need to review the rest of Russ's comments, and see what changes may be 
>necessary, but I don't see any of these as show stoppers.

I agree.  None of my comments are show stoppers.  Although, I do think that 
building the interoperability matrix necessary to advance from Proposed 
Standard to Draft Standard will be straightforward if the cited paragraph 
is not reworded.

Russ