Re: Symantec: Update

2017-05-13 Thread Michael Casadevall via dev-security-policy
On 05/11/2017 09:53 AM, Jonathan Rudenberg via dev-security-policy wrote:
> 
>> On May 10, 2017, at 11:52, Gervase Markham via dev-security-policy 
>>  wrote:
>>
>> I would appreciate people's comments on the details of the current draft.
> 
> I don’t think that this proposal goes far enough.

First post on the list but long time lurker, but I feel the need to
weigh in here that I think Jonathah's proposal is much closer to what
has to happen.

Reading through Gervase's document, I'd like to add the following to
this in addition to the existing notes in PKI operations:

 - EV certificate roots loose their trust bits effective immediately
   (I don't think this can be done via OneCRL so it would be via the
next release)
 - Any root stores (new or old) operated by Symantec shall require all
certificates to be posted to a CT log.
 - Within three months, require all certificates issued from Symantec to
have SCT embedded in the end point certificate, and mandate this from
the beginning for any root certificates.
   - NSS shall only accept certificates with the embedded SCT record in
the certificate.

Certificate transparency was the only way we began to get a real look at
how bad some of these issues are, and I feel that if we're going to
actually continue with Symatec as a CA, then we're going to make
absolutely sure we know how certificates are being utilized.

Mandating the X509v3 extension for TLS certificates means that
downstream servers don't have to be updated for CT awareness, and we
should never be in a case where a Mozilla product is accepting a
certificate that we can't independent review at a further point via the
CT logs. It should also prevent an undisclosed intermediately from being
undetected (as we've seen with Issue Y).


I'd also like to add the following to the transition plans:
 - Limit certificate expiration to nine months from the existing roots
for new certificates.
 - The above SCT requirement shall come into affect for the old roots no
less that three months from the date the proposal is ratified.
 - Create a whitelist of intermediate certificates from the root that
can continue issuing certificates, but cutting off RAs after an initial
six month time period
 - Require that Symantec reapply to the root program for a new DV and EV
root certificates, and begin the migration here. Once the new roots are
approved, then they can cross-sign from the old roots to the new ones.

My thought process here is to try and keep impact on WebPKI a minimum,
while making sure that we can externally audit how Symantec is using
their root store for certificates that will be trusted by Mozilla.

I'm concerned that spinning up new roots and having them be in the most
common root stores is going to take a significant period of time and
during that window we're still stuck with the old roots being in
operation. By limiting the branches of the old roots, it should limit
our risk while the new roots come into existence and begin to spread
through the ecosystem.

Winding down the old roots (phase four as described in the proposal) is
going to be a long and slow process so I want to make sure we're making
sure that while we're in the transition period that we've got an
extremely clear picture on what's going on on both sets of roots.

My problem with the Google "sliding scale" is that's its damn hard to
understand when exactly a certificate is good or when it expires since
the dates in the X509 certificate don't necessarily correspond with
reality. By simply capping Symantec certificates to nine months, it puts
us in a position that moving to a new DV/EV root would be required for
them to remain competitive while not drastically affecting the ecosystem
as a whole.

Maybe I'm off-kilter here, but I think this proposal would help keep
impact on WebPKI to a minimum but light a fairly serious fire to get
users moved to the new root stores ASAP. Please let me know if I am
seriously off base with my understanding of the situation or the
technologies involved; WebPKI is a complicated thing to understand :)
Michael





signature.asc
Description: OpenPGP digital signature
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy


Re: Configuring Graduated Trust for Non-Browser Consumption

2017-05-13 Thread Peter Bowen via dev-security-policy

> On May 12, 2017, at 3:48 PM, Ryan Sleevi via dev-security-policy 
>  wrote:
> 
> On Fri, May 12, 2017 at 6:02 PM, Jakob Bohm via dev-security-policy <
> dev-security-policy@lists.mozilla.org> wrote:
>> 
>> This SubThread (going back to Kurt Roeckx's post at 08:06 UTC) is about
>> suggesting a good format for sharing this info across libraries though.
>> Discussing that on a list dedicated to a single library (such as NSS or
>> OpenSSL) would be pointless.
>> 
> 
> And in the original message, what was requested was
> "If Mozilla is interested in doing a substantial public service, this
> situation could be improved by having Mozilla and MDSP define a static
> configuration format that expresses the graduated trust rules as data, not
> code."
> 
> Mozilla does express such graduated trust rules as data, not code, when
> possible. This is available with in the certdata.txt module data as
> expressive records using the NSS vendor attributes.
> 
> Not all such requirements can be expressed as code, not data, but when
> possible, Mozilla does. That consuming applications do not make use of that
> information is something that consuming applications should deal with.

One thing that doesn’t happen today but would likely be broadly compatible 
would be to replace certain self-signed root certs in the trust store with 
certs that appear to be cross-signed with restrictions.  They could in reality 
have fixed values in the signature section, but this would allow adding 
constraints directly in certificate structure.  Examples could include adding 
or modifying extensions such as extendedKeyUsage, nameConstraints, or  private 
key usage period.

Thanks,
Peter
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy