Subject: RE: CAdES implementation. The algorithm to hash attributes

From: "Pope, Nick" <[email-masked]>
Date: Fri, 6 Jul 2007 17:11:22 +0100

Pavel,

In response to your question:

> 	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?

In the case of the Archive Time-stamp, which may be added by the recipient,
the data being time-stamped will include unsigned attributes and content
which may not be encoded in DER when transmitted.  Also, in the cases of
ES-C timestamps the data being time-stamped is also unsigned.  It might be
feasible to re-encode the ES-C attributes in DER when applying a time-stamp,
but it could be a major burden re-encoding data for a archive time-stamp.

Nick

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: 06 July 2007 13:50
> To: Pope, Nick; [email-masked]
> Subject: RE: CAdES implementation. The algorithm to hash attributes
> 
> 
> 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:[email-masked]]
> > Sent: Monday, June 11, 2007 12:59 PM
> > To: Смирнов Павел Владимирович; [email-masked]'
> > 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@xxxxxxx>
> > Subject: CAdES implementation. The algorithm to hash attributes.
> > From: =?koi8-r?b?883J0s7P1yDwwdfFzCD3zMHEyc3J0s/Xyd4=?=
> > <spv@xxxxxxxxxxxx>
> > Date: Fri, 22 Dec 2006 14:01:14 +0300
> > Sender: owner-ietf-smime@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
> >
> >
Consider the environment before printing this mail.
"Thales e-Security Limited is incorporated in England and Wales with company
registration number 2518805. Its registered office is located at 2 Dashwood
Lang Road, The Bourne Business Park, Addlestone, Nr. Weybridge, Surrey KT15
2NX.
The information contained in this e-mail is confidential. It may also be
privileged. It is only intended for the stated addressee(s) and access to it
by any other person is unauthorised. If you are not an addressee or the
intended addressee, you must not disclose, copy, circulate or in any other
way use or rely on the information contained in this e-mail. Such
unauthorised use may be unlawful. If you have received this e-mail in error
please delete it (and all copies) from your system, please also inform us
immediately on +44 (0)1844 201800 or email [email-masked].
Commercial matters detailed or referred to in this e-mail are subject to a
written contract signed for and on behalf of Thales e-Security Limited".

---

From: "Pavel V. Smirnov" <[email-masked]>
Date: Tue, 10 Jul 2007 17:46:02 +0400

Nick,

> but it could be a major burden re-encoding data for a archive time-

	So this is what I suggested. I certainly had not have in mind an
Archive Time-stamp attribute. Let's add another note (may be just
recommended, not required) for ES-C timestamps to reencode data being
time-stamped in DER before calculating a hash.

Pavel Smirnov
Crypto-Pro
Tel./Fax: +7 495 933-1168
WWW: http://www.CryptoPro.ru
e-mail: [email-masked]