At 2:59 PM +1000 4/4/07, Geoff Huston wrote:
...
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.
When a CA is re-keyed, that establishes a new scope, so there will be
two CRL sequences, one for the old key and one for the new key. I
realized this last year when Robert and I were discussing this topic
and I sent a message trying to clarify the conclusion we reached back
then. Both the old and new CRLs need to be present in parallel, until
all the old certs expire or until the old CA cert expires, whichever
comes first. The sequences for both sets of CRLs are numbered
independently.
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?
all of the text that talks about multiple hash algorithms has a
problem, i.e., it does not establish what a CA and an RP MUST
support. We need to be more explicit here. We cannot allow a CA to
use algorithms that we do not require ALL RPs to support.
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.
I agree with this TA description, although I would delete the word
"trusted" from the items, because its redundant. 1-4 are defined in
3280 and 5 is defined as the additional set of parameters needed by
3779, so this is correct.
Steve
_______________________________________________
Sidr mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/sidr
