Sandy,
I can’t parse “but using the constraints applied come from this specification”.
Can you clarify?
The text I supplied for the replacement validation alg were based on the
original text, whenever possible. Unfortunately, the original text
refers to sections of 6487 implicitly as "this specification". Thus, in
the new document we need to explicitly note that the indicated
constraints on certs (e.g., required/prohibited extensions, etc.) are in
the relevant parts of 6487.
Sean added an implementation considerations section which I suggest will say:
Operators MAY choose to issue separate BGPsec Router Certificates for
different ASNs. Doing so may prevent a BGPsec Router Certificate from
becoming invalid if one of the ASNs is removed from any superior CA
certificate
along the path to a trust anchor.
I quibble about this wording. why do you say “may”? Is it because if the ASN
in one of the separate router certificates is one of the ASNs that is removed,
then it still becomes invalid?
I think you mean:
This document permits the operator to include a list of ASNs in a BGPsec Router
Certificate.
In that case, the router certificate would become invalid if any one of the
ASNs is removed
from any superior CA certificate along the path to a trust anchor. Operators
MAY choose
to avoid this possibility by issuing a separate BGPsec Router Certificate for
each distinct
ASN, so that the router certificates for ASNs that are retained in the superior
CA certificate
would remain valid.
I prefer your text. Nice job.
I’m not sure you meant a normative “MAY choose” ("there are reasons, <listed
here,> to make this choice”) or “could possibly choose”
I'm not picky about the case of the MAY here.
I hope these changes avoid the need to say anything about router certs in your
doc.
I'm not sure there is a need to change the ROA spec. If we agree that all
prefixes in the ROA MUST be contained in the EE cert for that ROA, then the
current text in the ROA spec does not need to change.
Well……
The ROA RFC says validation of the ROA must satisfy:
o The IP address delegation extension [RFC3779] is present in the
end-entity (EE) certificate (contained within the ROA), and each
IP address prefix(es) in the ROA is contained within the set of IP
addresses specified by the EE certificate's IP address delegation
extension.
If the EE certificate and the ROA mention a /18, and a /19 is removed from a
“superior CA certificate”, then there is/are only a /19 of the EE certificate
that is/are VRP. And every prefix in the ROA is still contained in the EE
cert, so this validation step is satisfied. What does this ROA now authorized?
How would it be applied in BGP route validation?
I see your point. yes, the ROA spec does need to be modified.
Steve
_______________________________________________
sidr mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/sidr
