Re: ComSign Root Renewal Request

[Wayne Thayer via dev-security-policy]

Hi Yair,

On Mon, Feb 12, 2018 at 11:50 AM, YairE via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> Hi Wayne,
> Please realize our situation versus the Israeli market. We are the major
> certificate authority and we comply with every piece of local regulation,
> we are also members of international forums and trying to establish a CA in
> the UK with a new "international" root (Comsign International).This is our
> long term plan.
> Meanwhile we are in a tough task to move from the RSA old and unsupported
> CA software to a new MS CA. It isn’t simple and involves many aspects,
> locally and internationally. On the same time, we try to be certified to
> eIDAS in order to be included in the European Trust list.
> Mozilla is a mile stone that we MUST pass once and for all, as it prevents
> and holds us from supplying a lot of signing services to the Israeli
> market, especially the increasing requests for services over the mobile.
> So, while we try to go "hand by hand" with you and with the BR, if you now
> send us back with the ROOT we have, it actually eliminates all the work we
> are doing to be complied with Mozilla for a long period of time, as you
> mentioned in your message. We can estimate that we will fully switch to MS
> within 6 months or so, mainly because we wait for the final audit and the
> approval of the  Israeli Ministry of Justice, but if, as you suggest, you
> do not trust the ROOT (not only the CA software in which we are all on the
> same page with you), it is a much bigger problem, as you understand the
> meaning of such severe conclusion after all our efforts we did with Mozilla
> not to speak about the damage to our reputation that such a decision
> creates.
>
> That was the background. For the essence:
> 1."ComSign Global Root CA that was created in 2011 was first BR audited on
> 26-April 2015, but 36 end-entity certificates were issued prior to that
> time, all but one has since expired)."
> >>This one certificate expires at 3/2018 and we commit not to issue new
> SSL certificates until we are authorized with the new MS CA. However this
> point should not affect the integrity of the entire Root.
>
> 2."However, am unable to locate any additional audit documentation
> covering 2011-2015.".
> >>We've asked the auditor (CPA Shefler which is approved by Webtrust from
> ~mid 2015) to send us all the audits reports. As is already disclosed this
> ROOT has passed many Webtrust audits over the last years and can be
> considered audited –we have already disclosed all the certificates that
> were issued prior to our first Webtrust as you have asked earlier on this
> thread.
>
> 3."ComSign stated that they are currently using “RSA CA 6.7 on Solaris” to
> issue certificates. This version has not been supported since July 2013
> [4]. This implies that all 36 certificates were issued using unsupported CA
> software."
> >>Correct. Wrong decision of Comsign, which we apologized for. However, we
> still believe is should not affect the entire ROOT.
>
> 4."I’ve discovered that ComSign recently issued two new unconstrained
> subordinate Cas [5] from this root that contain a non-critical
> basicConstraints extension in violation of BR 7.1.2.2.
> >>While we appreciate your point here, these subCA's are not issuing SSL
> certificates at all but client certificates only. We cannot revoke these
> subordinates that serve hundreds of thousands of customers. However, if you
> approve our root – we commit to disclose the new SSL subCA before we issue
> new SSL certificates, while we keep the BR rules strictly of course.
>
> This comment demonstrates a continued lack of knowledge of Mozilla
requirements. Specifically, section 1.1 places these intermediates in-scope
because they are capable of issuing SSL certificates, so they must comply
with the BRs.

5."Another unconstrained subordinate CA has been used to issue email
> certificates that contain encoding errors [6]."
> >>That subCA does not issue SSL certificates as we mentioned above, the
> encoding error was corrected long ago and is linked to the RSA software
> that we are replacing in any case.
>
> 6."In addition, numerous problems with ComSign’s CPS have been discussed
> in this thread".
> >>All these problems were corrected by us and approved by Mozilla
> representatives.
>
> Yes, these problems were corrected after being identified by Mozilla, but
that is not trustworthy behavior. How many problems remain that we haven't
identified? A CA earns trust by understanding and complying with
requirements without supervision.


