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

[marcelo bagnulo braun <[e-mail]>]

Ana Kukec escribió:
> 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.
>
not really

the draft says:

   The extended key usage extension MAY, at the option of the
   certificate issuer, be either critical or non-critical.

So, if we do it as the draft says, it would be compatible with current 
implementations, right?

>>
>> 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..

but wouldn't that be a different use of the semantics of the subject name?

So, afaiu from this, the currnet implementations would not accept certs 
wihtout the TA and they would fial inthis case
We may be able to tweak it in way that we can make this work, by upating 
the send nodes
the other options is to see how posible is for RPKI cert profile to 
accept TA, is this correct?

>
>>>
>>>
>>> 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.
>
>
great

>>>
>>> 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.
>
but if we don't do it, it would imply that we have current send support, 
right?

I mean, if we do it, it is an enhacement but we can not do it
I guess it is up to the wg to decide what to do

>>
>> 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.
>
ok, someone else has an opinion on ths?


regards, marcelo

> Ana