On 13/09/2016 05:01, Peter Bowen wrote:
On Mon, Sep 12, 2016 at 7:02 PM, Ryan Sleevi <[email protected]> wrote:
On Monday, September 12, 2016 at 6:09:05 PM UTC-7, Peter Bowen wrote:
This would have two advantages:
1) Helps limit blast radius of whitelisting a name/domain
I'm unclear what you mean by this. I suggest there's an additional, unstated
threat model or concern?
I'm trying to think of this as potentially reusable code. Just
because IssuerA is quasi-trusted for example.com doesn't mean IssuerB
should be. From a logic perspective, setting the whitelist per issuer
means you are basically creating name-constrained issuers.
2) Provides a path for a CA to continue issuing
certificates for use with trust stores and users that continue to
trust them. They could create new issuers from the existing roots
which wouldn't be subject to the whitelist. Users who want to trust
them simply need to add the roots to their trust store if the roots
are not already there.
If such a path seems desirable and worthwhile, that's certainly true. Call that
a variation of G, then, perhaps G.2, as perhaps not all trust stores would
consider a proverbial path to redemption at the Intermediate level, and might
only consider it at the Root level.
I guess I wasn't clear enough. I'm thinking that the trust store
would remove RootA but add IssuerA1, IssuerA2, etc as trust anchors.
So RootA could create IssuerNewA12 or whatever and issuer from that.
As the trust store doesn't have RootA at all (not trusted or
distrusted), users could choose how to handle RootA going forward.
RootA's operator could also apply to have RootA added back to the
trust store at some future point.
Requiring new issuers would also allow #3 to be easily enforced over a
disjoint set from the whitelist and allow various pinning-like rules
to be created in software (browsers or otherwise).
Possibly. However, unless #3 is implemented simultaneously (and as you know, it
has a dependency on a CA component), it's more likely that implementing #2 and
requiring a new root is functionally the same, but with significant less
complexity in code or for relying parties.
Again, assuming issuers are added as trust anchors, a "shortest path"
algorithm would choose them over a re-added Root. The Root could have
additional restrictions applied (e.g. Expect-CT) that don't apply to
the old issuers.
A variation of this, would be to create (compacted) whitelists for
specific old intermediary certs, then tag the CA root as requiring
other measures (such as CT) where not overridden via whitelisting.
That way, the CA cannot bypass the measure by creating new intermediary
certs for which no trust restrictions exist.
Enjoy
Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark. Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded
_______________________________________________
dev-security-policy mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-security-policy
