|
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:yasir.khan@xxxxxxxxxxxx] 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 ----------------------------------------------------------------- |