Re: Misissued/Suspicious Symantec Certificates

"auditing standards that underlie the accepted audit schemes found in Section 8.1" This is obviously a error in the BRs. That language is taken from Section 8.1 and there is no list of schemes in 8.1. 8.4 does have a list of schemes: 1. WebTrust for Certification Authorities v2.0; 2. A national

Re: Let's Encrypt appears to issue a certificate for a domain that doesn't exist

On Wed, Feb 22, 2017 at 7:35 PM, Richard Wang via dev-security-policy wrote: > As I understand, the BR 4.2.1 required this: > > “The CA SHALL develop, maintain, and implement documented procedures that > identify and require additional verification activity

Re: Google Trust Services roots

Ryan, Both Gerv and I posted follow up questions almost two weeks ago. I know you have been busy with CT days. When do you expect to have answers available? Thanks, Peter On Fri, Feb 10, 2017 at 2:01 AM, Gervase Markham via dev-security-policy wrote: >

Re: Let's Encrypt appears to issue a certificate for a domain that doesn't exist

Rather than what you suggest, I think the following could be high risk: свiтова-пошта.info. xn--i--7kcbgb7fdinng1f.info. гooms17139.link. xn--ooms17139-uzh.link. мцяsц.lol. xn--s-wtb4ab7b.lol. сaентология.net. xn--a-ftbfnnlhbvn2m.net. aμ.net. xn--a-mmb.net. μc.net. xn--c-lmb.net. ωe.net.

Re: Google Trust Services roots

Ryan, Thank you for the quick reply. My comments and questions are inline. On Thu, Feb 9, 2017 at 11:55 AM, Ryan Hurst via dev-security-policy wrote: > Peter, > > Thank you very much for your, as always, thorough review. > > Let me start by saying I agree

Re: Google Trust Services roots

On Thu, Feb 9, 2017 at 9:56 PM, Richard Wang via dev-security-policy wrote: > I can't see this sentence > " I highlight this because we (the community) see the occasional remark like > this; most commonly, it's directed at organizations in particular

Re: Public disclosure of root ownership transfers (was: Re: Google Trust Services roots)

On Thu, Feb 9, 2017 at 7:41 AM, Gervase Markham via dev-security-policy wrote: > On 09/02/17 14:32, Gijs Kruitbosch wrote: >> Would Mozilla's root program consider changing this requirement so that >> it *does* require public disclosure, or are there

Re: Public disclosure of root ownership transfers (was: Re: Google Trust Services roots)

On Mon, Feb 13, 2017 at 4:14 AM, Gervase Markham via dev-security-policy wrote: > On 10/02/17 12:40, Inigo Barreira wrote: >> I see many "should" in this link. Basically those indicating "should notify >> Mozilla" and "should follow the physical relocation

Re: (Possible) DigiCert EV Violation

On Mon, Feb 27, 2017 at 1:41 PM, Ryan Sleevi via dev-security-policy wrote: > The EV Guidelines require certificates issued for .onion include the > cabf-TorServiceDescriptor extension, defined in the EV Guidelines, as part of > these certificates. This is

Re: Notice of Intent to Deprecate and Remove: Trust in Symantec-issued Certificates

On Thu, Mar 23, 2017 at 12:54 PM, Jakob Bohm via dev-security-policy wrote: > > The above message (and one by Symantec) were posted to the > mozilla.dev.security.policy newsgroup prior to becoming aware of > Google's decision to move the discussion to its

Re: Symantec: Next Steps

On Fri, Mar 24, 2017 at 9:06 AM, Ryan Sleevi via dev-security-policy wrote: > (Wearing an individual hat) > > On Fri, Mar 24, 2017 at 10:35 AM, Jakob Bohm via dev-security-policy < > dev-security-policy@lists.mozilla.org> wrote: >> >> One common scenario

Re: Next CA Communication

On Fri, Mar 17, 2017 at 8:30 AM, Gervase Markham via dev-security-policy wrote: > The URL for the draft of the next CA Communication is here: >

Re: Next CA Communication

On Mon, Mar 20, 2017 at 4:52 PM Rob Stradling <rob.stradl...@comodo.com> wrote: > On 20/03/17 17:07, Peter Bowen via dev-security-policy wrote: > > >> B) Your attention is drawn to the cablint and x509lint tools, which you > >> may wish to incorporate into your

