|
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: owner-ietf-smime@xxxxxxxxxxxx
[mailto:owner-ietf-smime@xxxxxxxxxxxx] On Behalf Of Peter Rybar 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@xxxxxxxxx> 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". |