At 08:38 PM 26/03/2007, Robert Kisteleki wrote:
Hello,
Please find my comments below for discussion.
Thank you indeed for this review. I've responded to each of your
comments in turn. I have raised some followup questions in some of
these response, and I'd appreciate your views on these questions!
Geoff
1. Typo at the bottom of page 6: RSA-SHA-384 OID is {pkcs-1 12}, not
{pkcs-1 11}
agreed
2. In 3.9.5: Just as with the AIA, CRLDP should not appear in a root
certificate.
I looked for this in RFC3280 and could not find such a constraint for
CRLDP, but could find it for the AIA.
I propose adding the text to the CRLDP section (3.9.5)
This extension MUST be present and it is non-critical. [new text ->]
There is one exception; where a CA distributes its public key in the
form of a "self-signed" certificate, the CRLDP MUST be omitted.
I also propose adding the following para to the AIA section (3.9.6)
As noted in Section 4.2.1.1 of RFC3280, there is one exception; where
a CA distributes its public key in the form of a "self-signed"
certificate, the authority key identifier MAY be omitted.
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.
I've consulted section 5.2.3 of RFC 3280 and the text is that a CRL
Number "conveys a monotonically increasing sequence number for a
given CRL scope and CRL issuer. This extension allows users to easily
determine when a particular CRL supersedes another CRL."
Section 4 of this draft already defines the scope as "all
certificates issued by this CA" and the "The CRL Issuer is the CA"
So even when re-keying in the CA, RFC3280 appears to indicate that
the highest CRL supersedes all other CRL.
I don't propose changing the text at this point, as it appears that
the draft's text is already consistent with RFC 3280.
(I must admit that I'm a bit at sea when thinking about a certificate
issued with CA's key pair A being revoked with CA's key pair B, but
my interpretation of the text in 3280 appear to allow precisely that!)
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.
There is no a priori requirement that the same algorithms options be
present for CRLs. and yes, the profile says only SHA-256. Do you see
merit in adding RSA-SHA-384 and RSA-SHA-512 for CRLs?
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.
ok - I'll add
"A resource certificate request MAY use either of PKCS#10 or
Certificate Request Message Format (CRMF). There is no requirement
for a CA Issuer to support both request formats, and the choice of
formats is a matter for the Issuer and Subject to resolve."
Is this suitable?
6. In 5.1.1, signatureAlgorithm: again RSA-SHA-384 and RSA-SHA-512
options are missing.
noted - new text added as per 3.3
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.
Yes, it appears that the subject and issuer have to figure out which
CA is the target of the request through mechanisms other than control
fields in the request itself. I'll remove the test.
Should Authenticator Control be removed as well?
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.
rewording :
"The following extensions may appear in a PKCS#10 or CRMF Certificate
Request. This profile places the following additional constraints on
these extensions."
9. Section 5.3 lists the "SubjectInformationAccess" field twice,
with slightly different text. I believe the second appearance should
be simply omitted.
agreed
10. Same duplicate with SubjectAlternateName (also in 5.3).
agreed
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.
agreed s/MAY/MUST/
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.
Its probably better to remove this sentence, and add the following
The trust anchor information, describing a CA that serves as a trust
anchor, includes the following:
(1) the trusted issuer name,
(2) the trusted public key algorithm,
(3)the trusted public key,
(4)optionally, the trusted public key parameters associated with
the public key, and
(5) a resource set, consisting of a set of IPv4 resources, IPv6
resources and AS number resources.
The trust anchor information may be provided to the path processing
procedure in the form of a self-signed certificate.
13. In 6.3.: "... from the Root Trust Anchors via ..." The term
"Root Trust Anchor" is strange for me.
s/Root Trust Anchor/trust anchor CAs/ ?
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.
will fix!
Cheers,
Robert
thanks,
Geoff
_______________________________________________
Sidr mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/sidr