Re: Next CA Communication

On Mon, Mar 20, 2017 at 10:43 AM, Jeremy Rowley via dev-security-policy wrote: > A) Does your CA have an RA program, whereby non-Affiliates of your company > perform aspects of certificate validation on your behalf under contract? If > so, please tell us

Re: Researcher Says API Flaw Exposed Symantec Certificates, Including Private Keys

> On Mar 31, 2017, at 6:01 PM, Daniel Baxter via dev-security-policy > wrote: > > On Saturday, April 1, 2017 at 6:27:27 AM UTC+11, Jakob Bohm wrote: >> Oh, come on, if that's her job title, that's her job title, and at any >> CA, that is actually an

Re: Symantec Issues List

On Fri, Mar 31, 2017 at 4:38 PM, Ryan Sleevi via dev-security-policy wrote: > On Fri, Mar 31, 2017 at 2:39 PM, Gervase Markham wrote: > >> As we continue to consider how best to react to the most recent incident >> involving Symantec, and given that there is

Re: Email sub-CAs

On Thu, Apr 13, 2017 at 9:33 AM, douglas.beattie--- via dev-security-policy wrote: > On Thursday, April 13, 2017 at 10:49:17 AM UTC-4, Gervase Markham wrote: >> On 13/04/17 14:23, Doug Beattie wrote: >> > There is no statement back to scope or corresponding

Re: Google Trust Services roots

On Wed, Mar 8, 2017 at 10:14 PM, Richard Wang wrote: > Why we setup one EV OID for all roots is that we use the same policy for all > EV SSL certificate no matter it is issued by which root. The policy OID is > unique ID > > If Google use the GlobalSign EV OID, and

Re: Google Trust Services roots

That is the Starfield Services EV policy identifier, not the Starfield EV policy identifier. We clearly call out in section 1.1 of the our CPS that Starfield Services Root Certificate Authority - G2 is covered under the CPS. On Thu, Mar 9, 2017 at 10:29 PM, Richard Wang

Re: Symantec: Next Steps

On Wed, Mar 8, 2017 at 6:50 AM, Ryan Sleevi wrote: > > On Wed, Mar 8, 2017 at 9:23 AM, Peter Bowen wrote: > >> > Does this make it clearer the point I was trying to make, which is that >> > they're functionally equivalent - due to the fact that both DTPs and >> > sub-CAs >> >

Re: Google Trust Services roots

Richard, I'm afraid a few things are confused here. First, a single CA Operator may have multiple roots in the browser trust list. Each root may list one or more certificate policies that map to the EV policy. Multiple roots that follow the same policy may use the same policy IDs and different

Re: Google Trust Services roots

On Thu, Mar 9, 2017 at 11:02 PM, Jakob Bohm via dev-security-policy wrote: > > Of all these, Starfield seems to be the only case where a single CA > name now refers to two different current CA operators (GoDaddy and > Amazon). All the others are cases of

Re: DigiCert BR violation

On Mon, Mar 13, 2017 at 6:08 PM, Nick Lamb via dev-security-policy wrote: > On Monday, 13 March 2017 21:31:46 UTC, Ryan Sleevi wrote: >> Are you saying that there are one or more clients that require DigiCert to >> support Teletext strings? > > Can we stop

Re: Symantec: Next Steps

On Wed, Mar 8, 2017 at 5:08 AM, Ryan Sleevi <r...@sleevi.com> wrote: > > > On Wed, Mar 8, 2017 at 12:57 AM, Peter Bowen via dev-security-policy > <dev-security-policy@lists.mozilla.org> wrote: >> >> If the DTP is only performing the functions that Jakob lists,

Re: Google Trust Services roots

Ryan, I appreciate you finally sending responses. I hope you appreciate that they are clearly not adequate, in my opinion. Please see the comments inline. On Mon, Mar 6, 2017 at 6:02 PM, Ryan Hurst wrote: > First, let me apologize for the delay in my response, I have had a

Re: Google Trust Services roots

One more question, in addition to the ones in my prior response: On Mon, Mar 6, 2017 at 6:02 PM, Ryan Hurst wrote: > rmh: I just attached two opinion letters from our auditors, I had previously > provided these to the root programs directly but it took some time to get >

