Re: CA handling of contact information when reporting problems

2019-08-19 Thread Jakob Bohm via dev-security-policy

On 20/08/2019 03:15, Corey Bonnell wrote:

On Monday, August 19, 2019 at 10:26:06 AM UTC-4, Mathew Hodson wrote:

Tom Wassenberg on Twitter reported an experience he had with Sectigo
when reporting a compromised private key.

https://twitter.com/tomwas54/status/1162114413148725248
https://twitter.com/tomwas54/status/1162114465065840640
https://twitter.com/tomwas54/status/1162114495017299976

"So a few weeks ago, I came across a private key used for a TLS
certificate, posted online. These should never be public (hence the
"private"), and every trusted CA is obliged to revoke any certificate
they issued when they become aware its private key is compromised.

"So when I informed the issuing CA (@SectigoHQ) about this, they
promptly revoked the cert. Two weeks later however, I receive an angry
email from the company using the cert (cc'd to their lawyer), blaming
me for a disruption in the services they provide.

"The company explicitly mentioned @SectigoHQ "was so kind" to give
them my contact info! It was a complete surprise for me that
@SectigoHQ would do this without my consent. Especially seeing how the
info was used to badger me."

If these situations were common, it could create a chilling effect on
problem reporting that would hurt the WebPKI ecosystem. Are specific
procedures and handling of contact information in these situations
covered by the BRs or Mozilla policy?


Many CAs disclose the reporter's name and email address as part of their 
response to item 1 of the incident report template [1]. So this information is 
already publicly available if the Subscriber were so inclined to look for it.

Section 9.6.3 of the BRs list the provisions that must be included in the 
Subscriber Agreement that every Applicant must agree to. Notably, one of them 
is protection of the private key. The Subscriber in this case materially 
violated the Subscriber Agreement by disclosing their private key, so I don't 
think they have much footing to go badgering others for problems that they 
brought on themselves.

Thanks,
Corey

[1] https://wiki.mozilla.org/CA/Responding_To_An_Incident#Incident_Report



The question was if this is appropriate behavior, when the incident is
not at the CA, but at a subscriber.  This is typically different from
the case of security researchers filing systemic CA issues for which
they typically want public recognition.

Specificially, the question is one of whistleblower protection for the
reporter (in the general sense of whistleblower protection, not that of
any single national or other whistleblower protection legal regime).

On the other hand there is the question of subscribers having a right
to face their accuser when there might be a question of trust of
subjectivity (example: Someone with trusted subscriber private key
access maliciously sending it to the CA to cause revocation for failure
to protect said key).

Situation would get much more complicated when the report is one of
claiming a subscriber violates a subjective rule, such as malicious cert
use or name ownership conflicts.



Enjoy

Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S.  https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark.  Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy


Re: Fwd: Intent to Ship: Move Extended Validation Information out of the URL bar

2019-08-19 Thread scott.helme--- via dev-security-policy
> 
> What evidence or research shows that the new location is providing better
> protection for the end users?

What evidence or research shows that any location provides any protection for 
the end users? 
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy


CA handling of contact information when reporting problems

2019-08-19 Thread Mathew Hodson via dev-security-policy
Tom Wassenberg on Twitter reported an experience he had with Sectigo
when reporting a compromised private key.

https://twitter.com/tomwas54/status/1162114413148725248
https://twitter.com/tomwas54/status/1162114465065840640
https://twitter.com/tomwas54/status/1162114495017299976

"So a few weeks ago, I came across a private key used for a TLS
certificate, posted online. These should never be public (hence the
"private"), and every trusted CA is obliged to revoke any certificate
they issued when they become aware its private key is compromised.

"So when I informed the issuing CA (@SectigoHQ) about this, they
promptly revoked the cert. Two weeks later however, I receive an angry
email from the company using the cert (cc'd to their lawyer), blaming
me for a disruption in the services they provide.

"The company explicitly mentioned @SectigoHQ "was so kind" to give
them my contact info! It was a complete surprise for me that
@SectigoHQ would do this without my consent. Especially seeing how the
info was used to badger me."

If these situations were common, it could create a chilling effect on
problem reporting that would hurt the WebPKI ecosystem. Are specific
procedures and handling of contact information in these situations
covered by the BRs or Mozilla policy?
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy


Re: Request to Include 4 Microsoft Root CAs

2019-08-19 Thread Daniel Marschall via dev-security-policy

Hello,

Is there an EV Policy OID assigned? I can't find it.

- Daniel


Am Mittwoch, 14. August 2019 00:42:44 UTC+2 schrieb Wayne Thayer:
> This request is for inclusion of the Microsoft RSA Root Certificate
> Authority 2017, Microsoft ECC Root Certificate Authority 2017, Microsoft EV
> RSA Root Certificate Authority 2017, and Microsoft EV ECC Root Certificate
> Authority 2017 trust anchors as documented in the following bug:
> https://bugzilla.mozilla.org/show_bug.cgi?id=1448093
> 
> * BR Self Assessment is
> https://bugzilla.mozilla.org/attachment.cgi?id=8989260
> 
> * Summary of Information Gathered and Verified:
> https://ccadb-public.secure.force.com/mozilla/PrintViewForCase?CaseNumber=0275
> 
> * Root Certificate Download URL:
> https://www.microsoft.com/pkiops/docs/repository.htm
> 
> * CP/CPS:
> ** CP:
> https://www.microsoft.com/pkiops/Docs/Content/policy/Microsoft_PKI_Services_CP_v3.1.2.pdf
> ** CPS:
> https://www.microsoft.com/pkiops/Docs/Content/policy/Microsoft_PKI_Services_CPS_v3.1.3.pdf
> 
> * This request is to include the roots with the websites trust bit enabled,
> and with EV treatment.
> 
> * Test Websites
> ** Valid: https://actrsaevroot2017.pki.microsoft.com/,
> https://actrsaroot2017.pki.microsoft.com/,
> https://acteccevroot2017.pki.microsoft.com/,
> https://acteccroot2017.pki.microsoft.com/
> ** Expired: https://exprsaevroot2017.pki.microsoft.com/,
> https://exprsaroot2017.pki.microsoft.com/,
> https://expeccevroot2017.pki.microsoft.com/,
> https://expeccroot2017.pki.microsoft.com/
> ** Revoked: https://rvkrsaevroot2017.pki.microsoft.com/,
> https://rvkrsaroot2017.pki.microsoft.com/,
> https://rvkeccevroot2017.pki.microsoft.com/,
> https://rvkeccroot2017.pki.microsoft.com/
> 
> * CRL URLs:
> ** ECC:
> http://www.microsoft.com/pkiops/crl/Microsoft%20ECC%20Root%20Certificate%20Authority%202017.crl
> ** RSA:
> http://www.microsoft.com/pkiops/crl/Microsoft%20RSA%20Root%20Certificate%20Authority%202017.crl
> ** EV ECC:
> http://www.microsoft.com/pkiops/crl/Microsoft%20EV%20ECC%20Root%20Certificate%20Authority%202017.crl
> ** EV RSA:
> http://www.microsoft.com/pkiops/crl/Microsoft%20EV%20RSA%20Root%20Certificate%20Authority%202017.crl
> 
> * OCSP URL:http://ocsp.msocsp.com
> 
> * Audit: Annual audits are performed by BDO according to the WebTrust for
> CA, BR, and EV audit criteria.
> ** WebTrust for CA: https://bugzilla.mozilla.org/attachment.cgi?id=9083810
> ** BR: https://bugzilla.mozilla.org/attachment.cgi?id=9083812
> ** EV: https://bugzilla.mozilla.org/attachment.cgi?id=9083813
> 
> I’ve reviewed the CP, CPS, BR Self Assessment, and related information for
> inclusion of the Microsoft roots that are being tracked in this bug and
> have the following comments:
> 
> ==Good==
> * A root key generation ceremony audit report has been provided [1].
> 
> ==Meh==
> * CPS section 3.2.4 stated that OU is not verified, however, BR section
> 7.1.4.2.2(i) does place requirements on this field, and the CPS made it
> unclear if these requirements are met. This was clarified in the latest
> version of the CPS.
> * CPS section 3.2.5 stated that Microsoft PKI Services shall verify
> authority for all certificate requests, and that for Domain Validated
> requests, this is done using one of the methods described in the BRs.
> Section 3.2.5 of the BRs only describes validation of authority for OV
> certificates using a reliable method of communication. This was clarified
> in the latest version of the CPS.
> * CPS section 6.1.5 indicated that P-512 keys may be used, which would
> violate Mozilla policy. This was corrected in the latest version of the CPS.
> * The content-type header in CRL responses is not set to
> 'application/pkix-crl' but to 'application/octet-stream' (RFC 5280, section
> 4.2.1.13). Microsoft explanation: the reason for the content-type being set
> to octet-stream is that we use a content upload service at Microsoft that
> hosts different types of content. All of the content in the service is
> hosted in Azure’s BLOB storage and the content type by default is octet
> stream. This has not been an issue because the browsers will resolve the
> file type based on the extension in the file name. It should also be noted
> that the RFC 5280 shows SHOULD rather than MUST.
> 
> ==Bad==
> * It had been more than a year since the CP was updated when I reviewed
> this request. CPS and BR section 2 require annual updates. The CP was
> updated on 5-August.
> * CP/CPS section 1.5.2 did not meet the BR 4.9.3 requirement to provide
> clear problem reporting instructions. This was corrected in the latest
> versions of the CP and CPS.
> * A number of unrevoked certificates chaining to the Microsoft RSA Root
> Certificate Authority 2017 have recently been issued with BR violations [2]
> 
> This begins the 3-week comment period for this request [3].
> 
> I will greatly appreciate your thoughtful and constructive feedback on the
> acceptance of these roots into the Mozilla CA program.
> 
> - Wayne