RE: On the value of EV

[Tim Hollebeek via dev-security-policy]

Wayne,

Thanks for updating us on Mozilla's thinking on this issue.  On behalf of the 
CA/Browser forum Validation Working Group, I would like to thank everyone
for their time and contributions.  We will be going over everyone's points
and take them all into consideration as we look into what potential ways
EV validation can be improved.

-Tim

> -Original Message-
> From: dev-security-policy [mailto:dev-security-policy-
> bounces+tim.hollebeek=digicert@lists.mozilla.org] On Behalf Of Wayne
> Thayer via dev-security-policy
> Sent: Monday, December 18, 2017 2:09 PM
> To: Ryan Sleevi 
> Cc: mozilla-dev-security-policy  pol...@lists.mozilla.org>
> Subject: Re: On the value of EV
> 
> 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
> ___
> dev-security-policy mailing list
> dev-security-policy@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy


smime.p7s
Description: S/MIME cryptographic signature
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: ComSign Root Renewal Request

[Wayne Thayer via dev-security-policy]

Doug,

I am not aware of any requirement for CAs to detect or prevent homograph
spoofing in the names contained in certificates they issue. Mozilla's
position is that this is something best handled by registries/registrars
just as stated in the CPS you quoted.

In the case of the ComSign CPS, my concerns were that the paragraph was
confusing and it described an ineffective process, so I asked for
clarification.

Wayne

On Tue, Dec 19, 2017 at 4:14 PM, Doug Beattie 
wrote:

> 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 

Mozilla CA Team availability

[Gervase Markham via dev-security-policy]

The Mozilla CA team will have limited availability over the Christmas
and New Year period, and so you should not expect us to engage
substantively in complex debates, make controversial decisions, or
otherwise act as if we were functioning at full strength :-)

We hope that normal service will be resumed in mid-January.

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