Re: Maximum validity of pre-BR certificates

On Sat, Mar 4, 2017 at 12:22 PM, Daniel Cater via dev-security-policy wrote: > On Saturday, 4 March 2017 20:14:09 UTC, Jeremy Rowley wrote: >> 1.0 is not the definitive version any more. As of 2015‐04‐01, Section >> 6.3.2 prohibits validity periods longer

Re: Symantec: Next Steps

On Tue, Mar 7, 2017 at 9:27 PM, Ryan Sleevi via dev-security-policy wrote: > On Tue, Mar 7, 2017 at 11:23 PM, Jakob Bohm via dev-security-policy < > dev-security-policy@lists.mozilla.org> wrote: ]> >> For example, an RA whose sole involvement is to receive a

Re: Symantec Issues List

On Sun, Apr 2, 2017 at 9:36 PM, Ryan Sleevi <r...@sleevi.com> wrote: > > On Sun, Apr 2, 2017 at 11:14 PM Peter Bowen via dev-security-policy > <dev-security-policy@lists.mozilla.org> wrote: >> >> On Fri, Mar 31, 2017 at 11:39 AM, Gervase Markham via >> d

Re: Grace Period for Sub-CA Disclosure

On Mon, Apr 3, 2017 at 1:45 PM, Jakob Bohm via dev-security-policy wrote: > On 03/04/2017 21:48, Ryan Sleevi wrote: >> >> On Mon, Apr 3, 2017 at 3:36 PM, Jakob Bohm via dev-security-policy < >> dev-security-policy@lists.mozilla.org> wrote: >>> >>> >>> The

Re: Grace Period for Sub-CA Disclosure

On Mon, Apr 3, 2017 at 12:36 PM, Jakob Bohm via dev-security-policy wrote: > On 03/04/2017 19:24, Ryan Sleevi wrote: >> >> On Mon, Apr 3, 2017 at 12:58 PM, Jakob Bohm via dev-security-policy < >> dev-security-policy@lists.mozilla.org> wrote: >>> >>> >>>

Re: Symantec Issues List

On Fri, Mar 31, 2017 at 11:39 AM, Gervase Markham via dev-security-policy wrote: > As we continue to consider how best to react to the most recent incident > involving Symantec, and given that there is a question of whether it is > part of a pattern of

Re: Criticism of Google Re: Google Trust Services roots

On Fri, Mar 31, 2017 at 8:18 AM, Gervase Markham via dev-security-policy wrote: > On 30/03/17 15:01, Peter Kurrasch wrote: >> By "not new", are you referring to Google being the second(?) >> instance where a company has purchased an individual root cert from

Re: Final Decision by Google on Symantec

On Mon, Jul 31, 2017 at 7:17 AM, Jakob Bohm via dev-security-policy wrote: > On 31/07/2017 16:06, Gervase Markham wrote: >> >> On 31/07/17 15:00, Jakob Bohm wrote: >>> >>> - Due to current Mozilla implementation bugs, >> >> >> Reference, please? >> > > I am

Re: Final Decision by Google on Symantec

On Thu, Jul 27, 2017 at 11:14 PM, Gervase Markham via dev-security-policy wrote: > Google have made a final decision on the various dates they plan to > implement as part of the consensus plan in the Symantec matter. The > message from blink-dev is included

Re: DigiCert-Symantec Announcement

On Wed, Aug 2, 2017 at 8:10 PM, Peter Gutmann via dev-security-policy wrote: > Jeremy Rowley via dev-security-policy > writes: > >>Today, DigiCert and Symantec announced that DigiCert is acquiring the >>Symantec CA

Re: DigiCert-Symantec Announcement

On Wed, Aug 2, 2017 at 2:12 PM, Jeremy Rowley via dev-security-policy wrote: > Today, DigiCert and Symantec announced that DigiCert is acquiring the > Symantec CA assets, including the infrastructure, personnel, roots, and > platforms. At the same time,

Re: SRVNames in name constraints

On Tue, Aug 15, 2017 at 8:01 AM, Jeremy Rowley wrote: > I realize use of underscore characters was been debated and explained at the > CAB Forum, but I think it's pretty evident (based on the certs issued and > responses to Ballot 202) that not all CAs believe certs

