Subject: [Sidr] draft-ietf-sidr-res-certs-05.txt comments

From: Robert Kisteleki <[email-masked]>
Date: Mon, 26 Mar 2007 12:38:23 +0200

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-masked]
https://www1.ietf.org/mailman/listinfo/sidr