Re: [secdir] secdir review of draft-ietf-csi-send-cert-03

["Richard L. Barnes" <[e-mail]>]

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?