> 7."While I appreciate ComSign’s efforts to resolve issues that have been
> identified, new ones continue to be found. I am not at all comfortable
> recommending that this request proceed at this time, and I have also lost
> confidence that trust can ever be established for this root given its
> history. I support Ryan’s recommendation that this request be denied and
> that ComSign be asked to submit a new 

Re: Japan GPKI Root Renewal Request

[Wayne Thayer via dev-security-policy]

All of my questions regarding the CP/CPS and audits have been answered to
my satisfaction. I am left with two concerns:

1. This root was signed on 12-March 2013. The first end-entity certificate
that I'm aware of was signed later in 2013. Mozilla began requiring BR
audits in 2014, but the first BR assessment for this root was on
30-September 2015. [1] The assessment shows 22 issues. [2] A PITRA was
finally performed on January 31, 2017 [3] and no qualifications were noted.
This was followed by a clean period-of-time audit. It is clear that
hundreds of certificates were issued in this certificate hierarchy while it
was not BR compliant, some of which have not yet expired.

2. A number of misissued certificates under this hierarchy have been logged
[4], some of which are still valid. Some of these contain significant
compatibility problems such as the lack of a SAN and the lack of an OCSP
URL. The good news is that all of the bad certificates were issued prior to
2017.

At a minimum, the unexpired misissued certificates should be revoked, just
as has been done by other CAs in the Mozilla program. However, given the
demonstrated lack of BR compliance from 2013-2016, we should consider
rejecting this request and requiring that a new root using a new key pair
be generated and submitted for inclusion.

Please be aware that trust in this root will be constrained to .go.jp
domains, significantly reducing the risk it presents to Mozilla users.

I would appreciate everyone's constructive feedback on these issues, and
any others that are relevant to this inclusion request.

- Wayne

[1] https://bug870185.bmoattachments.org/attachment.cgi?id=8667814
[2] https://bug870185.bmoattachments.org/attachment.cgi?id=8667815
[3] https://bug870185.bmoattachments.org/attachment.cgi?id=8852738
[4]
https://crt.sh/?caid=1419=cablint,zlint,x509lint=2013-01-01

