Subject: draft-ietf-pkix-time-stamp-01.txt comments

From: Peter Sylvester <[email-masked]>
Date: Wed, 12 May 1999 10:54:46 +0200

I have forgotten to include the group in the following message.

I profit from the occasion to comment Michael Zolotarev's remarks:

Comment1: The need for a tag had indeed been discussed, but is it
clear at which protocol level a tag is needed, i.e. is this an
issue of some underlying transport protocol, or would the tag be included
in the signature of the response?
  
For example if one uses an e-mail based service, the request would
probably have a message-id in the header and the response may use
an in-reply-to or references. In the ftp case you may need a 
convention what filenames to use.  

Comment2: The sequence number is use when you want a 

 "strictly monotonically increasing Integer from one TimeStampToken
  XXXXXXXX
 to the next."

If you don't have a sequence number, you don't have "strictly".

There is no need to always provide unique time stamps for certain
types of service. The 'stamps' from a real postal service are
within a precision of half an hour or even less for example.  

Comment3: Is there a a De Morgan problem in the wording?

Comment4: Why just 8 bits signed integer for a precision. The encoding
          is just an integer.
          The fractionofSecond definition is not quite nice for
          a display. A power of 10 seems more appropriate. In fact
          I do not see at all why it should be an integer: The
          genTime is a STRING, thus fractionOfSecond would probably
          better be a NumericalString, so a display may simply
          concatenate   genTime '.' franctionOfSecond

          Whether the precision is really needed in this case is
          another matter. Shouldn't it be optional?
               
Comment5: There seems to be some kind of inflation of similar
          protocols (X over Y, Y over X, ...)

Peter 

----- Begin Included Message -----

From: Peter Sylvester <[email-masked]>
Date: Tue, 11 May 1999 20:30:12 +0200
To: [email-masked], [email-masked], [email-masked],
        [email-masked]
Subject: draft-ietf-pkix-time-stamp-01.txt comments

Hi, 

a little bit of nit-picking (and maybe more) :-)

2.1. Requirements of the TSA

The TSA is REQUIRED:
     1. to provide a trusted source of time.
                     trustworthy ?? 

     2. not to include any identification of the requesting entity in 
        the time stamp token.

     3. to include a monotonically incrementing value of the time of day 
        into its time stamp token.
                            tokens.      

     4. to produce a time stamp token upon receiving a valid request 
        from the requester.
What does this mean if the TSA can ignore the request due to overrun?
See security section 4.5 ??

     5. to include within each time stamp token an identifier to 
        uniquely indicate the trust and validation policy under which
        the token was created.
The policy is optional, isn't it?

     6. to only time stamp a hash representation of the datum, i.e. a
        data imprint associated with a one-way collision resistant hash-
        function OID.

     7. to examine the OID of the one-way collision resistant hash-
        function and to verify that this function is "sufficient" (see
        Section 2.4). 
The text later on does not specify what kind of error should be returned.
Shouldn't there be an error code in the PKIFailureInfo? Or is this
badAlg or badRequest ?

     8. not to examine the imprint being time stamped in any way. 
What does THAT mean? If you keep a log of requests/tokens, are you
'examining' the request?  
    
     9. to sign each time stamp token using a key generated exclusively 
        for this purpose and have this property of the key indicated on 
        the corresponding certificate.

    10. to include supplementary temporal information in the time stamp 
        token (from TDA's) if asked by the requester.  If this is not 
        possible, the TSA shall respond with an error message.
Would it be possible to respond with a 'modified answer' 
and simply not including the missing TDAs in the token.
The application could decide how to interprete the result? I don't really
care.  

    11. to provide a signed receipt (i.e. in the form of an 
        appropriately defined time stamp token) to the requester, where 
        appropriate, as defined by policy.

The definition of TSTTime (or TSTInfo) does not say what should
put as time in case of a PKIStatus rejected especially when

    timeNotAvailable {14},
      -- the TSAs time source is not available

A small wording change in the following:

     6. A CA shall normally conduct a test for proof of possession for 
        each user's signing private key (including the TSA/TDA signing 
        private key). However, in some environments, the CA might not 
        perform a proof-of-possession of the private key when issuing 
        certificates. In these instances, in order to prevent certain
        attacks and to properly check the validity of the binding 
        between an end entity and a key pair, a certificate identifier 
        of the TSA/TDA shall be included as a signed attribute.

                                              the signature MUST contain
        an ESSCertID authenticated attribute.

see also the wording in:

