Re: [CGA-EXT] about draft-krishnan-cgaext-send-cert-eku-03.txt

["Ana Kukec" <[e-mail]>]

Hi Marcelo,

Tnx for the comments, please see my comments below..


marcelo bagnulo braun wrote:
>
> 2.  Introduction
>
>   Secure Neighbor Discovery [RFC3971] Utilizes X.509v3 certificates for
>   performing router authorization.  It uses the X.509 extension for IP
>   addresses to verify whether the router is authorized to advertise the
>   mentioned IP addresses.
>
> s/addresses/prefixes
>
>   The SEND specification does not describe the set of extensions that
>   need to be supported
>
> This is strictly true, right? I mean section 6.3.1.  Router 
> Authorization Certificate Profile of the send spec does define the 
> cert profile.
>

The send spec describes just the X.509 IP address extension in the 
section 6.3.1 RAC profile, and indirectly the Subject name and the 
subjectAltName extension in the section 6.4.3 TA option.

>
> then it reads
>
> 5.  Backward Compatibility
>
>   The disadvantages of this model are related to the fact that the SEND
>   specification was developed before the standardization of the RPKI.
>   Hence, SEND is not completely compliant with the RPKI specifications
>   since it defines its own IP prefix validation routine and it is not
>   suitable for the use with CRLs, while the RPKI suports only CRLs.
>   This means that SEND implementations supporting this profile will not
>   be able to interoperate with legacy SEND implementations.
>
> I don't fully understnad the implications of this
> I mean, what needs to be changed in a current send implementation to 
> be compatible with this new format?
> I mean, the optimal would be that current send implementations accept 
> RPKI certs but skip the new extensions and that new send 
> implementations are able to read the new extensions defined by this 
> document. is this not possible?


The incompliances between the RPKI and SEND are related to the X.509 
extensions profile and their validation. Regarding the acception of the 
RPKI certificate profile into SeND, there are two problematic 
extensions, the EKU extension (as we already discussed) and the 
subjectAltName extension. The send spec requires the usage of the 
subjectAltName extension in order to match its contents with the Trust 
Anchor option of the FQDN type (as described in the section 6.4.5 of the 
send spec). But, since the RPKI is about the authorization and not about 
the authentication, the subject names in RPKI are not intended to be 
descriptive, and thus the RPKI certificate profile, i.e. 
draft-ietf-sidr-res-certs-16 does not use/describe the subjectAltName 
extension at all.

Regarding the validation routines, the rfc3779 extension validation 
routine conflicts with the one described in the send spec. But together 
with the RPKI certificate profile we can accept the rfc3779 extension 
validation routine.

Contrary to the X.509 extensions and the validation routines, the 
revocation is not a conflicting thing, it is just that the SeND lacks 
the text describing how to incorporate the RPKI revocation into SeND. 
With carefully chosen validity intervals for the RPKI certificates on 
the lower tiers, i.e. at the SEND level,  the CRL is not expected to 
grow to large sizes, and it can fit well into the SEND messages.

Regarding the section 4.1. EKU extension, we will describe it more in 
details, in collaboration with the sidr wg.

Ana