[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: New time stamping standard by ISO

Stefan Santesson wrote:

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.

I think that an open discussion would be useful.

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.
Ah, this looks like someone just wants to timestamp data and combine the data and the timestamp, Since CMS is a way to add envelopes. One could create a timestampedData for example. I think 
one reason is about what CMS types are actually supported in the wild.


Stefan Santesson
Senior Program Manager
Windows Security, Standards


-----Original Message-----
From: Peter Sylvester [mailto:Peter.Sylvester@xxxxxxxxxx]
Sent: den 28 september 2006 18:48
To: Stefan Santesson
Cc: Peter Rybar; "José A. Mañas"; Stephen Kent; Russ Housley; ietf-
pkix@xxxxxxx
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:rybar@xxxxxxxx]
Sent: den 28 september 2006 15:20
To: Stefan Santesson; '"José A. Mañas"'; 'Stephen Kent'
Cc: 'Russ Housley'; ietf-pkix@xxxxxxx
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: owner-ietf-pkix@xxxxxxxxxxxx [mailto:owner-ietf-
pkix@xxxxxxxxxxxx] On Behalf Of Stefan Santesson
Sent: Wednesday, September 27, 2006 5:42 PM
To: "José A. Mañas"; Stephen Kent
Cc: Russ Housley; ietf-pkix@xxxxxxx
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:jmanas@xxxxxxxxxx]
Sent: den 27 september 2006 08:08
To: Stephen Kent
Cc: Stefan Santesson; Russ Housley; ietf-pkix@xxxxxxx
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.








--
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.

Attachment: smime.p7s
Description: S/MIME Cryptographic Signature