[cabfpub] Ballot 167 - Baseline Requirements Corrections

Ryan Sleevi sleevi at google.com
Fri Apr 15 20:01:59 UTC 2016


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.

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)

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/public/attachments/20160415/83d1cb4d/attachment-0003.html>


More information about the Public mailing list