Re: SRVNames in name constraints

On Tue, Aug 15, 2017 at 4:20 AM, Gervase Markham via dev-security-policy wrote: > On 06/07/17 16:56, Ryan Sleevi wrote: >> Relevant to this group, id-kp-serverAuth (and perhaps id-kp-clientAuth) > > So what do we do? There are loads of "name-constrained"

Re: Certificates with improperly normalized IDNs

On Thu, Aug 10, 2017 at 2:31 PM, Jakob Bohm via dev-security-policy wrote: > On 10/08/2017 22:22, Jonathan Rudenberg wrote: >> >> RFC 5280 section 7.2 and the associated IDNA RFC requires that >> Internationalized Domain Names are normalized before encoding

Re: Certificates with reserved IP addresses

Congratulations on finding something not caught by certlint. It turns out that cabtlint does zero checks for reserved IPs. Something else for my TODO list. On Sat, Aug 12, 2017 at 6:52 PM, Jonathan Rudenberg via dev-security-policy wrote: > Baseline

Re: Certificates with improperly normalized IDNs

On Thu, Aug 10, 2017 at 1:22 PM, Jonathan Rudenberg via dev-security-policy wrote: > RFC 5280 section 7.2 and the associated IDNA RFC requires that > Internationalized Domain Names are normalized before encoding to punycode. > > Let’s Encrypt appears to

Re: 2017.08.10 Let's Encrypt Unicode Normalization Compliance Incident

On Sun, Aug 13, 2017 at 5:59 PM, Matt Palmer via dev-security-policy wrote: > On Fri, Aug 11, 2017 at 06:32:11PM +0200, Kurt Roeckx via dev-security-policy > wrote: >> On Fri, Aug 11, 2017 at 11:48:50AM -0400, Ryan Sleevi via >> dev-security-policy wrote:

Re: WoSign new system passed Cure 53 system security audit

Richard, I can only guess what Ryan is talking about as the report wasn't sent to this group, but it is possible that the system described could not meet the Baseline Requirements, as the BRs do require certain system designs. For example, two requirements are: "Require that each individual in

Re: [EXT] Symantec Update on SubCA Proposal

Steve, I think this level of public detail is very helpful when it comes to understanding the proposal. On Thu, Jul 20, 2017 at 8:00 AM, Steve Medin via dev-security-policy wrote: > 1) December 1, 2017 is the earliest credible date that any RFP >

SRVNames in name constraints

In reviewing the Mozilla CA policy, I noticed one bug that is probably my fault. It says: "name constraints which do not allow Subject Alternative Names (SANs) of any of the following types: dNSName, iPAddress, SRVName, rfc822Name" SRVName is not yet allowed by the CA/Browser Forum Baseline

Re: SRVNames in name constraints

he review period now, it'll be > passed by the time the Mozilla policy is updated. > > -Original Message- > From: dev-security-policy > [mailto:dev-security-policy-bounces+jeremy.rowley=digicert.com@lists.mozilla > .org] On Behalf Of Peter Bowen via dev-security-policy >

Re: SRVNames in name constraints

> On Jul 5, 2017, at 4:23 AM, Gervase Markham via dev-security-policy > wrote: > > On 03/07/17 17:44, Peter Bowen wrote: >> We still need to get the policy changed, even with the ballot. As >> written right now, all name constrained certificates are no

Re: Certificates with metadata-only subject fields

The point of certlint was to help identify issues. While I appreciate it getting broad usage, I don't think pushing for revocation of every certificate that trips any of the Error level checks is productive. This reminds of me of people trawling a database of known vulnerabilities then reporting

Re: Certificates with invalidly long serial numbers

On Mon, Aug 7, 2017 at 12:53 AM, Franck Leroy via dev-security-policy wrote: > Hello > > I checked only one but I think they are all the same. > > The integer value of the serial number is 20 octets, but when encoded into > DER a starting 00 may be

Re: Certificates with invalidly long serial numbers

(inserted missed word; off to get coffee now) On Mon, Aug 7, 2017 at 7:54 AM, Peter Bowen wrote: > On Mon, Aug 7, 2017 at 12:53 AM, Franck Leroy via dev-security-policy > wrote: >> Hello >> >> I checked only one but I think they are all

