Subject: RE: CAdES implementation. Complete Revocation References attribut e.

From: "Pope, Nick" <[email-masked]>
Date: Wed, 5 Mar 2008 10:08:55 -0000

Pavel,

The text says "SHOULD" which implies if there is a good reason (e.g. no data
exists) then this need not be present.  A similar issue was raised earlier
add the conclusion was to allow empty SEQUENCE.

There was some clarification text that should have gone into the new RFC
just about to be published but unfortunately it got missed out.

Nick

> -----Original Message-----
> From: Julien Stern [mailto:[email-masked]]
> Sent: 05 March 2008 10:03
> To: Pope, Nick
> Cc: 'Pavel V. Smirnov'; [email-masked]; [email-masked]'
> Subject: Re: CAdES implementation. Complete Revocation References
> attribute.
> 
> 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:[email-masked]]
> > *Sent:* 04 March 2008 13:46
> > *To:* [email-masked]; [email-masked]
> > *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: [email-masked] <mailto:[email-masked]>
> >
> >
> >

---

From: "Pope, Nick" <[email-masked]>
Date: Thu, 13 Mar 2008 11:20:49 -0000

To clarify my point 3 - The text currently requires a one-to-one
relationship between the between the revocation information and the
certificate.  There has been a suggestion that this is relaxed so that there
is just a list of revocation information un related to particular
certificates.

I have some concern of this change as it could lead to ambiguity over which
revocation information (if any) was used to check which certificate.  Even
though this might be repetitious I suggest that we should keep this as it
is.

Nick

> From: esi : etsi tc esi (electronic signatures and infrastructures)
> [mailto:[email-masked]] On Behalf Of Giessmann, Ernstg
> Sent: 13 March 2008 09:25
> To: [email-masked]
> Subject: Re: CAdES implementation. Complete Revocation References attribut
> e.
> 
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
> 
> Dear all,
> Nick's proposals 1) and 2) are good.
> 
> I can't imagine what a 1-to-1 relationship in 3) means.
> Certainly revocation information is in relationship to certificates and
> vice versa. Or is it required that for each certificiate one and only
> one revocation information appears?
> Please clarify to get a positive response on 3)
> 
> Regards,
> Ernst.
> 
> ....snip....
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.7 (MingW32)
> 
> iQEVAwUBR9jwGL6TjTZyMv2oAQgsngf/WMCJyhgmpD/xeg29R5Omob5deDIdyn4F
> FPAtmrDbWor2Or3UEnSpPO5N59gfZAHDl7T+sC2yTqcw0iQXnynKi3j1TcrAP7hH
> YV9l3VhWEtx7OotK/4dEwULz+YFueQKS8ZnBdKqqn5ElHHqzGprY2GTE6YwOOCjI
> cxLbMvqnNd5txuaBiiJKe1BztEWBmLUBFwBBfU9MnSP6esF+jqSc4zTb1WCSFgyK
> IQMmWHdl/Yl5gLxCcW+734035vx67PziB/Lk07osYW+w4L18b6w1TP8e+mLKZxQS
> quEl40LFgjvbsEU9IKvKXpkzt1kEepO52pH3Y3BsLmDQoHETmbX66A==
> =e8pl
> -----END PGP SIGNATURE-----
> 
> -------------------------------------------------------------------
> Mail archive for ESI can be browsed at the following url:
>          http://list.etsi.org/ESI.html
> -------------------------------------------------------------------
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 [email-masked].
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".

---

From: "Pope, Nick" <[email-masked]>
Date: Sun, 16 Mar 2008 19:41:13 -0000

Pavel,

My reading of this paragraph is, as Julien states, that the TSU certificate
itself (as an EE cert) is not to be included in the chain.

Nick

-----Original Message-----
From: Pavel V. Smirnov [mailto:[email-masked]] 
Sent: 13 March 2008 18:04
To: 'Pope, Nick'; [email-masked]
Cc: Julien Stern
Subject: RE: CAdES implementation. Complete Revocation References attribute.

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.

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

Pavel Smirnov

Crypto-Pro
Tel./Fax: +7 495 780-4820
WWW:  <http://www.cryptopro.ru/> http://www.CryptoPro.ru
e-mail:  <mailto:[email-masked]> [email-masked]

From: Pope, Nick [mailto:[email-masked]] 
Sent: Thursday, March 13, 2008 11:33 AM
To: Смирнов Павел Владимирович; [email-masked]; [email-masked]
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:[email-masked]] 
Sent: 06 March 2008 16:47
To: 'Pope, Nick'; [email-masked]
Cc: [email-masked]
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:  <mailto:[email-masked]> [email-masked]

From: [email-masked] [mailto:[email-masked]]
On Behalf Of Pope, Nick
Sent: Wednesday, March 05, 2008 12:27 PM
To: Смирнов Павел Владимирович; Pope, Nick; [email-masked]
Cc: [email-masked]'
Subject: RE: CAdES implementation. Complete Revocation References attribute.

Pavel,

"RFC 2560

      signature            BIT STRING,

      certs                [0] EXPLICIT SEQUENCE OF Certificate OPTIONAL }

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:[email-masked]] 
Sent: 04 March 2008 13:46
To: [email-masked]; [email-masked]
Subject: CAdES implementation. Complete Revocation References attribute.

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.

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:  <mailto:[email-masked]> [email-masked]