On Mon, Feb 5, 2018 at 10:05 PM, apca2.2013--- via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> Below is the answer to the pointed out earlier.
>
> == Bad ==
> * CPS docs are not assigned a version number (Mozilla policy 3.3)
>
> We had set up CP / CPS version number assignment rules. Based on this, at
> present CP / CPS Root version is Ver. 1.05 and CP / CPS Sub version is
> 1.07. We attached CP / CPS with version number.
>
>
> * I can’t find a current WebTrust for CAs audit statement - I've requested
> a translated copy in the bug. There may be confusion over the fact that two
> audits are required.
>
> Since the audit reports were posted on WebTrust's website as follows, we
> will report those URLs.
> WebTrust: https://cert.webtrust.org/ViewSeal?id=2385
> SSLBR: https://cert.webtrust.org/ViewSeal?id=2386
>
>
> * The translated WebTrust BR audit report does not include all the
> information required by Mozilla policy 3.1.4. Based on information in the
> bug I believe this meant to be a period-of-time audit, but it looks like a
> point-in time readiness audit.
>
> (Same as the above answer）
> Since the audit reports were posted on WebTrust's website as follows, we
> will report those URLs.
> WebTrust: https://cert.webtrust.org/ViewSeal?id=2385
> SSLBR: https://cert.webtrust.org/ViewSeal?id=2386
>
>
> == Meh ==
> * Full name of the BRs is cut off in section 1: “CA/Browser  Forum,
> Baseline Requirements for the Issuance and Management of Publicly.”
>
> At the next revision, we will modify the corresponding part of CP / CPS
> section 1 of application CA 2 (Root) and application CA 2 (Sub) as follows.
> Application CA 2 (Root / Sub) conforms to the Baseline Requirements of CA
> / Browser Forum published at https://www.cabforum.org/.
>
>
> * Revision history doesn’t state what was changed (Mozilla policy 3.3
> requires a “dated changelog” but doesn’t explicitly require a description
> of changes to be included)
>
> At the next revision, we will add a change history of application CA 2
> (Root) and application CA 2 (Sub).
>
>
> * Neither the CPS or the BR Self Assessment explain how GPKI identifies
> high-risk certificate requests
>
> We have confirmed that the subjects of the server certificates are limited
> to "go.jp" and that those are the web servers managed by the government.
> In addition, we check the case of phishing on the websites such as the
> Council of Anti-Phishing Japan etc. and refer them to the examination work.
>
>
> * There are separate CPS’s for the root and it’s subordinate CA. Some of
> the required information (CAA, domain validation methods) is only contained
> in the sub CA’s CPS.
>
> Confirmation of CAA records, verification of domains, etc. are performed
> in the operation of application CA 2 (Sub), since it is being carried out
> in the application, not application CA 2 (Root), but application CA 2 (Sub).
>
>
> * The CPS doesn’t contain an explicit open-source license statement as
> encouraged by Mozilla policy 3.3(3)
>
> The CP / CPS document created by us has no special restrictions.
>
>
> * A minimal description of the 

Re: ComSign Root Renewal Request

[Ryan Sleevi via dev-security-policy]

I hope you can understand that trust is not just based on the state of the
world 'today', but based on everything that key has ever done and every bit
of infrastructure that key has run on.

We know that key has been run on deficient infrastructure, with deficient
software, and done deficient things. The continued public examination has
continued to find and discover new issues since 2016. While remedying these
issues is a crucial minimum step towards trust, it only gets you to a point
where the current infrastructure might be suitable to be trusted going
forward.

Ensuring the creation of a new root, with new keys, which has never
certified any of the deficient infrastructure, is the only way the public
has to ensure they are not introducing additional risk to their users.

On Mon, Feb 12, 2018 at 3:23 PM, YairE via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> Dear Ryan, with all due respect and we do respect you, back in 2016 all
> the issues you mentioned were about the CPS and were corrected.
> It took us a lot to create the documentation you've asked for.
> There was no mentioning of any kind about our CA software or anything
> about the root itself.
> We believe that by solving all the problems that you've rose  - we have
> shown integrity and that we are trustworthy and we expected to hear a minor
> good word about accomplishing the correction you've asked for including
> creating a complete new CPS, which have costed us a lot of time.
> We initiated out of our own integrity the new CA environment  (nobody
> forced us to do so), and created already the new CA environment and one of
> our considerations was to use a trusted company like MS and not a
> relatively small vendor of CA. We knew they have some functionality
> disadvantages in their software but we hope they will correct it.
> As mentioned – we do agree that we need to switch our CA software ASAP and
> we are doing so and make progress every day. We did all the corrections
> you've asked for. If not – please point them out.
> You now, after we did everything you've asked for, put dark shadow, over
> our trust and we do not see why. The only real point now is that we've used
> and still are using a software that must be replaced ASAP.
> Bear in mind please that we cannot switch in one day because we need the
> approval of the government to every step we plan.
> In conclusion, we don’t see any trust problems regarding Comsign itself
> and\or this particular root.
> We still ask that this root will be approved on the new MS-CA when we
> switch to it, and we see no need to decline our request as long as we
> continue to comply with the BR and issue on a trusted CA software.
> ___
> dev-security-policy mailing list
> dev-security-policy@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy
>
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: ComSign Root Renewal Request

[YairE via dev-security-policy]

Dear Ryan, with all due respect and we do respect you, back in 2016 all the 
issues you mentioned were about the CPS and were corrected.
It took us a lot to create the documentation you've asked for.
There was no mentioning of any kind about our CA software or anything about the 
root itself.
We believe that by solving all the problems that you've rose  - we have shown 
integrity and that we are trustworthy and we expected to hear a minor good word 
about accomplishing the correction you've asked for including creating a 
complete new CPS, which have costed us a lot of time.
We initiated out of our own integrity the new CA environment  (nobody forced us 
to do so), and created already the new CA environment and one of our 
considerations was to use a trusted company like MS and not a relatively small 
vendor of CA. We knew they have some functionality disadvantages in their 
software but we hope they will correct it.
As mentioned – we do agree that we need to switch our CA software ASAP and we 
are doing so and make progress every day. We did all the corrections you've 
asked for. If not – please point them out.
You now, after we did everything you've asked for, put dark shadow, over our 
trust and we do not see why. The only real point now is that we've used and 
still are using a software that must be replaced ASAP.
Bear in mind please that we cannot switch in one day because we need the 
approval of the government to every step we plan.
In conclusion, we don’t see any trust problems regarding Comsign itself and\or 
this particular root.
We still ask that this root will be approved on the new MS-CA when we switch to 
it, and we see no need to decline our request as long as we continue to comply 
with the BR and issue on a trusted CA software.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: ComSign Root Renewal Request

[Ryan Sleevi via dev-security-policy]

On Mon, Feb 12, 2018 at 1:50 PM, YairE via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> Hi Wayne,
> Please realize our situation versus the Israeli market. We are the major
> certificate authority and we comply with every piece of local regulation,
> we are also members of international forums and trying to establish a CA in
> the UK with a new "international" root (Comsign International).This is our
> long term plan.
> Meanwhile we are in a tough task to move from the RSA old and unsupported
> CA software to a new MS CA. It isn’t simple and involves many aspects,
> locally and internationally. On the same time, we try to be certified to
> eIDAS in order to be included in the European Trust list.
> Mozilla is a mile stone that we MUST pass once and for all, as it prevents
> and holds us from supplying a lot of signing services to the Israeli
> market, especially the increasing requests for services over the mobile.
> So, while we try to go "hand by hand" with you and with the BR, if you now
> send us back with the ROOT we have, it actually eliminates all the work we
> are doing to be complied with Mozilla for a long period of time, as you
> mentioned in your message. We can estimate that we will fully switch to MS
> within 6 months or so, mainly because we wait for the final audit and the
> approval of the  Israeli Ministry of Justice, but if, as you suggest, you
> do not trust the ROOT (not only the CA software in which we are all on the
> same page with you), it is a much bigger problem, as you understand the
> meaning of such severe conclusion after all our efforts we did with Mozilla
> not to speak about the damage to our reputation that such a decision
> creates.
>
> That was the background. For the essence:
> 1."ComSign Global Root CA that was created in 2011 was first BR audited on
> 26-April 2015, but 36 end-entity certificates were issued prior to that
> time, all but one has since expired)."
> >>This one certificate expires at 3/2018 and we commit not to issue new
> SSL certificates until we are authorized with the new MS CA. However this
> point should not affect the integrity of the entire Root.
>
> 2."However, am unable to locate any additional audit documentation
> covering 2011-2015.".
> >>We've asked the auditor (CPA Shefler which is approved by Webtrust from
> ~mid 2015) to send us all the audits reports. As is already disclosed this
> ROOT has passed many Webtrust audits over the last years and can be
> considered audited –we have already disclosed all the certificates that
> were issued prior to our first Webtrust as you have asked earlier on this
> thread.
>
> 3."ComSign stated that they are currently using “RSA CA 6.7 on Solaris” to
> issue certificates. This version has not been supported since July 2013
> [4]. This implies that all 36 certificates were issued using unsupported CA
> software."
> >>Correct. Wrong decision of Comsign, which we apologized for. However, we
> still believe is should not affect the entire ROOT.
>
> 4."I’ve discovered that ComSign recently issued two new unconstrained
> subordinate Cas [5] from this root that contain a non-critical
> basicConstraints extension in violation of BR 7.1.2.2.
> >>While we appreciate your point here, these subCA's are not issuing SSL
> certificates at all but client certificates only. We cannot revoke these
> subordinates that serve hundreds of thousands of customers. However, if you
> approve our root – we commit to disclose the new SSL subCA before we issue
> new SSL certificates, while we keep the BR rules strictly of course.
>
> 5."Another unconstrained subordinate CA has been used to issue email
> certificates that contain encoding errors [6]."
> >>That subCA does not issue SSL certificates as we mentioned above, the
> encoding error was corrected long ago and is linked to the RSA software
> that we are replacing in any case.
>
> 6."In addition, numerous problems with ComSign’s CPS have been discussed
> in this thread".
> >>All these problems were corrected by us and approved by Mozilla
> representatives.
>
> 7."While I appreciate ComSign’s efforts to resolve issues that have been
> identified, new ones continue to be found. I am not at all comfortable
> recommending that this request proceed at this time, and I have also lost
> confidence that trust can ever be established for this root given its
> history. I support Ryan’s recommendation that this request be denied and
> that ComSign be asked to submit a new root containing a new key pair that
> has not been used with their outdated CA system."
> >>As we understand Ryan’s recommendation, after we accomplished almost all
> the points of rejection, is that Ryan recommends to wait for the new MS-CA,
> but Ryan did not express mistrust of the ROOT.
> We fully understand the points that both you and Ryan made, but to throw
> the root back now, will be like starting everything from the beginning all
> over again and will take long precious time.
> We 

Re: ComSign Root Renewal Request

[YairE via dev-security-policy]

Hi Wayne,
Please realize our situation versus the Israeli market. We are the major 
certificate authority and we comply with every piece of local regulation, we 
are also members of international forums and trying to establish a CA in the UK 
with a new "international" root (Comsign International).This is our long term 
plan.
Meanwhile we are in a tough task to move from the RSA old and unsupported CA 
software to a new MS CA. It isn’t simple and involves many aspects, locally and 
internationally. On the same time, we try to be certified to eIDAS in order to 
be included in the European Trust list.
Mozilla is a mile stone that we MUST pass once and for all, as it prevents and 
holds us from supplying a lot of signing services to the Israeli market, 
especially the increasing requests for services over the mobile. 
So, while we try to go "hand by hand" with you and with the BR, if you now send 
us back with the ROOT we have, it actually eliminates all the work we are doing 
to be complied with Mozilla for a long period of time, as you mentioned in your 
message. We can estimate that we will fully switch to MS within 6 months or so, 
mainly because we wait for the final audit and the approval of the  Israeli 
Ministry of Justice, but if, as you suggest, you do not trust the ROOT (not 
only the CA software in which we are all on the same page with you), it is a 
much bigger problem, as you understand the meaning of such severe conclusion 
after all our efforts we did with Mozilla not to speak about the damage to our 
reputation that such a decision creates.

