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**
www.ascertia.com <http://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:* owner-ietf-smime(_at_)mail(_dot_)imc(_dot_)org
[mailto:owner-ietf-smime(_at_)mail(_dot_)imc(_dot_)org] *On Behalf Of *Pavel V. Smirnov
*Sent:* Thursday, June 26, 2008 1:04 PM
*To:* 'Yasir Khan'; ietf-smime(_at_)imc(_dot_)org
*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: spv(_at_)CryptoPro(_dot_)ru <mailto:spv(_at_)CryptoPro(_dot_)ru>
*From:* owner-ietf-smime(_at_)mail(_dot_)imc(_dot_)org
[mailto:owner-ietf-smime(_at_)mail(_dot_)imc(_dot_)org] *On Behalf Of *Yasir Khan
*Sent:* Thursday, June 26, 2008 12:19 PM
*To:* Смирнов Павел Владимирович; ietf-smime(_at_)imc(_dot_)org
*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:spv(_at_)cryptopro(_dot_)ru]
*Sent:* Wednesday, June 25, 2008 4:07 PM
*To:* 'Yasir Khan'; ietf-smime(_at_)imc(_dot_)org
*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: spv(_at_)CryptoPro(_dot_)ru <mailto:spv(_at_)CryptoPro(_dot_)ru>
*From:* owner-ietf-smime(_at_)mail(_dot_)imc(_dot_)org
[mailto:owner-ietf-smime(_at_)mail(_dot_)imc(_dot_)org] *On Behalf Of *Yasir Khan
*Sent:* Wednesday, June 25, 2008 2:43 PM
*To:* ietf-smime(_at_)imc(_dot_)org
*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
-----------------------------------------------------------------