Subject: RE: Extending CAdES to support usual signature upgrading to CAdES -T and further

From: "Pope, Nick" <[email-masked]>
Date: Wed, 4 Jun 2008 09:36:50 +0100

Pavel,

I personally have some sympathy for your view.  I will add this issue to
those for discussion at the next ETSI meeting later in June.

Nick

-----Original Message-----
From: Pavel V. Smirnov [mailto:[email-masked]] 
Sent: 26 May 2008 11:50
To: 'Pope, Nick'; [email-masked]; [email-masked]
Subject: Extending CAdES to support usual signature upgrading to CAdES-T and
further

Hello all and personally Nick,

In current CAdES wording a regular signature without at least one signed
attribute (Signing certificate reference) cannot be added with timestamps
and validation data to achieve CAdES-T or more advanced CAdES signature.
This need arises, e.g., in a system with existing regular signatures. There
is no chance to add the required attribute to the already computed
signature, but there is a strong need to add CAdES properties to such
signatures.

There is rather simple approach to achieve the same properties without
including signing certificate reference as a signed attribute. Let us
include this reference as an extension in the CAdES-T timestamp (signature
timestamp). To get such timestamp one would need to include this extension
in a timestamp request and a TSA would have to shift this extension to a
timestamp token.

Let us define the proposed extension to a timestamp protocol and call the
signature we get a valid CAdES-T signature. More advanced CAdES signature
types turn out from this new CAdES-T perfectly without any modification.
What do you think?

Pavel Smirnov

Crypto-Pro
Tel./Fax: +7 495 780-4820
WWW:  <http://www.cryptopro.ru/> http://www.CryptoPro.ru
e-mail:  <mailto:[email-masked]> [email-masked]

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: "Peter Rybar" <[email-masked]>
Date: Thu, 5 Jun 2008 11:02:56 +0200

Pavel,

In my opinion, like in previous mail, the AdES signatures could in 3 important sates from the time perspective.

And for these 3 states there is important that the signature in the 1st state contains the information about the signer certificate protected by signature.

The 2nd state of the signature is mainly important for validation of expired certificates and in this case signature must contain evidence that the signature was created before expiration of signer certificate e. g. through signature timestamp and any revocation list or OCSP which could contain information about potential revocation must be available for verifier. 

The 3rd state of the signature is important for the long term validation. Signature in this state must contain not only all certificates and revocation lists or OCSPs which could contain information about potential revocation but also the integrity of all this information must be protected because some algorithms can become not secure. In this case the signature and all information must be protected with additional more secure HASH (for integrity) in time when lastly used integrity hash was considered as secure it is usually achived by archive timestamp.

AdES offers for implementers many attributes which could be used to satisfy these requirements of these 3 states and you NEED NOT to use all of them.

In my opinion it could be very helpful if some security annex of AdES standard will contain any recommendation which attribute is useful to protect which security attack or in which system its usage is important.

In this case, in my opinion, the following attributes are important for the common usage. 

1st state

id-contentType 

id-messageDigest 

id-aa-ets-signingCertificateV2 or id-aa-signingCertificate

2nd state

id-contentType 

id-messageDigest 

id-aa-ets-signingCertificateV2 or id-aa-signingCertificate

id-aa-signatureTimeStampToken

Signature must contain certificates for validation of the signature and the whole certification path with CRL or OCSP and if there are used indirect CRL or OCSP then also certificates for its validation.

 3rd state

id-contentType 

id-messageDigest 

id-aa-ets-signingCertificateV2 or id-aa-signingCertificate

id-aa-signatureTimeStampToken

Signature must contain certificates for validation of the signature and the whole certification path with CRL or OCSP and if there are used indirect CRL or OCSP then also certificates for its validation.

Each signature of the timestamp must contain certificates for validation of the timestamp signature and the whole certification path with CRL or OCSP and if there are used indirect CRL or OCSP then also certificates for its validation.

Any subsequent id-aa-ets-archiveTimestamp can be applied only if previous one contains all verification information.

Timestamp itself is electronic signature and in this case the verification information must only be added to the timestamp and not to de signature which was time stamped. !!!

Peter

>  Notably, one must store certificate and revocation values for signature-timestamp validation in the timestamp itself, hence, after receiving CAdES-C-timestamp one cannot add or remove these values from signature-timestamp.

>An obvious solution is to allow to include timestamp validation data in certificate-values and revocation-values attributes of the signature itself. What do you think?

---------- Forwarded message ----------

From: Peter Rybar g <[email-masked]>

Date: Wed, 4 Jun 2008 17:41:55 +0200

Subject: Re: Extending CAdES to support usual signature upgrading to

CAdES-T and further

To: [email-masked]

Cc: [email-masked], [email-masked], [email-masked]

Pavel,

A signer protects his certificate with his signature. 

It must be only under his control that the verifier will use only his certificate. 

The signer certificate is usually protected by hash value of signer certificate inside in the signed attributes signed by SIGNER or it could by done when the certificate is present in the signed document like in the PDF signature.

The "security expiration" of the HASH algorithm used in the signed attributes like reference to the signer certificate in the long term validation is another important issue!!! !!! 

It requires archive timestamp or secure HASH in archiving system used in time when the hash algorithm in the signature was secure and must include also the certificate value.

Your suggest to use the timestamp for it but it is not correct because the timestamp could be removed with another timestamp and in this case there is no protection from the substitution attack of the signer certificate.

