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

[Jeremy Rowley via dev-security-policy]

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 than" binary relation is
transitive.
[JR] No confusion on what the arithmetic property, but I am having trouble
seeing how the transitive
trust applies to a self-signed and self-issued root with a publicly trusted
root.  Can you explain this more? 

The previously undisclosed certificate chains to a certificate which chains
to another certificate and so on until you reach one that is included in the
programme.  The Mozilla policy isn't trying to do anything very fancy here,
it's just spelling out how chains actually work, which is why it was a
concern that you seem so surprised this policy applies.
[JR] Well yeah - but this one is self-signed and self-issued, so how does it
chain? 

It seems _especially_ strange to object for this certificate that you had
never imagined it was necessary to disclose it, while perhaps half a dozen
similar certificates in the same family were previously disclosed. I would
suggest that rather than demonstrating DigiCert had no idea it was supposed
to disclose them, it instead indicates that DigiCert's processes for
actually ensuring this gets done are inadequate and so some random
proportion of sub-CAs may go undisclosed entirely by accident. That's not
good news.

[JR] No. We have a process for disclosing. We didn't issue the cert...
directly. This was issued by the Belgium government, who is obligated to
follow the policy themselves for all cross-signed certs.  However, this
isn't a cross-signed cert since it's self-signed.  We've never encountered
transitive trust as we don't reuse keys in our certs.  This is a unique
situation for us as it's a program that's long been deprecated that we
haven't been able to force migration from. 


___
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: DigiCert policy violation - non-disclosure of https://crt.sh/?id=160110886

[Nick Lamb via dev-security-policy]

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
> the mathematical expression.

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 than" binary relation is transitive.

The previously undisclosed certificate chains to a certificate which chains to 
another certificate and so on until you reach one that is included in the 
programme.  The Mozilla policy isn't trying to do anything very fancy here, 
it's just spelling out how chains actually work, which is why it was a concern 
that you seem so surprised this policy applies.

It seems _especially_ strange to object for this certificate that you had never 
imagined it was necessary to disclose it, while perhaps half a dozen similar 
certificates in the same family were previously disclosed. I would suggest that 
rather than demonstrating DigiCert had no idea it was supposed to disclose 
them, it instead indicates that DigiCert's processes for actually ensuring this 
gets done are inadequate and so some random proportion of sub-CAs may go 
undisclosed entirely by accident. That's not good news.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

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

[Ryan Sleevi via dev-security-policy]

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 (simultaneously) form,
and then have a continuous integration build translate that into something
consumable by NSS, and then commit that generated file back into the tree
(as I understand it). For example, the resulting certdata.txt or certdata.c


> I'd prefer a bit more control. Any conversion script, which translates
> from a
> new high level file format, to a specific technical file format used by our
> software, could have bugs.
>
> If everything is automated, there's more risk that changes might not get
> reviewed, and bugs aren't identified.
>

Agreed


> > I don't believe the state of NSS infrastructure is well-placed to
> support that
> > claim. I'd be curious for Kai's/Red Hat's feedback.
>
> I'm not sure I correctly understand this sentence, but if you're asking if
> we
> have such conversion magic, we don't.
>

That's what I was asking about.


> There's the technicaly possibility of having commit hooks. But I'm not
> sure I
> like that approach.
>

I agree.


> I would discourage a few things when introducing a JSON file format, like,
> avoid
> unnecessary changes in line wrapping or reordering, to make it easier to
> compare
> different revisions.
>

Right. And JSON can't have comments. So we'd lose substantially in
expressiveness.


> > > No, because NSS consumers could choose to continue consuming the
> > > (autogenerated by the CI tool) certdata.txt.
> >
> > The CI tools don't check in artifacts.
>
> What does artifact mean in this context?
>

"Artifact" = generated file run as part of a build process, and then
checked back in.


> > Thought experiment: Why not have certdata.txt generate a CI artifact that
> > interoperates for other consumers to use?
>
> Are you suggesting that we should convert certdata.txt into a file format
> that
> others would prefer to consume?
>
> Yes, that's another option.
>
> But it wouldn't solve the idea to also store the Mozilla EV attributes in
> the
> common place. Firefox developers would have to start converting information
> found inside NSS to Firefox application code.
>

I'm not sure I fully understand your response. The suggestion was that if
there's some 'other format' that leads interoperability to downstream
consumers, it 'could' be a path to take certdata.txt and have a tool that
can generate that 'other format' from certdata.txt.

The purpose of this thought experiment was to find what, if any,
limitations exist in certdata.txt. You've highlighted a very apt and
meaningful one, in theory - which is that EV data is a Mozilla Firefox (and
exclusively Firefox) concept, while trust records are an aspect of the root
store, hence, the dual expression between Mozilla Firefox source and NSS
source. If we wanted to make "EV" a portion of NSS (which makes no sense
for, say, Thunderbird), we could certainly express that - but it means
carrying around unneeded and unused attributes for other NSS consumers.


> > > Mozilla's opinions on roots are defined by the sum total of:
> > >
> > > 1) certdata.txt
> > > 2) ExtendedValidation.cpp
> > > 3) The changes listed on
> > > https://wiki.mozilla.org/CA/Additional_Trust_Changes
> >
> > 1 & 2 for sure. I don't believe #3 can or should be, certainly not
> effectively
> > maintained.
>
> I think Mozilla could and should try to. See my suggestion to use invented
> identifiers for describing each category of invented partial distrust.
>

I don't disagree we can - on a technical level. But I don't agree that the
ontology of invented partial distrust holds, nor is it terribly useful to
try to expect us to generalize distrust for the various ways in which CAs
fail the community. That said, even when thinking about the concepts, the
fact that the goal is presently woefully underspecified means we cannot
have a good objective discussion about why "Apply the WoSign policy" is
better or worse than a notion of "Distrust certificates after this date" -
or perhaps even a more complex policy, like "Distrust X certificates after
A date, Y certificates after B date, Z certificates after C date, unless
conditions M, N, O are also satisfied"
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

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

[Ben Wilson via dev-security-policy]

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 dev-security-policy
Sent: Monday, July 3, 2017 4:05 PM
To: Nick Lamb ;
mozilla-dev-security-pol...@lists.mozilla.org
Subject: 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 of
the usual trust paths, not defined in the standard RFCs, and not the same as
the mathematical expression.  Instead, you're substituting one signed object
with another.  I'd figure two-way cross-signed objects would be more akin to
transitive trust than this scenario. After all, they are substitute trust
anchors instead of here where one isn't intended for trust in Mozilla.  It'd
be more helpful to provide additional educational resources rather than
snide comments.  I'd rather understand how it works than argue about what it
means. 

Yes - we pass all policy without comment on to the Sub CA.  

-Original Message-
From: dev-security-policy
[mailto:dev-security-policy-bounces+jeremy.rowley=digicert.com@lists.mozilla
.org] On Behalf Of Nick Lamb via dev-security-policy
Sent: Monday, July 3, 2017 3:22 PM
To: mozilla-dev-security-pol...@lists.mozilla.org
Subject: 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 official report and potentially penalizing the Sub CA for
non-compliance.

You're asking for a "formal definition" of the word transitively. A word
which was in a policy you have previously accepted without comment, but NOW
you assert you aren't sure what it means. Transitivity is a normal concept
of mathematics and logic, its meaning here seems pretty transparent to me,
it's something we introduce (albeit not with trying to process cyclic
graphs) to secondary school children as part of their normal background in
arithmetic.

Was this policy, which you apparently didn't understand, passed without
comment to the affected Sub CA? Or did you figure that despite not
understanding what it meant you'd be able to somehow implement it?
___
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: DigiCert policy violation - non-disclosure of https://crt.sh/?id=160110886

[Jeremy Rowley via dev-security-policy]

"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 of
the usual trust paths, not defined in the standard RFCs, and not the same as
the mathematical expression.  Instead, you're substituting one signed object
with another.  I'd figure two-way cross-signed objects would be more akin to
transitive trust than this scenario. After all, they are substitute trust
anchors instead of here where one isn't intended for trust in Mozilla.  It'd
be more helpful to provide additional educational resources rather than
snide comments.  I'd rather understand how it works than argue about what it
means. 

Yes - we pass all policy without comment on to the Sub CA.  

-Original Message-
From: dev-security-policy
[mailto:dev-security-policy-bounces+jeremy.rowley=digicert.com@lists.mozilla
.org] On Behalf Of Nick Lamb via dev-security-policy
Sent: Monday, July 3, 2017 3:22 PM
To: mozilla-dev-security-pol...@lists.mozilla.org
Subject: 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 official report and potentially penalizing the Sub CA for
non-compliance.

