Subject: New time stamping standard by ISO

From: "Stefan Santesson" <[email-masked]>
Date: Fri, 8 Sep 2006 20:54:38 +0100

It has come to my attention that ISO is working on a time stamping
standard which to a large part is based on RFC 3161 from this group.

Except this, the ISO draft ISO/IEC WD 18014-2.3 (by (ISO/IEC JTC1/SC27)
Defines the means to include time stamps in SignerInfo of CMS messages
(stand alone or as part of the time stamping protocol). They also
provide a complete XML syntax for time stamping.

I'm not involved in this work and this is nothing this group can
influence directly but I would still see value in getting input from
people here on at least one particular change they have made to the
ASN.1 syntax. 

RFC 3161 defines:

TimeStampToken ::= ContentInfo

-- contentType is id-signedData ([CMS])

-- content is SignedData ([CMS]) 

Where ISO/IEC WD 18014-2.3 defines:

TimeStampToken ::= CHOICE {

cms ContentInfo,

signerInfo [1] EXPLICIT SignerInfo

-- room for additional formats

}

This seems rather unnecessary as it creates another possible way to form
a time stamp response in the time stamping protocol which is just
confusing.

Unfortunately the draft document is secret and can not be distributed
(and I'm so grateful IETF doesn't work like that).

Stefan Santesson

Senior Program Manager

Windows Security, Standards

---

From: Peter Sylvester <[email-masked]>
Date: Mon, 18 Sep 2006 13:27:30 +0200

> I’m not involved in this work and this is nothing this group can 
I am not involved either, and your text snippet is small, so only some 
speculation.

This format seems to be targetted to transform the rfc 3161 example of 
how to add a timestamp
to a signature into a simple cms countersignature.

There seems to be a requirement to have this alternative format of the asn1
based token, one can either have new mime types or add something like 
the proposed syntax.
I assume that the xml protocol adds -xml to the mime types?

One also has to look what parameter allows client or servers to detect 
what response has to be
made or is acceptable.

maybe Denis knows more?

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

---

From: [email-masked] (Peter Gutmann)
Date: Thu, 21 Sep 2006 10:00:26 +1200

Peter Sylvester <[email-masked]> writes:

>This format seems to be targetted to transform the rfc 3161 example of how to
>add a timestamp to a signature into a simple cms countersignature.

This not-quite-countersignature issue been a known flaw in TSP for a long
time.  Amusingly enough, even the RFC admits that the way it does things is
stupid.  Instead of the usual "MUST xxx" when specifying how to do
timestamping with CMS, it uses the rather unusual text "a sensible place to
...", and then goes on to define something that looks like a CMS
countersignature but is gratuitously incompatible with CMS countersignatures.
Since what it's doing isn't "sensible", by the spec's own admission it's
stupid.  It's unusual to see such frankness in an RFC.

Peter :-).

---

From: Russ Housley <[email-masked]>
Date: Wed, 20 Sep 2006 21:32:38 -0400

Yet, everyone implement it this way, right?

If there is a need for change, it should begin with an update to RFC 3161.

Russ

---

From: "Stefan Santesson" <[email-masked]>
Date: Thu, 21 Sep 2006 03:03:39 +0100

I must admit that I have made a similar reflection about if the
complexity is beneficial, but this is the way it is and changing it at
this stage is most certainly more harmful than leaving it as is.

The motivation for ISO to expand on the choices is not well founded. And
there has been objections to it from the US side.

Stefan Santesson
Senior Program Manager

> -----Original Message-----
> From: Russ Housley [mailto:[email-masked]]
> Sent: den 20 september 2006 18:33
> To: [email-masked]; [email-masked]; Stefan
> Santesson
> Cc: [email-masked]
> Subject: Re: New time stamping standard by ISO
>

---

From: [email-masked] (Peter Gutmann)
Date: Thu, 21 Sep 2006 20:46:32 +1200

>Yet, everyone implement it this way, right?

Well of course they implement it that way, because the spec says they have to.
If the spec said they had to run naked down the middle of the road in order to
claim RFC 3161 compliance they'd do that too, even though it's not a sensible
thing to do.

>If there is a need for change, it should begin with an update to RFC 3161.

