Pope, Nick wrote:
Pavel,
One your first question, if there is no CRL or OCSP available than the
sequence can be empty.
Nick,
The standard says:
At least one of CRLListID or OcspListID or OtherRevRefs should be
present for all but the "trusted" CA of the certificate path.
So it seems the sequence cannot be empty.
Peter Rybar's suggestion regarding the second point (repeated below) is
fine.
I respectfully disagree. What Pavel asked was how to _reference_ an OCSP
responder certificate, not how to include it into the signature.
So, for CAdES-C, the proposed solution is not applicable.
Furthermore, if you do this, CAdES-X is not a secure form of CAdES
anymore because you do not timestamp the reference to the OCSP responder
certificate.
I already pointed out on both lists that CAdES section 6.2.2 was not
suited to real-world PKIs.
Again, this issue comes from the fact it assumes that all validation
data can be represented as a single chain, when it is in fact a tree (as
soon as there is a certificate renewal or an indirect CRL or a dedicated
OCSP responder).
CAdES should really be fixed to handle these cases.
One solution would be to allow implementations to put certificate
references and revocation references in any order and not to check for
correspondance between the two (like in XAdES actually).
During the latest plugtest on CAdES that we participated in, it appeared
that implementations already handled this scenario anyway...
Regards,
--
Julien
"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>