Hey Suresh,
Most of these comments look OK to me. Couple of responses inline.
--Richard
The inclusion of the owner authorization value indicates that the
certificate has been issued for allowing the node to use the
address(es) or prefix(es) that are mentioned using the X.509
extensions for IP addresses and AS identifiers [RFC3779]. For an
address
in such certificate the host can assign the address, send/receive
traffic from this address, and can respond to NSes about that address.
For a prefix in such certificate the node can perform all the above
mentioned operations for any address in that prefix. Also, when a
prefix
is present in the certificate with the owner authorization value, the
node cannot advertise the prefix in an RA.
This will replace paragraph 6 of section 7. Does this work?
Ok, I understand the difficulty more now, and that text looks fine.
Sec 3 Para "End Entity"
This definition is incorrect. Refer to RFC 4949.
Can we use
"End Entity - an entity that is not a CA"
Might want to note that the entity in question is the subject of a
certificate in the PKI rather than, say, my cat (which, AFAIK, does
not hold any certificates). Suggested text:
"End Entity - An entity in the PKI that is not a CA"
Sec 4 Para 1
The RPKI profile should be applied in *addition* to the RFC 3971
profile, right? Please clarify.
Not really. The csi wg decided to base the new SEND certificate
profile solely on the RPKI profile.
Ok, that should be clearer in the document. Suggest adding this after
the first sentence of Section 4:
"This certificate profile supercedes the profile for router
certificates specified in RFC 3971. That is, certificates used in
SEND (by routers, proxies, or address owners) MUST conform to this
certificate profile and MAY conform to the original profile in RFC
3971."
Sec 4 Para 2
Why can there only be one RFC 3779 extensions? It doesn't seem
like there's a risk in including IPv4 space (e.g., for a dual-
stack router that was vouching for IPv4 space in some other
application?), or multiple extensions for IPv6 space.
I am not sure where this restriction is specified. Can you clarify?
The text I was referring to is the following:
"
SEND certificates MUST include the IP Resources extension for IPv6
Address Family (AFI=0002) described in section 3.9.10 of [I-D.ietf-
sidr-res-certs] and MUST be the only resource extension present.
"
I had read this to mean that the only resources that could be in the
certificate could be a single IPv6 address block. Suggest replacing
with the following clarification:
"
SEND certificates MUST include the IP Resources extension [RFC3779].
This extension MUST include at least one address block for the IPv6
Address Family (AFI=0002), as described in Section 3.9.10 of [I-D.ietf-
sidr-res-certs]. SEND certificates MUST NOT have more than one IP
Resources extension.
"
Sec 5
This section should note that another deployment model (arguably
the most likely) is a combination of these two, in which most
resources are certified under the global RPKI, while some (e.g.,
ULAs) are certified under local TAs.
Sounds good. Will add the following text about a hybrid deployment
model at the end of section 5.
" These two models are not mutually exclusive. It is entirely
possible
to have a hybrid model that incorporates features from both these
models. In one such hybrid deployment model most IP address
resources (e.g. global unicast addresses) would be certified under
the global RPKI, while some others (e.g., ULAs) are certified under
local TAs."
That text looks good, thanks.
Sec 6 Para 4
The requirement for RFC 3779 extension seems to contradict the use
of ETAs as Trust Anchor Material, i.e., the last sentence of the
first paragraph in this section.
Good catch. I am not sure how to resolve this. One way would be to
specify that the ETA EE certificates are exempt from requiring the
RFC3779 extensions. Do you have any suggestions?
I think the rest of the section is clear enough -- the TA material
either has to be a self-signed certificate or it has to be an ETA. So
maybe you could just delete the phrase "and MUST always refer to a
certificate that includes a RFC 3779 address extension"?
As an aside, do you want to specify that in the first case (the non-
ETA case), the self-signed TA cert MUST conform to the RPKI profile?
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf