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
_______________________________________________
CGA-EXT mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/cga-ext