That was the background. For the essence:
1."ComSign Global Root CA that was created in 2011 was first BR audited on 
26-April 2015, but 36 end-entity certificates were issued prior to that time, 
all but one has since expired)." 
>>This one certificate expires at 3/2018 and we commit not to issue new SSL 
>>certificates until we are authorized with the new MS CA. However this point 
>>should not affect the integrity of the entire Root.

2."However, am unable to locate any additional audit documentation covering 
2011-2015.". 
>>We've asked the auditor (CPA Shefler which is approved by Webtrust from ~mid 
>>2015) to send us all the audits reports. As is already disclosed this ROOT 
>>has passed many Webtrust audits over the last years and can be considered 
>>audited –we have already disclosed all the certificates that were issued 
>>prior to our first Webtrust as you have asked earlier on this thread.

3."ComSign stated that they are currently using “RSA CA 6.7 on Solaris” to 
issue certificates. This version has not been supported since July 2013 [4]. 
This implies that all 36 certificates were issued using unsupported CA 
software."
>>Correct. Wrong decision of Comsign, which we apologized for. However, we 
>>still believe is should not affect the entire ROOT.

4."I’ve discovered that ComSign recently issued two new unconstrained 
subordinate Cas [5] from this root that contain a non-critical basicConstraints 
extension in violation of BR 7.1.2.2.
>>While we appreciate your point here, these subCA's are not issuing SSL 
>>certificates at all but client certificates only. We cannot revoke these 
>>subordinates that serve hundreds of thousands of customers. However, if you 
>>approve our root – we commit to disclose the new SSL subCA before we issue 
>>new SSL certificates, while we keep the BR rules strictly of course.

5."Another unconstrained subordinate CA has been used to issue email 
certificates that contain encoding errors [6]."
>>That subCA does not issue SSL certificates as we mentioned above, the 
>>encoding error was corrected long ago and is linked to the RSA software that 
>>we are replacing in any case.

6."In addition, numerous problems with ComSign’s CPS have been discussed in 
this thread". 
>>All these problems were corrected by us and approved by Mozilla 
>>representatives.

7."While I appreciate ComSign’s efforts to resolve issues that have been 
identified, new ones continue to be found. I am not at all comfortable 
recommending that this request proceed at this time, and I have also lost 
confidence that trust can ever be established for this root given its history. 
I support Ryan’s recommendation that this request be denied and that ComSign be 
asked to submit a new root containing a new key pair that has not been used 
with their outdated CA system."
>>As we understand Ryan’s recommendation, after we accomplished almost all the 
>>points of rejection, is that Ryan recommends to wait for the new MS-CA, but 
>>Ryan did not express mistrust of the ROOT.
We fully understand the points that both you and Ryan made, but to throw the 
root back now, will be like starting everything from the beginning all over 
again and will take long precious time. 
We suggest that we keep working on this root and fix all that still needs to be 
fixed.
As for the CPS, we should be totally compliant now.
As for the CA software we will enclose all the 

Re: Mozilla’s Plan for Symantec Roots

[Ryan Sleevi via dev-security-policy]

On Mon, Feb 12, 2018 at 11:36 AM, Kai Engert  wrote:

> On 09.02.2018 22:20, Ryan Sleevi wrote:
> > As a small clarification - while Chrome has included the certificates,
> > as noted in the readme, the whitelist is based on SPKI. This was
> > intentional, to avoid situations of interoperability issues.
>
> Hi Ryan,
>
> IIUC, the current implementation in Firefox (for the early console
> warnings) is based on distinguished named (DN), not SPKI:
>
> https://hg.mozilla.org/integration/autoland/rev/d3acb68f73c4
>
>
> > Whitelisting by certificate, rather than either SPKI or SPKI-Tuple,
> > brings with it significant compatibility risks to the ecosystem in terms
> > of being able to respond to issues.
>
> Can these risks be avoided, too, by using the DN matching strategy that
> the Firefox code uses?
>

No.


> If not, it would be helpful to list these risks, and why they can only
> be addressed by using SPKI matching.
>

These risks were previously extensively discussed during the finalization
of the plan, and are expanded upon below.

Is your worry that alternative subCAs (already existing, or potentially
> being introduced in the future) could be used in server configurations,
> and that path building code might fail to match unexpected subCAs
> against the whitelist?
>

Yes.


> I hope we shouldn't have to worry about alternative, already existing
> subCAs. There shouldn't be alternative subCAs, because it would have
> been required to request their whitelisting already, right?
>

No, not if done by SPKI.


> Also, I hope we shouldn't have to worry about alternative, future
> subCAs. It's not allowed to use the old Symantec CA infrastructure to
> issue alternative subCAs that might require whitelisting, right?
>

No, it's not, provided they use the same SPKI.

https://crt.sh/?spkisha256=ac50b5fb738aed6cb781cc35fbfff7786f77109ada7c08867c04a573fd5cf9ee
is a concrete example of this.

The initial Transition RSA Root was cut, then issued under the VeriSign
Class 3 G5 root - https://crt.sh/?id=250864698

This was all done prior to 2017-12-01.

