Re: DigiCert-Symantec Announcement

[Peter Bowen via dev-security-policy]

On Thu, Sep 21, 2017 at 7:17 PM, Ryan Sleevi via dev-security-policy
 wrote:
> I think we can divide the discussion into two parts, similar to the
> previous mail: How to effectively transition Symantec customers with
> minimum disruption, whether acting as the Managed CA or as the future
> operator of Symantec’s PKI, and how to effectively transition DigiCert’s
> infrastructure. This is a slightly different order than your e-mail
> message, but given the time sensitivity of the Symantec transition, it
> seems more effective to discuss that first.
>
> I think there may have been some confusion on the Managed CA side. It’s
> excellent that DigiCert plans to transition Symantec customers to DigiCert
> roots, as that helps with an expedient reduction in risk, but the plan
> outlined may create some of the compatibility risks that I was trying to
> highlight. In the discussions of the proposed remediations, one of the big
> concerns we heard raised by both Symantec and site operators was related to
> pinning - both in the Web and in mobile applications. We also heard about
> embedded or legacy devices, and their needs for particular chains.
>
> It sounds like this plan may have been based on a concern that I’d tried to
> address in the previous message. That is, the removal of the existing
> Symantec roots defines a policy goal - the elimination in trust in these
> legacy roots, due to the unknown scope of issues. However, that goal could
> be achieved by a number of technical means - for example, ‘whitelisting’ a
> set of Managed CAs (as proposed by Chrome), or replacing the existing
> Symantec roots with these new Managed CA roots in a 1:1 swap. Both of these
> approaches achieve the same policy objective, while reducing the
> compatibility risk.

Ryan,

As an existing Symantec customer, I'm not clear that this really
addresses the challenges we face.

So far we have found several different failure modes.  We hope that
any solution deployed will assure that these don't trigger.

First, we found that some clients have a limited set of roots in their
trust store.   The "VeriSign Class 3 Public Primary Certification
Authority - G5" root with SPKI SHA-256 hash of
25b41b506e4930952823a6eb9f1d31def645ea38a5c6c6a96d71957e384df058 is
the only root trusted by some clients. They do, somewhat
unfortunately, check the certificate issuer, issuer key id, and
signature, so they changing any will break things.  However they don't
update their trust store.  So the (DN, key id, public key) tuple needs
to be in the chain for years to come.

Second, we have found that some applications use the system trust
store but implement additional checks on the built and validated
chain.  The most common case is  checking that at least one public key
in the chain matches a list of keys the application has internally.

As there is an assumption that the current root (DN, public key)
tuples will be replaced relatively soon by some trust store
maintainers, there needs to be a way that that both of these cases can
work.  The only way I can see this working long term on both devices
with updated trust stores as well as devices that have not updated the
trust store is to do a little bit of hackery and create new (DN,
public key) tuples with the existing public key.  This way apps with
pinning will work on systems with old trust stores and one systems
with updated trust stores.

As a specific example, again using the Class 3 G5 root, today a chain
looks like:

1) End-entity info
2) 
spkisha256:f67d22cd39d2445f96e16e094eae756af49791685007c76e4b66f154b7f35ec6,KeyID:5F:60:CF:61:90:55:DF:84:43:14:8A:60:2A:B2:F5:7A:F4:43:18:EF,
DN:CN=Symantec Class 3 Secure Server CA - G4, OU=Symantec Trust
Network, O=Symantec Corporation, C=US,
3) spkisha256:25b41b506e4930952823a6eb9f1d31def645ea38a5c6c6a96d71957e384df058,
KeyID:7F:D3:65:A7:C2:DD:EC:BB:F0:30:09:F3:43:39:FA:02:AF:33:31:33,
DN: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

If there is a desire to (a) remove the Class 3 G5 root and (b) keep
the pin to its key working, the only solution I can see is to create a
new root that uses the same key.  This would result in a chain that
looks something like:

