[cabfpub] Ballot 167 - Baseline Requirements Corrections

[Ryan Sleevi]

So it would seem you are arguing that a CA should be permissible to encode
these fields in BER, because that is the only possible way to support the
interpretation that you're concerned about being material and non-trivial,
since this would prohibit such an interpretation.

Though I strongly disagree, it's helpful to understand your perspective,
and would hope we don't have to see a 2 week delay for a pre-existing
concern of a hypothetical problem for which auditors can be informed on the
basis of this discussion here, but we'll have to see how the vote turns out.

On Fri, Apr 15, 2016 at 1:14 PM, Jeremy Rowley <jeremy.rowley at digicert.com>
wrote:

> *Potentially non-trivial. Whether it’s material probably depends on the CA
> and their interpretation and auditor.
>
>
>
> *From:* public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] *On
> Behalf Of *Jeremy Rowley
> *Sent:* Friday, April 15, 2016 2:12 PM
> *To:* Ryan Sleevi
> *Cc:* CABFPub
> *Subject:* Re: [cabfpub] Ballot 167 - Baseline Requirements Corrections
>
>
>
> On Fri, Apr 15, 2016 at 12:50 PM, Jeremy Rowley <
> jeremy.rowley at digicert.com> wrote:
>
> Alright, but if I am planning to introduce the ballot that clearly
> conflicts with 5280, won't this be a problem? Plus, name constraints  are
> an obvious conflict as they are required to be marked critical in 5280 but
> not required to be marked critical in the BRs. This was done to support
> Apple (similar to the proposal I am making for IP Addresses).
>
> This language is a change as it says "All other fields and extensions MUST
> be set in accordance with 5280".  The language you proposed removes the
> "All other.."
>
>
>
> Surely you don't mean to suggest that it would be permissible, based on
> that language, to encoder in BER the Certificate Policies (v.1.3.4,
> 7.1.2.2, item a), right? So the "all other" surely does not exempt the
> current, enumerated fields from needing to comply with 5280, or else we'd
> have a great mess on our hands.
>
> [JR]  I’m suggesting this language change is a material change and
> non-trivial.
>
>
>
> Similarly for basicConstraints - if we take the approach you're implying,
> it would suggest that a conforming BR certificate does not need to conform
> to RFC 5280, only to the obligations set forth in the BRs (e.g. v.1.3.4,
> 7.1.2.3, item D), which don't specify the encoding rules (e.g. DER vs BER)
>
> [JR]  See above
>
>
>
> I think your concern with respect to non-criticality is already addressed,
> and unaffected by, this ballot, in that v1.3.4, 7.1.2.2, item f provides
> the scope-limited exception to 5280, very explicitly, rather than
> interpreting it as if there's a blanket exception to 5280 for all
> enumerated fields, which you seem to be arguing for.
>
> [JR] No. I’m saying the old language needs to be retained as the impact
> hasn’t really been evaluated yet.
>
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://cabforum.org/pipermail/public/attachments/20160415/a54d420d/attachment.html