Re: BR compliance of legacy certs at root inclusion time

On Fri, Aug 18, 2017 at 8:47 AM, Ryan Sleevi via dev-security-policy wrote: > On Fri, Aug 18, 2017 at 11:02 AM, Gervase Markham via dev-security-policy < > dev-security-policy@lists.mozilla.org> wrote: > >> Sometimes, CAs apply for inclusion with new, clean

Re: Configuring Graduated Trust for Non-Browser Consumption

> On May 16, 2017, at 7:42 AM, Jakob Bohm via dev-security-policy > wrote: > > On 13/05/2017 00:48, Ryan Sleevi wrote: >> >> And in the original message, what was requested was >> "If Mozilla is interested in doing a substantial public service, this >>

Re: Configuring Graduated Trust for Non-Browser Consumption

On Tue, May 16, 2017 at 10:04 AM, Jakob Bohm via dev-security-policy wrote: > On 16/05/2017 18:10, Peter Bowen wrote: >> >> On Tue, May 16, 2017 at 9:00 AM, Jakob Bohm via dev-security-policy >> wrote: >>> >>> Your

Re: Configuring Graduated Trust for Non-Browser Consumption

On Tue, May 16, 2017 at 10:52 AM, Jakob Bohm via dev-security-policy wrote: > On 16/05/2017 19:36, Peter Bowen wrote: >> >> My experience is that Mozilla is very open to taking patches and will >> help contributors get things into acceptable form, so I'm

Re: Configuring Graduated Trust for Non-Browser Consumption

On Tue, May 16, 2017 at 9:00 AM, Jakob Bohm via dev-security-policy wrote: > Your post above is the first response actually saying what is wrong > with the Microsoft format and the first post saying all the > restrictions are actually in the certdata.txt

Re: Configuring Graduated Trust for Non-Browser Consumption

> On May 12, 2017, at 3:48 PM, Ryan Sleevi via dev-security-policy > wrote: > > On Fri, May 12, 2017 at 6:02 PM, Jakob Bohm via dev-security-policy < > dev-security-policy@lists.mozilla.org> wrote: >> >> This SubThread (going back to Kurt Roeckx's post

Re: New undisclosed intermediates

On Thu, Jun 8, 2017 at 7:09 PM, Jonathan Rudenberg via dev-security-policy wrote: > >> On Jun 8, 2017, at 20:43, Ben Wilson via dev-security-policy >> wrote: >> >> I don't believe that disclosure of root certificates

Re: New undisclosed intermediates

On Thu, Jun 8, 2017 at 7:02 PM, Matthew Hardeman via dev-security-policy wrote: > On Thursday, June 8, 2017 at 7:44:08 PM UTC-5, Ben Wilson wrote: >> I don't believe that disclosure of root certificates is the responsibility >> of a CA that has

Re: Root Store Policy 2.5: Call For Review and Phase-In Periods

On Wed, Jun 21, 2017 at 7:15 AM, Gervase Markham via dev-security-policy wrote: > On 21/06/17 13:13, Doug Beattie wrote: >>> Do they have audits of any sort? >> >> There had not been any audit requirements for EKU technically >> constrained CAs, so no, there

Re: ETSI auditors still not performing full annual audits?

On Mon, Jun 19, 2017 at 12:14 PM, Kathleen Wilson via dev-security-policy wrote: > I just filed https://bugzilla.mozilla.org/show_bug.cgi?id=1374381 about an > audit statement that I received for SwissSign. I have copied the bug > description below,

Re: Unknown Intermediates

On Fri, Jun 23, 2017 at 6:17 AM, Rob Stradling via dev-security-policy wrote: > On 23/06/17 14:10, Kurt Roeckx via dev-security-policy wrote: >> >> On 2017-06-23 14:59, Rob Stradling wrote: >>> >>> Reasons: >>>- Some are only trusted by the old Adobe CDS

Re: Mozilla Policy and CCADB Disclosure scope

On Fri, May 19, 2017 at 6:47 AM, Gervase Markham via dev-security-policy wrote: > We need to have a discussion about the appropriate scope for: > > 1) the applicability of Mozilla's root policy > 2) required disclosure in the CCADB > > The two questions are

