On Fri, May 19, 2017 at 01:04:45PM -0700, Kathleen Wilson via 
dev-security-policy wrote:
> 
> Gerv, thank you for all the effort you have been putting into this 
> investigation into Symantec's mis-issuances, and in identifying the best way 
> to move forward with the primary goal being to help keep end-users safe.
> 
> I fully support requiring Symantec to set up a new PKI on new infrastructure, 
> and to transition to it in phases, in order to minimize the impact and reduce
> the risk for end-users.
> 
> I think the general direction is correct, but I think there are a few details 
> to be ironed out, such as:
> 
> - What validity periods should be allowed for SSL certs being issued in the 
> old PKI (until the new PKI is ready)? I prefer that this be on the order of 
> 13 months, and not on the order of 3 years, so that we can hope to distrust 
> the old PKI as soon as possible. I prefer to not have to wait 3 years to stop 
> trusting the old PKI for SSL, because a bunch of 3-year SSL certs get issued 
> this year.

So I think we have a few categories of certificates:
- Those issued in the past, which can still be valid for up to 3
  years. I'm not sure when the last 5 year certificates are
  supposed to expire, or if they all expired, but I don't think
  those take long to expire.
- Those that still get issued before they move to some new PKI.

If you want to distrust their existing roots before those
certificates expire, this will most likely results in at least
some people having problems. And that it would be up to Symantec
to make sure those people get new certificates and started using
them.

>From the mail about Chrome's plan, I understand that Chrome's plan
is to only allow certificates from the old PKI if they qualify for
their CT requirements. They plan to only allow certificates issued
after 2016-06-01 because that's the date when they required CT
from Symantec. It seems that Symantec can still issue new certificates
using the old PKI up to 2017-08-08 that are still valid for 3
years.

I'm a little concerned that Firefox and Chrome will have different
certificates they don't trust, and would hope that you can come to
some agreement about when which one would get distrusted.

> - Perhaps the new PKI should only be cross-signed by a particular 
> intermediate cert of a particular root cert, so that we can begin to distrust 
> the rest of the old PKI as soon as possible.

I'm not really sure what you're saying here. If the new PKI is
signed by an other CA, does it matter if it's signed by their
root CA or some (dedicated) intermediate? I don't see how that
relates to distruting the old PKI.

I have a problem with one CA signing an other unrelated CA. I
would prefer that we have a policy that forbids that, and that the
CA should make sure it's own root gets added to the root store.
The only reason I can see for cross signing is for people that still
using an old root store.

> - I'm not sold on the idea of requiring Symantec to use third-party CAs to 
> perform validation/issuance on Symantec's behalf. The most serious concerns 
> that I have with Symantec's old PKI is with their third-party subCAs and 
> third-party RAs. I don't have particular concern about Symantec doing the 
> validation/issuance in-house. So, I think it would be better/safer for 
> Symantec to staff up to do the validation/re-validation in-house rather than 
> using third parties. If the concern is about regaining trust, then add 
> auditing to this.

So they should just create new root CAs and ask them to be
included in the root store?


Kurt

_______________________________________________
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Reply via email to