|
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-----
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
From:
Pope, Nick [mailto:Nick.Pope@xxxxxxxxxxxxxxxxxxxx]
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-----
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
From:
owner-ietf-smime@xxxxxxxxxxxx [mailto:owner-ietf-smime@xxxxxxxxxxxx] On Behalf Of Pope, Nick
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-----
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
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". |