You're asking for a "formal definition" of the word transitively. A word
which was in a policy you have previously accepted without comment, but NOW
you assert you aren't sure what it means. Transitivity is a normal concept
of mathematics and logic, its meaning here seems pretty transparent to me,
it's something we introduce (albeit not with trying to process cyclic
graphs) to secondary school children as part of their normal background in
arithmetic.

Was this policy, which you apparently didn't understand, passed without
comment to the affected Sub CA? Or did you figure that despite not
understanding what it meant you'd be able to somehow implement it?
___
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: DigiCert policy violation - non-disclosure of https://crt.sh/?id=160110886

[Nick Lamb via dev-security-policy]

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 official report and potentially penalizing the Sub CA for non-compliance.

You're asking for a "formal definition" of the word transitively. A word which 
was in a policy you have previously accepted without comment, but NOW you 
assert you aren't sure what it means. Transitivity is a normal concept of 
mathematics and logic, its meaning here seems pretty transparent to me, it's 
something we introduce (albeit not with trying to process cyclic graphs) to 
secondary school children as part of their normal background in arithmetic.

Was this policy, which you apparently didn't understand, passed without comment 
to the affected Sub CA? Or did you figure that despite not understanding what 
it meant you'd be able to somehow implement it?
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

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

[Jeremy Rowley via dev-security-policy]

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 non-compliance.