1) End-entity info
2b) spkisha256:,KeyID:, DN:CN=New Server Issuing CA, O=DigiCert, C=US,
3b) spkisha256:25b41b506e4930952823a6eb9f1d31def645ea38a5c6c6a96d71957e384df058,
KeyID:6c:e5:3f:7b:45:1f:66:b4:e6:7c:70:05:86:19:79:4f:a6,
DN:CN=VeriSign Class 3 Public Primary Certification Authority - G5,
OU=DigiCert Compatibility Root, OU=(c) 2006 VeriSign, Inc. - For
authorized use only, OU=VeriSign Trust Network, O=VeriSign\, Inc.,
C=US
3) spkisha256:25b41b506e4930952823a6eb9f1d31def645ea38a5c6c6a96d71957e384df058,
KeyID:7F:D3:65:A7:C2:DD:EC:BB:F0:30:09:F3:43:39:FA:02:AF:33:31:33,
DN:CN=VeriSign Class 3 Public Primary Certification Authority - G5,

Re: DigiCert-Symantec Announcement

[Ryan Sleevi via dev-security-policy]

Jeremy,

Thanks for attaching the diagrams - this is very useful in helping
visualize out the graph! Special thanks for detailing out the validation
flow DigiCert both practices and plans to practice - this level of
transparency goes a long way to helping assess and understand both risks
and mitigations.

I think we can divide the discussion into two parts, similar to the
previous mail: How to effectively transition Symantec customers with
minimum disruption, whether acting as the Managed CA or as the future
operator of Symantec’s PKI, and how to effectively transition DigiCert’s
infrastructure. This is a slightly different order than your e-mail
message, but given the time sensitivity of the Symantec transition, it
seems more effective to discuss that first.

I think there may have been some confusion on the Managed CA side. It’s
excellent that DigiCert plans to transition Symantec customers to DigiCert
roots, as that helps with an expedient reduction in risk, but the plan
outlined may create some of the compatibility risks that I was trying to
highlight. In the discussions of the proposed remediations, one of the big
concerns we heard raised by both Symantec and site operators was related to
pinning - both in the Web and in mobile applications. We also heard about
embedded or legacy devices, and their needs for particular chains.

The plan you’ve outlined doesn’t seem to clearly account for this, which
was a key factor in the “Managed CA” design. In the previous reply, I tried
to highlight a bit more of at least one technically viable way to
accomplish that - what we might call the “Managed CA Lookalike”
infrastructure, in that it follows the structural outline and requirements
of the Managed CA plan, even if DigiCert may be performing all the
validation themselves and not relying on any previous data or documents
(which I assume is what you mean by “Transitioned to DigiCert”).

To make sure we’re on the same page, when you say “DigiCert Global Root
G2”, you mean the certificate at
https://crt.sh/?q=DF3C24F9BFD666761B268073FE06D1CC8D4F82A4, right? This CA,
in turn, has signed “DigiCert Global CA G2”, https://crt.sh/?caid=5886 ,
which in turn has signed a number of end entity certificates -
https://crt.sh/?Identity=%25=5886 . While it does not appear to be a
large number of certificates (looks like roughly 84, with some
compatibility testing certificates issued), these certificates may stop
working - and would need to migrate.

However, this doesn’t address the main concern that informed the
requirements of the “Managed CA,” in response to community feedback. You
propose signing the Root G2 with Verisign Class 3 Public Primary
Certificate Authority – G5, https://crt.sh/?id=93 . This could reduce the
risk if someone pinned to that root, or https://crt.sh/?caid=443 (because
of https://crt.sh/?id=21606053 ), or https://crt.sh/?caid=25 ( because of
https://crt.sh/?id=2503596 ), which is fantastic, but wouldn’t address
situations like https://crt.sh/?caid=808 (which issued
https://crt.sh/?caid=1212 which is actively issuing certs -
https://crt.sh/?Identity=%25=1212 ). Any of those customers who
pinned would potentially be negatively impacted, as no other cross-signs
exist for this path.

The Managed CA process was meant to address these concerns, by allowing at
least a 1:1 transition of the existing roots to new roots without the same
risk - by taking the existing roots, signing a new (DigiCert-operated)
“Managed CA”, and then transitioning online issuance to a hierarchy within
that new “Managed CA”. This doesn’t address situations where applications
pinned to intermediates - but unfortunately, I don’t have any suggestions
on how to effectively address that use case while also achieving the
necessary reduction in risk.

