Not able to validate archive-time-stamp-v3 using a hash algorithm different than one used for signature creation

[bsanchezb]

Hello,

I believe there is an issue when validating the archive-time-stamp-v3's message-imprint in a CAdES signature. The issue occurs when archive-time-stamp-v3 uses a different hash algorithm than the one used on signature creation.

Two test cases with the same and different hash algorithms are provided in the attached archive.

Best regards, Aleksandr.

examples.zip

[orm888]

Hellow I try to create AtV3. I use only one alghorithm. I can create V3 on CAdES-T. I collect two chains and crls, and put it into signedData root. And, i creat ATSHashIndexV3 with hashs, put it into time stamp to unsAttrs and put stamp to unsattrs in signerInfo. But i don't anderstand, how can i update it? I didnt get clear/strong answer in doc - ETSI EN 319 122-1 V1.2.1 (2021-10) how i can do it. I saw, what i need to recollect chains and crls, but where must i put it? in signedData in unsAttr timestamp (previous)? Do i need to put it with dublicates or i need to clear this set? Can you give me answer or links about it? Thanks

[bsanchezb]

@orm888 , hi.

You put all additional validation data within SignedData of signature's CMS, and create a new ATSTv3 with references to all data, including the previous ATSTv3.

KR, Aleksandr

[orm888]

For example, i have AtV3 (first) on CAdES-T I filled in root SignedData.certificate and signedData.crls and, i calculated and put ATSHASHIndexV3 in TimeStamp on concatenated hesh. After created AtV3 i have 2 unsigned Attrs - TimeStamp (CAdES-T) and TimeStamp on dataHesh(TimeStamp - AtV3) I want to update it.

I am collecting all the necessary data on this moment - certificates, crl/other and i expanding data in the root SignedData.certificates and SignedData.crls (without dublicates like in doc) After, i calculate ATSHashIndexV3(2) on extended data - includes CAdES-T and AtV3(1) for unsignedAttrValuesHashIndex and, i get TimeStamp (AtV3(2)). I put in AtV3(2) new ATSHashIndexV3(2) and add it to unsigned Attrs Is it correct chain of mind?

Will i get the following in Unigned Attrs? unsAttrs: --timeStamp CAdES-T --timeStamp AtV3(1) (ATSHashIndexV3{1}) --timeStamp AtV3(2) (ATSHashIndexV3(2))

Is thne number of updates equal number of AtV3 in unsigned attrs?

Thank you in advance

[bsanchezb]

Sounds right. Every next ATSTv3 will cover all available data, including new validation data (certs, crls, ocsps), and all preceding unsigned attributes (including the previous ATSTv3).

[orm888]

@bsanchezb, Hellow. Now, I try to check AtV3. In signed data i have certificates (chains for signer certificate and tsp certificate) . Will be enough to check hashes? I mean compare hashes for certificates part and hashes in ATSHashIndexV3. Or I need to add checking chains - what i can creat chain for signer certificate and tsp certificate?

Thank you in advance

[bsanchezb]

@orm888 , you simply compare hashes of certificates, individually. Do not forget to include in AtV3HashTable also hashes of revocation data (from signedData) and existing unsigned properties.

[orm888]

@bsanchezb, for example: I have some ES with AtV3, ATSHashIndexV3 has all neccessary hashes - certificatesHashIndex, crlsHashIndex, unsignedAttrValuesHashIndex (and hashIndAlgorithm) And, signed data has certificates (chains), crls/others and timeStamp in unsAttrs

Before, then i have XLT formate it needs to check all information in unsAttrs: I need to check signer certificate - create certificate chain Next, it needs to check this certificate in crls lists, or if its ocsp, it needs to check status of certificate. And athers....

And, some body compromise ES (AtV3) - added somthing or remove from certificates or crl/other. In this case we can't get the equal hashs. And, we don't need to somthing else.

Sorry if it isn't clearly enought I mean checking of hashes of certificates, crl/others. unsAttrs, and hash for timeStampV3 is it enought for AtV3?

[bsanchezb]

And, some body compromise ES (AtV3) - added somthing or remove from certificates or crl/other.

Please note, that addition of new data entries within SignedData is allowed behavior for CMS signatures. Such change would not invalidate the signature (while removal of data may have consequences, i.e. breaking AtV3).

I mean checking of hashes of certificates, crl/others. unsAttrs, and hash for timeStampV3 is it enought for AtV3?

For crypto validation of AtV3 it is enough.

[orm888]

@bsanchezb, Good day. I try to ferify ES, not mine. I caculated hash of certificates(1), crl/other (0 in this section) and unsAttrs (2) from signedData. I compared these hashs with hashs in ATSHashIndexV3, and i've got success.