certificate that is to be used to verify the token.  This field MAY be 
omitted if the Signing Certificate Attribute has been included as a 
signed attribute.  (See Section 5 of [ESS].)  It MUST be present if the 
ESSCertID Attribute is not used to identify the TSA.

The socket based protocol does not seem to follow the requirements
of not giving non signed responses.
 
In fact, there seems to be some confusion in layers. What is considered
as 'not respond' in a context of http for example. You cut the
connection? You just let the connection time out? 

        produce a valid response before responding, if this is possible.  
        If this is not possible, it MUST ignore the requests and not 
                                    ????????????????????????????????
        respond.
        ???????

It seems to me that the socket based protocol is basically designed
as an internal protocol among a front end transaction based http 
and a back end signing entity for example, thus operated in a different
security context; no problem with that. 

In general I guess it is necessary to make a precise definition what means
'returning a response', 'not returning a response' depending on each
lower layer, especially for http, 'document contains no data' = 0 length
response or time out.  

> A simple MIME object is specified as follows.

>    Content-Type: application/timestamp
>   Content-Transfer-Encoding: base64

>   <<the ASN.1 DER-encoded Time Stamp message, base64-encoded>>
No: An appropriate, content preserving transfer encoding should be used.
Someone can reencode in quoted-printable or whatever. 

Which method should be used in http to send a request. 
(POST ??) PUT?? Don't care?? 

> This MIME object can be sent and received using common HTTP processing
> engines over WWW links and provides a simple browser-server transport
                                               CLIENT
> for Time Stamp messages.

     1. When there is a reason to believe that the TSA/TDA can no longer
        be trusted, the authority's certificate MUST be revoked and 
        placed on the appropriate CRL.  Thus, at any future time the 
        tokens signed with the corresponding key will not be valid.

Tokens with a time superior than the end of validity are not valid.

And telling HOW a ca should act should not be the business of this
text. There might be OCSP for example.

It seems that a paragraph about configuration is missing:

- what URI should be used?
- How do I get a trustworthy certificate

One suggestion that minimises the two parameters into one:

A certificate of a TSA/TDA may contain an AIA with 
id-kp-temporalDataAuthority and an URL. 

and to say that it is a local matter of an application to decide
which time stamp service is 'trustworthy'. 

Appendix A:

For this purpose, we define a PKCS #9 [PKCS9] time stamp token attribute 
type.  This attribute type specifies the time stamp token, which MUST be 
                                                                 can
included as a signed attribute of the SignedData object. 

have fun

----- End Included Message -----

---

From: "Todd S. Glassey - ELN" <[email-masked]>
Date: Wed, 12 May 1999 07:10:16 -0700

Peter, I disagree with a good bit of your commentary.

----- Original Message -----
From: Peter Sylvester <[email-masked]>
To: <[email-masked]>
Sent: Wednesday, May 12, 1999 1:54 AM
Subject: draft-ietf-pkix-time-stamp-01.txt comments

> in the signature of the response?

The need for the tag is also specific to the use models. Here again, what is
being attempted here - to audit who is doing what and to whom? For what
purpose?

> an in-reply-to or references.

I agree a tag is necessary to identify the applications, how ever I would
like to see something larger than a tag. Say I want to authenticate, end to
end, that a particular application sent the logging server a message for
logging. I would want  to store a branding token from the app itself in the
timestamp structure to support identifying which app and which specific
instance of it did the deed.

Here again the missing piece would be a standard way of watermarking  or
branding executables so that they could identify themselves. My feeling is
that this is a much bigger issue than people think.

>In the ftp case you may need a

Peter, pardon my reply here, but this comment is both out of context,
generally wrong, and irrelevent to commercial timestamping.

If you are trying to create a postal processing system, wherein you only see
(or contact) the postal agent once a day, then the issue of the
date/timestamp may be OK. But by the way, the actuality of when you deposit
mail with the post office and when it is stamped is also a mystery in most
instances, except to say, that the mail will be cancled when it is
processed, and that is the time that it will have stamped on it. So in
reality, unless the mail is hand canceled, what you get stamped on the mail,
is the "when they got around to it" time which in most instance is within 24
hrs of depositing the mail with "them".

All in all, the 200+ year old postal process is changing and since
Electronic Mail and Document Processing systems are moving into digital and
operating 7x24 hrs and your comment doesn't seem to make sense to me in
light of this.

> Comment3: Is there a a De Morgan problem in the wording?

Potentially

>           concatenate   genTime '.' franctionOfSecond