-Original Message-
From: Rob Stradling [mailto:rob.stradl...@comodo.com] 
Sent: Monday, July 3, 2017 2:14 PM
To: Jeremy Rowley ; 
mozilla-dev-security-pol...@lists.mozilla.org
Subject: 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 a collection of intermediate certs that Tavis 
Ormandy found (when "crawling the pkcs7 blobs in public pdf
files") that were not at the time known to any CT logs.  Most of those 
intermediates did not need to be disclosed to Mozilla.

https://crt.sh/?id=160110886 was not in Tavis's collection and has not AFAICT 
been previously discussed on this list.

> I don't agree this is a policy violation, and I doubt any CA not involved in 
> the previously mentioned thread would even register that Mozilla may be 
> requiring disclosure of self-signed CAs.

See this post (from another recent thread) in which Ryan Sleevi explained why 
it makes sense to require disclosure of self-signed CA certs (for which the 
subject public key also exists in one or more trusted cross-certificates):
https://www.mail-archive.com/dev-security-policy@lists.mozilla.org/msg07049.html

> The only disclosure requirement this root may fall under is the weird 
> "transitive" trust phrase in the policy. Note, this phrase is not defined in 
> 5280 or the Mozilla policy. Can you please link me to the definition in an 
> RFC? If there isn't one, until Mozilla clarifies what this means, the 
> definition of transitive trust is vague, meaning any third interpretation is 
> as good as the one you propose.

I think the meaning of "transitive" trust is actually quite simple.

A leaf cert (L) or intermediate cert (IC1) "transitively chains" to a root (R) 
if it is issued by an intermediate CA whose cert (IC2) chains to R.  The trust 
for L / IC1 is "transitive" because a relying party will only be able to verify 
that trust under certain circumstances - i.e., the RP needs to have been made 
aware of, and received a copy of, the IC2 cert.

If IC1 is issued directly by R, trust is "direct".  The RP is able to verify 
that trust under all circumstances, because R is built into the application / 
shipped with the trust store that the RP is using.

> Regardless, we will log the cert in the database pending resolution of the 
> dispute on what this means in the Mozilla policy to avoid the debate over 
> this particular root.
> 
> Jeremy
> 
> -Original Message-
> From: dev-security-policy 
> [mailto:dev-security-policy-bounces+jeremy.rowley=digicert.com@lists.m
> ozilla.org] On Behalf Of Rob Stradling via dev-security-policy
> Sent: Monday, July 3, 2017 5:32 AM
> To: mozilla-dev-security-pol...@lists.mozilla.org 
> 
> Subject: 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 are not technically constrained, and that directly or transitively chain 
> to a certificate included in Mozilla’s root program MUST be audited in 
> accordance with Mozilla’s Root Store Policy and MUST be publicly disclosed in 
> the CCADB by the CA that has their certificate included in Mozilla’s root 
> program. The CA with a certificate included in Mozilla’s root program MUST 
> disclose this information *within a week* of certificate creation, and before 
> any such subordinate CA is allowed to issue certificates."
> 
> It's a self-signed root certificate, but nonetheless there exists a signature 
> chain up to an included root and so disclosure is required.
> 
> 
> [1]
> https://www.mozilla.org/en-US/about/governance/policies/security-group
> /certs/policy/
> 
> 
> 
> ___
> dev-security-policy mailing list
> dev-security-policy@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy
> 

--
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online
Office Tel: +44.(0)1274.730505
Office Fax: +44.(0)1274.730909
www.comodo.com

COMODO CA Limited, Registered in England No. 04058690 Registered Office:
   3rd Floor, 26 Office 

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

[Rob Stradling via dev-security-policy]

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 a collection of intermediate certs 
that Tavis Ormandy found (when "crawling the pkcs7 blobs in public pdf 
files") that were not at the time known to any CT logs.  Most of those 
intermediates did not need to be disclosed to Mozilla.


https://crt.sh/?id=160110886 was not in Tavis's collection and has not 
AFAICT been previously discussed on this list.



I don't agree this is a policy violation, and I doubt any CA not involved in 
the previously mentioned thread would even register that Mozilla may be 
requiring disclosure of self-signed CAs.


See this post (from another recent thread) in which Ryan Sleevi 
explained why it makes sense to require disclosure of self-signed CA 
certs (for which the subject public key also exists in one or more 
trusted cross-certificates):

https://www.mail-archive.com/dev-security-policy@lists.mozilla.org/msg07049.html


The only disclosure requirement this root may fall under is the weird 
"transitive" trust phrase in the policy. Note, this phrase is not defined in 
5280 or the Mozilla policy. Can you please link me to the definition in an RFC? If there 
isn't one, until Mozilla clarifies what this means, the definition of transitive trust is 
vague, meaning any third interpretation is as good as the one you propose.


I think the meaning of "transitive" trust is actually quite simple.

A leaf cert (L) or intermediate cert (IC1) "transitively chains" to a 
root (R) if it is issued by an intermediate CA whose cert (IC2) chains 
to R.  The trust for L / IC1 is "transitive" because a relying party 
will only be able to verify that trust under certain circumstances - 
i.e., the RP needs to have been made aware of, and received a copy of, 
the IC2 cert.


If IC1 is issued directly by R, trust is "direct".  The RP is able to 
verify that trust under all circumstances, because R is built into the 
application / shipped with the trust store that the RP is using.



Regardless, we will log the cert in the database pending resolution of the 
dispute on what this means in the Mozilla policy to avoid the debate over this 
particular root.

Jeremy

-Original Message-
From: dev-security-policy 
[mailto:dev-security-policy-bounces+jeremy.rowley=digicert@lists.mozilla.org]
 On Behalf Of Rob Stradling via dev-security-policy
Sent: Monday, July 3, 2017 5:32 AM
To: mozilla-dev-security-pol...@lists.mozilla.org 

Subject: 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 are 
not technically constrained, and that directly or transitively chain to a certificate 
included in Mozilla’s root program MUST be audited in accordance with Mozilla’s Root 
Store Policy and MUST be publicly disclosed in the CCADB by the CA that has their 
certificate included in Mozilla’s root program. The CA with a certificate included in 
Mozilla’s root program MUST disclose this information *within a week* of certificate 
creation, and before any such subordinate CA is allowed to issue certificates."

It's a self-signed root certificate, but nonetheless there exists a signature 
chain up to an included root and so disclosure is required.


[1]
https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/



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



--
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online
Office Tel: +44.(0)1274.730505
Office Fax: +44.(0)1274.730909
www.comodo.com

COMODO CA Limited, Registered in England No. 04058690
Registered Office:
  3rd Floor, 26 Office Village, Exchange Quay,
  Trafford Road, Salford, Manchester M5 3EQ

This e-mail and any files transmitted with it are confidential and 
intended solely for the use of the individual or entity to whom they are 
addressed.  If you have received this email in error please notify the 
sender by replying to the e-mail containing this attachment. Replies to 
this email may be monitored by COMODO for operational or business 
reasons. Whilst every endeavour is taken to ensure that e-mails are free 
from viruses, no liability can be accepted and the recipient is 
requested to use their own virus checking software.

___
dev-security-policy mailing list

Re: SRVNames in name constraints

[Peter Bowen via dev-security-policy]

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 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
> Sent: Monday, July 3, 2017 10:30 AM
> To: mozilla-dev-security-pol...@lists.mozilla.org
> Subject: 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 Requirements
> (BRs), so I highly doubt any CA has issued a cross-certificate containing
> constraints on SRVName-type names.  Until the Forum allows such issuance, I
> think this requirement should be changed to remove SRVName from the list.
> If the Forum does allow such in the future, adding this back can be
> revisited at such time.
>
> Thanks,
> Peter
> ___
> dev-security-policy mailing list
> dev-security-policy@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

RE: SRVNames in name constraints

[Jeremy Rowley via dev-security-policy]

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 dev-security-policy
Sent: Monday, July 3, 2017 10:30 AM
To: mozilla-dev-security-pol...@lists.mozilla.org
Subject: 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 Requirements
(BRs), so I highly doubt any CA has issued a cross-certificate containing
constraints on SRVName-type names.  Until the Forum allows such issuance, I
think this requirement should be changed to remove SRVName from the list.
If the Forum does allow such in the future, adding this back can be
revisited at such time.

Thanks,
Peter
___
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: Symantec meeting and status

[Loshin, Peter via dev-security-policy]

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 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 its proposal for 
> implementing the consensus remediation plan, did Symantec provide any 
> other information about its progress?

Yes, they did. However, it seems unnecessary to document all that here, as the 
meat of what they told me should end up in their implementation proposal.

Due to my upcoming holiday starting just before their planned publication date, 
they may choose to share a not-final draft of the proposal with me privately, 
which I will comment on (if I have time) in a non-binding fashion. This is not 
to pre-judge the proposal, but to speed the process and try and make sure the 
proposal contains everything necessary to evaluate it. As always, we will be 
coming to our position in consultation with our community here.

> Did Symantec offer any other
> information that you are able to share? Any other information that you 
> are _not_ able to share?

Our general principle for such meetings, consistent with Mozilla's desire to 
run our root program in an open and transparent fashion, is that we will not 
promise confidentiality up front, although we will honour reasonable requests 
for it on a case-by-case basis. We treat all CAs and all meetings equally in 
this regard.

In this case, the only information Symantec gave me which we agreed not to 
reveal was the names of the particular companies they were considering as CA 
partners. No doubt their implementation plan will show who they eventually 
choose.

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

SRVNames in name constraints

[Peter Bowen via dev-security-policy]

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
Requirements (BRs), so I highly doubt any CA has issued a
cross-certificate containing constraints on SRVName-type names.  Until
the Forum allows such issuance, I think this requirement should be
changed to remove SRVName from the list.  If the Forum does allow such
in the future, adding this back can be revisited at such time.

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

Re: Symantec meeting and status

[Gervase Markham via dev-security-policy]

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 its proposal for
> implementing the consensus remediation plan, did Symantec provide any
> other information about its progress? 

Yes, they did. However, it seems unnecessary to document all that here,
as the meat of what they told me should end up in their implementation
proposal.

Due to my upcoming holiday starting just before their planned
publication date, they may choose to share a not-final draft of the
proposal with me privately, which I will comment on (if I have time) in
a non-binding fashion. This is not to pre-judge the proposal, but to
speed the process and try and make sure the proposal contains everything
necessary to evaluate it. As always, we will be coming to our position
in consultation with our community here.

> Did Symantec offer any other
> information that you are able to share? Any other information that
> you are _not_ able to share?

Our general principle for such meetings, consistent with Mozilla's
desire to run our root program in an open and transparent fashion, is
that we will not promise confidentiality up front, although we will
honour reasonable requests for it on a case-by-case basis. We treat all
CAs and all meetings equally in this regard.

In this case, the only information Symantec gave me which we agreed not
to reveal was the names of the particular companies they were
considering as CA partners. No doubt their implementation plan will show
who they eventually choose.

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

Symantec meeting and status

[Loshin, Peter via dev-security-policy]

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 provide any other information about 
its progress? Did Symantec offer any other information that you are able to 
share? Any other information that you are _not_ able to share?

Again, thank you for your work on improving browser security.

Best,
Peter


Peter Loshin
Site Editor, Security Media Group

Twitter: @PeterLoshin
+1 617/431-9819
TechTarget
Where Serious Technology Buyers Decide
http://www.techtarget.com

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

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

[Kai Engert via dev-security-policy]

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
> > in a modern CI

CI meaning Continuous Integration ?


> > tool that did "Oh, you changed file X. Let me regenerate
> > file Y and check it in alongside". Without really needing anyone's
> > permission beyond checkin access.

I'd prefer a bit more control. Any conversion script, which translates from a
new high level file format, to a specific technical file format used by our
software, could have bugs.

If everything is automated, there's more risk that changes might not get
reviewed, and bugs aren't identified.


> I don't believe the state of NSS infrastructure is well-placed to support that
> claim. I'd be curious for Kai's/Red Hat's feedback.

I'm not sure I correctly understand this sentence, but if you're asking if we
have such conversion magic, we don't.

There's the technicaly possibility of having commit hooks. But I'm not sure I
like that approach.


> > Well, I don't do the actual maintenance of certdata.txt, but I assume
> > (perhaps without evidence) that telling whoever does that "hey, you now
> > need to use this tool to edit the canonical information store, instead
> > of the text editor you have been using" might not go down well. It
> > wouldn't if it were me.
> 
> It already (effectively) requires a tool to make sure it's done right, AIUI :)
> 
> But I think you're still conflating "text" vs "human readable", and I'm not
> sure that they represent equivalents. That is, "human readable" introduces a
> subjective element that can easily lead to ratholes about whether or not
> something is "readable enough", or coming up with sufficient ontologies so
> that it can "logically map" - just look at XML for the case study in this.
> 
> You can have a JSON file, but that doesn't mean it's human-readable in the
> least.
> 
> That's why I'm pushing very hard on that.

I wouldn't call our existing certdata.txt format easily human readable either.
It's only human readable because our tool, which produces new entries, also adds
human readable comments. It would be very difficult to notice if the text
differes from the binary presentation (unless you write and execute a
verification script that ensures everything matches). We currently achieve the
matching (hopefully) by carefully reviewing changes.

I would discourage a few things when introducing a JSON file format, like, avoid
unnecessary changes in line wrapping or reordering, to make it easier to compare
different revisions.


> > No, because NSS consumers could choose to continue consuming the
> > (autogenerated by the CI tool) certdata.txt.
> 
> The CI tools don't check in artifacts.

What does artifact mean in this context?


> You're proposing giving some piece of infrastructure the access to generate
> and check in files? I believe Mozilla may do that, but NSS does not, and the
> infrastructure is separately maintained.
> 
> > You want me to rank my goals in order of preference? :-)
> 
> Moreso be more explicit in the goals. It's trying to figure out how 'much'
> interoperability is being targeted here :)
> 
> > If Apple said "we are happy to use the MS format", I guess the next
> > thing I would do is find Kai or whoever maintains certdata.txt and say
> > "hey, it's not ideal, but what do you think, for the sake of everyone
> > using the same thing?".
> 
> Thought experiment: Why not have certdata.txt generate a CI artifact that
> interoperates for other consumers to use?

Are you suggesting that we should convert certdata.txt into a file format that
others would prefer to consume?

Yes, that's another option.

But it wouldn't solve the idea to also store the Mozilla EV attributes in the
common place. Firefox developers would have to start converting information
found inside NSS to Firefox application code.


> Which is all still a facet of the original question: Trying to determine what
> your goals are / what the 'necessary' vs 'nice to have' features are :)
> 
> > It's not a massive improvement if we are the only group using it. I
> > think there is value to Mozilla even if MS and Apple don't get on board,
> > because our root store gets more descriptive of reality, but that value
> > alone might not be enough to convince someone like the two people who
> > have expressed interest thusfar to take the time to work on the spec. I
> > don't know.
> 
> But why doesn't certdata.txt meet that already, then? It's a useful thought
> experiment to find out what you see the delta as, so that we can understand
> what are and are not acceptable solutions.
> 
> > Mozilla's opinions on roots are defined by the sum total of:
> > 
> > 1) certdata.txt
> > 2) ExtendedValidation.cpp
> > 3) The changes listed on
> > 

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

[Jeremy Rowley via dev-security-policy]

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 mentioned thread would even register that Mozilla may be 
requiring disclosure of self-signed CAs.  The only disclosure requirement this 
root may fall under is the weird "transitive" trust phrase in the policy. Note, 
this phrase is not defined in 5280 or the Mozilla policy. Can you please link 
me to the definition in an RFC? If there isn't one, until Mozilla clarifies 
what this means, the definition of transitive trust is vague, meaning any third 
interpretation is as good as the one you propose.  

Regardless, we will log the cert in the database pending resolution of the 
dispute on what this means in the Mozilla policy to avoid the debate over this 
particular root. 

Jeremy

-Original Message-
From: dev-security-policy 
[mailto:dev-security-policy-bounces+jeremy.rowley=digicert@lists.mozilla.org]
 On Behalf Of Rob Stradling via dev-security-policy
Sent: Monday, July 3, 2017 5:32 AM
To: mozilla-dev-security-pol...@lists.mozilla.org 

Subject: 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 are not technically constrained, and that directly or transitively chain 
to a certificate included in Mozilla’s root program MUST be audited in 
accordance with Mozilla’s Root Store Policy and MUST be publicly disclosed in 
the CCADB by the CA that has their certificate included in Mozilla’s root 
program. The CA with a certificate included in Mozilla’s root program MUST 
disclose this information *within a week* of certificate creation, and before 
any such subordinate CA is allowed to issue certificates."

It's a self-signed root certificate, but nonetheless there exists a signature 
chain up to an included root and so disclosure is required.


[1] 
https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/

-- 
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online
___
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: Machine- and human-readable format for root store information?

[Kai Engert via dev-security-policy]

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 a format of arbitrary
> complexity.

I agree the complexity shouldn't be part of the format. It might be sufficient
to have an identifier for the type of restriction, which is described elsewhere,
plus a flexible list of {name,value} pairs for parameters.


