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