Hi,
the RFC contains the same issues as the corresponding ETSI standard.
These issue will most likely by fixed in a revision of the standard,
but they are currently present.
If the RFC is supposed to be strictly aligned with version 1.7.3
of ETSI 101 733, and if a new version revision of the RFC is planned
when the new revision of the ETSI standard occurs, then dismiss these
comments.
Regards,
--
Julien
----------------------
In section 6.2.1:
QUOTE:
| The complete-certificate-references attribute is an unsigned attribute.
| It references the full set of CA certificates ...
There can (and SHOULD in fact) be some other certificates
(CRL Issuers, OCSP responders, ...)
----------------------
In section 6.2.2:
This section calls for a one-to-one mapping from the revocation
information on the certificates and talks about certificate path.
QUOTE:
| 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 certificate "path" is not a "path". It is a "tree" in the
general case. This makes the one-to-one mapping more complex to
implement. This may force the duplication of references. And finally,
it is not possible to always respect the latest rules (e.g. for an
OCSP responder with the no-check extension).