On Fri, May 19, 2017 at 6:47 AM, Gervase Markham via
dev-security-policy <dev-security-policy@lists.mozilla.org> wrote:
> We need to have a discussion about the appropriate scope for:
>
> 1) the applicability of Mozilla's root policy
> 2) required disclosure in the CCADB
>
> The two questions are related, with 2) obviously being a subset of 1).
> It's also possible we might decide that for some certificates, some
> subset of the Mozilla policy applies, but not all of it.
>
> I'm not even sure how best to frame this discussion, so let's have a go
> from this angle, and if it runs into the weeds, we can try again another
> way.
>
> The goal of scoping the Mozilla policy is, to my mind, to have Mozilla
> policy sufficiently broadly applicable that it covers all
> publicly-trusted certs and also doesn't leave unregulated sufficiently
> large number of untrusted certs inside publicly-trusted hierarchies that
> it will hold back forward progress on standards and security.
>
> The goal of CCADB disclosure is to see what's going on inside the WebPKI
> in sufficient detail that we don't miss important things. Yes, that's vague.
>
> Here follow a list of scenarios for certificate issuance. Which of these
> situations should be in full Mozilla policy scope, which should be in
> partial scope (if any), and which of those should require CCADB
> disclosure? Are there scenarios I've missed?
You seem to be assuming each of A-I have a path length constraint of
0, as your scenarios don't include CA-certs below each category.
> A) Unconstrained intermediate
> AA) EE below
> B) Intermediate constrained to id-kp-serverAuth
> BB) EE below
> C) Intermediate constrained to id-kp-emailProtection
> CC) EE below
> D) Intermediate constrained to anyEKU
> DD) EE below
> E) Intermediate usage-constrained some other way
> EE) EE below
> F) Intermediate name-constrained (dnsName/ipAddress)
> FF) EE below
> G) Intermediate name-constrained (rfc822Name)
> GG) EE below
> H) Intermediate name-constrained (srvName)
> HH) EE below
> I) Intermediate name-constrained some other way
> II) EE below
>
> If a certificate were to only be partially in scope, one could imagine
> it being exempt from one or more of the following sections of the
> Mozilla policy:
>
> * BR Compliance (2.3)
> * Audit (3.1) and auditors (3.2)
> * CP and CPS (3.3)
> * CCADB (4)
> * Revocation (6)
I would say that any CA-certificate signed by a CA that does not have
name constraints and not constrained to things outside the set
{id-kp-serverAuth, id-kp-emailProtection, anyEKU} should be disclosed.
This would mean that the top level of all constrained hierarchies is
disclosed but subordinate CAs further down the tree and EE certs are
not. I think that this is a reasonable trade off of privacy vs
disclosure.
Thanks,
Peter
_______________________________________________
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy
