|
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 Ascertia Limited ---------------------------------------------------------------------------------- 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@xxxxxxxxxxxx [mailto:owner-ietf-smime@xxxxxxxxxxxx] On Behalf Of Pavel V. Smirnov 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 From:
owner-ietf-smime@xxxxxxxxxxxx [mailto:owner-ietf-smime@xxxxxxxxxxxx] On Behalf Of Yasir Khan 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@xxxxxxxxxxxx] 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 From:
owner-ietf-smime@xxxxxxxxxxxx [mailto:owner-ietf-smime@xxxxxxxxxxxx] On Behalf Of Yasir Khan 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 Ascertia Ltd t. +44 (0)1483 685500 ----------------------------------------------------------------- |
Attachment:
smime.p7s
Description: S/MIME cryptographic signature