It sounds like this plan may have been based on a concern that I’d tried to
address in the previous message. That is, the removal of the existing
Symantec roots defines a policy goal - the elimination in trust in these
legacy roots, due to the unknown scope of issues. However, that goal could
be achieved by a number of technical means - for example, ‘whitelisting’ a
set of Managed CAs (as proposed by Chrome), or replacing the existing
Symantec roots with these new Managed CA roots in a 1:1 swap. Both of these
approaches achieve the same policy objective, while reducing the
compatibility risk.

Note that another part of the Managed CA proposal was to allow for the
(limited) reuse of information, due to Symantec’s assertions that no
partner could be found that could match the volume of issuance necessary to
avoid customer disruption. Based on your description of the plan, it sounds
like you intend to transition all of the Symantec customers over on Dec 1
to DigiCert roots - but that seems like it may result in an overload of
your support team if path building or pinning issues are discovered, and
your policy and compliance team as solutions have to be explored. As
communicated in the past, an 

Re: PROCERT decision

[Andrew via dev-security-policy]

On Thursday, September 21, 2017 at 11:23:28 AM UTC-5, Gervase Markham wrote:
> The CA Certificates module owner and peers have come to a decision
> regarding our investigations into the activities of the CA "PROCERT".
> 
> A large number of issues were raised regarding the operations and
> practices of this CA:
> https://wiki.mozilla.org/CA:PROCERT_Issues
> 
> Considering them, it seems clear to us that PROCERT have not been, and
> continue not to be, adequately aware of the requirements placed upon
> them by various RFCs, the CA/Browser Forum's Baseline Requirements, and
> Mozilla Root Store Policy. They have not demonstrated sufficient control
> of their issuance pipeline or sufficient checking of the results to
> avoid regularly creating certificates which violate the requirements of
> one or more of those documents. PROCERT have also made assurances to us,
> via responses to CA Communications, that certain things were true which
> are manifestly not so (e.g. that they were using properly-randomized
> serial numbers).
> 
> In addition, PROCERT's response to these issues was inadequate. While
> they revoked (most, but not all, of) the certificates which were flagged
> as problematic, their written responses have been limited in number and
> are very superficial. In some cases, it is clear that they have not
> understood the issue that was raised. They have not, to our knowledge,
> performed any root cause analysis which might allow us to have some
> confidence that problems of this or a similar nature will not recur. We
> have very little insight into their systems and what, if any, safeguards
> they have in place.
> 
> It seems that PROCERT's belief is that revocation is an adequate remedy
> for all of the problems listed. We disagree. Therefore, we feel we can
> no longer trust PROCERT, and plan to proceed with removing their
> "PSPProcert" certificate from our root program and root store.
> 
> Kathleen Wilson
> Gervase Markham
> Ryan Sleevi

Will there be any sort of deprecation period for PROCERT certificates as with 
StartCom/Wosign & Symantec? Or is PROCERT small enough that you believe it's 
feasible to just immediately distrust them without any significant negative 
impact on the overall web ecosystem?
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: CAs not compliant with CAA CP/CPS requirement

[richmoore44--- via dev-security-policy]

On Thursday, September 21, 2017 at 10:13:56 AM UTC+1, Rob Stradling wrote:
> Our CPS has now been updated.

Will you be ensuring that CAs like Gandi who are chaining back to your roots 
also update their CPS?

Regards

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

Re: PROCERT issues

[Patrick Figel via dev-security-policy]

On 21/09/2017 23:08, alejandrovolcan--- via dev-security-policy wrote:
> Dear Gerv, I have attached a document that gives us a greater
> response to each of the points, as well as Mr. Oscar Lovera sent you
> an email with the same information
> 
> https://www.dropbox.com/s/qowngzzvg5q5pjj/Mozilla%20issues.docx?dl=0


To save everyone else some time trying to find out what has changed,
these are the additions for every issue, diffed against the original
response[1]:



Issue D:

