Hello,
Please find my comments below for discussion.
1. Typo at the bottom of page 6: RSA-SHA-384 OID is {pkcs-1 12}, not
{pkcs-1 11}
2. In 3.9.5: Just as with the AIA, CRLDP should not appear in a root
certificate.
3.In 4, last paragraph: "... Where two or more CRLs issued by a single
CA are present in a certificate repository, the CRL with the highest
value of the "CRL Number" field supersedes all other CRLs issued by this
CA."
When doing a rekey, a CA may have more than one key pair working in
parallel, therefore must issue more than one CRL. In this case, the
highest CRL number does not supersede all CRLs by that CA.
4. In 4.5, Signature can be RSA-SHA-256 only. Looking back at 3.3, I
miss RSA-SHA-384 and RSA-SHA-512 from here.
5. In 5, I miss an introductory paragraph stating something like "a
resource certificate request can be either PKCS#10 or CRMF". Without it,
it is quite unclear why two different request formats are described below.
6. In 5.1.1, signatureAlgorithm: again RSA-SHA-384 and RSA-SHA-512
options are missing.
7. In 5.2.2, Resource Class: As the subject can also use PKCS#10 which
does not have this option, I don't really see why is this field is a
MUST. Also, when generating a request, the subject may not be aware of
exactly which resource class that request/keypair will be used with, in
which case this field cannot be filled in.
8. Section 5.3 starts with "This profile allows the following extensions
to appear..." and then goes on describing fields which "MUST be
omitted". I find this a bit confusing.
9. Section 5.3 lists the "SubjectInformationAccess" field twice, with
slightly different text. I believe the second appearance should be
simply omitted.
10. Same duplicate with SubjectAlternateName (also in 5.3).
11. At the very end of 5.3: I think the CA should not alter the
SubjectInformationAccess requested by the subject. There is a reason why
the subject asked for any particular URL: that is the adress they will
be able to publish to. If the CA deliberately changes this, then the
subject may end up with an unusable certificate.
12. In 6.1 we see "The only exception to the "no loop" condition would
be where a putative trust anchor may issue a self-signed root
certificate." This is confusing: "a self-signed certificate" by
definition cannot be issued by anyone else but itself. The may be signed
by the trust anchor key though.
13. In 6.3.: "... from the Root Trust Anchors via ..." The term "Root
Trust Anchor" is strange for me.
14. In the example in Appendix A, the SIA value is syntactically wrong
according to 3.9.7, as it does not end with '/'. Also, although it is
theoretically not wrong, I miss the '.cer' extension from the end of the
AIA value.
Cheers,
Robert
_______________________________________________
Sidr mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/sidr
