Re: OCSP Responder monitoring (was Re: Violations of Baseline Requirements 4.9.10)
Thanks Rob! I went through the list and filed a bug for each CA if there wasn't one already open (with one exception that I'm still researching). All open OCSP issues are included in the list at https://wiki.mozilla.org/CA/Incident_Dashboard Wayne On Mon, Dec 11, 2017 at 10:49 PM, Rob Stradling via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > > Some example reports: > > 1. CAs / Responder URLs that are in scope for, but violate, the BR > prohibition on returning a signed a "Good" response for a random serial > number, and are also in scope for Mozilla's consideration: > https://crt.sh/ocsp-responders?trustedExclude=constrained% > 2Cexpired%2Conecrl=Mozilla=Server+Auth > entication=Good > > ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
RE: ComSign Root Renewal Request
Hi Wayne, I noticed your comment on IDN validation. Is there a requirement that CAs establish an effective safeguard against homograph spoofing? The reason I ask is that Let's Encrypt's CPS says this: "Regarding Internationalized Domain Names, ISRG will have no objection so long as the domain is resolvable via DNS. It is the CA’s position that homoglyph spoofing should be dealt with by registrars, and Web browsers should have sensible policies for when to display the punycode versions of names." Doug > -Original Message- > From: dev-security-policy [mailto:dev-security-policy- > bounces+doug.beattie=globalsign@lists.mozilla.org] On Behalf Of > Wayne Thayer via dev-security-policy > Sent: Tuesday, December 5, 2017 1:44 PM > To: mozilla-dev-security-pol...@lists.mozilla.org > Subject: Re: ComSign Root Renewal Request > > > We can restart the discussion and please review their updated documents > and comment in this discussion if you have further questions or concerns > about this request. > > > After reviewing Comsign's updated CPS and related documents, I have the > following comments: > > == Good == > - CPS follows RFC 3647 and includes a table of revisions > - CAA requirements are met > - Audit reports cover a full year > - Contact information for problem reporting is clearly stated in section 4.9.3 > - Aside from what I’ve listed below, all of the issues reported earlier by > Ryan > Sleevi appear to have been addressed. > > == Meh == > - Fingerprints in the audit reports are SHA-1; should be SHA-256 > - The CPS is located at https://www.comsign.co.il/CPS under the heading > “CPS – in accordance with the Electronic Signature Law of Israel” but earlier > discussions indicate that SSL certificates aren’t covered by this law, in > which > case it’s not clear what the difference is between this CPS and the one listed > under “CPS – for - Certificates that are not under the Electronic Signature > Law of Israel” on the same page. > - None of the subordinate CAs contain an EKU extension. [1] > - Section 3.1.3 states that “Comsign will not issue an Electronic Certificate > bearing a nickname of the Subscriber or one that does not state the name of > the Subscriber” but section 7.1.2.3(iv) shows a DV certificate profile that > doesn’t name the Subscriber. If the term ‘Electronic Certificate’ is intended > to only apply to non-SSL certificates, then the definition should be > clarified. > - The domain validation methods specified in CPS section 3.2.2.4 are nearly > cut-and-paste from the BRs, so this section provides little information that > can be used to evaluate Comsign’s domain validation practices. [2] > - None of the four intermediates shown in the root hierarchy diagram [3] are > disclosed in CCADB at this time (this isn’t required until the root is > included). > There are (at least) 3 different “ComSign Organizational CA” subordinate CA > certificates with the same public key that should be disclosed. > > == Bad == > - The Hebrew version of the CPS at https://www.comsign.co.il/repository/ is > version 3.1 while the English version on the same page is 4.0, so I assume > that these are different documents. I see nothing in the English version > stating that it takes precedence over the Hebrew version. > - Section 1 of the CPS doesn’t clearly state that Comsign adheres to the > **latest** version of the BRs, nor that the BRs take precedence over the CPS > (BR 2.2). > - The Creative Commons license is not listed in the CPS (Mozilla policy 3.3). > - Audit reports don’t list any intermediates covered by the audit (Mozilla > policy 3.1.4). > - 3.2.2.4 states “All authentication and verification procedures in this > sub- > section shall be performed either directly by Comsign's personnel (RAs) or > by Comsign's authorized representatives.”. There is no definition of who can > be an ‘authorized representative’, but in this context it sounds like a > Delegated Third Party, and CAs are not permitted to delegate domain > validation (BR 1.3.2). > - CPS 3.2.2.4 states: “For issuing certificates to organizations requesting > SSL > certificates,Comsign performs domain name owners verification to detect > cases of homographic spoofing of IDNs. Comsign employs an automated or > manual process that searches various ‘whois’ services to find the owner of a > particular domain. A search failure result is flagged and the RA rejects the > Certificate Request. Additionally, the RA rejects any domain name that > visually appears to be made up of multiple scripts within one hostname > label.” How does a WHOIS check or a human review effectively detect mixed > scripts in a label? I don’t believe this is an effective safeguard against > homograph spoofing. > - The audit reports supplied cover the period from 2015-04-27 to present. > This doesn’t appear to satisfy the requirement for an unbroken sequence of > audit periods back to the issuance of the first certificate on 2014-10-26 > (refer
Re: On the value of EV
On 18/12/2017 21:54, Andrew wrote: On Monday, December 18, 2017 at 3:09:31 PM UTC-6, Wayne Thayer wrote: Thank you Ryan for raising this question, and to everyone who has been contributing in a constructive manner to the discussion. A number of excellent points have been raised on the effectiveness of EV in general and on the practicality of solving the problems that exist with EV. While we have concerns about the value of EV as well as the potential for EV to actually harm users, Mozilla currently has no definite plans to remove the EV UI from Firefox. At the very least, we want to see Certificate Transparency required for all certificates before making any change that is likely to reduce the use of EV certificates. Is Google planning to remove the EV UI from desktop Chrome? If so, how does that relate to the plan to mark HTTP sites as ‘Not secure’ [1]? Does this imply the complete removal of HTTPS UI? While we agree that improvements to EV validation won’t remove many of the underlying issues that have been raised here, we hope that CAs will move quickly to make the EV Subject information displayed in the address bar more reliable and less confusing. - Wayne [1] https://security.googleblog.com/2016/09/moving-towards-more-secure-web.html So, given that Mozilla has no immediate plans to remove the EV UI from Firefox, perhaps the UI should be adjusted to include the state the Subject is registered in on the EV badge. No reason for that text to be any more misleading than necessary. (I assume this is something we can pretty much all agree on, yes?) As people have already mentioned, states aren't necessarily that informative even within the US. Plus it opens up other phishing-y avenues, like registering a California company that matches some Canadian company's name. So it's not clear that would be an improvement, and certainly not a *strict* improvement -- even before factoring in screen real estate, development and testing effort required, etc. ~ Gijs ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: ComSign Root Renewal Request
Thank you again, On section 1 - we now added links to the current BR etc, and removed the "annual" update so we are bound to update anytime a new version is released. About the homograph spoofing - we have changed the section so now it tells its only automatic (because as you have pointed, there is no way to validate manually) the attachements again: https://drive.google.com/open?id=1VzrWqouZeda5bQkyhdboO_KvfBo9QV17 ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
