Hello,
(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!)
We may have to ask for some guidance from the PKIX folk on this one.
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?
It only seems logical to allow it here too.
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?
I believe it could be useful, so we probably want allow it.
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 believe that regarding a TA:
- (1) is optional
- (5) is optional
- A URL for top-down chaining (practically a "starting SIA") is useful,
therefore optional.
Cheers,
Robert
thanks,
Geoff
_______________________________________________
Sidr mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/sidr
