|
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: 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@xxxxxxxxxxxx Cc: ietf-smime@xxxxxxx, ESI@xxxxxxxxxxxxx,
Nick.Pope@xxxxxxxxxxxxxxxxxxxx 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 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@xxxxxxxxxxxx [mailto:owner-ietf-smime@xxxxxxxxxxxx] On Behalf Of Pope, Nick 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----- 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 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@xxxxxxxxxxxxxxxxxxxxx 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". |