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

[Ana Kukec <[e-mail]>]

marcelo bagnulo braun wrote:
>>
>> 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?

Right, sorry. Yes, it would be, i.e. it is according to the current text 
in the draft.

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


No.. what do you mean? According to the send spec the TA option can be 
either of the type DER Encoded X.501 Name (matching the certificate 
Subject name) or the FQDN (matching the subjectAltName).


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

Yes, we can specify the usage of the TA option only of the type X.501 
DN. The other option is to include the subjectAltName in the RPKI 
certificate profile, which is not likely to happen (see the section 3.5. 
in the draft-ietf-sidr-res-certs-16).

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

Yes.


Ana