Subject: [pkix] New Time-Stamp (RFC3161 update) draft available

From: Stefan Santesson <[email-masked]>
Date: Mon, 24 Aug 2009 19:31:18 +0200

A new RFC 3161 (Time-Stamping) update draft is available at:
http://www.ietf.org/id/draft-ietf-pkix-rfc3161-update-00.txt

This draft is submitted following the decision by the WG to reject the
recently expired draft-ietf-pkix-rfc3161bis-01.txt as basis for updating
RFC3161.

The new draft is limited to updating RFC3161 by allowing use of ESSCertIDv2
defined in RFC 5035.

/Stefan

---

From: Sean Turner <[email-masked]>
Date: Mon, 24 Aug 2009 13:58:29 -0400

Stefan,

I think these are all editorial:

throughout: r/SHA 1/SHA-1

sec 1:

OLD:

The time stamping protocol defined in RFC 3161 [RFC3161] require CMS 
[RFC3852] signatures on time-stamp tokens to include an identifier of 
the signer's certificate to be included as a signed attribute according 
to [ESS].

NEW:

The time stamping protocol defined in RFC 3161 [RFC3161] requires that 
the CMS SignedData [RFC3852] used to apply a digital signature on the 
time-stamp token include a signed attribute that identifies the signer's 
certificate.

sec 1:

OLD:

RFC 2634 [ESS] has since then been updated by RFC 5035 [ESSv2] which 
defines the updated certificate identifier ESSCertIDv2, which allows use 
of any hash algorithm.

NEW:

The mechanism used in [RFC3161] employed ESSCertID from RFC 2634 [ESS]. 
  RFC 5035 [ESSv2] updated ESSCertID with ESSCertIDv2 to allow the use 
of any hash algorithm.

sec 1: last para missing period at the end.

sec 3: 1st para missing period.

sec 4: missing period.

References: Is [SHA1] really normative or should it be informative?  You 
don't have to do SHA-1 to implement this ID so shouldn't it be informative?

Cheers,

spt

Stefan Santesson wrote:
> ------------------------------------------------------------------------
> 
> _______________________________________________
> pkix mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/pkix

---

From: Stefan Santesson <[email-masked]>
Date: Mon, 24 Aug 2009 21:37:21 +0200

Thanks Sean,

I took them all and updated the draft.  A new version 01 is available with
the updates:
http://www.ietf.org/id/draft-ietf-pkix-rfc3161-update-01.txt

/Stefan

---

From: Stefan Santesson <[email-masked]>
Date: Mon, 24 Aug 2009 21:46:38 +0200

OK, you don't have to tell me. I noticed I missed this one....
I promise you will have your "dot" in the next version :)

/Stefan

---

From: Peter Sylvester <[email-masked]>
Date: Tue, 25 Aug 2009 14:52:45 +0200

The text allows for having only a essCertIDv2

      If the certReq field is present and set to true, the TSA's public
      key certificate that is referenced by the ESSCertID [ESS] field
      inside a SigningCertificate attribute or by the ESSCertIDv2
      [ESSv2] field inside a SigningCertificateV2 attribute in the
      response MUST be provided by the TSA in the certificates field
      from the SignedData structure in that response.  That field may
      also contain other certificates.

   This allows the token to be incompatible with 3161 if only a V2 attribute
   is added, is this intended? 

   This paragraph concerns certReq, it should not mention
   the certificate content at all. (Only in 2.4.2 it should be mentioned)

---

From: Stefan Santesson <[email-masked]>
Date: Thu, 27 Aug 2009 09:45:21 +0200

Peter,

In-line.

>    is added, is this intended?

Yes and no. If the hash algorithm is SHA-1 then you SHOULD use the old
structure (ESS), making it compatible. If you are using a hash algorithm
other than SHA-1, then only clients that understands ESSv2 will be able to
parse it.

This is how I have been told that this is implemented.

>    the certificate content at all. (Only in 2.4.2 it should be mentioned)

This and the following paragraph in RFC 3161 discuss the servers response to
presence or absence of a certReq field in the request. It seems appropriate
to me.

/Stefan

---

From: Peter Sylvester <[email-masked]>
Date: Thu, 27 Aug 2009 12:08:26 +0200

S
> This is how I have been told that this is implemented.
Using a hash where?
"this" is what, and what do you mean by "is implemented"?
"I have been told" == in french "On m'a dit .."?  :-)

- When one wants to  make a "stronger that sha-1 based "reference",
  then one has to use the new attribut.  This has the advantadge that
  one can continue to set the sha-1 based attribut IF one desires not to
  break  existing verifiers. To me, ESSv2 seems to encourage this IMO

- The update to 3161 say "or", i.e. allows  to use the new attribut alone,
  "or" may  be understood as  "either or",  at  least,  ESSv2 may allow
  such non-interoperability, but  is this desired her.

  A TSA that does not set the the sha-1 based reference is shooting itself
  into the foot at least until the two major timestamp
  token validators are updated and deployed, not even speaking
  of all other handwritten ones.

  I'd recommend to really "update" by saying somthing like
  An implementation MAY add an ESSv2 signingcert attribute
  if a reference with a stronger protection that sha-1 is desired.
  When interoperability with existing time stamp token is
  required, it MUST also the ess signingCertificate attribut.
> presence or absence of a certReq field in the request. It seems appropriate
well, the same texts occurs at three places but not
in paragraph 2.3 which talks about 'identification'. Well, ...

Anyway:

- A request is always encoded in DER, thus, a "default false" value
  is always absent in the encoding. or set to false is misleading.
  and replace "when it is present and true" by when it is true.
  (same error is there for "ordering" in the response)
  ==> errata.

- Practice has shown, that requiring absence when certReq is
  not set is a useless restriction. No client seems to be hurt.

IMO The two paragraphs should simply be replaced by

  "When certReq is indicated, the TSA SHOULD provide a validating
   certificate (including any desirable chain) as part of the signedData"

  or  at least the "MUST not be present"  replaced by "SHOULD not be 
present"
  in the second paragraph.

of course, this is not really part of an update for hash algo agility.