[Top] [All Lists]

Re: CAdES implementation. Complete Revocation References attribute.

2008-03-05 05:33:32

Pope, Nick wrote:

One your first question, if there is no CRL or OCSP available than the sequence can be empty.


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...



"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."


-----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; 
*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

Tel./Fax: +7 495 780-4820
WWW: <>
e-mail: spv(_at_)CryptoPro(_dot_)ru <mailto:spv(_at_)CryptoPro(_dot_)ru>