But, then i tried to calculate all hash, consists of eContentType, eContent(hash), signerInfo, ATSHashIndexV3 i get hash and it isn't equal the hesh from AtV3.

Before i tried to calculate signerInfo like concatenation of it's fields, without unsAttrs and i've got length 1000 chars But after, i removed unsAttrs from signerInfo and got all date. And i've got length like 1004 chars And, of course it isn't the same hash value

But now, i dont' have the equal hashes. again (after removed unsAttrs from signerInfo)

I do somthing wrong with concatination of fields. I encoded eContentType from SignedData.encapContentInfo.eContentType I got hash from eContent I encoded signerInfo without unsAttrs and, I encoded ATSHashIndexV3 from timeStampV3

I think, maybe I have a dont't correct encode with ATSHashIndexV3, becouse i have one empty field (crls), size = 0 What's the reason can be?

Thank you in advance

[bsanchezb]

Hi,

You do not need to concatenate the whole SignerInfo, but only the chosen attributes, see ETSi EN 319 122-1, chapter "5.5.3 The archive-time-stamp-v3 attribute":

3) The fields version, sid, digestAlgorithm, signedAttrs, signatureAlgorithm, and signature within the SignedData.signerInfos's item corresponding to the signature being archive time-stamped, in their order of appearance.

For further information, try to validate your signature with CAdES Conformance Checker and see "Trace on Message Imprints" tab for information regarding the timestamp message-imprint.

[orm888]

Hi

For further information, try to validate your signature with CAdES Conformance Checker and see "Trace on Message Imprints" tab for information regarding the timestamp message-imprint.

I tried to registry. I waited 24 houres and nothing. What do I have some special for registration?

[bsanchezb]

@orm888 , I am not the maintainer of the service, but maybe @lovele0107 or @jccruellas could help with acceptance of your registration request.

[jccruellas]

Good morning orm88. The register process is in hands of ETSI technical staff. I will contact with them by email, putting you in copy, so that this is fixed as soon as possible.

Regards Juan-Carlos Cruellas

[jccruellas]

Good morning again,

Message sent. I could not put in copy @orm888, because I do not find your email anywhere. Will let you know as soon as I get feedback from ETSI technical staff.

Juan-Carlos Cruellas

[orm888]

@jccruellas, good morning this is my email: andrey.sorokin057@gmail.com

Thanks

[orm888]

@bsanchezb, hello I tried to "Trace on Message Imprints" And, I see, what signedAttrs filel begin by whitespace It's in the Hex format. And ' ' in the char format.

But then i try to get information from data i have the "one" at the first place- '1' std::vector signedAttrs = Common::GetEncode(&asn_DEF_SignedAttributes, signerInfo->signedAttrs) But, other characters are the same

And, then I tried to check your file - "signed-same-algo.p7m" i have the same problem. But, if I put whitespace to the first position instead of '1' -> ' ', then I can check your hash from timeStampV3 , And, I have one else example, and I can check it if i use the same steps, like for you file

Is it like something a special rule, or encode/decode problem? Can you help me in this question?

[bsanchezb]

Hi,

And, I see, what signedAttrs filel begin by whitespace

There is no whitespace in here. Only the data encoded in HEX format should be used.

But then i try to get information from data i have the "one" at the first place- '1'
std::vector signedAttrs = Common::GetEncode(&asn_DEF_SignedAttributes, signerInfo->signedAttrs)
But other, characters are the same

What you are talking about is probably a tag, see RFC 5652:

5.4 Message Digest Calculation Process

A separate encoding of the signedAttrs field is performed for message digest calculation. The IMPLICIT [0] tag in the signedAttrs is not used for the DER encoding, rather an EXPLICIT SET OF tag is used. That is, the DER encoding of the EXPLICIT SET OF tag, rather than of the IMPLICIT [0] tag, MUST be included in the message digest calculation along with the length and content octets of the SignedAttributes value.

See what we do in DSS for encoding the signedAttrs field (using JAVA BouncyCastle library).

[orm888]

@bsanchezb, good day I saw ES with 2 v3 stamps without signature Time Stamp. All proofes are in root SignedData - 2 certifacate chains, i think, and crls

Can i have ES with v3 without signature Time Stamp? Somthing like this:

-
SignedData.certificates
  1
  2
  3
  4
  5
SignedData.crls
  1
  2
  3
  4
-
UnsignedAttributes
  AtV3 0.4.0.1733.2.4
  -
  ATSHashIndexV3 0.4.0.19122.1.5
    certicicates
      1
      2
    crls
      1
    unsAttrs
  AtV3 0.4.0.1733.2.4
   -
    ATSHashIndexV3 0.4.0.19122.1.5
    certicicates
      1
      2
      3
      4
      5
    crl
      1
      2
      3
      4
    unsAttrs
      1

Thank you in advance