My feeling is that *any* timestamp structure MUST be able to support time
resolution into the MicroSeconds, and if the Draft McNeil and I are about to
send, you will see we have done just this. AQlso the structure should be
totally binary in nature. The who of who is using it is a computer, so keep
it digital.

>           another matter. Shouldn't it be optional?

No, the precision of the stamp structure is part of what's being
standardized and so it should be fixed, IMHO.

---

From: "Michael Zolotarev" <[email-masked]>
Date: Thu, 13 May 1999 10:59:14 +1000

The unique monotonic etc serialNumber is critical when you have to resolve
'who was the first' argument between two stamps, having the same time value.
This may well happen if the resolution of the clock is relatively low, and
two requests entered the TS server virtually simultaneously. Think about
on-line betting, auctions, etc.

Defining serialNumber OPTIONAL will make it very confusing for a client who
relies on the sequence as well as on the time itself.

And I would be deadly scared of seeing something like "if more than one time
stamp are generated with the same time value, then TSA MUST include
serialNumber into the TSTInfo. Otherwise, the field may not be present ...".

MichaelZ

---

From: "Michael Zolotarev" <[email-masked]>
Date: Thu, 13 May 1999 11:49:02 +1000

Let me speculate a little bit about the problem of tags.

First, an abstract: A tag, (at least my idea of it, MZ), is an optional
sequence, containing any sort of data, that allows a requestor to associate
the time stamp with the data it has been produced for.

Second, a few questions to ask:
Q1. Does anybody need the tags at all?
Q2. Does having tags create any problems?
Q3. Can we achieve the same goals without tags? Is it more practical?
Q4. Would many clients need tags? Would the majority of clients use tags?

If you answered Q1:Y, Q2:N, Q2:N, then you agree that tags have right to
exist. I do not think many people would argue, and many have already come up
with real life examples where tags come handy.

Now, the question is WHERE should a tag be defined.

The only possible options are:
1) As a field inside the TS request and response structures
2) As a field inside outer protocol frame or even transport frame.

The choice directly depends on how you answer Q4.
If it is reasonable to expect that tags will be used by the majority of the
clients, then it should become a field inside the core time stamp
structures.
Otherwise, we can get around by just providing recommendations on how
tagging can be implemented using various encapsulations of the time stamp
messages.

-------------------------------------------------
My suggestion would be that a TimeStampReq is added with an optional field.
If present, the response will contain the same value. This can be done by
1)Preserving a similar field in the TimeStampToken, or 2)by merging the tag
into the unauthenticatedAttrib of the signerInfo. The former seems to be
simpler, but I have no particular preferences here.
-------------------------------------------------
Talking about the practicalities of having tags - recently I have tried a
Notary application, developed by some company. Guess what - they do not have
tags, and the solution (to associate the tokens with the origins) they came
up with is inevitable ugly, and does not always work anyway.

MichaelZ

---

From: "Dave Sweigert" <[email-masked]>
Date: Wed, 12 May 1999 21:40:38 -0400

Inside the Army, 10 May 1999

Hamre pushes ahead with infosec effort
NEW PKI POLICY WILL HAVE DRAMATIC IMPACT ON MILITARY, BUSINESS AFFAIRS
By Jeremy Singer

Copyright Inside the Army

A new public key infrastructure policy signed by Deputy Defense Secretary
John Hamre last week will have a "huge impact" on the way the Army and other
services conduct military and business affairs, a service official told
Inside the Army last week.

"As far as electronic commerce goes, this is a watershed event," he said.

In many cases, the new policy will reduce the number of intermediaries
handling documents, and greatly expedite the process of approving travel
orders, for example, he said.

PKI is one element of the layered strategy information assurance officials
are working on this year. A department-wide PKI will allow DOD to
communicate securely and help eliminate paper from the military's
operations, two major priorities for Hamre. Public key cryptography involves
two related keys, one public and one private, and an infrastructure of
people and systems is required in order to manage the keys and the services
they provide, which include data integrity, user identification and
authentication, encryption and digital signature.

"The DOD PKI, in the context of the Defense-in-Depth strategy, will provide
a solid foundation for IA capabilities across the Department," Hamre wrote
in the memo, obtained by Inside the Army.

"The goal of this DOD-wide infrastructure is to provide general-purpose PKI
services (e.g. issuance and management of certificates and revocation lists
in support of digital signature and encryption services) to a broad range of
applications, at levels of assurance consistent with operational
imperatives," he continued.

