|
Re: CAdES implementation. Complete Revocation References attribute.
2008-03-13 11:54:55
Pavel,
comments inline,
Pavel V. Smirnov wrote:
Nick and other,
2) On the second point I have a concern of a marked text (time-stamping
authorities). The paragraph closing 6.2.1 says:
This attribute MAY include references to the certification chain for any
TSUs that provides time-stamp tokens. In this
case the unsigned attribute shall be added to the signedData of the
relevant times tamp token as an unsignedAttrs in
the signerInfos field.
It seems that this is a direct contradiction. All other is perfect to me.
I agree that the timestamping certificate does not seem to fit in here.
This attribute is (as far as I understand) meant to include all the
certificate references needed to validate a chain, but the EE reference.
Should this attribute be added to timestamp token as suggested, the EE
certificate (e.g. the timestamping one in that case) would be referenced
in the signing certificate attribute, and the attribute would only
contain CA certificates, OCSP responder certificates and Indirect CRL
issuer certificates, as in the previous case.
3) On the third point. It seems reasonable not to enforce one-to-one
relationship, but I think it is too late to change because it could
break existing implementations. Or maybe we can introduce a new
CompleteRevocationRefs attribute with other OID and declare the old one
deprecated but supported for backward compatibility?..
I agree that it could theoretically break some verification
implementations. However, authorizing empty references can also break
the implementations that are checking the mapping. Also, I fail to see
any simple way to take advantage of the mapping, so I assume that most
implementations will
1) Retrieve all the revocation material in a unordered bag
2) Proceeed with X509 validation
3) Optionally, verify the one-to-one relationship
That is what we originally wanted to do. Now, because of the other issue
of empty references that you mentioned earlier (OCSP response with the
no-check extension), even checking the one-to-one mapping is not clearly
defined, as different implementations may either skip one entry or put
an empty one in that case.
Instead of declaring invalid a perfect signature because some arbitrary
mapping is not respected, we decided to remove the mapping check all
together.
During a plugtest on CAdES, I enquired about this issue and I turned out
that other implementations that faced the same issue would simply not
verify the one-to-one mapping.
That about it for my 2 cents...
Regards,
--
Julien
Pavel Smirnov
Crypto-Pro
Tel./Fax: +7 495 780-4820
WWW: http://www.CryptoPro.ru <http://www.cryptopro.ru/>
e-mail: spv(_at_)CryptoPro(_dot_)ru <mailto:spv(_at_)CryptoPro(_dot_)ru>
*From:* Pope, Nick [mailto:Nick(_dot_)Pope(_at_)thales-esecurity(_dot_)com]
*Sent:* Thursday, March 13, 2008 11:33 AM
*To:* Смирнов Павел Владимирович; ietf-smime(_at_)imc(_dot_)org;
ESI(_at_)LIST(_dot_)ETSI(_dot_)ORG
*Cc:* Julien Stern
*Subject:* RE: CAdES implementation. Complete Revocation References
attribute.
Pavel,
Apologies for not getting back earlier. I was at an ETSI meeting where
I had a chance to briefly discuss this issue with colleagues including
Julien Stern who had raised the same issue earlier.
I would like to ensure that we have agreement on the best approach and
include the necessary change in TS 101 733 (post 1.7.4). Unfortunately
it is too late to update RFC 5126 but I hope we can find an approach
that does not break existing implementations.
1) On the first point (there being no revocation information for a given
CA certificate) for the record I suggest there should be a clarification
in 6.2.2 of TS 101 733:
/"The CrlOcspRef may contain an empty SEQUENCE if there is no revocation
information for a certificate."/
2) On the second point I also propose that in 6.2.1:
/Change "CA certificates that have been used to validate ..." to "CA and
any other certificates (e.g. certificates of CRL issuers, OCSP
responders, ??? time-stamping authorities) that have been used to
validate ..."/
3) There is an further point that has been raised whether in 6.2.2 there
should be a direct one to one relationship between the revocation
information in 6.2.2 and the certificates in 6.2.1.
Views are sought from ETSI ESI and IETF experts on the proposed changes
and the third point.
Nick
-----Original Message-----
*From:* Pavel V. Smirnov [mailto:spv(_at_)cryptopro(_dot_)ru]
*Sent:* 06 March 2008 16:47
*To:* 'Pope, Nick'; ietf-smime(_at_)imc(_dot_)org
*Cc:* LISTSERV(_at_)LIST(_dot_)ETSI(_dot_)ORG
*Subject:* RE: CAdES implementation. Complete Revocation References
attribute.
Nick,
The first point is closed now, thanks.
On the second one. I certainly can store a certificate of OCSP-responder
in OCSP response itself, but this response by default is not protected
by CrlOcspRef and hence, existence of this certificate is not protected
by CAdES-C time-stamp or by time-stamped-certs-crls-references
attribute. Of course, I can force OcspResponsesID to include optional
ocspRepHash to protect this certificate, but this way somehow
contradicts a remark on ocspRepHash (cited): Since it may be needed to
make the difference between two OCSP responses received within the same
second, then the hash of the response contained in the OcspResponsesID
may be needed to solve the ambiguity.
That said, I want to bring your attention to the other case. Consider a
dedicated CRL issuer implied by policy with its own
CRL-issuer-certificate. Where could I store this certificate and a
reference to it? Now there is only a CRL (or may be ARL) signed by this
issuer in my message and I cannot include its certificate in that CRL.
Why don't we just allow _any certificate needed to validate a path_ (not
only CA certificates) to be included in complete certificate references
attribute?
Pavel Smirnov
Crypto-Pro
Tel./Fax: +7 495 780-4820
WWW: http://www.CryptoPro.ru <http://www.cryptopro.ru/>
e-mail: spv(_at_)CryptoPro(_dot_)ru <mailto: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 *Pope, Nick
*Sent:* Wednesday, March 05, 2008 12:27 PM
*To:* Смирнов Павел Владимирович; Pope, Nick; ietf-smime(_at_)imc(_dot_)org
*Cc:* 'LISTSERV(_at_)LIST(_dot_)ETSI(_dot_)ORG'
*Subject:* RE: CAdES implementation. Complete Revocation References
attribute.
Pavel,
One your first question, if there is no CRL or OCSP available than the
sequence can be empty.
Peter Rybar's suggestion regarding the second point (repeated below) is
fine.
"RFC 2560
4.2.1 ASN.1 Specification of the OCSP Response
BasicOCSPResponse ::= SEQUENCE {
tbsResponseData ResponseData,
signatureAlgorithm AlgorithmIdentifier,
signature BIT STRING,
certs [0] EXPLICIT SEQUENCE OF Certificate OPTIONAL }
It means: you must use the OPTIONAL certs for this purpose.
Similar problem is solving with timestamp, where the certs and CRL for
timestamp validation are included in the timestamp and not in the
signature which is timestamped."
Peter
-----Original Message-----
*From:* Pavel V. Smirnov [mailto:spv(_at_)cryptopro(_dot_)ru]
*Sent:* 04 March 2008 13:46
*To:* Nick(_dot_)Pope(_at_)thales-esecurity(_dot_)com;
ietf-smime(_at_)imc(_dot_)org
*Subject:* CAdES implementation. Complete Revocation References attribute.
Hello all and personally Nick!
I have a couple new questions regarding CAdES implementation.
Consider section 6.2.2 of ETSI 101 733 v1.7.3 (excerpt):
CompleteRevocationRefs shall contain one CrlOcspRef for the
signing-certificate, followed by one
for each OtherCertID in the CompleteCertificateRefs attribute. The
second and subsequent CrlOcspRef
fields shall be in the same order as the OtherCertID to which they
relate. At least one of CRLListID or
OcspListID or OtherRevRefs should be present for all but the "trusted"
CA of the certificate path.
The first question.
It seems to me that one can include an empty CrlOcspRef (without any
CRLListID or
OcspListID or OtherRevRefs) for a "trusted" CA. Am I right? If one
cannot do like that, then all "trusted" CA certificates have to be
placed at the end of CompleteCertificateRefs SEQUENCE. Which way is
right? Or may be both?
The second question.
It's quite clear how to compose this attribute in a simple CRL-only
case. Now, let us use OCSP. Where should one place a certificate of
OCSP-responder? It would be great if one could place a reference to this
certificate in CompleteCertificateRefs (but it is in some way prohibited
by the phrase "It references the full set of _CA_
certificates that ... " in section 6.2.1). Let us assume that this
certificate is no-check and one does not need to place the corresponding
CrlOcspRef into CompleteRevocationRefs attribute. Then one have to
equate such OCSP-responder certificate to a "trusted" CA and either
include an empty CrlOcspRef in CompleteRevocationRefs or place the
certificate at the end of CompleteCertificateRefs SEQUENCE. How should I
solve this?
Pavel Smirnov
Crypto-Pro
Tel./Fax: +7 495 780-4820
WWW: http://www.CryptoPro.ru <http://www.cryptopro.ru/>
e-mail: spv(_at_)CryptoPro(_dot_)ru <mailto: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"./*
|
|