Re: Mozilla Policy and CCADB Disclosure scope

On Mon, May 22, 2017 at 1:02 PM, Matthew Hardeman via dev-security-policy wrote: > On Monday, May 22, 2017 at 2:43:14 PM UTC-5, Peter Bowen wrote: > >> >> I would say that any CA-certificate signed by a CA that does not have >> name constraints and not

Re: Mozilla Policy and CCADB Disclosure scope

On Mon, May 22, 2017 at 12:21 PM, Ryan Sleevi via dev-security-policy wrote: > Consider, on one extreme, if every of the Top 1 sites used TCSCs to > issue their leaves. A policy, such as deprecating SHA-1, would be > substantially harder, as now there's

Re: Google Plan for Symantec posted

On Mon, May 22, 2017 at 9:33 AM, Gervase Markham via dev-security-policy wrote: > On 19/05/17 21:04, Kathleen Wilson wrote: >> - What validity periods should be allowed for SSL certs being issued >> in the old PKI (until the new PKI is ready)? > > Symantec

Re: Symantec: Update

On Fri, May 19, 2017 at 7:25 AM, Gervase Markham via dev-security-policy wrote: > On 15/05/17 21:06, Michael Casadevall wrote: > >>> Are there any RA's left for Symantec? >> >> TBH, I'm not sure. I think Gervase asked for clarification on this >> point, but

Re: Policy 2.5 Proposal: Add definition of "mis-issuance"

On Thu, Jun 1, 2017 at 5:49 AM, Ryan Sleevi via dev-security-policy wrote: > On Thu, Jun 1, 2017 at 4:35 AM, Gervase Markham via dev-security-policy < > dev-security-policy@lists.mozilla.org> wrote: > >> On 31/05/17 18:02, Matthew Hardeman wrote: >> >

Re: Policy 2.5 Proposal: Add definition of "mis-issuance"

On Fri, Jun 2, 2017 at 4:27 AM, Ryan Sleevi <r...@sleevi.com> wrote: > > > On Thu, Jun 1, 2017 at 10:19 PM, Peter Bowen via dev-security-policy > <dev-security-policy@lists.mozilla.org> wrote: >> >> On Thu, Jun 1, 2017 at 5:49 AM, Ryan Sleevi via dev-securi

Re: Policy 2.5 Proposal: Make it clear that Mozilla policy has wider scope than the BRs

On Fri, Jun 2, 2017 at 8:50 AM, Gervase Markham via dev-security-policy wrote: > On 02/06/17 12:24, Kurt Roeckx wrote: >> Should that be "all certificates" instead of "all SSL certificates"? > > No; the Baseline Requirements apply only to SSL certificates.

Re: Policy 2.5 Proposal: Add definition of "mis-issuance"

On Fri, Jun 2, 2017 at 8:12 AM, Ryan Sleevi wrote: > On Fri, Jun 2, 2017 at 10:09 AM Jakob Bohm wrote: > >> On 02/06/2017 15:54, Ryan Sleevi wrote: >> > On Fri, Jun 2, 2017 at 9:33 AM, Peter Bowen wrote: >> > >> >> Yes, my concern is that this could make SIGNED{ToBeSigned} considered >> >>

Re: Mozilla requirements of Symantec

On Thu, Jun 8, 2017 at 9:38 AM, Jakob Bohm via dev-security-policy wrote: > > As the linked proposal was worded (I am not on Blink mailing lists), it > seemed obvious that the original timeline was: > > Later: Once the new roots are generally accepted,

Re: New undisclosed intermediates

On Fri, Jun 9, 2017 at 9:11 AM, Matthew Hardeman via dev-security-policy wrote: > For these self-signed roots which have a certificate subject and key which > match to a different certificate which is in a trusted path (like an > intermediate to a trusted

Re: Symantec: Draft Proposal

On Fri, May 5, 2017 at 9:02 AM, Gervase Markham via dev-security-policy wrote: > On 04/05/17 21:58, Ryan Sleevi wrote: > > I asked Symantec what fields CrossCert had control over. Their answer is > here on page 3: >

Re: Symantec: Draft Proposal

On Fri, May 5, 2017 at 9:18 AM, Gervase Markham wrote: > On 05/05/17 17:09, Peter Bowen wrote: >> We know that the RAs could use different certificate profiles, as >> certificates they approved had varying issuers, and "Issuer DN" has >> the same "No(1)" that CP has in the table

Re: Policy 2.5 Proposal: Fix definition of constraints for id-kp-emailProtection

On Fri, May 5, 2017 at 11:44 AM, Dimitris Zacharopoulos via dev-security-policy wrote: > > Looking at https://github.com/mozilla/pkipolicy/issues/69 > > do you have a proposed language that takes all comments into account? From > what I understand, the

Re: Email sub-CAs

(Resending as the attached file was too large) On Fri, May 5, 2017 at 10:46 AM, Peter Bowen wrote: > On Thu, Apr 20, 2017 at 3:01 AM, Gervase Markham via > dev-security-policy wrote: >> On 15/04/17 17:05, Peter Bowen wrote: >>> Should

Re: Policy 2.5 Proposal: Fix definition of constraints for id-kp-emailProtection

On Fri, May 5, 2017 at 11:58 AM, Dimitris Zacharopoulos via dev-security-policy <dev-security-policy@lists.mozilla.org> wrote: > > > On 5/5/2017 9:49 μμ, Peter Bowen via dev-security-policy wrote: >> >> On Fri, May 5, 2017 at 11:44 AM, Dimitris Zacharopoulos via

Re: Policy 2.5 Proposal: Fix definition of constraints for id-kp-emailProtection

On Fri, May 5, 2017 at 2:21 PM, Jakob Bohm via dev-security-policy wrote: > On 05/05/2017 22:45, Dimitris Zacharopoulos wrote: >> >> >> >> On 5/5/2017 10:58 μμ, Peter Bowen wrote: >>> >> >> I don't know if all implementations doing path validation, use the

Re: Changing CCADB domains

On Wed, May 3, 2017 at 10:52 AM, Kathleen Wilson via dev-security-policy wrote: > All, > > I think it is time for us to change the domains that we are using for the > CCADB as follows. > > Change the links for... > > 1) CAs to login to the CCADB > from >

Re: DigiCert-Symantec Announcement

On Tue, Sep 19, 2017 at 8:39 PM, Jeremy Rowley via dev-security-policy wrote: > > The current end-state plan for root cross-signing is provided at > https://bugzilla.mozilla.org/show_bug.cgi?id=1401384. The diagrams there show > all of the existing sub CAs

Re: DigiCert-Symantec Announcement

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

Re: DigiCert-Symantec Announcement

On Fri, Sep 22, 2017 at 6:22 AM, Nick Lamb via dev-security-policy wrote: > On Friday, 22 September 2017 05:01:03 UTC+1, Peter Bowen wrote: >> I realize this is somewhat more complex than what you, Ryan, or Jeremy >> proposed, but it the only way I see root

Re: Public trust of VISA's CA

On Wed, Sep 20, 2017 at 12:37 AM, Martin Rublik via dev-security-policy wrote: > On Tue, Sep 19, 2017 at 5:22 PM, Alex Gaynor via dev-security-policy < > dev-security-policy@lists.mozilla.org> wrote: > >>

Re: New Version Notification for draft-belyavskiy-certificate-limitation-policy-04.txt

On Tue, Sep 12, 2017 at 5:59 AM, Dmitry Belyavsky via dev-security-policy wrote: > Here is the new version of the draft updated according to the discussion on > mozilla-dev-security list. Given that RFC 5914 already defines a TrustAnchorList and

Re: Mozilla’s Plan for Symantec Roots

On Mon, Oct 16, 2017 at 10:32 AM, Gervase Markham via dev-security-policy wrote: > As per previous discussions and > https://wiki.mozilla.org/CA:Symantec_Issues, a consensus proposal[0] was > reached among multiple browser makers for a graduated distrust of

Re: CAs not compliant with CAA CP/CPS requirement

On Fri, Sep 8, 2017 at 12:24 PM, 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

Re: CAA Certificate Problem Report

On Sat, Sep 9, 2017 at 3:57 AM, Jonathan Rudenberg <jonat...@titanous.com> wrote: > >> On Sep 9, 2017, at 06:19, Peter Bowen via dev-security-policy >> <dev-security-policy@lists.mozilla.org> wrote: >> >> In all three of these cases, the "domain's zon

Re: CAA Certificate Problem Report

On Sat, Sep 9, 2017 at 11:50 AM, Andrew Ayer <a...@andrewayer.name> wrote: > On Sat, 9 Sep 2017 08:49:01 -0700 > Peter Bowen via dev-security-policy > <dev-security-policy@lists.mozilla.org> wrote: > >> On Sat, Sep 9, 2017 at 3:57 AM, Jonathan Rudenberg &g

Re: CAA Certificate Problem Report

On Sat, Sep 9, 2017 at 1:50 PM, Andrew Ayer wrote: > > drill is buggy and insecure. Obviously, such implementations can > be found. Note that drill is just a "debugging/query" tool, not a > resolver you would actually use in production. You'll find that the >

Re: CAA Certificate Problem Report

On Sat, Sep 9, 2017 at 1:59 PM, Andrew Ayer <a...@andrewayer.name> wrote: > On Sat, 9 Sep 2017 13:53:52 -0700 > Peter Bowen via dev-security-policy > <dev-security-policy@lists.mozilla.org> wrote: > >> On Sat, Sep 9, 2017 at 1:50 PM, Andrew Ayer <a...@andrewaye

Re: CAA Certificate Problem Report

> Certificate 3 contains a single DNS identifier for > refused.caatestsuite-dnssec.com > Attempts to query the CAA record for this DNS name result in a REFUSED DNS > response. Since there is a DNSSEC validation chain from this zone to the > ICANN root, CAs are not permitted to treat the lookup

Re: Verisign signed speedport.ip ?

On Sat, Dec 9, 2017 at 11:42 AM, Lewis Resmond via dev-security-policy wrote: > I was researching about some older routers by Telekom, and I found out that > some of them had SSL certificates for their (LAN) configuration interface, > issued by Verisign

Re: Bit encoding (AW: Policy 2.6 Proposal: Add prohibition on CA key generation to policy)

I don't think that is true. Remember for OV/IV/EV certificates, the Subscriber is the natural person or Legal Entity identified in the certificate Subject. If the Subscriber is using the certificate on a CDN, it is probably better to have the CDN generate the key rather than the Subscriber. The

Re: Mozilla’s Plan for Symantec Roots

On Tue, Oct 17, 2017 at 2:06 AM, Gervase Markham wrote: > On 16/10/17 20:22, Peter Bowen wrote: >> Will the new managed CAs, which will operated by DigiCert under >> CP/CPS/Audit independent from the current Symantec ones, also be >> included on the list of subCAs that will

Re: Certificates with shared private keys by gaming software (EA origin, Blizzard battle.net)

On Mon, Dec 25, 2017 at 7:10 AM, Adrian R. via dev-security-policy wrote: > since it's a webserver running on the local machine and is using that > certificate key/pair, i think that someone more capable than me can easily > extract the key from it. > >

Re: Updating Root Inclusion Criteria

On Tue, Jan 16, 2018 at 3:45 PM, Wayne Thayer via dev-security-policy wrote: > I would like to open a discussion about the criteria by which Mozilla > decides which CAs we should allow to apply for inclusion in our root store. > > Section 2.1 of Mozilla’s

Re: Retirement of RSA-2048

On Sat, Jan 20, 2018 at 8:31 AM, James Burton via dev-security-policy wrote: > Approximate date of retirement of RSA-2048? This is a very broad question, as you don't specify the usage. If you look at the US National Institute of Standards and Technology's

Re: TLS-SNI-01 and compliance with BRs

> On Jan 19, 2018, at 7:22 AM, Doug Beattie via dev-security-policy > wrote: > > Many CA’s haven’t complied with the Mozilla requirement to list the methods > they use (including Google btw), so it’s hard to tell which CAs are using > method 10. Of

Re: Updating Root Inclusion Criteria (organizations)

On Wed, Jan 17, 2018 at 11:49 AM, Jakob Bohm via dev-security-policy wrote: > 4. Selected company CAs for a handful of too-bit-to-ignore companies > that refuse to use a true public CA. This would currently probably > be Microsoft, Amazon and Google.

  1   2   >