> > Regarding the question how we create new entries for certdata.txt today, we
> > currently use the NSS tool "addbuiltin". It takes a certificate as input,
> > and
> > can create both positive trust or distrust lines in the current file format,
> > that we simply appended to the certdata.txt file.
> 
> Ah, OK. So you would not be against the idea of using a tool to maintain
> the list in the future?

Do you have a particular kind of tool in mind?

I'd prefer a simple open source tool that operates on files, which can be used
from a command line, with a free license, e.g. MPL2.


> > Regarding which file format should be used for the new master trust list.
> > Unless
> > we want to change the way how NSS works, it will probably be helpful to
> > continue
> > to use the certdata.txt file format, even if it's just used as an
> > intermediate
> > in a double conversion.
> 
> I certainly think we should continue to maintain the store in that
> format. The question is whether that format is the canonical format, or
> a derivative format. My feeling was that if we want to be able to add
> these new forms of restriction, EV status and so on, we should define a
> new format. Ryan seems to think we may be able to do this within the
> existing certdata.txt format.

I don't have a strong preference.

I agree that it should be possible to extend the existing certdata.txt file
format. For meta level items that NSS cannot consume yet, we could define new
identifiers that NSS ignores (or might potentially process at a later time).

However, the certdata.txt file format was built specifically around the needs of
NSS, and we currently have the flexibility to change it in any way we want to.
Also it's based on the idea that the file elements will rather directly
converted into PKCS#11 objects. Other root stores might not use PKCS#11 to store
their list of root CAs at all.

If the intention is to define a file format that is shared with other groups,
who would be the owner of the file format? What if another group needs to
introduce additional fields into the file format, that aren't of interest to
Mozilla or NSS?

Having a more abstract file format could give anyone more flexibility to add
more information, that don't need to be coordinated with others prior to adding
them, and allows consumers to ignore the fields they aren't interested in.

For example, some root store maintainer might invent the golden circle of CA
vouching, which everyone else considers questionable. It might require to store
a flexible list of vouchers for each CA. With JSON it would be trivial to add
another arbitrary length list for that. 

So, if the intention is to have a shared file format that everyone can accept,
today and in the future, a more flexible file format seems more appropriate to
me.


> > Instead of requiring everything to be a single file, maybe it could even
> > work to
> > use an archive file (e.g. zip), that contains all information in easily
> > consumable pieces, which would make it unnecessary to serialize and
> > deserialize
> > the certificates while working with the list, and allows maintainers to use
> > tools that work with the certificates directly.
> 
> I think that runs the greater risk of people creating systems which just
> trust every certificate in the bundle...

There could be ways to avoid that, for example by using subdirectories, named
like:
- trusted-for-ssl-tls-only
- partially-trusted-for-ssl-tls-only
- trusted-for-email-security-only
- partially-trusted-for-email-security-only
- trusted-for-multiple-uses
- partially-trusted-for-multiple-uses
- distrusted

This is just a thought. If there's too much doubt, I don't mind to stay with the
concept of having a single file that contains serializations of all attributes.