It is the same as the usage of the MIME-TYPE of the signed document to prevent signatures from the attack of changing the type of the visualization of the signed document. Example is on the page:

http://elpi2.szm.com/priklad.htm

And one possible solution how to prevent the signature from this attack is in the document

http://www.nbusr.sk/en/electronic-signature/approved-formats/index.html

http://www.nbusr.sk/ipublisher/files/nbusr.sk/elektronicky-podpis/legislativa/9/specifyingcontentformalspecofdocqes_en_071.pdf

This attack is similar as the substitution attack of the signer certificate. 

Only the signer is able with his signature to protect important information which must be used by the verifier in the visualization of the signed document. 

It is the attack on the signed document which contains quite correct information but not only for one type of the document but also for two or more types of the document. Then if we try to view it as the first type of the document then the viewer will read information which is relevant for the first type and another one will be ignored. The same situation happens if we view it as the second type of the document where the viewer will only recognize the information relevant to the second type of the document and so on. 

The problem occurs if we sign the document without information about the type of the document which was shown to the signer.

Then the verifier could see the different information.

For solving this attack the application must be able to do:

* In the XAdES signature – the type of the signed document must be present in the MIME-TYPE element of DataObjectFormat signed attribute.

* In the CAdES signature – the type of the signed document must be present in the MIME-TYPE which must be in the MIME header which envelopes the signed document. 

* Or the type of the signed document is implicitly defined by the signed document content containing the signature and rules of manipulation of the signed data and document like in PDF signature.

In this case the signatures of some data without protected information about the type of the data like the MIME-TYPE protected by the signature could be hazardous similarly as signatures without the protection of the signer certificate.

Peter

  _____  

From: [email-masked] [mailto:[email-masked]] On Behalf Of Pope, Nick
Sent: Wednesday, June 04, 2008 10:37 AM
To: 'Pavel V. Smirnov'; [email-masked]; [email-masked]
Subject: RE: Extending CAdES to support usual signature upgrading to CAdES-T and further

Pavel,

I personally have some sympathy for your view.  I will add this issue to those for discussion at the next ETSI meeting later in June.

Nick

-----Original Message-----
From: Pavel V. Smirnov [mailto:[email-masked]] 
Sent: 26 May 2008 11:50
To: 'Pope, Nick'; [email-masked]; [email-masked]
Subject: Extending CAdES to support usual signature upgrading to CAdES-T and further

In current CAdES wording a regular signature without at least one signed attribute (Signing certificate reference) cannot be added with timestamps and validation data to achieve CAdES-T or more advanced CAdES signature. This need arises, e.g., in a system with existing regular signatures. There is no chance to add the required attribute to the already computed signature, but there is a strong need to add CAdES properties to such signatures.

There is rather simple approach to achieve the same properties without including signing certificate reference as a signed attribute. Let us include this reference as an extension in the CAdES-T timestamp (signature timestamp). To get such timestamp one would need to include this extension in a timestamp request and a TSA would have to shift this extension to a timestamp token.

Let us define the proposed extension to a timestamp protocol and call the signature we get a valid CAdES-T signature. More advanced CAdES signature types turn out from this new CAdES-T perfectly without any modification. What do you think?

Pavel Smirnov

Crypto-Pro

"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: Sat, 7 Jun 2008 12:26:42 +0400

Peter, Nick, Denis,

First of all, thanks for your attention.

Peter, Denis,

I agree that suggested CAdES-T-with-certref-in-timestamp does not provide exactly the same protection as usual CAdES-T. But there is a strong need to extend a lifetime of already-done usual signatures going to some kind of archive. Why doesn’t one use CAdES attributes to achieve this?

OK. Let’s not call such signatures CAdES-T, CAdES-C etc. But let’s define a new branch of CAdES without signing certificate reference in a signed attribute. There is an obvious benefit to standardize these formats rather than anyone will do on its own. My suggestion is mainly related to standardizing using timestamp extension for this purpose.

>CadES requires the signing certificate reference. This is not going to change.

 >You would like to time-stamp non-CAdES signatures. You can certainly do this, but do not call this CAdES-T.

>Placing the reference in the time-stamp token would not provide the same protection.

Peter,

I agree that it is a matter of good style to include validation data for a timestamp in itself. I just wanted to point to a drawback implied by this requirement. We may accept it and we may try to settle it.

Another way to settle it is to hash the CAdES-T timestamp in a CAdES-C-timestamp selectively, notably without attributes containing certificate and revocation values.

Pavel Smirnov

Crypto-Pro

From: [email-masked] [mailto:[email-masked]] On Behalf Of Peter Rybar
Sent: Thursday, June 05, 2008 1:03 PM
To: 'Pope, Nick'; 'Pavel V. Smirnov'; [email-masked]; [email-masked]
Cc: [email-masked]
Subject: RE: Extending CAdES to support usual signature upgrading to CAdES-T and further

 Pavel,

1st state

id-contentType 

id-messageDigest 

2nd state

id-contentType 

id-messageDigest 

 3rd state

id-contentType 

id-messageDigest 

Peter

---------- Forwarded message ----------

CAdES-T and further

To: [email-masked]

Pavel,

Peter

  _____  

Pavel,

Nick

-----Original Message-----
From: Pavel V. Smirnov [mailto:[email-masked]] 
Sent: 26 May 2008 11:50
To: 'Pope, Nick'; [email-masked]; [email-masked]
Subject: Extending CAdES to support usual signature upgrading to CAdES-T and further

Pavel Smirnov

Crypto-Pro