>
Hi Sriram,
>> Perhaps if I rephrase the validation question a little,
>> it may be a little clearer.
>
>> The validation question is: Given a certificate X and a TA certificate,
>> for what resources is this certificate "valid"?
>
> Suggestion:
> s/Given a certificate X and a TA certificate/Given a certificate X and
> its certification path (per Section 6 of RFC5280)/
>
agreed, this is a little cleared
>> You point out
>>> (In terms of language and clarity, the notion of calling a certificate
>>> "valid"
>>> is misleading when in fact all that is being checked is merely
>>> whether a given INR is subsumed in it.)
>
>> Maybe there is a way of tightening this up.
>> How about: A resource contained in the resource extension
>> of a certificate is defined as "valid" if this resource
>> is listed in the resource extension field of all certificates
>> that are contained in a certification path, where the
>> construction of this certification path is defined in section 6 of RFC5280.
>
> Suggestion:
> s/is listed in the resource extension field of all certificates/
> /is subsumed in the resource extension field of each of the certificates/
>
> (Note: A prefix may not be listed but may be subsumed in a less specific that
> is listed.)
>
agreed
> Do you need somewhat different wording for the case of ROA validation?
> (Is a ROA also technically a "certificate"?)
> When you say "resource contained in the resource extension",
> is that well defined for a ROA as well?
RFC6482 need not be altered at all.
Section 4 of RFC64582 states:
The IP address delegation extension [RFC3779 is present in the
end-entity (EE) certificate (contained within the ROA), and each
IP address prefix(es) in the ROA is contained within the set of IP
addresses specified by the EE certificate's IP address delegation
extension.
which still holds in this slightly altered certificated validation framework.
>
>> (In the WG I also considered a slightly expanded question:
>> Given a certificate X and a set of TA certificates,
>> for what resources is this certificate "valid"?,
>> but that proved to be a little more controversial for many!)
>
> Yes, I also feel that the “join” idea is far more complicated and the
> benefits are not clear.
>
I am working on clarity here in terms of explaining the benefits of this
approach.
thanks,
Geoff
_______________________________________________
sidr mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/sidr
