Re: [sidr] Ben Campbell's Discuss on draft-ietf-sidr-rpki-validation-reconsidered-08: (with DISCUSS and COMMENT)

[Tim Bruijnzeels <[e-mail]>]

Hi,

My apologies for the delay - I am just back from a late summer holiday.

Let me address the DISCUSS is in this, and Terry Manderson’s email, first.

> On 29 Aug 2017, at 04:36, Ben Campbell <[e-mail]> wrote:
> 
> Ben Campbell has entered the following ballot position for
> draft-ietf-sidr-rpki-validation-reconsidered-08: Discuss
> 
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
> 
> 
> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
> 
> 
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-sidr-rpki-validation-reconsidered/
> 
> 
> 
> ----------------------------------------------------------------------
> DISCUSS:
> ----------------------------------------------------------------------
> 
> This is probably just a matter of me being dense, but I'd like to understand
> what I am missing:
> 
> Is it legal to mix certificate policies in a given cert path? The last
> paragraph of section 5 implies that you can, but doesn't say so explicitly. If
> you _can_ mix policies, what happens if you do? If I read the rules in 4.2.4.4.
> correctly (and it's likely that I am not), if you run into a cert in the chain
> that does not follow this profile, it's likely to give a null VRS-IP or VRS-AS
> value, which would seem to invalidate an certificate further down the chain
> that _does_ follow this policy?
> 
> So, I guess it comes down to the following: If mixed policies are allowed, how
> does that work? If mixed policies are not allowed, there needs to be text that
> says that. It's quite possible such text exists (here or elsewhere), and I
> missed it.
> 

First of all it was my understanding that there was an agreement with the AD that actual deployment should be discussed in sidrops. So this document serves as a benchmark to describe the alternative algorithm. In my opinion a mix is supported by this document, but the choice whether this is an acceptable deployment model can be discussed later.

The current document leaves the OID as a per certificate choice and 4.2.2.4 provides a validation model that can be used in either case. In either case the VRS-IP/AS are calculated as described in item #7. Under item #8, the VRS-IP/AS is then compared again to the certificate to determine if it was ‘over-claiming’ compared to its acceptable VRS-IP/AS set. The OID choice determines whether this results in a warning about such over claiming resources, or rejecting. The algorithm defined here when only old OIDs are used is semantically equivalent to section 7.2 of RFC6847.

Note that item #7 does not have explicit text on the case where ‘inherit’ is used, but I believe that this is technically covered by the text in sections 2.2.3.5 and 3.2.3.3 of RFC3779. Essentially: the value of the signing certificate applies, use recursion if that also uses inherit.




> 
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
> 
> Substantive:
> 
> - General: There's a lot of amending going on here--does this draft really not
> update any RFCs (e.g. 6487)?
> 
> - 4.2.4.4:
> -- "Any extension not thus identified MUST NOT appear in
>       certificate x." (Repeats multiple times)
> That seems to prevent future extensibility. Is that the intent?
> 
> -- "Certificate x MUST NOT have been revoked, i.e., it MUST NOT
>       appear on a CRL issued by the CA represented by certificate x-1"
> Is this intended as a requirement to check CRLs? If so, please say that
> explicitly.
> 
> Editorial:
> 
> -4.2.2.1: The third paragraph seems redundant to the first paragraph (pattern
> repeats in several sections.)he
> 
> - 4.2.4.3: "Either the IP Resources extension, or the AS Resources extension, or
>   both, MUST be present in all RPKI certificates, and if present, MUST
>   be marked critical."
> "... and if present..." seems redundant, since the previous clause said one
> MUST be present.
> 
> - 4.3.4.3: "... values are NOT supported..."
> a floating, capitalized "NOT" is not defined in RFC 2119. I suspect the
> all-caps is just for emphasis, but we typically reserve that for RFC 2119
> keywords.
> 
> - 4.2.4.4 :
> -- "Certificate validation requires verifying that all of the following
>   conditions hold, in addition to the certification path validation
>   criteria specified in Section 6 of [RFC5280]."
> 
> The "... in addition to..." part doesn't seem quite true. For example, making
> sure the current date fits in the active range, ensuring a cert is signed by
> the issuer, etc.  are already covered in 5280.
> 
> - - "...certificate MUST contain all
>       extensions defined in section 4.8 of [RFC6487] that must be
>       present."
> That seems tautologically true. If this is a statement of fact, then please
> avoid the MUST. If this is really a new normative requirement, then I'm
> confused at the intent.
> 
> -- "all extensions defined in section 4.8 of
>       [RFC6487], except sections 4.8.9, 4.8.10 and 4.8.10 MUST be
>       present. "
> It would be more reader-friendly to mention what extensions are defined in
> 4.8.9.
> 
> -- "7. Compute the VRS-IP and VRS-AS set values as indicated below:"
> Inconsistent voice.
> 
> -- list entry 7, 4th bullet: "If the IP Address Delegation extension is present
> in
>          certificate x and x=1, set the VRS-IP to the resources found
>          in this extension."
> That seems identical to the first bullet. Should it has said "AS Address
> Delegation extension"?
> 
> 
> _______________________________________________
> sidr mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/sidr
>