This problem was pointed out years ago, when the RFC was still in draft stage.
The authors ignored it, along with other comments people submitted about other
issues.  So I think ISO is the only forum for change.

Peter.

---

From: "Stefan Santesson" <[email-masked]>
Date: Thu, 21 Sep 2006 11:34:07 +0100

ISO can't change RFC 3161. At most they can create diversion.

Stefan Santesson
Senior Program Manager

> From: pgut001 [mailto:[email-masked]]
> Sent: den 21 september 2006 10:47
> To: [email-masked]; [email-masked];
> [email-masked]; Stefan Santesson
> Cc: [email-masked]
> This problem was pointed out years ago, when the RFC was still in
draft
> stage.

---

From: "José A. Mañas" <[email-masked]>
Date: Thu, 21 Sep 2006 14:21:07 +0200

I am working in the iso group updating the time-stamping standard.
It is not so much a brand-new standard.

I think everyone in the group understands that backwards
compatibility with 3161 is a must;
then we try to improve, and basically to standardize
improvements so there is some agreed way of doing things right.

The aims are
   - to keep 3161 tokens
   - to allow for cms "embeddable" tokens
   - to align xml and asn1 tokens

The new standard is still in the working draft stage,
so there is room for listening as wide an audience as possible.

Best
jam

---

From: "Stefan Santesson" <[email-masked]>
Date: Thu, 21 Sep 2006 14:40:40 +0100

Hi José

Since you participate in this effort in ISO, could you check if they for the interest of more effective liaison could make the draft available to people on this list.
After personally reviewing this draft I discovered some compliance problems with rfc 3161 and I may no have caught it all.

Critical parts or references to the full encoding of timeStampToken, especially the CMS parts, seems also be missing.

As of the CMS "embeddable" tokens, I find no explanation or use case motivating it or any discussion on interoperability issues with CMS parsing applications.
The purpose seems to be to allow addition of a timestamp to a standard CMS object, however this is not the only result. This results also in the TSA blindly signing the CMS object, not just the time stamp. I assume the ISO standard think this is OK since the TSA certificate contains the id-kp-timeStamping EKU only. But basically it is a breach of semantics that may lead to unexpected behaviors in legacy applications trying to understand the signatures of the CMS object.

Do you have the full story?

Stefan Santesson
Senior Program Manager
> From: "José A. Mañas" [mailto:[email-masked]]
> Sent: den 21 september 2006 14:21
> To: Peter Gutmann
> Cc: [email-masked]; [email-masked]; Stefan Santesson;
> [email-masked]
> draft stage.

---

From: "José A. Mañas" <[email-masked]>
Date: Thu, 21 Sep 2006 16:22:38 +0200

> Since you participate in this effort in ISO, could you check if they for the interest of more effective liaison could make the draft available to people on this list.
I can check, but the most likely answer is "no way".
The right option is that you get involved as an sc27 expert in your
country: you get drafts and the right to influence with your comments
and your vote

> After personally reviewing this draft I discovered some compliance problems with rfc 3161 and I may no have caught it all.
the iso standard is a 3 part standard

part 1 is rather stable, and just modifies one bit (on the wire)
wrt 3161

part 2 is wide open currently, there have been 3 drafts,
the last one late july;
after reading your text below, it might well be you are dealing with
an old one; but i am not sure

current draft is on the comment stage and will be discussed in november 
meeting

part 3 (about linked tokens) is not under modification

so i understand you refer to 18014-2

> As of the CMS "embeddable" tokens, I find no explanation or use case motivating it or any discussion on interoperability issues with CMS parsing applications.

that should be easy to repair,
tough the phrasing
	"interoperability issues with CMS parsing applications"
is too vague:
   - asn1 parsing is too trivial for you to mention
   - signerinfo parsing is as usual, up to signed attributes
   - then there is a new kind of attribute with its own semantics

can you be more precise about your concern?

> The purpose seems to be to allow addition of a timestamp to a standard CMS object,

the purpose is to produce a SignerInfo where the signer is a TSA
and the signed attribute is the time-value
(plus plus for non-repudiation issues)

