RE: DigiCert-Symantec Announcement

[Jeremy Rowley via dev-security-policy]

Hi everyone, 

 

We’re still progressing towards close and transition.  One of the items we are 
heavily evaluating is the root structure and cross-signings post close.  
Although the plan is still being finalized, I wanted to provide a community 
update on the current proposal.

 

Right now, Mozilla post stated that they plan to deprecate Symantec roots for 
TLS by the end of 2018.  We continue to work on a plan to transition all 
customers using the roots for TLS to another root, likely the DigiCert High 
Assurance root.  We will not cross-sign any Symantec roots, however we will 
continue using those roots for code signing and client/email certs post close 
(non-TLS use cases).  We also plan on using Symantec roots to cross-sign some 
of the DigiCert roots to provide ubiquity in non-Mozilla systems and processes. 
 However, this sign will only provide one-way trust, with the ultimate chain in 
Mozilla being EE-> Issuing CA -> DigiCert root in all cases.

 

DigiCert currently has four operational roots in the Mozilla trust store: 
Baltimore, Global, Assured ID, and High Assurance. The other roots are some 
permutation of these four roots that were established for future use 
cases/rollover (ECC vs. RSA).  We already separate operations by Sub CA, with 
TLS, email, and code signing using different issuing CAs. As mentioned in my 
previous post, we plan on using multiple Sub CAs chained to the DigiCert roots 
to further control the population trusted by each Sub CA but have not decided 
on exact numbers. OV and EV will be limited  by Alexa distribution and/or 
number of customers.  DV isn’t readily identifiable by customer and will use a 
common sub CA.

 

Root separation proves a difficult, yet achievable, task as there are only four 
operational roots: Baltimore, High Assurance, Global, and Assured ID. Global 
and High Assurance issue mostly OV/EV certs but do include code signing and 
client certificates. High Assurance is our EV root and used for both EV code 
signing certificates and TLS certs.   Baltimore is our cross-signed root and 
used primarily by older Verizon customers. Assured ID is used mostly for code 
signing and client.  However, Assured ID is also our FBCA root, meaning 
government-issued TLS certificates chain to it.  Of course, all TLS certs are 
issued in accordance with the BRs regardless of root.  

 

Looking at the current customer base, our current plan is to issue EV (code and 
TLS) from High Assurance, OV (code and TLS) from Global. Assured ID will 
continue as our client certificate and government root. We plan to continue 
using Symantec roots for code signing and client.  We’re still looking into 
this though. We’d love to separate out the roots more than this, but that’s not 
likely possible given the current root architecture. If there is a 
non-cross-signed Symantec root that the browsers are not planning to remove, 
we’d like to continue using the root to issue high volume DV and device 
certificates.  If this is not possible and Mozilla is still planning on 
distrusting all Symantec roots, we’ll likely migrate DV certs to a Sub CA 
chained to the Baltimore root.

 

Of course, this is only an initial proposal.  We’ll revise as things progress 
and based on the community feedback.  We appreciate your thoughts.

 

Jeremy

 

 

From: Peter Kurrasch [mailto:fhw...@gmail.com] 
Sent: Thursday, August 3, 2017 11:21 PM
To: Jeremy Rowley ; mozilla-dev-security-policy 

Subject: Re: DigiCert-Symantec Announcement

 

I agree with the high-level concepts, although I would probably like to add 
something about "being good stewards of technologies that play a critical role 
in the global economy." (Feel free to use your own words!)

 

Regarding the current Mozilla/Google plans, I don't necessarily have a problem 
with them but I do think we should give ourselves permission to make 
adjustments (if needed) because the circumstances have changed since those 
plans were developed. Consider:

 

