Re: Removing "Wildcard DV Certs" from Potentially Problematic Practices list

On Tue, Apr 25, 2017 at 1:31 AM, Peter Kurrasch via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > Wildcard certs present a level of risk that is different (higher?) than > for other end-entity certs.‎ The risk as I see it is two-fold: > > 1) Issuance: Setting aside the

Re: Removing "Wildcard DV Certs" from Potentially Problematic Practices list

Wildcard certs present a level of risk that is different (higher?) than for other end-entity certs.‎ The risk as I see it is two-fold:1) Issuance: Setting aside the merits of the 10 Blessed Methods, there is no

Re: Criticism of Google Re: Google Trust Services roots

On Monday, April 24, 2017 at 9:58:29 PM UTC-7, Jakob Bohm wrote: > On 25/04/2017 05:04, Ryan Sleevi wrote: > > On Mon, Apr 24, 2017 at 9:42 PM, Jakob Bohm via dev-security-policy < > > dev-security-policy@lists.mozilla.org> wrote: > > > >> On 25/04/2017 03:10, Peter Kurrasch wrote: > >> > >>> Fair

Re: Criticism of Google Re: Google Trust Services roots

On 25/04/2017 05:04, Ryan Sleevi wrote: On Mon, Apr 24, 2017 at 9:42 PM, Jakob Bohm via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: On 25/04/2017 03:10, Peter Kurrasch wrote: Fair enough. I propose the following for consideration: Prior to ‎transferring ownership of

Re: Criticism of Google Re: Google Trust Services roots

On Monday, April 24, 2017 at 8:02:15 PM UTC-7, Peter Kurrasch wrote: > I see what you're saying and there should be some consideration for that > scenario. If the acquiring company will keep all the same infrastructure and > staff and if decision making authority will remain with that staff,

Re: Symantec Conclusions and Next Steps

On Tue, Apr 25, 2017 at 12:14 AM, Ryan Sleevi wrote: > Gerv, > > Is there any update on https://wiki.mozilla.org/ > CA:Symantec_Issues#STRUCK:_Issue_Y:_Unaudited_ > Unconstrained_Intermediates_.28December_2015_-_April_2017.29 ? > > I'm just wanting to understand how this relates

Re: Symantec Conclusions and Next Steps

Gerv, Is there any update on https://wiki.mozilla.org/CA:Symantec_Issues#STRUCK:_Issue_Y:_Unaudited_Unconstrained_Intermediates_.28December_2015_-_April_2017.29 ? I'm just wanting to understand how this relates to Mozilla's PKI policy and expectations, and better understand why you struck it. -

Re: Criticism of Google Re: Google Trust Services roots

On Mon, Apr 24, 2017 at 9:42 PM, Jakob Bohm via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > On 25/04/2017 03:10, Peter Kurrasch wrote: > >> Fair enough. I propose the following for consideration: >> >> Prior to ‎transferring ownership of a root cert contained in the

Re: Criticism of Google Re: Google Trust Services roots

I see what you're saying and there should be some consideration for that scenario. If the acquiring company will keep all the same infrastructure and staff and if decision making authority will remain with that

Re: Criticism of Google Re: Google Trust Services roots

On 25/04/2017 03:10, Peter Kurrasch wrote: Fair enough. I propose the following for consideration: Prior to ‎transferring ownership of a root cert contained in the trusted store (either on an individual root basis or as part of a company acquisition), a public attestation must be given as to

Re: Criticism of Google Re: Google Trust Services roots

Fair enough. I propose the following for consideration:Prior to ‎transferring ownership of a root cert contained in the trusted store (either on an individual root basis or as part of a company acquisition), a

Updating Bugzilla Product/Component groups for CA Program Bugs

All, This is just for informational purposes... I have filed Bug #1359112 to update the Bugzilla Product/Components for the CA Program Bugs. The bugs asks: ~~ Current Product: NSS Current Component Name: CA Certificates change to Product: NSS Component Name: CA Certificate Code Current

Re: DRAFT - BR Self Assessments

On Saturday, April 22, 2017 at 5:25:35 AM UTC-7, wangs...@gmail.com wrote: > We have a question about completing the BR self assessment,  > is it necessary that all the BRs requirements appear in  > relevant sections of the CP/CPS?  It is OK if the information is in different sections in the

Re: Extend deadline for April 2017 CA Communication?

I added a note about the extension to May 5 to https://wiki.mozilla.org/CA:Communications#April_2017 Cheers, Kathleen ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy

Re: Certificate issues

On 21/04/2017 21:29, Nick Lamb wrote: On Tuesday, 18 April 2017 18:33:29 UTC+1, Jakob Bohm wrote: I believe the point was to check the prospective contents of the TBSCertificate *before* CT logging (noting that Ryan Sleevi has been violently insisting that failing to do that shall be punished

Announcing TLS Canary 3.0

Hi all, TLS Canary is a tool that finds Firefox SSL regressions. We run the tool on a regular basis, at a minimum post-branch and sporadically during the release cycle. Results of runs are posted to a public web site [1]. We use the canary to gauge impact of proposed changes to our TLS stack,

Re: Symantec Conclusions and Next Steps

On 2017-04-24 11:18, Gervase Markham wrote: On 21/04/17 11:38, Kurt Roeckx wrote: I'm still concerned that they don't seem to have an idea of what software they're all (still) running, and they didn't reply to any question about it. I'm sorry, I don't follow. Can you expand? I confused some

Re: SHA-1 serverAuth cert issued by Trustis in November 2016

Hi Blake, On 21/04/17 16:55, blake.mor...@trustis.com wrote: > Following further discussion with, and guidance from Mozilla, it has > been determined that the getset.trustis.com certificate issued in > November 2016 was a mis-issuance. This incident has highlighted an > ambiguity arising from

Re: Symantec Conclusions and Next Steps

On 21/04/17 11:38, Kurt Roeckx wrote: > I'm still concerned that they don't seem to have an idea of what > software they're all (still) running, and they didn't reply to any > question about it. I'm sorry, I don't follow. Can you expand? Gerv ___

Re: Removing "Wildcard DV Certs" from Potentially Problematic Practices list

On 22/04/17 02:23, Matt Palmer wrote: > Didn't a CA get caught fairly recently issuing certs with sAN:example.com > when the validation was for www.example.com, and got a stern talking to as a > result? I vaguely recall something about that, but not with enough detail > to trawl the archives

Re: Removing "Wildcard DV Certs" from Potentially Problematic Practices list

On 21/04/17 12:09, Nick Lamb wrote: > Of the ballot 169 methods, 3.2.2.4.7 is most obviously appropriate > for verifying that the applicant controls the entire domain and thus > *.example.com, whereas say 3.2.2.4.6 proves only that the applicant > controls a web server, it seems quite likely they