> however this is not the only result.
 > This results also in the TSA blindly signing the CMS object, not just 
the time stamp.
somehow

the tsa is not expected to have access to the actual contents,
but as far as the message-digest attribute is present: yes,
the tsa is actually signing it

current cms (3852) is strict in page 39
"Within signed-data, the message-digest signed attribute type MUST be
  present when there are any signed attributes present.  ..."

i guess you refer to that text

and the message-digest attribute is expected to be there
since the tsa is using that piece of knowledge to bind the time to

> I assume the ISO standard think this is OK since the TSA certificate contains the id-kp-timeStamping EKU only.
right

> But basically it is a breach of semantics that may lead to unexpected behaviors in legacy applications trying to understand the signatures of the CMS object.
Mmmm,
do you mean in applications that do not care after the policy that
the signer applies to the signature?

> Do you have the full story?
I´m not sure; so I tried to explain my point of view above...

best
jam

---

From: [email-masked] (Peter Gutmann)
Date: Fri, 22 Sep 2006 03:57:38 +1200

"Stefan Santesson" <[email-masked]> writes:

>ISO can't change RFC 3161. 

True, but they can at least create a fixed version.

Peter.

---

From: "Stefan Santesson" <[email-masked]>
Date: Fri, 22 Sep 2006 04:50:28 +0100

José

Thanks for the answer. This gets more into a CMS discussion and maybe should be moved the the S/MIME group, but the basic issues are 2.

1) The changes/amendments to RFC 3161 (even if it is a single bit, but in fact it is more. RFC 3161 restrict the CMS type to SignedData, the ISO draft does not)
2) The appropriateness of letting the TSA actually sign the time-stamped message, not just the time stamp info (TSTInfo).

> > But basically it is a breach of semantics that may lead to unexpected
> behaviors in legacy applications trying to understand the signatures of
> the CMS object.
> Mmmm,

I assume the choice of SignerInfo as alternative token structure is so that it will be included in a CMS SignedData.
However, this is not explicitly stated. If it is then the TSA has, by CMS definitions, just become signer of the encapsulated data, not only the timestamp.
But at the same time it has an extended key usage in its certificate that is incompatible with this role as message signer. They way I read CMS and Signed Data, the TSA can not only sign the signed attribute in SignerInfo, it MUST also sign the encapsulated data in SidnedData.

To me this feels like a conflict and I worry about how applications will deal with it. 

I have access to the drafts, but I was more interested in the review from other people in this group.

Stefan Santesson
Senior Program Manager

> Sent: den 21 september 2006 16:23
> To: Stefan Santesson
> Cc: Peter Gutmann; [email-masked]; [email-masked];
> [email-masked]
> > Since you participate in this effort in ISO, could you check if they
> for the interest of more effective liaison could make the draft
> available to people on this list.
> > After personally reviewing this draft I discovered some compliance
> problems with rfc 3161 and I may no have caught it all.
> > Critical parts or references to the full encoding of timeStampToken,
> especially the CMS parts, seems also be missing.
> >
> > As of the CMS "embeddable" tokens, I find no explanation or use case
> motivating it or any discussion on interoperability issues with CMS
> parsing applications.
> 
> > I assume the ISO standard think this is OK since the TSA certificate
> contains the id-kp-timeStamping EKU only.
> right
> 
> > But basically it is a breach of semantics that may lead to unexpected
> behaviors in legacy applications trying to understand the signatures of
> the CMS object.
> Mmmm,
> >>> Well of course they implement it that way, because the spec says
> they
> >> have to.
> >>> If the spec said they had to run naked down the middle of the road
> in
> >> order to
> >>> claim RFC 3161 compliance they'd do that too, even though it's not
> a
> >> sensible
> >>> thing to do.
> >>>
> >>>> If there is a need for change, it should begin with an update to
> RFC
> >> 3161.

---

From: "José A. Mañas" <[email-masked]>
Date: Fri, 22 Sep 2006 07:59:04 +0200

Stefan Santesson wrote:
 > José
 >
 > Thanks for the answer. This gets more into a CMS discussion and maybe 
