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
Tel./Fax: +7 495 780-4820
WWW: <http://www.cryptopro.ru/> http://www.CryptoPro.ru
e-mail: <mailto:spv(_at_)CryptoPro(_dot_)ru> spv(_at_)CryptoPro(_dot_)ru
From: owner-ietf-smime(_at_)mail(_dot_)imc(_dot_)org
[mailto:owner-ietf-smime(_at_)mail(_dot_)imc(_dot_)org] On Behalf Of Peter Rybar
Sent: Thursday, June 05, 2008 1:03 PM
To: 'Pope, Nick'; 'Pavel V. Smirnov'; ESI(_at_)LIST(_dot_)ETSI(_dot_)ORG;
ietf-smime(_at_)imc(_dot_)org
Cc: peterryb(_at_)gmail(_dot_)com
Subject: RE: Extending CAdES to support usual signature upgrading to CAdES-T
and further
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 <peterryb(_at_)gmail(_dot_)com>
Date: Wed, 4 Jun 2008 17:41:55 +0200
Subject: Re: Extending CAdES to support usual signature upgrading to
CAdES-T and further
To: spv(_at_)cryptopro(_dot_)ru
Cc: ietf-smime(_at_)imc(_dot_)org, ESI(_at_)list(_dot_)etsi(_dot_)org,
Nick(_dot_)Pope(_at_)thales-esecurity(_dot_)com
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: owner-ietf-smime(_at_)mail(_dot_)imc(_dot_)org
[mailto:owner-ietf-smime(_at_)mail(_dot_)imc(_dot_)org] On Behalf Of Pope, Nick
Sent: Wednesday, June 04, 2008 10:37 AM
To: 'Pavel V. Smirnov'; ESI(_at_)LIST(_dot_)ETSI(_dot_)ORG;
ietf-smime(_at_)imc(_dot_)org
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:spv(_at_)cryptopro(_dot_)ru]
Sent: 26 May 2008 11:50
To: 'Pope, Nick'; ESI(_at_)LIST(_dot_)ETSI(_dot_)ORG;
ietf-smime(_at_)imc(_dot_)org
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:spv(_at_)CryptoPro(_dot_)ru> spv(_at_)CryptoPro(_dot_)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 postmaster(_at_)thales-esecurity(_dot_)com(_dot_) 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".