* Because the acquisition is now in the picture, legal issues might impede 
progress in certain areas. The most notable example is the fact that DigiCert 
will have limited authority over Symantec until the deal actually closes. For 
example, what will happen in the period between Dec 1 and the closing (assuming 
it's after the first)?

 

* Once the deal does close, personnel and management issues could present 
various challenges in meeting certain deadlines. For example, if subject matter 
experts decide to leave Symantec prior to the closing, how might that hinder 
DigiCert?

 

* A lot of churn is about to be introduced in the global PKI. Times of chaos 
create moments of opportunity for those who wish to do bad things. Should 
something happen, corrections may be necessary which can impact delivery dates, 
and so on.





Let me be clear that these are just hypothetical situations and rhetorical 
questions. 

Re: BR compliance of legacy certs at root inclusion time

[Ryan Sleevi via dev-security-policy]

On Sun, Aug 20, 2017 at 3:44 PM, Peter Bowen  wrote:

> From the perspective of being "clean" from a given NSS version this,
> makes sense.  However the reality for most situations is there is
> demand to support applications and devices with trust stores that have
> not been updated for a while.  This could be something as similar as
> Firefox ESR or it could be a some device with an older trust store.
> Assuming there is a need to have the same certificate chain work in
> both scenarios, the TLS server may need to send a chain with multiple
> root to root cross-certificates.
>

I'm not sure it's fair to say there needs to be the 'same' certificate
chain working in both. The variety of trust stores already shows how that's
not necessary today. Merely, one needs to have 'a' certificate chain.

Perhaps I've missed a point you weren't stating, but I'm not sure why you
would need root-to-root cross-certificates, as this proposal only applies
to the roots included in Mozilla's store, and offers a transition path for
those roots.


> https://gist.github.com/pzb/cd10fbfffd7cb25bb57c38c3865f18f2 is just
> the roots in each unique disconnected graph.  Having the entries there
> does not imply that all have cross-signed each other, rather than
> there is a path from each pair of roots to a common node.  For
> example, Root A and Root B might each have a subordinate CA that have
> each cross-certified the same, third subordinate.
>

I'm not sure if you're arguing that this is a desired config, or merely, a
config that exists. I certainly would not be willing to suggest CAs have
(effectively) managed their cross-certificates well, and it would seem as
if some of these paths are reflective of business transitions/deals (and
their expirations) rather than intrinsic needs of the Web PKI.

As it sounds like you agree that the overall design is both sound and
desirable, from a Web PKI perspective, perhaps you could clarify what you
believe is a case not supported by this design. This would be useful to
understanding what, if any, material consequence there would be of
implementing this saner approach to root store management.


> Considering we already see paths like:
>
> OU=Class 3 Public Primary Certification Authority,O=VeriSign\, Inc.,C=US =>
> CN=VeriSign Class 3 Public Primary Certification Authority - G3,OU=(c)
> 1999 VeriSign\, Inc. - For authorized use only,OU=VeriSign Trust
> Network,O=VeriSign\, Inc.,C=US =>
> CN=VeriSign Class 3 Public Primary Certification Authority - G5,OU=(c)
> 2006 VeriSign\, Inc. - For authorized use only,OU=VeriSign Trust
> Network,O=VeriSign\, Inc.,C=US =>
> CN=VeriSign Universal Root Certification Authority,OU=(c) 2008
> VeriSign\, Inc. - For authorized use only,OU=VeriSign Trust
> Network,O=VeriSign\, Inc.,C=US =>
> CN=Symantec Class 3 Extended Validation SHA256 SSL CA,OU=Symantec
> Trust Network,O=Symantec Corporation,C=US * =>
> (End-Entity Certificate)
>
> I think we need to be careful when considering root rotations.
>

While a useful real world example, I think the cross-signing activities of
several CAs (and one can examine Entrust for a similar issue, or the
multiple paths StartCom previously did) are not necessarily designed with
either interoperability or consideration of the ecosystem in mind. After
all, this is the same set of activities that make it easy for 'forget'
disclosure of critical intermediates.

Rather, with appropriate advice, one can easily end up with a linear path,
where the only 'cost' is paid by legacy systems that don't update, and the
servers that need to support such legacy systems. As there is an inherent
lifetime for how long something can be 'safely' connected to the Internet,
this doesn't seem unreasonable to build upon.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: BR compliance of legacy certs at root inclusion time

[Peter Bowen via dev-security-policy]

On Fri, Aug 18, 2017 at 8:47 AM, Ryan Sleevi via dev-security-policy
 wrote:
> On Fri, Aug 18, 2017 at 11:02 AM, Gervase Markham via dev-security-policy <
> dev-security-policy@lists.mozilla.org> wrote:
>
>> Sometimes, CAs apply for inclusion with new, clean roots. Other times,
>> CAs apply to include roots which already have a history of issuance. The
>> previous certs issued by that CA aren't always all BR-compliant. Which
>> is in one sense understandable, because up to this point the CA has not
>> been bound by the BRs. Heck, the CA may never even have heard of the BRs
>> until they come to apply - although this seems less likely than it would
>> once have been.
>>
>> What should our policy be regarding BR compliance for certificates
>> issued by a root requesting inclusion, which were issued before the date
>> of their request? Do we:
>>
>> A) Require all certs be BR-compliant going forward, but grandfather in
>>the old ones; or
>> B) Require that any non-BR-compliant old certs be revoked; or
>> C) Require that any seriously (TBD) non-BR-compliant old certs be
>>revoked; or
>> D) something else?
>>
>
> D) Require that the CA create a new root certificate to be included within
> Mozilla products, and which all future BR-compliant certificates will be
> issued from this new root. In the event this CA has an existing root
> included within one or more software products, this CA may cross-certify
> their new root with their old root, thus ensuring their newly-issued
> certificates (which are BR compliant) work with such legacy software.
>
> This ensures that all included CAs operate from a 'clean slate' with no
> baggage or risk. It also ensures that the slate always starts from "BR
> compliant" and continues forward.
>
> However, some (new) CAs may rightfully point out that existing, 'legacy'
> CAs have not had this standard applied to them, and have operated in a
> manner that is not BR compliant in the past.
>
> To reduce and/or eliminate the risk from existing CAs, particularly those
> with long and storied histories of misissuance, which similar present
> unknowns to the community (roots that may have been included for >5 years,
> thus prior to the BR effective date), require the same of existing roots
> who cannot demonstrate that they have had BR audits from the moment of
> their inclusion. That is, require 'legacy' CAs to create and stand up new
> roots, which will be certified by their existing roots, and transition all
> new certificate issuance to these new 'roots' (which will appear to be
> cross-signed/intermediates, at first). Within 39 months, Mozilla will be
> able to remove all 'legacy' roots for purposes of website authentication,
> adding these 'clean' roots in their stead, without any disruption to the
> community. Note that this is separable from D, and represents an effort to
> holistically clean up and reduce risk.
>
> The transition period at present cannot be less than 39 months (the maximum
> validity of a newly issued certificate), plus whatever time is afforded to
> CAs to transition (presumably, on the order of 6 months should be
> sufficient). In the future, it would also be worth considering reducing the
> maximum validity of certificates, such that such rollovers can be completed
> in a more timely fashion, thus keeping the ecosystem in a constant 'clean'
> state.

