RE: DigiCert policy violation - non-disclosure of https://crt.sh/?id=160110886

Thanks Nick. I'm missing something on this, so I appreciate the help so far. I replied to each section. Perhaps you have confused transitivity with commutativity or one of the other simple properties. Transitivity is the property whereby if F(A,B) and F(B,C) then F(A,C), for example the "greater

Re: DigiCert policy violation - non-disclosure of https://crt.sh/?id=160110886

On Monday, 3 July 2017 23:05:53 UTC+1, Jeremy Rowley wrote: > And it's hardly fair to deride my lack of understanding on what transitive > trust entails in the digital certificate space considering it's outside of > the usual trust paths, not defined in the standard RFCs, and not the same as >

Re: Machine- and human-readable format for root store information?

On Mon, Jul 3, 2017 at 11:53 AM, Kai Engert wrote: > > > I suspect, means anyone could plug > > > in a modern CI > > CI meaning Continuous Integration ? > Yes. Gerv's proposal rests on the idea of having a file committed that explains it in human-readable and machine-readable

RE: DigiCert policy violation - non-disclosure of https://crt.sh/?id=160110886

We've now uploaded the self-signed root into the CCADB as a subordinate CA to the same self-signed root, if that makes sense. -Original Message- From: dev-security-policy [mailto:dev-security-policy-bounces+ben=digicert@lists.mozilla.org] On Behalf Of Jeremy Rowley via

RE: DigiCert policy violation - non-disclosure of https://crt.sh/?id=160110886

"Previously accepted without comment" is hardly accurate. There's lots of comments on the Mozilla policy (including Ben's comment on this very term). And it's hardly fair to deride my lack of understanding on what transitive trust entails in the digital certificate space considering it's outside

Re: DigiCert policy violation - non-disclosure of https://crt.sh/?id=160110886

On Monday, 3 July 2017 22:00:00 UTC+1, Jeremy Rowley wrote: > Link please to a formal definition? As your email alleges a policy violation > by one a cross-signed CAs, we take the investigation and response very > seriously. I'd like to know the basis for the definition before formulating > an

RE: DigiCert policy violation - non-disclosure of https://crt.sh/?id=160110886

Link please to a formal definition? As your email alleges a policy violation by one a cross-signed CAs, we take the investigation and response very seriously. I'd like to know the basis for the definition before formulating an official report and potentially penalizing the Sub CA for

Re: DigiCert policy violation - non-disclosure of https://crt.sh/?id=160110886

On 03/07/17 16:10, Jeremy Rowley via dev-security-policy wrote: I am surprised you decided to fork the thread from here https://groups.google.com/forum/#!topic/mozilla.dev.security.policy/sNDN6q26_uM where this was already being discussed. Seems unnecessary. Hi Jeremy. That thread discusses

Re: SRVNames in name constraints

We still need to get the policy changed, even with the ballot. As written right now, all name constrained certificates are no longer considered constrained. On Mon, Jul 3, 2017 at 9:42 AM, Jeremy Rowley wrote: > Isn't this ballot ready to go? If we start the review

RE: SRVNames in name constraints

Isn't this ballot ready to go? If we start the 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

RE: Symantec meeting and status

Thank you, Gerv (and have a great vacation!) Best, Peter -Original Message- From: Gervase Markham [mailto:g...@mozilla.org] Sent: Monday, July 03, 2017 12:21 PM To: Loshin, Peter; mozilla-dev-security-pol...@lists.mozilla.org Cc: pr...@mozilla.com; Justin O'Kelly Subject: Re: Symantec

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: Symantec meeting and status

Hi Peter, I note you have copied in our press team and that you are a journalist; I will answer your question as I would the same question from any member of our community here if it were asked in this forum. On 03/07/17 16:54, Loshin, Peter wrote: > Other than stating that it will be publishing

Symantec meeting and status

Hi Gerv: Thank you for posting this update on last week's meeting with Symantec. Are you able to share any additional information about what transpired at this meeting? Other than stating that it will be publishing its proposal for implementing the consensus remediation plan, did Symantec

Re: Machine- and human-readable format for root store information?

On Wed, 2017-06-28 at 15:08 -0700, Ryan Sleevi via dev-security-policy wrote: > On Wednesday, June 28, 2017 at 5:29:19 PM UTC-4, Gervase Markham wrote: > > Well, the fact that we now use Git, NSS and the root store don't use Git, it uses HG/Mercurial. > > I suspect, means anyone could plug > >

RE: DigiCert policy violation - non-disclosure of https://crt.sh/?id=160110886

I am surprised you decided to fork the thread from here https://groups.google.com/forum/#!topic/mozilla.dev.security.policy/sNDN6q26_uM where this was already being discussed. Seems unnecessary. I don't agree this is a policy violation, and I doubt any CA not involved in the previously

Re: Machine- and human-readable format for root store information?

On Mon, 2017-07-03 at 15:12 +0100, Gervase Markham wrote: > > > I think the new format should be as complete as possible, including both > > trust > > and distrust information, including EV and description of rules for partial > > distrust. > > I agree, as long as we can stay away from defining

Symantec meeting and status

Hi everyone, As I was in the Bay Area for the Mozilla All Hands, Symantec requested a face-to-face meeting with Mozilla, which happened last Friday. In attendance were Tom Ritter, Aaron Wu and I for Mozilla, and the following people from Symantec (I hope I have the titles right): * Quentin Liu

Re: Machine- and human-readable format for root store information?

Hi Kai, On 30/06/17 17:38, Kai Engert wrote: > given that today we don't have a single place where all of Mozilla's > certificate > trust decisions can be found, introducing that would be a helpful. I'm glad you see the value in my goal :-) > I think the new format should be as complete as

DigiCert policy violation - non-disclosure of https://crt.sh/?id=160110886

https://crt.sh/mozilla-disclosures#undisclosed has listed https://crt.sh/?id=160110886 for over 1 week. This is a violation of section 5.3.2 of the Mozilla Root Store Policy v2.5 [1], which says (emphasis mine): "All certificates that are capable of being used to issue new certificates, that