should be moved the the S/MIME group, but the basic issues are 2.
 >
 > 1) The changes/amendments to RFC 3161 (even if it is a single bit, 
but in fact it is more. RFC 3161 restrict the CMS type to SignedData, 
the ISO draft does not)
the one bit i refer to is between 18014-1:2002 and current drafts

the usage of other cms constructions has been there for years,
and it is not breaking cms at all: it is standard usage

 > 2) The appropriateness of letting the TSA actually sign the 
time-stamped message, not just the time stamp info (TSTInfo).

 > I assume the choice of SignerInfo as alternative token structure is 
so that it will be included in a CMS SignedData.

the picture is that the contents gets several signatures
(either in parallel or nested)

each signature has its value; but all of them deal with the same contents

 > However, this is not explicitly stated. If it is then the TSA has, by 
CMS definitions, just become signer of the encapsulated data, not only 
the timestamp.
 > But at the same time it has an extended key usage in its certificate 
that is incompatible with this role as message signer. They way I read 
CMS and Signed Data, the TSA can not only sign the signed attribute in 
SignerInfo, it MUST also sign the encapsulated data in SidnedData.
 > To me this feels like a conflict and I worry about how applications 
will deal with it.

theoretically, i'd say it is a new usage applications may (or may not) 
adapt to.
anyhow, from a business point of view, accepting a signature
without understanding its policy sounds strange;
i'd expect old applications to follow an
	adapt or ignore
policy with respect to this "strange" signerinfo

if you ignore the signature, there is no time-stamp
(by these means - still there are independent tokens,
and AdES formats; btw, also extended cms usage)

i do not foresee a big problem, but sure actual implementors have
something to say about

 > I have access to the drafts, but I was more interested in the review 
from other people in this group.

i think we can discuss on the list (and/or smime)
but distributing the documents is against iso nda
... as far as i know ...

jam

---

From: Russ Housley <[email-masked]>
Date: Thu, 21 Sep 2006 17:54:47 -0400

Wouldn't it be better to explain the things that you see as 
shortcomings and work with the IETF PKIX WG to come to a mutually 
acceptable solution?

Russ

At 08:21 AM 9/21/2006, José A. Mañas wrote:
>>they have to.
>>in order to

---

From: "Stefan Santesson" <[email-masked]>
Date: Fri, 22 Sep 2006 17:05:51 +0100

Russ,

There are 2 issues worth discussing as I see it. One directly related to RFC 3161 and one to S/MIME

1) Change of the TimeStampToken

RFC 3161 define:

ISO/IEC WD 18014-2.3 expand this to:

Two issues with this, it adds alternatives to how a TSA may respond to a timestamp request. Even it this fits on top of RFC 3161, it introduce the aspect and need for negotiating response formats, secondly, when ContentInfo is used, RFC 3161 requires contentType to be SignedData, ISO/IEC WD 18014-2.3 allows it to be almost anything.

2) Making the TSA signer of the document of a time-stamped signature
Traditionally a TSA has been seen as an entity signing the time of an event or the existence of a document, but not signing the document itself.
ISO/IEC WD 18014-2.3 changes this and introduces an alternative (where the TimStampToken takes the form of a SignerInfo). Here the TSA is signing BOTH the time stamped message AND the timestamp (TSTInfo) provided in a signed attribute. The TSA makes this with a certificate with an EKU explicitly restricted to time-stamping.

So we have a semi situation where the TSA kind of has signed the CMS message, but kind of not (if you care about the EKU).

The question is if this is a reasonable use of CMS, and if it is reasonable to have the TSA signing the message. I feel that this whole concept is shaky, stretching CMS semantics and I fear all sorts of unexpected errors. Basically, I don't like it.

Stefan Santesson
Senior Program Manager

> From: [email-masked] [mailto:owner-ietf-
> [email-masked]] On Behalf Of Russ Housley
> Sent: den 21 september 2006 23:55
> To: José A. Mañas
> Cc: [email-masked]

---

From: Stephen Kent <[email-masked]>
Date: Mon, 25 Sep 2006 16:01:39 -0400

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

---

From: "José A. Mañas" <[email-masked]>
Date: Wed, 27 Sep 2006 08:07:55 +0200

> hash of a document, as a way to time stamp the data contained in the 

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

---

From: "Stefan Santesson" <[email-masked]>
Date: Wed, 27 Sep 2006 16:42:17 +0100

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

> Sent: den 27 september 2006 08:08
> To: Stephen Kent
> Cc: Stefan Santesson; Russ Housley; [email-masked]

---

From: "Peter Rybar" <[email-masked]>
Date: Thu, 28 Sep 2006 15:20:09 +0200

> 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:[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

Stefan Santesson
Senior Program Manager

---

From: "Stefan Santesson" <[email-masked]>
Date: Thu, 28 Sep 2006 15:19:13 +0100

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

> 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]
> 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:
> (
> 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.
> 
>   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  {
> [email-masked]] On Behalf Of Stefan Santesson
> 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.
>

---

From: "Stefan Santesson" <[email-masked]>
Date: Thu, 28 Sep 2006 18:09:13 +0100

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

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

---

From: Peter Sylvester <[email-masked]>
Date: Thu, 28 Sep 2006 18:48:22 +0200

or else. A countersignature can simply be a confirmation that the signer had
the right to sign.

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:
>>>> I too am not comfortable with a TSA signing a document, vs. signing
>>>>         
>> a
>>

---

From: Peter Sylvester <[email-masked]>
Date: Thu, 28 Sep 2006 19:47:33 +0200

> 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…
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.
>>>> Second module: The signing CMS module can have more then one HSM and
>>>>         
>> it
>>     
>>>> Binary TSTInfo document contains especially trusted connection
>>>>         
>> between
>>     
>>>>   id-aa-ets-contentTimestamp = The value of messageImprint field
>>>>         
>> within
>>     
>>>> (HASH of the signed document which can be added during the signature
>>>>         
>> as
>>     
>>>> Or it can be a id-aa-signatureTimeStampToken, id-aa-ets-
>>>>         
>> escTimeStamp,
>>     
>>>>    extensions                   [1] IMPLICIT Extensions   OPTIONAL
>>>>         
>> }
>>     
>>>>
>>>> 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
>>

---

From: "José A. Mañas" <[email-masked]>
Date: Thu, 28 Sep 2006 21:34:34 +0200

> one reason is about what CMS types are actually supported in the wild.

a new cms type sounds as an overkill

3161 produces a CMS-SignedData where the contents is the TSTInfo

AdES adds such a CMS thing as an unsigned attribute to another
CMS-SignedData

ISO merges both into a TS-SignerInfo attached to the subject CMS-SignedData;
as is the case when you sign a paper, and the public administration
adds a time-stamp to the same paper acknowledging receipt

jam

---

From: "José A. Mañas" <[email-masked]>
Date: Thu, 28 Sep 2006 21:35:45 +0200

> I am not so sure.  I think the assumption is to use a countersignature.

I do not think this is the intention of countersignatures.
If you sign B, I may countersign your signature.
Though the asn1 structure is quite similar,
the bits that go into the hashing are different ones.

The tsa could time-stamp the original contents,
or the signed content,
using the same structs;

as mentioned previously, the thing that makes the signature
a different kind of signature is not the structure,
but the signing policy of the tsa

and that lack of structural difference is the one that
makes stefan feel uneasy -- if i summarized correctly

> you would only give a hash.

you might be interested on time-stamping a countersignature;
i see this as orthogonal to (signing | countersigning)

> of the TSTInfor would be replaced by signed attributes or so for example.

it is a pity I cannot put forth the text;
but i may try to explain it shortly

according to cms way of doing things,
in order to produce a SignerInfo you do not need the contents,
only its hash;
if anybody provides the hash, you may sign it

sure it is dangerous to sign a hash without knowing what is after it,
UNLESS you state clearly that you are not agreeing to
the bulk contents of the document

i have seen may signatures attached to the same document,
where each signer has a specific role and liabilities;
for instance, in adobe, you may explicitly choose out of
a number of predefined reasons to sign
   - I attest to the accuracy and integrity of this document
   - I agree to the terms defined by the placement of
     my signature on this document
   - I am the author of this document
   - I have reviewed this document
   - I am approving this document
   - I agree to specified portions of this document

In commercial transactions, there are usually several signatures
   - the seller commits to deliver the specified product
   - the buyer commits to pay the specified price
   - a third party may provide an insurance to cover the transaction,
     without involving itself on delivering or paying
   - a tsa may involve herself as a proof of time
   - ...

so, as far as the relation of the signer to the contents is an
unforgeable statement, i am not nervous about

imho, of course,
jam

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

---

From: "Stefan Santesson" <[email-masked]>
Date: Fri, 29 Sep 2006 00:32:28 +0100

> adds a time-stamp to the same paper acknowledging receipt

I do not agree with this analogy. IN the ISO approach, according to CMS, the TSA adds another time stamped signature to the document, indeed signing the document.
AdES, however only adds a time stamp.

That does not make me a big fan of AdES, but it is the way it works.

Stefan Santesson
Senior Program Manager

> Sent: den 28 september 2006 21:35
> To: Peter Sylvester
> Cc: Stefan Santesson; Peter Rybar; Stephen Kent; Russ Housley; ietf-
> [email-masked]

---

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

Stefan Santesson wrote:

 > I do not agree with this analogy. IN the ISO approach, according to 
CMS, the TSA adds another time stamped signature to the document, indeed 
signing the document.
 > AdES, however only adds a time stamp.

sorry,
i think it is only poor wording of mine;
perhaps "analogy" is not the right way of speaking ...

in AdES you attach a tsa attribute to one signerinfo pack
(the attribute happens to be a cms-signeddata itself)

in ADES the aim is to qualify the signature

in iso a new signerinfo is attached to one cms pack;
therefore, the time-stamp becomes one more commitment
to the same contents
(that is, the tsa stating existence at some point of time)

jam

---

From: "Peter Rybar" <[email-masked]>
Date: Fri, 29 Sep 2006 11:31:51 +0200

Thanks Stefan,
I was afraid of inaccurate understanding of RFC 3161 from other discussions being sent about this problem.

Timestamp is CMS signature which can be inserted to another CMS signature as signed attribute (id-aa-ets-contentTimestamp) or as unsigned attribute (id-aa-signatureTimeStampToken, id-aa-ets-escTimeStamp, id-aa-ets-certCRLTimestamp, id-aa-ets-archiveTimestamp).
Timestamp according to RFC 3161 is not a countersignature and there was the misunderstanding!

If ISO plans to do that as a countersignature then it looks like as problem in implementations in some applications.
The countersignature is an unsigned attribute of the type SignerInfo which is included in the main SignerInfo and the countersignature signs hash of the signature (SignatureValue) within the main SignerInfo.
If new CMS attribute type will be defined then it will depend on its definition.  

Peter Rybar

-----Original Message-----
From: Stefan Santesson [mailto:[email-masked]] 
Sent: Thursday, September 28, 2006 4:19 PM
To: Peter Rybar; "José A. Mañas"; Stephen Kent
Cc: Russ Housley; [email-masked]
Subject: RE: New time stamping standard by ISO

Peter,

Did I misunderstand you?

Stefan Santesson
Senior Program Manager

---

From: Jean-Marc Desperrier <[email-masked]>
Date: Fri, 29 Sep 2006 19:17:22 +0200

> I was afraid of inaccurate understanding of RFC 3161 from other discussions being sent about this problem.
There seem to be some confusion indeed lying here, and not having a 
*good* description of what there is in the ISO doc will not help.
> The countersignature is an unsigned attribute of the type SignerInfo which is included in the main SignerInfo and the countersignature signs hash of the signature (SignatureValue) within the main S…
RFC3161 defines timestamp as an unsigned attribute inside a  SignerInfo 
that signs hash of the signature (SignatureValue) within that SignerInfo 
(I will not cover here the various CADES variations).

So this is extremly similar to a counter signature except that
- the format of the counter signature is SignerInfo and
- the format of the token is TimeStampToken (a signed CMS whose signed 
content is a TSTInfo structure with various information amongst which 
the hash ).

How can the ISO standard be nearer to a counter signature than that ? Is 
it that the ISO standard defines the timestamp as a SignerInfo 
structure  and uses specific signed attributes to add the needed 
additional info for a time-stamp ?