"Implementation of these policies will ensure that DOD components are using
the infrastructure, and that future uses of public key cryptography as part
of the Department's Defense-in-Depth strategy are consistent with threat and
risk tolerance," Hamre concluded.

Hamre first outlined his plans for a defense-wide PKI in August 1997. The
going has been slow, however, due to the complexities involved in
implementing such an intricate system in such a large community. Just a few
weeks ago, DOD released its PKI Roadmap, which begins to spell out in detail
how the department will establish a PKI.

Key elements of the PKI are the issuance and revocation of digital
certificates, which are electronic proofs of identity. According to Hamre's
memo, Class 5 assurance certificates should be used for the sending of
classified information over unencrypted networks. Class 4 certificates will
be used for sending unclassified, mission critical information over
unencrypted networks, and for protection information crossing classification
boundaries.

Category one mission-critical systems, which the Clinger-Cohen Act says must
be related to command and control of military forces, integral to a weapon
or weapons system or critical to direct fulfillment of military or
intelligence missions, must begin migrating to Class 4 certificates and
tokens and achieve full implementation by June 2000, the memo states.

When operating over unencrypted networks, category two systems, which
operate in direct support of systems identified by commander-in-chiefs as
mission critical, and category three systems, which are required to perform
department level and component level core functions, must use a Class 3
certificates. "These systems, that employ public key cryptography, must
migrate to the use of Class 4 certificates and tokens by December 31, 2002,"
the memo states. "All other applications that employ public key technology
(e.g. mission critical information on encrypted networks using [National
Security Agency] Type 1 approved encryption, and mission
support/administrative information on any networks) must use Class 3
certificates. All DOD users, at a minimum, will be issued a Class 3
certificate by October 2001."

The Defense Department plans to leverage two ongoing PKI efforts for the
target PKI defined in the DOD road map: Fortezza (the near-term solution for
Class 4) and Class 3, formerly known as medium assurance PKI. The memo
directs DOD organizations to deploy trained personnel and installed software
and hardware for registration operations for the efforts, as well as
infrastructure with the capability to issue certificates from the Class 3
PKI to each member of the organization, by October 2000.

All certificates will evolve to Class 4 certificates with the target PKI,
the memo states. As hardware token technology becomes more mature and
ubiquitous, DOD will move from Class 3 to Class 4 certificates for all
applications, the memo states. Components will begin to issue the Class 4
certificates by January 2002. The planned architecture for the Class 4
certificate will draw on the features of an identification card, building
access token and workstation access token, on a single token.

By issuing a memo to get all DOD components on the same page, the overall
effort will be more cost-effective, the service source told ITA. "You need
to engage the buying power of DOD," he said. "When you're talking about
buying cards in the tens of thousands, it's very expensive, but when you
start talking about ordering in the hundreds of thousands, the price begins
to look quite reasonable."

The memo is also intended to make sure the services are on the same page to
ensure interoperability, he continued, and difficulties could result if any
of the components are lagging behind.

DOD plans to use external certificate authorities to ensure secure
interoperability between the department and its vendors and contractors,
according to the memo. "ECAs will operate under a process that delivers the
level of assurance that is required to meet business and legal
requirements," the document states.

By June 2000, DOD webservers that are not publicly accessible will need to
have a minimum of Class 3 certificates, and will use these certificates for
server authentication via Secure Sockets Layer protocol or higher, the memo
states; by October 2001, all private DOD and DOD-interest web servers will
require client identification and authentication using Class 3 user
certificates.

Incorporating the PKI policy in the tactical arena may present difficulties,
the source said. Officials will need to decide "who has the authority to do
what," he said. If an intelligence officer with access to restricted
information is killed or otherwise incapacitated, the person stepping into
his position must have the same attributes on his electronic identification
to be able to access the same information, he said, and it is difficult to
plan ahead for that type of contingency.

---

From: Stephen Kent <[email-masked]>
Date: Tue, 18 May 1999 17:34:40 -0400

Todd,

>operating 7x24 hrs and your comment doesn't seem to make sense to me in

The last time I sent a piece of certified mail, I received a printed
receipt from the postal clerk, generated by a PC, containing a time stamp,
the zip code of the destination, the post office ID, and the cost of the
postage.  Sounds a bit more high tech than what you describe, and this was
a limited service postal station in a small town.  certified mail, which is
an example of a postal service where time of sending is consider important,
has always involved direct interaction with a person, vs. dropping
something in a mailbox. i think your example, abovem, is a poor one, re the
context of our discussions.

Steve