> > With this approach, we could also declare that the master location for this
> > trust list is somewhere outside of NSS (in a separate repository). If we did
> > that, the primary location could simply be its own HG/GIT repository, with
> > all
> > the individual files. Releases of Mozilla trust list could be an archive
> > file
> > that gets published with a checksum file/signature.
> 
> We could do this with any approach. Are you interested in the idea of
> making the trust list an independently-maintained item, which is just
> pulled into NSS each time an NSS release is done?

Yes, I had previously suggested this here:
  

Symantec meeting and status

[Gervase Markham via dev-security-policy]

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 (Head of Engineering for Website Security)
* Roxane DeVol (General Manager of Website Security)
* Hugh Thomson (CTO of Symantec Corporate)
* Michael Klieman (VP Product Management of Website Security)

Symantec asked for the meeting to update us on their progress in finding
a CA partner or partners to work with them in implementing the consensus
remediation plan, which as you will know involves them passing off
issuance to a third party while they stand up a new PKI on new,
best-practice infrastructure.

We expect Symantec, at the end of this week or early next week, to
publish a document giving their proposal for how they will implement the
plan, including a set of milestone dates with justification for how they
are reached. They will also give some indications of ways the plan might
be modified to alter the dates - e.g. "if we do X instead of Y, we can
do it N weeks faster". After that, we need to get agreement by all the
parties to form of the final plan and some attached dates, and then
Symantec can sign contracts and start executing the plan. We hope to
reach this agreement swiftly.

However, the fly in the ointment is that I am going on holiday for 3
weeks from Friday. I am working occasional days during that time, but I
will be relying on members of this group to be analysing and considering
Symantec's proposal.

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

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

[Gervase Markham via dev-security-policy]

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 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 a format of arbitrary
complexity.

> It would be good if the new format made it very clear that there are distrust
> entries, and that trust for some CAs is only partial. The latter could make it
> easier for list consumers to identify the partially restricted CA. E.g. some
> might decide to rather not trust a restricted CA at all, if the consumer is
> technically unable to implement the restricting checks.

Yes, indeed.

> Regarding the question how we create new entries for certdata.txt today, we
> currently use the NSS tool "addbuiltin". It takes a certificate as input, and
> can create both positive trust or distrust lines in the current file format,
> that we simply appended to the certdata.txt file.

Ah, OK. So you would not be against the idea of using a tool to maintain
the list in the future?

> Regarding which file format should be used for the new master trust list. 
> Unless
> we want to change the way how NSS works, it will probably be helpful to 
> continue
> to use the certdata.txt file format, even if it's just used as an intermediate
> in a double conversion.

I certainly think we should continue to maintain the store in that
format. The question is whether that format is the canonical format, or
a derivative format. My feeling was that if we want to be able to add
these new forms of restriction, EV status and so on, we should define a
new format. Ryan seems to think we may be able to do this within the
existing certdata.txt format.

> Instead of requiring everything to be a single file, maybe it could even work 
> to
> use an archive file (e.g. zip), that contains all information in easily
> consumable pieces, which would make it unnecessary to serialize and 
> deserialize
> the certificates while working with the list, and allows maintainers to use
> tools that work with the certificates directly.

I think that runs the greater risk of people creating systems which just
trust every certificate in the bundle...

> With this approach, we could also declare that the master location for this
> trust list is somewhere outside of NSS (in a separate repository). If we did
> that, the primary location could simply be its own HG/GIT repository, with all
> the individual files. Releases of Mozilla trust list could be an archive file
> that gets published with a checksum file/signature.

We could do this with any approach. Are you interested in the idea of
making the trust list an independently-maintained item, which is just
pulled into NSS each time an NSS release is done?

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

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

[Rob Stradling via dev-security-policy]

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 are not technically constrained, and that directly or 
transitively chain to a certificate included in Mozilla’s root program 
MUST be audited in accordance with Mozilla’s Root Store Policy and MUST 
be publicly disclosed in the CCADB by the CA that has their certificate 
included in Mozilla’s root program. The CA with a certificate included 
in Mozilla’s root program MUST disclose this information *within a week* 
of certificate creation, and before any such subordinate CA is allowed 
to issue certificates."


It's a self-signed root certificate, but nonetheless there exists a 
signature chain up to an included root and so disclosure is required.



[1] 
https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/


--
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy