Subject: RE: Using Signature Policy in RFC-5126

From: "Yasir Khan" <[email-masked]>
Date: Thu, 3 Jul 2008 21:07:15 +0500

RFC 5126 explains how to create archived time stamp i.e.

ArchiveTimeStampToken ::= TimeStampToken

   The value of the messageImprint field within TimeStampToken shall be

   a hash of the concatenation of:

      - the encapContentInfo element of the SignedData sequence;

      - any external content being protected by the signature, if the

        eContent element of the encapContentInfo is omitted;

      - the Certificates and crls elements of the SignedData sequence,

        when present, and;

      - all data elements in the SignerInfo sequence including all

        signed and unsigned attributes.

The ArchiveTimeStamp will be added as an unsigned attribute in the
SignerInfo sequence.

According to the RFC, it is clear that message imprint will be the hash of
above concatenated values but it is not explained how to concatenate these
values? Please clarify this point. Some hint for implementing this would be
highly appreciated. Thanks!

----------------------------------------------------------------------------
------

YASIR KHAN
Development Manager

Ascertia Limited
 <http://www.ascertia.com/> www.ascertia.com   

www.globaltrustfinder.com <http://www.globaltrustfinder.com/>  

----------------------------------------------------------------------------
------

Delivering Trust for e-business Documents & Workflows

----------------------------------------------------------------------------
------

NOTICE: This message is intended for the recipient(s) only. This
communication may contain privileged or other

confidential information. If you are not the intended recipient, or believe
that you have received this communication in

error, please do not print, copy, retransmit, disseminate, or otherwise use
the information. Please notify the sender that

you have received this email in error, and delete the copy you received

  _____  

From: [email-masked] [mailto:[email-masked]]
On Behalf Of Pavel V. Smirnov
Sent: Thursday, June 26, 2008 1:04 PM
To: 'Yasir Khan'; [email-masked]
Subject: RE: Using Signature Policy in RFC-5126

Yes, I mean "digital signature policy" as a "policy document" present at
SPUri. But I use SPUri only for example, you may specify a SigPolicyId and
omit sigPolicyQualifiers at all. In this case you have to rely on some other
means to convey a correspondence between SigPolicyIds and "policy
documents".

In case of SPuri you have to retrieve a "policy document" by its URI and
hash it.

Note that if your infrastructure provides a trusted source of "policy
documents", and there will never be two different (versions of) "policy
documents" identified by the same OID, you don't have to hash them at all.
Just use zero policy hash value.

Pavel Smirnov

Crypto-Pro
Tel./Fax: +7 495 780-4820
WWW:  <http://www.cryptopro.ru/> http://www.CryptoPro.ru
e-mail:  <mailto:[email-masked]> [email-masked]

From: [email-masked] [mailto:[email-masked]]
On Behalf Of Yasir Khan
Sent: Thursday, June 26, 2008 12:19 PM
To: Смирнов Павел Владимирович; [email-masked]
Subject: RE: Using Signature Policy in RFC-5126

You wrote: "You have to hash a digital signature policy represented as a
sequence of bytes in some format and place the computed value in
SigPolicyHash."

To which item you are naming as "digital signature policy". You mean policy
document present at SPUri? If Yes then it makes some sense. But if only
SPUserNotice is present or nothing is present as sigPolicyQualifiers as it
is an OPTIONAL element:

            sigPolicyQualifiers SEQUENCE SIZE (1..MAX) OF
SigPolicyQualifierInfo OPTIONAL

then on which item the hash would be computed?

Regards,

Yasir Khan

  _____  

From: Pavel V. Smirnov [mailto:[email-masked]] 
Sent: Wednesday, June 25, 2008 4:07 PM
To: 'Yasir Khan'; [email-masked]
Subject: RE: Using Signature Policy in RFC-5126

Hello Yasir,

There is no need to protect by SigPolicyHash other fields of
SignaturePolicyId structure because it is placed in a signed attribute. All
signed attributes are protected by the signature itself.

In most cases the policy would be an external document not included in your
signed message, and you have to unambiguously indicate specific policy with
respect to which your document should be treated. E.g., you may only have an
URI pointing to the policy as a SigPolicyQualifier.

You have to hash a digital signature policy represented as a sequence of
bytes in some format and place the computed value in SigPolicyHash.

Pavel Smirnov

Crypto-Pro
Tel./Fax: +7 495 780-4820
WWW:  <http://www.cryptopro.ru/> http://www.CryptoPro.ru
e-mail:  <mailto:[email-masked]> [email-masked]

From: [email-masked] [mailto:[email-masked]]
On Behalf Of Yasir Khan
Sent: Wednesday, June 25, 2008 2:43 PM
To: [email-masked]
Subject: Using Signature Policy in RFC-5126

We have a question related to using the signature policy in the CAdES
signatures (EPES) defined in RFC-5126. Here is the relevant structure:

SignaturePolicyId ::= SEQUENCE {

            sigPolicyIdentifier SigPolicyId,

            sigPolicyHash SigPolicyHash,

            sigPolicyQualifiers SEQUENCE SIZE (1..MAX) OF

            SigPolicyQualifierInfo OPTIONAL

}

SigPolicyId ::= OBJECT IDENTIFIER

SigPolicyHash ::= OtherHashAlgAndValue

OtherHashAlgAndValue ::= SEQUENCE {

            hashAlgorithm   AlgorithmIdentifier,

        hashValue       OtherHashValue 

}

SigPolicyQualifierInfo ::= SEQUENCE {

            sigPolicyQualifierId SigPolicyQualifierId,

            sigQualifier ANY DEFINED BY sigPolicyQualifierId

}

SigPolicyQualifierId ::= OBJECT IDENTIFIER

id-spq-ets-uri OBJECT IDENTIFIER ::= { 

            iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9)
smime(16) id-spq(5) 1 

}

SPuri ::= IA5String

id-spq-ets-unotice OBJECT IDENTIFIER ::= { 

            iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9)
smime(16) id-spq(5) 2 

}

SPUserNotice ::= SEQUENCE {

            noticeRef NoticeReference OPTIONAL,

            explicitText DisplayText OPTIONAL

}

NoticeReference ::= SEQUENCE {

            organization DisplayText,

            noticeNumbers SEQUENCE OF INTEGER

}

DisplayText ::= CHOICE {

            visibleString VisibleString (SIZE (1..200)),

            bmpString BMPString (SIZE (1..200)),

            utf8String UTF8String (SIZE (1..200))

}

In the given structure for CAdES-EPES signature, its is not clear that
whether are we computing the hash "SigPolicyHash" over the document at
"SPuri" and/or over the "SPUserNotice"

Are the following combinations valid?

1) Only compute hash over document present at SPURI if only SPUri is set 

2) Only compute hash over SPUserNotice  if only SPUserNotice is set

3) Compute hash over document at SPURI and SPUserNotice if both are set

Please clarify it. Thanks!

Regards,

Yasir Khan
Development Manager

Ascertia Ltd
40 Occam Road 
Surrey Research Park
Guildford
Surrey, GU2 7YG
United Kingdom

t.  +44 (0)1483 685500
f.  +44 (0)1483 573704 

www.ascertia.com <http://www.ascertia.com/>     

-----------------------------------------------------------------
         Identity Proven, Trust Delivered
-----------------------------------------------------------------

---

From: Julien Stern <[email-masked]>
Date: Thu, 03 Jul 2008 17:27:34 +0200

Yasir,

this specific point has caused many interoperability issues. Not only is 
the concatenation method subject to interpretation, but also, if you 
have several archive timestamps, you have to use heuristics to guess the 
previous encoding of the attribute sequence because it can be in BER.

I can give you my humble interpretation of the way to concatenate but I 
cannot promise it will be the same as everyone else.

There are currently discussions regarding a change of this attribute, 
possibly mandating DER encoding to remove all ambiguities. Do you 
believe such a change would be worthwhile ?

Regards,

--
Julien Stern

Yasir Khan wrote:
> According to the RFC, it is clear that message imprint will be the hash 
> of above concatenated values but it is not explained how to concatenate 
> these values? Please clarify this point. Some hint for implementing this 
> would be highly appreciated. Thanks!
> 
>  
> 
> ----------------------------------------------------------------------------------
> 
> **YASIR KHAN***
> *Development Manager****
> 
>  
> 
> **Ascertia Limited**
> ----------------------------------------------------------------------------------
> 
> //Delivering Trust for e-business Documents & Workflows//
> 
> ----------------------------------------------------------------------------------
> 
> confidential information. If you are not the intended recipient, or 
> believe that you have received this communication in
> 
> error, please do not print, copy, retransmit, disseminate, or otherwise 
> use the information. Please notify the sender that
> 
> ------------------------------------------------------------------------
> 
> *From:* [email-masked] 
> [mailto:[email-masked]] *On Behalf Of *Pavel V. Smirnov
> *Sent:* Thursday, June 26, 2008 1:04 PM
> *To:* 'Yasir Khan'; [email-masked]
> *Subject:* RE: Using Signature Policy in RFC-5126
> 
>  
> 
> Yes, I mean “digital signature policy” as a “policy document” present at 
> SPUri. But I use SPUri only for example, you may specify a SigPolicyId 
> and omit sigPolicyQualifiers at all. In this case you have to rely on 
> some other means to convey a correspondence between SigPolicyIds and 
> “policy documents”.
> 
>  
> 
> In case of SPuri you have to retrieve a “policy document” by its URI and 
> hash it.
> 
>  
> 
> Note that if your infrastructure provides a trusted source of “policy 
> documents”, and there will never be two different (versions of) “policy 
> documents” identified by the same OID, you don’t have to hash them at 
> all. Just use zero policy hash value.
> 
>  
> 
> Pavel Smirnov
> 
> Crypto-Pro
> WWW: http://www.CryptoPro.ru <http://www.cryptopro.ru/>
> e-mail: [email-masked] <mailto:[email-masked]>
> 
>  
> 
> *From:* [email-masked] 
> [mailto:[email-masked]] *On Behalf Of *Yasir Khan
> *Sent:* Thursday, June 26, 2008 12:19 PM
> *To:* Смирнов Павел Владимирович; [email-masked]
> *Subject:* RE: Using Signature Policy in RFC-5126
> 
>  
> 
> You wrote: ”You have to hash a *digital signature policy* represented as 
> a sequence of bytes in some format and place the computed value in 
> SigPolicyHash.”
> 
>  
> 
> To which item you are naming as “digital signature policy”. You mean 
> policy document present at SPUri? If Yes then it makes some sense. But 
> if only SPUserNotice is present or nothing is present as 
> *sigPolicyQualifiers* as it is an OPTIONAL element:
> 
>  
> 
> ------------------------------------------------------------------------
> 
> *From:* Pavel V. Smirnov [mailto:[email-masked]]
> *Sent:* Wednesday, June 25, 2008 4:07 PM
> *To:* 'Yasir Khan'; [email-masked]
> *Subject:* RE: Using Signature Policy in RFC-5126
> 
>  
> 
> Hello Yasir,
> 
>  
> 
> SignaturePolicyId structure because it is placed in a signed attribute. 
> All signed attributes are protected by the signature itself.
> 
>  
> 
> In most cases the policy would be an external document not included in 
> your signed message, and you have to unambiguously indicate specific 
> policy with respect to which your document should be treated. E.g., you 
> may only have an URI pointing to the policy as a SigPolicyQualifier.
> 
>  
> 
> WWW: http://www.CryptoPro.ru <http://www.cryptopro.ru/>
> e-mail: [email-masked] <mailto:[email-masked]>
> 
>  
> 
> *From:* [email-masked] 
> [mailto:[email-masked]] *On Behalf Of *Yasir Khan
> *Sent:* Wednesday, June 25, 2008 2:43 PM
> *To:* [email-masked]
> *Subject:* Using Signature Policy in RFC-5126
> 
>  
> 
>             *sigPolicyHash SigPolicyHash,*
> 
> *SigPolicyHash ::= OtherHashAlgAndValue*
> 
> * *
> 
> *OtherHashAlgAndValue ::= SEQUENCE {*
> 
> *            hashAlgorithm   AlgorithmIdentifier,*
> 
> *        hashValue       OtherHashValue *
> 
> *}*
> 
>  
> 
>             iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) 
> pkcs9(9) smime(16) id-spq(5) 1
> 
> }
> 
> SPuri ::= IA5String
> 
>  
> 
>             iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) 
> pkcs9(9) smime(16) id-spq(5) 2
> 
> }
>

---

From: "Pavel V. Smirnov" <[email-masked]>
Date: Fri, 4 Jul 2008 08:32:23 +0400

There are a couple of notes regarding archive timestamp that could help you.

Note 4 says: "The hash is calculated over the concatenated data elements as
received/stored, including the Type and Length encoding".

Julien mentioned a point considered in Note 3: "Unless DER is used
throughout, it is recommended that the binary encoding of the ASN.1
structures being time-stamped be preserved when being archived to ensure
that the recalculation of the data hash is consistent".

So. To simplify your implementation you should use DER encoding everywhere
or just always keep original binary encoding. After that you have to
concatenate binary representations of all the fields listed not trying to
throw away Type and Length tags, or getting all certificates or crls from
Certificates or crls elements of SignedData and concatenating them. Just
concatenate full binary encodings of the listed elements in the mentioned
order. But you have to turn over a SignerInfo sequence: you should not
include outer SignerInfo Type and Length tags in hashing, but rather include
every element of SignerInfo starting from version and finising with
unsignedAttrs.

Said above is enough to add an archive timestamp attribute. Concerning
verifying of this timestamp you should do the same concatenation, but throw
away all archive timestamps with time later then in the timestamp being
verified from unsignedAttrs element and encode it over again.

Pavel Smirnov

Crypto-Pro

From: Yasir Khan [mailto:[email-masked]] 
Sent: Thursday, July 03, 2008 8:07 PM
To: Смирнов Павел Владимирович; [email-masked]
Subject: RE: Using Signature Policy in RFC-5126

 

        when present, and;

 

YASIR KHAN
Development Manager

Ascertia Limited

  _____  

Pavel Smirnov

Crypto-Pro

Regards,

Yasir Khan

  _____  

Hello Yasir,

Pavel Smirnov

Crypto-Pro

}

        hashValue       OtherHashValue 

}

}

}

SPuri ::= IA5String

}

}

}

DisplayText ::= CHOICE {

}

Regards,

Yasir Khan
Development Manager

Ascertia Ltd
40 Occam Road 
Surrey Research Park
Guildford
Surrey, GU2 7YG
United Kingdom

t.  +44 (0)1483 685500
f.  +44 (0)1483 573704

---

From: [email-masked] (Peter Gutmann)
Date: Fri, 04 Jul 2008 16:54:54 +1200

>that the recalculation of the data hash is consistent".

Oh, I'm surprised this isn't the default for everything - are implementors 
really trying to decode and re-encode data and expecting the signature to 
still validate?  Doing this violates the primary enoding rule, "There is only 
one (re-)encoding mechanism and memcpy() is its name".

Peter.