However, this was insufficient for a number of customers, who needed
certificates chaining to other roots. Several DigiCert/Symantec customers
reached out with examples of this, such as requiring chains to the VeriSign
Universal Root Certification Authority ( https://crt.sh/?caid=1110 ). There
is no path from G5 to UCA.

To accommodate such customers, DigiCert performed another signing ceremony,
on December 8, in which they issued several additional certificates which
chain to other Symantec roots (other than G5), while sharing the same SPKI.
To avoid causing path building issues on clients, each of these new
certificates varies by DN, but all share the same SPKI, providing assurance
that it's the same key material with the same audited controls as the
managed PKI.

When thinking about what assurances are desired by the Managed CA, the
security assurance is tied to the key, not to the name. This is why
Chrome's whitelist is based on SPKI - if the key is adequately secured and
audited, we have assurance, but the name can be associated with any key,
and is not.

It's not unreasonable to predict that, as the transition continues, and
more customers look to transition (particularly those with certificates
issued after 2016-06-01), we may see further managed CAs cut. In a DN-based
whitelist, all of these would fail to work in browsers unless code changes
were made, whereas in an SPKI whitelist, all of these would work just fine.


> A separate question which would be good to clarified: What about
> environments, which want to distrust all old Symantec roots in October
> 2018, but cannot add whitelisting to their cert validation code, and
> choose to explicitly trust each of the subCAs. Such an environment
> should be able to find a chain to one of the explicitly trusted subCAs,
> right?
>

You're asking about non-browser environments that cannot implemented
https://wiki.mozilla.org/CA:FAQ#Can_I_use_Mozilla.27s_set_of_CA_certificates.3F
? I thought we'd ruled that out of scope rather comprehensively.

Explicitly trusting by sub-CAs is, in effect, a DN whitelist with added
restrictions, and thus runs the risk I mentioned.


> > We've already seen this born out
> > with respect to DigiCert and their Managed PKI intermediates, and wanted
> > to avoid disruption to both Apple and Google that would otherwise
> > destablize the ecosystem.
>
> What is the relationship between the distrust of Symantec CAs and
> intermediates managed by DigiCert? Did DigiCert already run managed
> intermediates, before the Symantec-to-DigiCert migration efforts begun,
> that still depend on Symantec CAs to be trusted?
>

I'm not sure I understand this question?


> What is the potential disruption, and how are you avoiding it?
>

See above.


> Are you avoiding it by including the two DigiCert Transition RSA/ECC
> Root certificates in the whitelist?


> Why is it necessary to refer to 

Re: DRAFT January 2018 CA Communication

[Wayne Thayer via dev-security-policy]

Friday was the deadline for responding to this survey. Responses are now
published at
https://wiki.mozilla.org/CA/Communications#January_2018_Responses

I would like to thank everyone who took the time to respond, and especially
those who provided detailed answers to Action 2 regarding methods 1 and 5.

The following CAs have not responded:

   - Government of Spain, Fábrica Nacional de Moneda y Timbre (FNMT)
   - GoDaddy
   - Disig, a.s.
   - Certinomis / Docapost
   - Cybertrust Japan / JCSI
   - Deutscher Sparkassen Verlag GmbH (S-TRUST, DSV-Gruppe)
   - TurkTrust
   - Web.com
   - E-Tugra

I will allow a grace period of a few days and then will open incident bugs
for those CAs that still haven't responded.

- Wayne

On Mon, Jan 29, 2018 at 5:14 PM, Wayne Thayer via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> The email has been sent, and we've published a blog post:
>
> https://blog.mozilla.org/security/2018/01/29/january-2018-ca
> -communication/
>
> On Monday, January 29, 2018 at 1:15:51 PM UTC-7, Wayne Thayer wrote:
> > You can find a link to the final version of the survey at
> > https://wiki.mozilla.org/CA/Communications#January_2018_CA_Communication
> >
> > We're planning to send this out to all CAs in the Mozilla program later
> > today. The deadline for responses has been set to 9-February.
> >
> > Thanks to everyone who contributed to this effort.
> >
> > - Wayne
>
>
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Mozilla’s Plan for Symantec Roots

[Piotr Kucharski via dev-security-policy]

On Mon, Feb 12, 2018 at 5:36 PM, Kai Engert  wrote:

> > For example, if you note, there are two Google certificates, but they
> > share the same SPKI and Subject Name - which is why the Chromium
> > whitelist only has one certificate listed, as it extracts the SPKI from
> > that resource as part of the whitelist.
>
> Are you referring to these two subCAs?
>   https://crt.sh/?id=23635000
>   https://crt.sh/?id=142951186
>
> It seems the first one has already expired, and it might no longer be
> necessary to worry about it?
>

While nothing is certain, it is likely that Google might have another subCA
certificate issued with the same SPKI and Subject.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Mozilla’s Plan for Symantec Roots

[Kai Engert via dev-security-policy]

On 09.02.2018 22:20, Ryan Sleevi wrote:
> As a small clarification - while Chrome has included the certificates,
> as noted in the readme, the whitelist is based on SPKI. This was
> intentional, to avoid situations of interoperability issues.

Hi Ryan,

IIUC, the current implementation in Firefox (for the early console
warnings) is based on distinguished named (DN), not SPKI:

https://hg.mozilla.org/integration/autoland/rev/d3acb68f73c4


> Whitelisting by certificate, rather than either SPKI or SPKI-Tuple,
> brings with it significant compatibility risks to the ecosystem in terms
> of being able to respond to issues.

Can these risks be avoided, too, by using the DN matching strategy that
the Firefox code uses?

If not, it would be helpful to list these risks, and why they can only
be addressed by using SPKI matching.

Is your worry that alternative subCAs (already existing, or potentially
being introduced in the future) could be used in server configurations,
and that path building code might fail to match unexpected subCAs
against the whitelist?

I hope we shouldn't have to worry about alternative, already existing
subCAs. There shouldn't be alternative subCAs, because it would have
been required to request their whitelisting already, right?

Also, I hope we shouldn't have to worry about alternative, future
subCAs. It's not allowed to use the old Symantec CA infrastructure to
issue alternative subCAs that might require whitelisting, right?

Maybe the compatibility risks aren't about alternative subCAs?


A separate question which would be good to clarified: What about
environments, which want to distrust all old Symantec roots in October
2018, but cannot add whitelisting to their cert validation code, and
choose to explicitly trust each of the subCAs. Such an environment
should be able to find a chain to one of the explicitly trusted subCAs,
right?


> We've already seen this born out
> with respect to DigiCert and their Managed PKI intermediates, and wanted
> to avoid disruption to both Apple and Google that would otherwise
> destablize the ecosystem.

What is the relationship between the distrust of Symantec CAs and
intermediates managed by DigiCert? Did DigiCert already run managed
intermediates, before the Symantec-to-DigiCert migration efforts begun,
that still depend on Symantec CAs to be trusted?

What is the potential disruption, and how are you avoiding it?

Are you avoiding it by including the two DigiCert Transition RSA/ECC
Root certificates in the whitelist?

Why is it necessary to refer to them by SPKI, e.g. do you expect there
might be future, alternative intermediates for transition roots those?


Also, I noticed that Gerv's post from 2017-10-17 had mentioned 7 Apple
subCAs,

https://crt.sh/?id=19602712
https://crt.sh/?id=19602724
https://crt.sh/?id=21760447
https://crt.sh/?id=5250464
https://crt.sh/?id=12716200
https://crt.sh/?id=19602706
https://crt.sh/?id=19602741

but the chromium "excluded" subdirectory contains only 6 Apple subCAs.

Based on your message, I just looked at them, but I see that all of them
have different SPKI. Do you know why the Chromium excluded directory
only lists 6 Apple subCAs?


> For example, if you note, there are two Google certificates, but they
> share the same SPKI and Subject Name - which is why the Chromium
> whitelist only has one certificate listed, as it extracts the SPKI from
> that resource as part of the whitelist.

Are you referring to these two subCAs?
  https://crt.sh/?id=23635000
  https://crt.sh/?id=142951186

It seems the first one has already expired, and it might no longer be
necessary to worry about it?

Thanks
Kai

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