PROCERT initially claimed that this was entirely RFC-compliant, a claim
comprehensively rebutted by Ryan Sleevi.

This certificate was issued with the modifications and here it is
possible to appreciate the evidence https://crt.sh/?id=209727657



Issue E:

This certificate is not in use and is appended to the internal
revocation schedule, the current certificate is 2048 in length and can
be seen in the attached OCSP response (ocsp.txt)



Issue G:

Please find evidence of new certificate issued without problems
https://crt.sh/?id=202869851



Issue I:

These certificates were revoked and generated again, please consult
through the following link
https://crt.sh/?iCAID=750=2000-01-01=1000=25



Issue J:

Although certificates are not certified, the certificates have been
revoked and corrected, please check the link
https://crt.sh/?iCAID=750=2000-01-01=782



Issue K:

Corrective action taken, please consult the link
https://crt.sh/?id=197158298=cablint



Issue L:

That certificate was revoked and generated again, please consult through
the following link https://crt.sh/?id=167929373



Issue M:

This is not an infringement or violation of the RFC. Regarding to the
language, the national language in Venezuela is the Spanish. We will
work to updated the English version of this document and posted in the
web page.
https://www.procert.net.ve/documentos/AC-D-0011.pdf
https://www.procert.net.ve/documentos/AC-D-0003.pdf

Standard
https://tools.ietf.org/html/rfc3647
https://tools.ietf.org/html/rfc2527



Issue N:

Taking into account what the Baseline says, it states the following:
i. Other Subject Attributes
All other optional attributes, when present within the subject field,
MUST contain information that has been verified by the CA.

Indicates that another field can be included as long as it is
information verified by the CA in this case the CA verifies the number
of RIF of each company and also the field is with an OID for that
purpose, which is 2.16.862.2.2



Issue O:

Our OCSP works without any problem in the validation with automatic
tools such as certutil, even with the same command openssl, in
consultation under standard.

The standard openssl query is done in the following way: openssl ocsp
-issuer issuer.cer -cert cert.cer -url http://ura.procert.net.ve/ocsp
-noverify -text.

We detected that OCSP does work correctly with the Microsoft tool.

Open SSL creates a problem when doing a non-standard query (hacking). We
are already working the point with Microsoft and we even have an
assigned ticket.



Issue P:

No RFC 2560 nor RFC 5280 is being violated.



Issue R:

The certificate was revoked and reissued, please see the link
https://crt.sh/?id=194225991



Issue S:

Already it was given previous answer to this point and was solved
modifying certain parameters in our CA, which counts on a CSPRNG that
acts like generator of serial numbers and was modified in its register
so that it increased the capacity and strength of the serial numbers
that generates automatically and without human intervention.



Issue T:

These certificates were revoked and generated again, please consult
through the following link
https://crt.sh/?iCAID=750=2000-01-01=1000=734
Additionally, we have already modified the certificate template to
prevent it from containing this key usage.



Issue V:

No additions.



Issue W:

This 

Re: PROCERT issues

[alejandrovolcan--- via dev-security-policy]

El lunes, 18 de septiembre de 2017, 8:27:18 (UTC-5), Gervase Markham  escribió:
> On 11/09/17 12:03, Gervase Markham wrote:
> > Thank you for this initial response. It is, however, far less detailed
> > than we would like to see. 
> 
> I have not had any further updates from PROCERT. I have tried to reflect
> their responses from this email here:
> https://wiki.mozilla.org/CA:PROCERT_Issues
> 
> We hope to conclude the discussion at the end of this week, although I
> am having minor surgery on Wednesday, so it may be next week.
> 
> Gerv

Dear Gerv, I have attached a document that gives us a greater response to each 
of the points, as well as Mr. Oscar Lovera sent you an email with the same 
information

https://www.dropbox.com/s/qowngzzvg5q5pjj/Mozilla%20issues.docx?dl=0

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

PROCERT decision

[Gervase Markham via dev-security-policy]

The CA Certificates module owner and peers have come to a decision
regarding our investigations into the activities of the CA "PROCERT".

A large number of issues were raised regarding the operations and
practices of this CA:
https://wiki.mozilla.org/CA:PROCERT_Issues

Considering them, it seems clear to us that PROCERT have not been, and
continue not to be, adequately aware of the requirements placed upon
them by various RFCs, the CA/Browser Forum's Baseline Requirements, and
Mozilla Root Store Policy. They have not demonstrated sufficient control
of their issuance pipeline or sufficient checking of the results to
avoid regularly creating certificates which violate the requirements of
one or more of those documents. PROCERT have also made assurances to us,
via responses to CA Communications, that certain things were true which
are manifestly not so (e.g. that they were using properly-randomized
serial numbers).

In addition, PROCERT's response to these issues was inadequate. While
they revoked (most, but not all, of) the certificates which were flagged
as problematic, their written responses have been limited in number and
are very superficial. In some cases, it is clear that they have not
understood the issue that was raised. They have not, to our knowledge,
performed any root cause analysis which might allow us to have some
confidence that problems of this or a similar nature will not recur. We
have very little insight into their systems and what, if any, safeguards
they have in place.

It seems that PROCERT's belief is that revocation is an adequate remedy
for all of the problems listed. We disagree. Therefore, we feel we can
no longer trust PROCERT, and plan to proceed with removing their
"PSPProcert" certificate from our root program and root store.

Kathleen Wilson
Gervase Markham
Ryan Sleevi
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Public trust of VISA's CA

[Paul Kehrer via dev-security-policy]

I can confirm that as of this moment the VISA OCSP responders are still
responding GOOD for non-existent certificates. VISA was originally
contacted by me on August 29 so it has now been over 21 days since initial
report.

-Paul

On September 21, 2017 at 9:32:12 PM, Gervase Markham via
dev-security-policy (dev-security-policy@lists.mozilla.org) wrote:

Additionally, 13 days ago it was reported to VISA that their OCSP
responder was misconfigured to return "good" responses for non-existent
certificates:
https://bugzilla.mozilla.org/show_bug.cgi?id=1398261
As far as I can see, this is the case for their end-entity certificates,
not just some roots or intermediates.

Two weeks later, they have not yet provided any response.

Gerv
___
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

Incident Report format

[Gervase Markham via dev-security-policy]

It seems like the list of topics to cover on the Responding to a
Misissuance page:
https://wiki.mozilla.org/CA/Responding_To_A_Misissuance#Incident_Report
has become a de facto template for incident reports.

We've now had quite a few CAs use this outline to respond to issues. If
people (CAs or others) have feedback on how this template could be
improved, that would be a fine thing.

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

Re: Public trust of VISA's CA

[Gervase Markham via dev-security-policy]

Additionally, 13 days ago it was reported to VISA that their OCSP
responder was misconfigured to return "good" responses for non-existent
certificates:
https://bugzilla.mozilla.org/show_bug.cgi?id=1398261
As far as I can see, this is the case for their end-entity certificates,
not just some roots or intermediates.

Two weeks later, they have not yet provided any response.

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

Re: CAs not compliant with CAA CP/CPS requirement

[Rob Stradling via dev-security-policy]

On 08/09/17 20:24, Andrew Ayer via dev-security-policy wrote:

The BRs state:

"Effective as of 8 September 2017, section 4.2 of a CA's Certificate
Policy and/or Certification Practice Statement (section 4.1 for CAs
still conforming to RFC 2527) SHALL state the CA's policy or practice
on processing CAA Records for Fully Qualified Domain Names; that policy
shall be consistent with these Requirements. It shall clearly specify
the set of Issuer Domain Names that the CA recognises in CAA 'issue' or
'issuewild' records as permitting it to issue. The CA SHALL log all
actions taken, if any, consistent with its processing practice."

Since it is now 8 September 2017, I decided to spot check the CP/CPSes
of some CAs.

At time of writing, the latest published CP/CPSes of the following CAs
are not compliant with the above provision of the BRs:



Comodo (https://www.comodo.com/about/comodo-agreements.php) - Does not
specify issuer domain names


Andrew, thanks for bringing this to our attention.

Our CPS has now been updated.

--
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy