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

[Ana Kukec <[e-mail]>]

marcelo bagnulo braun wrote:
>>
>>
>> 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)
>
> right, but my question is what happens when a current send node 
> receives a cert with the EKU? does it fails, or does it just skipe the 
> option takes the cert as valid?

The draft says that the EKU extension is a critical extension, i.e. if 
the receiving node does not recognize the extension, it must reject the 
certificate.

>
> So, this seems to psoe two problems:
> - first, that a current send node will not accept as valid a cert 
> without the subjectAltname, right? While this is not optimal, we may 
> be able to live with that
> - second, how does a send node uses the subjectAltName? i mean does 
> the send node needs this information to validate the anchor point? If 
> so, how do we deal with this?


The TA option either helps the receivers to decide which advertisements 
are useful for them or denotes the TAs that the client is willing to 
accept (in the solicitation message). If the TA is represented as a 
FQDN, the FQDN must be equal to the subjectAltName in the TA's certificate.

On the other hand, we can survive with using just the Subject name field 
and the DER Encoded X.501 Name Trust Anchor option..

>>
>>
>> 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.
>
> not sure waht do you mean here... can we still use the send validation 
> routing? Or we need to change the send nodes to do the new validation 
> routine?


The RPKI uses the validation described in rfc3779 (section 2.3). The 
validation described in the send spec is compliant with that one, but 
more detailed. So, we can just point out that despite using the RPKI 
profile, nodes have to take into account the send validation as well.


>>
>> 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.
> right, but do we need to specify the revocation routines as well?


The RPKI uses the PKI revocation routines with pure CRLs, and if we 
accept the RPKI profile, IMO we should use and process the CRLs in SeND. 
Thus, yes, IMO we should specify messages for the CRL transportation and 
the processing routines for the receivers.

>
> I would like to understnad if we need to update rfc3971 to support 
> this, i understnad we do. I am not sure i fully understnad what are 
> the updates that are needed to rfc3971... could you elaborate on this?

Afaiu, we should update the part about the revocation, and decide what 
exactly to do with the subjectAltName extension, and update that part as 
well.

Ana