Hello, all!
I'm glad that members of this list still have some interest in CAdES standard.
Thanks for all your answers.
See my comments inline.
Pavel V. Smirnov
CryptoPro
Tel: +7 495 933-1168
WWW: http://www.CryptoPro.ru
-----Original Message-----
From: Pope, Nick [mailto:Nick(_dot_)Pope(_at_)thales-esecurity(_dot_)com]
Sent: Monday, June 11, 2007 12:59 PM
To: Смирнов Павел Владимирович; 'ietf-smime(_at_)imc(_dot_)org'
Subject: Re: CAdES implementation. The algorithm to hash attributes
Pavel,
Sincere apologies for missing your email from a number of months ago.
Your
input is welcomed although the response was very late.
This identifies what I believe to be three issues:
1) What encoding is used? I suggest the answer should be the
equivalent to the note as for archive time-stamp.
"NOTE: Unless DER is used throughout, it is recommended that the binary
encoding of the ASN.1 structures being time-stamped are preserved to
ensure that the recalculation of the data hash is consistent."
This would be great. But why do we not add a requirement for these
attributes to be transmitted in DER form like it was done in CMS for signed and
authenticated attributes?
2) Exactly what part of the Attribute encoding is hashed? I suggest
that the current text implies that each attribute is hashed with the
attrType and attrValues (including type and length) but without the
type and length of the SEQUENCE.
This could be clarified by a note:
"NOTE: Each attribute is included in the hash with the attrType and
attrValues (including type and length) but without the type and length
of the outer SEQUENCE."
3) Why are Type and Length not include? I think this a matter of style
and provided it is explicit this is not an issue.
I will gladly agree with this stylistic requirement and the text of the
note above, if some of the authors of the standard under discussion will
confirm an intention to include suggested clarification in future versions.
I suggest the same clarification be added to 6.3.6.
I believe the revised text on archive timestamp already addresses these
issues.
I hope that these comments are still of help.
Regards
Nick Pope
Thales eSecurity.
To: <ietf-smime(_at_)xxxxxxx>
Subject: CAdES implementation. The algorithm to hash attributes.
From: =?koi8-r?b?883J0s7P1yDwwdfFzCD3zMHEyc3J0s/Xyd4=?=
<spv(_at_)xxxxxxxxxxxx>
Date: Fri, 22 Dec 2006 14:01:14 +0300
Sender: owner-ietf-smime(_at_)xxxxxxxxxxxx
Greetings!
We work on implementing the electronic signature formats defined in
ETSI TS
101 733 v1.6.3. We encountered a problem and need some help. S/MIME
working
group has adopted the previous version of this standard in RFC 3126 and
we
hope people on this list can answer the question. If this is the wrong
place, please give an advice where to address the problem.
The question arises when we must hash data to create a CAdES-C time-
stamp
(section 6.3.5). The standard says the following:
The value of messageImprint field within TimeStampToken shall be a hash
of
the concatenated values (without the type or length encoding for that
value)
of the following data objects:
* OCTETSTRING of the SignatureValue field within SignerInfo;
* signature-time-stamp; or a time mark operated by a Time-Marking
Authority;
* complete-certificate-references attribute;
* complete-revocation-references attribute.
The note "without the type or length encoding for that value" instructs
us
to omit the OCTETSTRING tag and length of the SignatureValue. It is
rather
clear (but unclear why, I will mention this later). Next, what do we
have to
do with three attributes left? Do we have to omit SEQUENCE tag and
length of
the Attribute object? Or do we have to omit attrType of this Attribute?
Or
do we have to hash the complete ASN.1 DER representation of these
attributes
as it was done for SignatureValue in CMS over signedAttrs value?
The standard should describe such points unambiguously. What did I
miss?
The same problem applies to the hash calculation for the archive time-
stamp
attribute:
The value of messageImprint field within TimeStampToken shall be a hash
of
the concatenation of:
* The encapContentInfo element of the SignedData sequence;
* When present, the Certificates and crls elements of the SignedData
sequence;
* Together with all data elements in the SignerInfo sequence including
all
signed and unsigned attributes.
Here we cannot see the magic "without the type or length encoding for
that
value" note. This leaves us wondering why there is such difference.
RFC on CMS has a very good explanation on how to calculate message
digest
for the signature. That explanation leaves no ambiguity and clears the
point
why we should omit tag and length encoding of eContent. So may be hash
calculation should be clarified in the current edition of CAdES
standard.
Pavel V. Smirnov
CryptoPro
Tel: +7 495 933-1168
WWW: http://www.CryptoPro.ru