>From the perspective of being "clean" from a given NSS version this,
makes sense.  However the reality for most situations is there is
demand to support applications and devices with trust stores that have
not been updated for a while.  This could be something as similar as
Firefox ESR or it could be a some device with an older trust store.
Assuming there is a need to have the same certificate chain work in
both scenarios, the TLS server may need to send a chain with multiple
root to root cross-certificates.

To get a feel for how long a not looping path might be, I recently
pulled trust stores for dozens of versions of Windows, Netscape,
Mozilla, and Java.  I then used unexpired cross-certificates from CT
to group these trust anchors into unique clusters or disconnected
graphs.  The results are available as gists.

https://gist.github.com/pzb/cd10fbfffd7cb25bb57c38c3865f18f2 is just
the roots in each unique disconnected graph.  Having the entries there
does not imply that all have cross-signed each other, rather than
there is a path from each pair of roots to a common node.  For
example, Root A and Root B might each have a subordinate CA that have
each cross-certified the same, third subordinate.

https://gist.github.com/pzb/ffab25cbe7d32c616792a5dec3711315 is the
same data with all the unexpired subordinate cross-certificates
included.

Note that the clustering does not take into account anything besides
expiration; for example it is possible that two paths to a common node
have conflicting constraints.

Considering we already see paths like:

OU=Class 3 Public