Subject: Re: New time stamping standard by ISO

From: "Denis Pinkas" <[email-masked]>
Date: Fri, 29 Sep 2006 09:04:18 +0200

Stefan or any other involved in this thread,

Would you be able to provide the document number of the SC27 document 
so that people on the PKIX list may dig it more easily from their ISO NB ?

Additional question : when is the dead line for sending NB comments to SC 27 ?

Denis

>Peter,
>
>You put the finger on the problem of this discussion, we don't have the draft because its secret.
>I personally have the draft but can't distribute it.
>
>I was rising the discussion here in order to hear the opinions from pkix "members" with the intent to forward them to ISO.
>
>However, ISO/IEC WD 18014-2.3 is pretty clear in the fact that the outcome of the so called "time-stamping signature" is a signature on the original message where the TSA is the signer. The concept of counter signing is not mentioned at all. The TSTInfo is provided as a signed attribute in a standard SignerInfo signing the original message.
>
>
>Stefan Santesson
>Senior Program Manager
>Windows Security, Standards
>
>> -----Original Message-----
>> From: Peter Sylvester [mailto:[email-masked]]
>> Sent: den 28 september 2006 18:48
>> To: Stefan Santesson
>> Cc: Peter Rybar; "José A. Mañas"; Stephen Kent; Russ Housley; ietf-
>> [email-masked]
>> Subject: Re: New time stamping standard by ISO
>> 
>> I am not so sure.  I think the assumption is to use a countersignature.
>> 
>> What is the context of a countersignature. The input of the
>> countersignature is
>> the signature, and not the document that was signed, at least if my
>> reading of CMS is correct.:CMS does not say anything
>> about whether you should first validate a signature before creating a
>> countersignature
>> or else. A countersignature can simply be a confirmation that the
>> signer had
>> the right to sign.
>> 
>> A timestamp formatted as a countersignature goes indeed a little bit
>> further because
>> you would only give a hash.
>> 
>> Again, since I do not have the proposed text, I do not know how the
>> content data
>> of the TSTInfor would be replaced by signed attributes or so for
>> example.
>> 
>> Peter
>> 
>> 
>> Stefan Santesson wrote:
>> > Peter,
>> >
>> > It appears to me that you are describing (and defending) the RFC 3161
>> time-stamp protocol, which we all agree are correct and which does not
>> make the TSA a signer of the document.
>> >
>> > The discussion here is that an ISO standard under development
>> (ISO/IEC WD 18014-2.3) has expanded on the RFC 3161 time-stamping
>> model, and offer an alternative where the TSTInfo is provided as a
>> signed attribute of a SignerInfo amended to the original document,
>> making the TSA signer of the document.
>> >
>> > Did I misunderstand you?
>> >
>> >
>> > Stefan Santesson
>> > Senior Program Manager
>> > Windows Security, Standards
>> >
>> >
>> >> -----Original Message-----
>> >> From: Peter Rybar [mailto:[email-masked]]
>> >> Sent: den 28 september 2006 15:20
>> >> To: Stefan Santesson; '"José A. Mañas"'; 'Stephen Kent'
>> >> Cc: 'Russ Housley'; [email-masked]
>> >> Subject: RE: New time stamping standard by ISO
>> >>
>> >>
>> >>
>> >>> the TSA becomes signer of the document without ever have seen it.
>> >>>
>> >> Timestamp is a simple automatic application, which signs binary
>> >> document specified in RFC 3161 as TSTInfo and this binary TSTInfo
>> >> document is included in CMS internal signature created by TSA.
>> >>
>> >> First module: The timestamp application module which creates binary
>> >> TSTInfo document can be stand-alone with trusted source of time.
>> >>
>> >> Second module: The signing CMS module can have more then one HSM and
>> it
>> >> signs only some data like TSTInfo with specific requirement of CMS
>> >> attributes:
>> >> (
>> >>   eContentType within SignedData is id-ct-TSTInfo
>> >>   eContent within SignedData is TSTInfo
>> >>
>> >>   signedAttrs within SignerInfo contain contentType (1 2 840 113549
>> 1 9
>> >> 3)
>> >>        within OBJECT IDENTIFIER id-ct-TSTInfo(1 2 840 113549 1 9 16
>> 1
>> >> 4)
>> >>   ...
>> >> )
>> >>
>> >> Binary TSTInfo document contains especially trusted connection
>> between
>> >> HASH in messageImprint and the trusted time in genTime. TSTInfo
>> >> contains also another useful attributes like TSA Policy Id in the
>> >> policy attribute.
>> >>
>> >> It means that the timestamp is CMS signature which can be used as a
>> >> proof that something from which  HASH was generated had been present
>> >> before the time when the TSTInfo document was created and signed.
>> >>
>> >> It can by used as  mentioned in RFC 3126:
>> >>   id-aa-ets-contentTimestamp = The value of messageImprint field
>> within
>> >> TimeStampToken must be hash of the value of eContent field within
>> >> encapContentInfo within the signedData.
>> >> (HASH of the signed document which can be added during the signature
>> as
>> >> a proof that signed document has existed before the signing time)
>> >>
>> >> Or it can be a id-aa-signatureTimeStampToken, id-aa-ets-
>> escTimeStamp,
>> >> id-aa-ets-certCRLTimestamp, id-aa-ets-archiveTimestamp.
>> >>
>> >> Peter Rybar
>> >>
>> >>
>> >> TSTInfo ::= SEQUENCE  {
>> >>    version                      INTEGER  { v1(1) },
>> >>    policy                       TSAPolicyId,
>> >>    messageImprint               MessageImprint,
>> >>      -- MUST have the same value as the similar field in
>> >>      -- TimeStampReq
>> >>    serialNumber                 INTEGER,
>> >>     -- Time-Stamping users MUST be ready to accommodate integers
>> >>     -- up to 160 bits.
>> >>    genTime                      GeneralizedTime,
>> >>    accuracy                     Accuracy                 OPTIONAL,
>> >>    ordering                     BOOLEAN             DEFAULT FALSE,
>> >>    nonce                        INTEGER                  OPTIONAL,
>> >>      -- MUST be present if the similar field was present
>> >>      -- in TimeStampReq.  In that case it MUST have the same value.
>> >>    tsa                          [0] GeneralName          OPTIONAL,
>> >>    extensions                   [1] IMPLICIT Extensions   OPTIONAL
>> }
>> >>
>> >>
>> >>
>> >> -----Original Message-----
>> >> From: [email-masked] [mailto:owner-ietf-
>> >> [email-masked]] On Behalf Of Stefan Santesson
>> >> Sent: Wednesday, September 27, 2006 5:42 PM
>> >> To: "José A. Mañas"; Stephen Kent
>> >> Cc: Russ Housley; [email-masked]
>> >> Subject: RE: New time stamping standard by ISO
>> >>
>> >>
>> >> You sign the document bits by encrypting the hash of the document in
>> a
>> >> signing context. So Yes, according to the CMS format (which defines
>> the
>> >> signing context for SignerInfos in SignedData), the TSA becomes
>> signer
>> >> of the document without ever have seen it.
>> >>
>> >> I think that is bad design of a standard and the motivation for it
>> >> still escapes me.
>> >>
>> >> Stefan Santesson
>> >> Senior Program Manager
>> >> Windows Security, Standards
>> >>
>> >>
>> >>> -----Original Message-----
>> >>> From: "José A. Mañas" [mailto:[email-masked]]
>> >>> Sent: den 27 september 2006 08:08
>> >>> To: Stephen Kent
>> >>> Cc: Stefan Santesson; Russ Housley; [email-masked]
>> >>> Subject: Re: New time stamping standard by ISO
>> >>>
>> >>> Stephen Kent wrote:
>> >>>
>> >>>> Stefan,
>> >>>>
>> >>>> I too am not comfortable with a TSA signing a document, vs.
>> signing
>> >>>>
>> >> a
>> >>
>> >>>> hash of a document, as a way to time stamp the data contained in
>> >>>>
>> >> the
>> >>
>> >>>> document.
>> >>>>
>> >>>> Steve
>> >>>>
>> >>>>
>> >>> the tsa is not signing any document bits, but only the hash of them
>> >>>
>> >>> however, I understand that technically (bits on the asn1 construct)
>> >>> the signer info does not make any structural difference
>> >>>
>> >>> jam
>> >>>
>> >>
>> >
>> >
>> >
>> >
>> >
>> 
>> 
>> --
>> To verify the signature, see http://edelpki.edelweb.fr/
>> Cela vous permet de charger le certificat de l'autorité;
>> die Liste mit zurückgerufenen Zertifikaten finden Sie da auch.
>
>

Regards,

Denis Pinkas

---

From: "José A. Mañas" <[email-masked]>
Date: Fri, 29 Sep 2006 10:34:40 +0200

> Additional question : when is the dead line for sending NB comments to SC 27 ?

The current WD is
	SC27N5134_3rdWD_18014-2_Jul2006.pdf

The deadline for comments is
	30.9.2006 (tomorrow)

anyhow, besides formal comments,
i'd try to listen to informal comments too,
and try to push for the best

jam