[cabf_validation] Clarification of BRs to address "default deny" implications

[Ryan Sleevi]

Thanks Doug,

This is a huge step forward. I'd like to try drafting default language, to
address feedback raised from various auditors about how best to ensure this
interpretation is auditable and actionable.

We can broadly focus on two core areas, both of which are related to
default-deny:

- For certificate profiles, unless a field or attribute is explicitly
permitted, it is denied
- For certificate practices, everything specified is the minimum that must
be implemented. CAs can impose additional constraints, but MUST meet the
specified requirements.

The second one may seem less obviously related to default deny, but it's
more systematically a place of folks assuming an implicit "or any other
method the CA determines to be equivalent", which is not explicitly stated.
That's why this fits within the broader "Default Deny", by trying to
clarify that they are indeed minimum requirements that must be met, and not
allowing substitutions.

The case you raised, of OCSP, is a good one that doesn't fit neatly into
those two scenarios, and so is good to clarify. In fact, I had previously
proposed a ballot nearly 3 years ago to clarify this, by mandating support
for RFC 5019 (which transitively requires the Transport Profile in Section
3, which transitively requires GET). This addresses the question of what
the HTTP Profile is when using RFC 6960 level support for GET. You may
recall some discussion of this during our Berlin Face to Face. back in 2017.

These are the cases that I think we want to continue to suss out and work
through.

On Wed, Feb 19, 2020 at 2:49 AM Doug Beattie via Validation <
validation at cabforum.org> wrote:

> This is my attempt to list the important sections of the BRs and get
> comments on where "default deny" is not clear or will break things.  This
> is one way to review the BRs, perhaps not the best, but this will get the
> discussions moving to address sections of the BRs which are not 100% clear:
>
>
> https://docs.google.com/document/d/1i3CvNbd6mHI9KYYith94C7RQ-ny6ibuo7x7j7m9hSM4/edit
>
>
>
> Here is one obvious example, 4.9.10:
>
>      OCSP responders operated by the CA SHALL support the HTTP GET method,
> as described in RFC 6960 and/or RFC 5019.
>
> If we were to take a "default deny" view of this, then POST is
> prohibited.  If "default deny is the only reasonable way to interpret the
> BRs", then we need to fix this statement and others like it.
>
> During the VWG meeting yesterday there was a suggestion to review the
> lists to be sure that they are clearly either "the" list, or if it's a
> sample of the list (others permitted).  If anyone wants to review this and
> supply their comments, then that would be great.  We can collect up the
> recommended changes from this document into a clarification ballot, or
> ballots.
>
> Doug
>
>
>
>
>
> _______________________________________________
> Validation mailing list
> Validation at cabforum.org
> https://cabforum.org/mailman/listinfo/validation
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cabforum.org/pipermail/validation/attachments/20200219/885e84b1/attachment.html>