Re: Mozilla Policy and CCADB Disclosure scope

[Matthew Hardeman via dev-security-policy]

Thanks, Nick, for the comment on the scope difference in the dnsName 
constraints vs. SAN wildcard.  I hadn't contemplated that.  As you note, the 
real risk isn't dissimilar.  (I would presume that this is because a CA willing 
to issue a SAN dnsName of *.example.com would also presumably issue a SAN 
dnsName of *.research.example.com.)

Having given further consideration to potential exposures and risks of 
certificates issued downline of the name constrained intermediate, I did come 
up with one metric in which the risk profile _could_ be different versus a 
wildcard EE cert: the wildcard EE certs issued by a CA in the normal course of 
business must comply with the BRs pertaining to length of validity of 
validation information and maximum length of validity period of EE certificate 
life (and, of course, with the rest of the BRs).  It's not clear that such a 
standard or requirement would presently apply to a name constrained technically 
constrained intermediate certificate.

Perhaps it makes sense to only accord preferential treatment of name + eku 
constrained intermediates which are also constrained to limited period of 
validity.  Perhaps that constraint should mirror or only slightly exceed the 
limits on EE certs.

Out of curiosity, I checked crt.sh's CA certificates disclosure report to see 
if I could find an in-the-wild name constrained intermediate that I think 
largely reflects the overall attributes/constraints which might allow for 
preferential treatment, and found one for Southern Company (an energy & telecom 
company in the southeast USA).  The intermediate certificate in question is at: 
 https://crt.sh/?id=11501550

Southern Company seems to use this certificate to issue some of the EE 
certificates on some of their public facing websites.  https://southernlinc.com 
features a leaf certificate issued from this technically constrained 
intermediate.

Features, in particular, that I think may allow for preferential treatment of 
these intermediates, as demonstrated in the crt.sh linked intermediate above, 
include:

1.  Pathlen constraint in this example was 0, but I would presume a pathlen 1 
for policy CAs to allow for separate internal intermediates might be allowable 
too.  Not sure if allowing that adds a further risk exposure or not?  The 
effective eku applied to the EE certificate is the most restrictive eku of the 
certificates in the chain including the leaf certificate, right?  (Thus, 
declaring the further intermediate to have lesser / different name constraints 
or extra eku permissions would not be effective, correct?)
2.  The eku values here are constrained to TLS Server Auth, TLS Client Auth, 
Email Protection, and OCSP signing
3.  As email protection eku is selected, at least one permitted rfc822 name 
constraint exists.  Here, there are actually two: .sourthernco.com and 
southernco.com (presumably to allow issuance of email certs covering anything 
in the southernco.com namespace.
4.  As TLS server auth eku is present, name constraint exclusions for the whole 
IPv4 and IPv6 IP space are present.  Additionally, a number of permitted 
dnsName constraints are provided, listing out domains over which the validated 
organization has control.

In contemplating the risk of such intermediates spefically to the Web PKI, the 
only risks that I can presently imagine to exceed that of wildcard EE 
certificates thus pertain to validity period.  The example certificate I found 
has a 5 year validity period.

It seems to me, however, that while I am aware that one could cause the 
constrained intermediate to sign a certificate which is NOT baseline 
requirements compliant, modern Web PKI software would not honor this.  With the 
exception of that caveat, it would appear that proper name constraints, 
validity period, ekus, and path length constraints can combine to effectively 
force subordinate leaf certificates into alignment with the baseline 
requirements.  Thus, it would seem that disclosure of certificates descending 
from such intermediates is likely unnecessary.

As long as the validation and issuance of such constrained intermediates is 
watched by an externally audit-able mechanism like CT, I don't think these 
intermediates themselves would need specific disclosure in CCADB.

Thanks,

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

Re: Mozilla Policy and CCADB Disclosure scope

[Nick Lamb via dev-security-policy]

On Friday, 19 May 2017 20:41:20 UTC+1, Matthew Hardeman  wrote:
> From a perspective of risk to the broader web PKI, it would appear that a 
> properly name constrained intermediate with (for example)  only the Server 
> and Client TLS authentication ekus with name constraints limited to 
> particular validated domains (via dnsName constraint along with excluding 
> wildcard IP/netmask for IPv4 and IPv6)  is really no substantively more risky 
> than a multi-SAN wildcard certificate with the same domains.

Unlike a wildcard, the constrained intermediate impacts all names under that 
tree. For example a certificate for *.example.com definitely isn't valid for 
mail.research.example.com, www.research.example.com etc. whereas a constrained 
intermediate for example.com _is_ able to issue for those names.

But yes, overall Matt's approach makes sense to me, lightweight disclosure such 
as via CT logging of such intermediates is appropriate from what I can see. 
Issuance _of_ the intermediates needs to have good oversight, but we don't need 
to freak out about the issuance _from_ them too much. If they're badly run they 
will join in that a huge number of poorly looked after end entity certificates, 
and have not dissimilar risk, narrowed to just the affected subject domain(s).
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Google Plan for Symantec posted

[Kurt Roeckx via dev-security-policy]

On Fri, May 19, 2017 at 01:04:45PM -0700, Kathleen Wilson via 
dev-security-policy wrote:
> 
> Gerv, thank you for all the effort you have been putting into this 
> investigation into Symantec's mis-issuances, and in identifying the best way 
> to move forward with the primary goal being to help keep end-users safe.
> 
> I fully support requiring Symantec to set up a new PKI on new infrastructure, 
> and to transition to it in phases, in order to minimize the impact and reduce
> the risk for end-users.
> 
> I think the general direction is correct, but I think there are a few details 
> to be ironed out, such as:
> 
> - What validity periods should be allowed for SSL certs being issued in the 
> old PKI (until the new PKI is ready)? I prefer that this be on the order of 
> 13 months, and not on the order of 3 years, so that we can hope to distrust 
> the old PKI as soon as possible. I prefer to not have to wait 3 years to stop 
> trusting the old PKI for SSL, because a bunch of 3-year SSL certs get issued 
> this year.

So I think we have a few categories of certificates:
- Those issued in the past, which can still be valid for up to 3
  years. I'm not sure when the last 5 year certificates are
  supposed to expire, or if they all expired, but I don't think
  those take long to expire.
- Those that still get issued before they move to some new PKI.

If you want to distrust their existing roots before those
certificates expire, this will most likely results in at least
some people having problems. And that it would be up to Symantec
to make sure those people get new certificates and started using
them.

>From the mail about Chrome's plan, I understand that Chrome's plan
is to only allow certificates from the old PKI if they qualify for
their CT requirements. They plan to only allow certificates issued
after 2016-06-01 because that's the date when they required CT
from Symantec. It seems that Symantec can still issue new certificates
using the old PKI up to 2017-08-08 that are still valid for 3
years.

I'm a little concerned that Firefox and Chrome will have different
certificates they don't trust, and would hope that you can come to
some agreement about when which one would get distrusted.

> - Perhaps the new PKI should only be cross-signed by a particular 
> intermediate cert of a particular root cert, so that we can begin to distrust 
> the rest of the old PKI as soon as possible.

I'm not really sure what you're saying here. If the new PKI is
signed by an other CA, does it matter if it's signed by their
root CA or some (dedicated) intermediate? I don't see how that
relates to distruting the old PKI.

I have a problem with one CA signing an other unrelated CA. I
would prefer that we have a policy that forbids that, and that the
CA should make sure it's own root gets added to the root store.
The only reason I can see for cross signing is for people that still
using an old root store.

> - I'm not sold on the idea of requiring Symantec to use third-party CAs to 
> perform validation/issuance on Symantec's behalf. The most serious concerns 
> that I have with Symantec's old PKI is with their third-party subCAs and 
> third-party RAs. I don't have particular concern about Symantec doing the 
> validation/issuance in-house. So, I think it would be better/safer for 
> Symantec to staff up to do the validation/re-validation in-house rather than 
> using third parties. If the concern is about regaining trust, then add 
> auditing to this.

So they should just create new root CAs and ask them to be
included in the root store?


Kurt

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

Re: Google Plan for Symantec posted

[Rob Stradling via dev-security-policy]

On 19/05/17 21:04, Kathleen Wilson via dev-security-policy wrote:


Hi Kathleen.  I'm not quite sure how to interpret this part...


- I'm not sold on the idea of requiring Symantec to use third-party CAs to 
perform validation/issuance on Symantec's behalf. The most serious concerns 
that I have with Symantec's old PKI is with their third-party subCAs and 
third-party RAs. I don't have particular concern about Symantec doing the 
validation/issuance in-house. So, I think it would be better/safer for Symantec 
to staff up to do the validation/re-validation in-house rather than using third 
parties. If the concern is about regaining trust, then add auditing to this.


Are you saying that Symantec would be a Delegated Third Party that can 
perform all of the validation and can trigger certificate issuance, but 
that it would actually be a third-party CA that handles the new Symantec 
PKI and issues certs (when triggered to do so by Symantec)?


Or, are you saying that Symantec would be permitted to operate their new 
PKI in-house from day 1?


--
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

Re: Google Plan for Symantec posted

[Jakob Bohm via dev-security-policy]

On 19/05/2017 17:41, Gervase Markham wrote:

Hi m.d.s.p.,

Google have posted their updated plan for Symantec in the blink-dev
forum (copied below).
https://groups.google.com/a/chromium.org/d/msg/blink-dev/eUAKwjihhBs/ovLalSBRBQAJ

Insofar as it pertains to Google's actions, you should go over and
discuss it there. But of course, this plan has significant overlap with
Mozilla's draft proposal here:
https://docs.google.com/document/d/1RhDcwbMeqgE2Cb5e6xaPq-lUPmatQZwx3Sn2NPz9jF8/edit#

I have passed that document to Kathleen, and I hope she will be
endorsing this general direction soon, at which point it will no longer
be a draft.

Assuming she does, this will effectively turn into a 3-way conversation
between Symantec, Google and Mozilla, to iron out the details of what's
required, with the Google proposal as a base. (Which I'm fine with as a
starting point.)

Comments are therefore invited on what modifications to the plan or
additional requirements Mozilla might want to suggest/impose, and
(importantly) why those suggestions/impositions are necessary and
proportionate.

Gerv


 Forwarded Message 
Subject:Re: [blink-dev] Intent to Deprecate and Remove: Trust in
existing Symantec-issued Certificates
Date:   Fri, 19 May 2017 10:27:41 -0400
From:   Ryan Sleevi 
Reply-To:   rsle...@chromium.org
To: blink-dev 
CC: Ryan Sleevi , awhal...@chromium.org

...



The following was written prior to seeing Kathleen's post, so it does
not consider her reservations with some key parts of the
Google/Symantec plan.  However it is mostly independent anyway, as it
is about how to extend the WebPKI considerations to other PKI areas
that affect Mozilla and/or the community.

Suggested trivial changes relative to the proposal for Mozilla use:

1. Replace or supplement every occurrence of "Google" by "Mozilla".

2. Replace or supplement every occurrence of "Chrome" by "Firefox,
Thunderbird and other Mozilla products".  State that the references to
non-Mozilla root stores does not apply to Mozilla.

Suggested reasonable changes based on my guesses at what would benefit
Mozilla Foundation and Mozilla Inc directly or as champions of the
relying parties community at large:

3. All non-expired Symantec issued certificates of any kind (including
SubCAs and revoked certificates) shall be CT logged as modified by #4
below.  All Symantec referenced OCSP responders shall return SCTs for
all such certificates, if possible even for revoked certificates.  This
also applies to expired certificates that were intended for use with
validity extending timestamping, such as the code signing certificate
issued to Mozilla Corporation with serial number 25 cc 37 35 e9 ec 1f
c9 71 67 0e 73 e3 69 c7 91.  Independent parties or root stores may at
their option use this data to generate public trust whitelists.

  Necessity: Whitelists in various forms based on such CT log entries,
as well as the SCTs in OCSP responses can provide an alternative for
relying parties checking current certificates even if the cleanup at
Symantec reveals a catastrophic breach during the past 20+ years.

  Proportionality: This should be relatively easy for the legitimate
certificates issued by Symantec, since the underlying data is still
used for OCSP response generation.

4. All stated requirements shall also apply to S/MIME certificates.
Except that CT logging shall be redacted as follows: Symantec shall
instead submit to at least two independent CT logs who accept that,
S/MIME TBScertificates with the CN, L, street, serialnumber and mailbox
parts, as well as the first 160 bits of any first randomNonce (PKCS#7)
extended attribute each replaced by the "filename safe" base64 SHA-384
hash of the unredacted TBScertificate, and shall embed SCTs in such
certificates just as for ServerAuth certificates.  This crude one-off
form of redaction should allow full checking while not revealing spam
friendly e-mail addresses or physical locations of individual persons.
The same redaction shall be applied to other non-ServerAuth
certificates issued to named single natural persons whether in a
personal or professional capacity.  The distinction between natural
persons (such as "J.Postel") and role names such as "IANA", shall be
based on the original validation data.

For certificates issued (NotBefore) without SCTs prior to
2017-07-01T00:00:00 UTC, the SHA-384 value shall be replaced by the
HMAC-SHA384 using SHA384(certificate signature) as key.

For example, a redacted TBScertificate could be for
CN=ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789-_,
email=ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789-
_...@example.com,O=The Example Corporation,
street=ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789-_,
L=ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789-_,ST=California,C=US
nonce=ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789-
_\321\234\345\267 (192 bits nonce in cert, first 160 

Re: Google Plan for Symantec posted

[Jakob Bohm via dev-security-policy]

On 19/05/2017 22:04, Kathleen Wilson wrote:

On Friday, May 19, 2017 at 8:42:40 AM UTC-7, Gervase Markham wrote:


I have passed that document to Kathleen, and I hope she will be
endorsing this general direction soon, at which point it will no longer
be a draft.

Assuming she does, this will effectively turn into a 3-way conversation
between Symantec, Google and Mozilla, to iron out the details of what's
required, with the Google proposal as a base. (Which I'm fine with as a
starting point.)

Comments are therefore invited on what modifications to the plan or
additional requirements Mozilla might want to suggest/impose, and
(importantly) why those suggestions/impositions are necessary and
proportionate.




Gerv, thank you for all the effort you have been putting into this 
investigation into Symantec's mis-issuances, and in identifying the best way to 
move forward with the primary goal being to help keep end-users safe.

I fully support requiring Symantec to set up a new PKI on new infrastructure, 
and to transition to it in phases, in order to minimize the impact and reduce
the risk for end-users.

I think the general direction is correct, but I think there are a few details 
to be ironed out, such as:

- What validity periods should be allowed for SSL certs being issued in the old 
PKI (until the new PKI is ready)? I prefer that this be on the order of 13 
months, and not on the order of 3 years, so that we can hope to distrust the 
old PKI as soon as possible. I prefer to not have to wait 3 years to stop 
trusting the old PKI for SSL, because a bunch of 3-year SSL certs get issued 
this year.



I think this can be solved by having either the new Symantec PKI (if
trusted) or some other trusted CA cross sign the Managed SubCA, then
including that cross cert in the P11 object in Mozilla products.

This would disconnect the new certs (even if they have 35 months left)
from the old Symantec PKI for any client that includes the cross certs
in its standard store, allowing the old CA certs to be removed in the
very same release (unless of cause there are pre-transition certs that
should still be trusted).


- Perhaps the new PKI should only be cross-signed by a particular intermediate 
cert of a particular root cert, so that we can begin to distrust the rest of 
the old PKI as soon as possible.



Again, the idea would be that once the new PKI cross signs the
transitional managed SubCAs, root stores can ship the new root CAs and
the new cross certs for the SubCAs while instantly distrusting the old
PKI.  In other words the Managed/transitional SubCAs would serve the
role of your proposed "particular intermediate cert".



- I'm not sold on the idea of requiring Symantec to use third-party CAs to 
perform validation/issuance on Symantec's behalf. The most serious concerns 
that I have with Symantec's old PKI is with their third-party subCAs and 
third-party RAs. I don't have particular concern about Symantec doing the 
validation/issuance in-house. So, I think it would be better/safer for Symantec 
to staff up to do the validation/re-validation in-house rather than using third 
parties. If the concern is about regaining trust, then add auditing to this.



That seems to be a matter of debate.  I have been arguing the same
point without success.



Enjoy

Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S.  https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark.  Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: DRAFT: Notice to CAs about CCADB changes May 19-21

[Kathleen Wilson via dev-security-policy]

On Thursday, May 18, 2017 at 10:08:32 AM UTC-7, Kathleen Wilson wrote:
> 
> On May 19 the following three breaking changes are planned, meaning that the 
> old URLs will no longer work. Any links or bookmarks to these URLs will need 
> to be updated. ...
> 
> 1) The CA login page and the domain CAs see when they are logged into the 
> CCADB will change.
> https://mozillacacommunity.force.com/
> will be changed to
> https://ccadb.force.com/
> 
> 2) The links to reports that are published directly from the CCADB will 
> change.
> https://mozillacaprogram.secure.force.com/CA/
> will be changed to
> https://ccadb-public.secure.force.com/mozilla/
> 
> 3) The links to CA communication responses that are published directly from 
> the CCADB will change.
> https://mozillacaprogram.secure.force.com/Communications
> will be changed to
> https://ccadb-public.secure.force.com/mozillacommunications
> 

These changes have happened, and I have updated the wiki pages with the correct 
links:
https://wiki.mozilla.org/CA:CommonCADatabase
https://wiki.mozilla.org/CA/Intermediate_Certificates
https://wiki.mozilla.org/CA/Communications

Kathleen


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

Re: Google Plan for Symantec posted

[Kathleen Wilson via dev-security-policy]

On Friday, May 19, 2017 at 8:42:40 AM UTC-7, Gervase Markham wrote:
> 
> I have passed that document to Kathleen, and I hope she will be
> endorsing this general direction soon, at which point it will no longer
> be a draft.
> 
> Assuming she does, this will effectively turn into a 3-way conversation
> between Symantec, Google and Mozilla, to iron out the details of what's
> required, with the Google proposal as a base. (Which I'm fine with as a
> starting point.)
> 
> Comments are therefore invited on what modifications to the plan or
> additional requirements Mozilla might want to suggest/impose, and
> (importantly) why those suggestions/impositions are necessary and
> proportionate.
> 


Gerv, thank you for all the effort you have been putting into this 
investigation into Symantec's mis-issuances, and in identifying the best way to 
move forward with the primary goal being to help keep end-users safe.

I fully support requiring Symantec to set up a new PKI on new infrastructure, 
and to transition to it in phases, in order to minimize the impact and reduce
the risk for end-users.

I think the general direction is correct, but I think there are a few details 
to be ironed out, such as:

- What validity periods should be allowed for SSL certs being issued in the old 
PKI (until the new PKI is ready)? I prefer that this be on the order of 13 
months, and not on the order of 3 years, so that we can hope to distrust the 
old PKI as soon as possible. I prefer to not have to wait 3 years to stop 
trusting the old PKI for SSL, because a bunch of 3-year SSL certs get issued 
this year.

- Perhaps the new PKI should only be cross-signed by a particular intermediate 
cert of a particular root cert, so that we can begin to distrust the rest of 
the old PKI as soon as possible.

- I'm not sold on the idea of requiring Symantec to use third-party CAs to 
perform validation/issuance on Symantec's behalf. The most serious concerns 
that I have with Symantec's old PKI is with their third-party subCAs and 
third-party RAs. I don't have particular concern about Symantec doing the 
validation/issuance in-house. So, I think it would be better/safer for Symantec 
to staff up to do the validation/re-validation in-house rather than using third 
parties. If the concern is about regaining trust, then add auditing to this.

Thanks,
Kathleen


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

Re: Mozilla Policy and CCADB Disclosure scope

[Matthew Hardeman via dev-security-policy]

Not speaking as to the status quo, but rather in terms of updates/changes which 
might be considered for incorporation into policy would be to recognize the 
benefit of name constrained intermediates and allow a reduction in burden to 
entities holding and utilizing name constrained intermediates, both in SSL 
Server Authentication, and Email Protection.  (Probably also allow that OCSP 
signing, client authentication, certain encrypted storage extended key usages, 
etc, be allowed).

>From a perspective of risk to the broader web PKI, it would appear that a 
>properly name constrained intermediate with (for example)  only the Server and 
>Client TLS authentication ekus with name constraints limited to particular 
>validated domains (via dnsName constraint along with excluding wildcard 
>IP/netmask for IPv4 and IPv6)  is really no substantively more risky than a 
>multi-SAN wildcard certificate with the same domains.  Indeed, in the kind of 
>enterprise environment where such an intermediate might be used, it is quite 
>possible that the one intermediate certificate in an enterprise CA  may result 
>in fewer wildcard certificates being distributed within that organization.  
>(Electing instead to dynamically generate system and purpose-specific 
>certificates internally without further direct external issuance cost for the 
>organization).

Similarly name constraints for email protection and client auth certificates 
within limited domain trees could be useful for S/MIME and login certs.

If I am not gravely mistaken with respect to the overall risk to the ecosystem, 
it would seem that clear rules encouraging issuance of such intermediates in 
lieu of other mechanisms which require close observation of the eventual 
signatures issued by the intermediate (Can we really say we trust that a CA cut 
for an enterprise customer is being held by a trusted CA in their 
infrastructure and constrained as to EE certificate contents by systems and 
rules at said CA can really be trusted?  Even if the CA says that's how it is?)

I would propose, for example, that the intermediate certificate itself and the 
process which led to its issuance is fully part of the scope of the program and 
requirements.  The validation data to be authenticated and preserved by the CA, 
etc.  With respect to the running of the technically constrained CA, is it 
possible to reward the narrow technical constraints with a hands-off approach 
to the use of the intermediate in issuing down-line certificates, especially 
end-entity certificates?  For example, no requirement of audit by the 
enterprise holding the technically constrained intermediate, and no requirement 
for audit or disclosure of certificates issued by the enterprise from that 
technically constrained intermediate.

In short, a compromise of the technically constrained intermediate has quite 
limited scope of harm and generally impacts only matters for which the 
enterprise that lost control of the technically constrained intermediate is at 
least one of the parties to any transaction.  (For example, a bank losing 
control of a trusted but technically constrained intermediate might cause an 
outside customer to believe that they're at the bank's website, but even while 
the outside customer is a victim the bank is also the victim in this 
circumstance.)  In reality, the loss of a wildcard certificate with the same 
domain(s) is just as damning for the same bank.  The difference is that it is 
highly probably that a wildcard certificate with those domains will be 
installed in multiple systems, and far less likely that the technically 
constrained intermediate certificate will be.

In short, as an enterprise customer, managing an in-house PKI infrastructure 
with external CA costs controlled at the price of issuance of a technically 
constrained intermediate versus buying hundreds of specific endpoint 
certificates may be attractive to a category of enterprises with complex needs 
for shared internal/external trust paths for certificates for certain systems 
and may encourage better deployment practice by cost optimization.

In an ideal world, if (and only if) the integrity of the Web PKI is not 
compromised by taking a freer hand with technically constrained intermediates 
of limited scope, it is my belief that overall security and adoption of good 
practice might be improved by reducing the compliance burdens upon enterprises 
that would utilize such a constrained intermediate.  If this is so, providing 
clear rules for the standards and issuance of these certificates may create a 
marketplace for a relatively new and unknown product (technically constrained 
CAs that are standardized to the point that they're on the price list just like 
an SSL cert is)  to enter the market on more competitive terms.  Perhaps a 
product for which various CAs can offer greater differentiation and value 
models.

I think the right compromise might be to treat the intermediate as in-scope for 
th

RE: [EXT] Google Plan for Symantec posted

[Steve Medin via dev-security-policy]

> -Original Message-
> From: dev-security-policy [mailto:dev-security-policy-
> bounces+steve_medin=symantec@lists.mozilla.org] On Behalf Of
> Gervase Markham via dev-security-policy
> Sent: Friday, May 19, 2017 11:42 AM
> To: mozilla-dev-security-pol...@lists.mozilla.org
> Subject: [EXT] Google Plan for Symantec posted
>
> Hi m.d.s.p.,
>
> Google have posted their updated plan for Symantec in the blink-dev forum
> (copied below).

Posting on behalf of Symantec.

Google’s latest proposal follows collaborative and constructive community 
discussions. Our goal has been to reach a solution that minimizes disruption 
for our customers and is in the best interests of the entire Internet community.

While there remain details to be considered, we believe Google has put forth a 
new proposal that limits business disruption for customers as compared to prior 
proposals. Notably, Google’s revised proposal would not require Symantec to 
move to shorter-term validity certificates beyond what was approved by the CA/B 
forum in Ballot 193 for all CAs and Symantec’s Extended Validation certificates 
would remain intact. Given the potential impact of any changes that might be 
implemented, we are carefully reviewing this proposal and will respond shortly 
with feedback for the community’s consideration.

We thank our customers and the community for their patience and participation 
in this important discussion.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: TrustCor root inclusion request

[Neil Dunbar via dev-security-policy]

> On 19 May 2017, at 10:24, Gervase Markham via dev-security-policy 
>  wrote:
> 
> On 18/05/17 23:40, Nick Lamb wrote:
>> Mmmm. I believe only 3.2.2.4 is acceptable to Mozilla, am I wrong
>> here? Judging from self-assessment document, TrustCor's actual
>> practices are all intended to be 3.2.2.4 compliant (I will examine in
>> more detail later) but the language here suggests it might be
>> possible for applicants to successfully validate for DV by some other
>> means not listed in 3.2.2.4, which (again unless I'm mistaken)
>> Mozilla considers always to be mis-issuance.
> 
> As of 21st July 2017, yes :-) The language should be clear that only
> 3.2.2.4-conforming methods are allowed, and each documented method
> should say which subsection of 3.2.2.4 it is complying with.

The BR self assessment document (as well as the CPS) does indeed stipulate 
which of the 3.2.2.4 subsections are allowed in validation of a DV certificate. 
No methods outside of 3.2.2.4 are permitted. The WHOIS method mentioned here is 
allowed via BR 3.2.2.4.1. Note that not all of the allowed methods from the 
3.2.2.4 subsections are actually used by TrustCor. It is possible that the 
self-assessment summary might lead to the (incorrect) conclusion that methods 
other than 3.2.2.4 could be successful, but the TrustCor documents make clear 
that only 3.2.2.4 methods are allowed

With respect to the particular clause referring to WHOIS, from the current CPS:

"3.2.2.4.1 Validating the Applicant as a Domain Contact
TrustCor will use the WHOIS or RDAP protocols to gain the Domain
Registration document for the domain(s) being requested for certification.
The email address, name, physical address present in the WHOIS record
must match those details submitted as part of the application."

Regards,

Neil Dunbar
CA Administrator,
TrustCor Systems, S. de R.L.



signature.asc
Description: Message signed with OpenPGP
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Google Plan for Symantec posted

[Gervase Markham via dev-security-policy]

Hi m.d.s.p.,

Google have posted their updated plan for Symantec in the blink-dev
forum (copied below).
https://groups.google.com/a/chromium.org/d/msg/blink-dev/eUAKwjihhBs/ovLalSBRBQAJ

Insofar as it pertains to Google's actions, you should go over and
discuss it there. But of course, this plan has significant overlap with
Mozilla's draft proposal here:
https://docs.google.com/document/d/1RhDcwbMeqgE2Cb5e6xaPq-lUPmatQZwx3Sn2NPz9jF8/edit#

I have passed that document to Kathleen, and I hope she will be
endorsing this general direction soon, at which point it will no longer
be a draft.

Assuming she does, this will effectively turn into a 3-way conversation
between Symantec, Google and Mozilla, to iron out the details of what's
required, with the Google proposal as a base. (Which I'm fine with as a
starting point.)

Comments are therefore invited on what modifications to the plan or
additional requirements Mozilla might want to suggest/impose, and
(importantly) why those suggestions/impositions are necessary and
proportionate.

Gerv


 Forwarded Message 
Subject:Re: [blink-dev] Intent to Deprecate and Remove: Trust in
existing Symantec-issued Certificates
Date:   Fri, 19 May 2017 10:27:41 -0400
From:   Ryan Sleevi 
Reply-To:   rsle...@chromium.org
To: blink-dev 
CC: Ryan Sleevi , awhal...@chromium.org



Overview / Background

Here's an update on the discussions about Symantec-issued certificates
and the steps Chrome is proposing to move forward. Thank you to
everybody who has contributed to the discussion so far.


On May 12, members of the Chrome team met with Symantec to discuss the
set of concerns and our proposed remedy for them. These discussions were
an expansion on a proposal previously shared with Symantec in April, and
later shared on the mozilla.dev.security.policy list
.


When the original Intent to Deprecate was posted, I proposed
a
plan that tried to best address issues we were aware of and provide a
long-term path for comprehensive protections. We received a lot of great
feedback from the Blink and wider PKI communities regarding the impact
this plan would have and further issues to consider. In light of this
feedback, we would like to propose a new plan that we believe ensures
users are sufficiently secured while trying to minimize disruption to
site operators, and providing an objective and reasonable path forward
for those that have critical dependencies on certificates that chain to
Symantec-operated roots.


We want to share an overview of this plan with the broader community,
with more specific, detailed requirements at the end. The high-level
overview of the plan is:

  *

Symantec will modernize their platform and PKI dedicated to website
certificate issuance. Symantec has previously posted


that this in their current roadmap, and we require that the
modernized platform adheres to best practices for CAs in security,
design, and process as part of that modernization process.

  *

Until the modernized platform is ready and accepted into major trust
stores, certificates would need to be issued through one or more
independently operated third-party CAs (aka “Managed CAs”) that
Symantec would partner with.

  *

The Managed CAs could be cross signed by an agreed upon set of
existing Symantec roots, to take advantage of the existing roots'
ubiquity in trust stores.

  *

EV certificates can be issued by Managed CAs, provided that they
meet the validation requirements.

  *

Validity period of new certificates can be up to 39 months, or to
the maximum allowed by Chrome for all CAs (currently specified in
the Baseline Requirements and EV Guidelines), provided that a
Managed CA fully revalidates the information. During a bridge
period, Managed CAs can reuse existing validation information but
lifetimes must be limited to 13 months.

  *

Existing certificates issued on or after June 1st 2016 would still
be trusted, provided they comply with the Chrome CT policy. EV
certificates issued on or after this date will continue to be
granted EV treatment.

  *

Existing certificates issued before June 1st 2016 would go through a
phased distrust based on notBefore dates.

  *

Chrome will offer an Enterprise Policy to allow older certificates
to be trusted to help with migration to the new PKI.

While the plan is not final, we believe it is converging on one that
strikes a good balance of addressing security risk and mitigating
interruption. We still welcome any feedback about it, as prior feedback
has been valuable in helping shape this plan.


Transition to a New Symantec PKI

Chrome will require that 

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

[Gervase Markham via dev-security-policy]

On 19/05/17 16:06, Inigo Barreira wrote:
> Yes, I wanted to know if a regular user can use its Gmail account to get an
> s/mime cert but that can´t be issued because the CA can´t validate the
> domain properly because it´s not his or authorized to use it when doing the
> 3.2.2.4

This is about technically constrained sub-CAs, not about general email
certs.

If you are issuing a TCSC for gmail.com, you should only be issuing that
to Google, who can prove ownership of gmail.com. You should not be
issuing it to any old Gmail user :-)

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

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

[Ryan Sleevi via dev-security-policy]

On Fri, May 19, 2017 at 11:04 AM, Jakob Bohm via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> On 19/05/2017 16:15, Gervase Markham wrote:
>
>> On 19/05/17 14:58, Jakob Bohm wrote:
>>
>>> Because the O and other dirname attributes may be shown in an e-mail
>>> client (current or future) as a stronger identity than the technical
>>> e-mail address.
>>>
>>
>> Do you know of any such clients?
>>
>>
> No, but it would be similar to how Fx displays that field in EV certs,
> so a future Thunderbird, or a non-Mozilla client could reasonably do
> something similar, even at OV level.


It sounds like that issue should be dealt with when there are Mozilla
clients that require such use case.

For example, the recognition of EV involves a whole separate set of
additional policies, for which OV is not suitable. The notion of EV S/MIME,
as terrible as it is from a security and usability perspective, would
minimally need to account for that in light of the existing lack of
standards regarding S/MIME issuance.

It does not seem useful or productive for Mozilla's Root Store to attempt
to solve that abstract case for which there are no direct Mozilla product
consumers, particularly when it can entirely be addressed at a later time.


> Keeps it short and simple and subject to well-understood policies.


Avoiding that policy requirement entirely avoids introducing feature creep
for unspecified and unused features.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

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

[Jakob Bohm via dev-security-policy]

On 19/05/2017 16:37, Gervase Markham wrote:

On 19/05/17 15:16, Inigo Barreira wrote:

What about those for gmail, Hotmail, etc.? Are out of scope?


I'm not sure what you mean. If Gmail wants a TCSC for @gmail.com, they
can have one. They would presumably need to set the dirName to "" or
null, because no dirName can cover all of their customers, as their
customerd don't represent Google?

Gerv



Or it could be O=GMail Canada Users, C=CA for @gmail.ca with the SubCA
itself being O=Google.  Etc. For each country-specific GMail domain.
@gmail.com would be C=US, or some C= value indicating unknown country
(if permitted in the X.500 standards).

Enjoy

Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S.  https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark.  Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

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

[Inigo Barreira via dev-security-policy]

Yes, I wanted to know if a regular user can use its Gmail account to get an
s/mime cert but that can´t be issued because the CA can´t validate the
domain properly because it´s not his or authorized to use it when doing the
3.2.2.4

Best regards

Iñigo Barreira
CEO
StartCom CA Limited


-Original Message-
From: dev-security-policy
[mailto:dev-security-policy-bounces+inigo=startcomca@lists.mozilla.org]
On Behalf Of Gervase Markham via dev-security-policy
Sent: viernes, 19 de mayo de 2017 16:38
To: mozilla-dev-security-pol...@lists.mozilla.org
Subject: Re: Policy 2.5 Proposal: Fix definition of constraints for
id-kp-emailProtection

On 19/05/17 15:16, Inigo Barreira wrote:
> What about those for gmail, Hotmail, etc.? Are out of scope?

I'm not sure what you mean. If Gmail wants a TCSC for @gmail.com, they can
have one. They would presumably need to set the dirName to "" or null,
because no dirName can cover all of their customers, as their customerd
don't represent Google?

Gerv

___
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: Policy 2.5 Proposal: Fix definition of constraints for id-kp-emailProtection

[Jakob Bohm via dev-security-policy]

On 19/05/2017 16:15, Gervase Markham wrote:

On 19/05/17 14:58, Jakob Bohm wrote:

Because the O and other dirname attributes may be shown in an e-mail
client (current or future) as a stronger identity than the technical
e-mail address.


Do you know of any such clients?



No, but it would be similar to how Fx displays that field in EV certs,
so a future Thunderbird, or a non-Mozilla client could reasonably do
something similar, even at OV level.


Imagine a certificate saying that ge...@wosign.cn is "CN=Gervase
Markham, O=Mozilla Corporation, ST=California, CN=US", issued by a
SubCA name constrained to "@wosign.cn", but not to any range of DNs.


Surely such a certificate would be misissued? Although I guess the issue
here is that we are excluding them from scope...

So the idea would be to say that dirName had to be constrained to either
be empty (is that possible?) or to contain a dirNames validated as
correctly representing an organization owning at least one of the domain
name(s) in the cert?



Rather: It should be constrained to an X.500 subtree identifying an
organization validated to at least BR compliant OV level (EV level if
SubCA notBefore after some policy date) as for a ServerAuth certificate
for the same domain names specified in the rfc822name restrictions.

Keeps it short and simple and subject to well-understood policies.

Enjoy

Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S.  https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark.  Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Policy 2.5 Proposal: Clarify requirement for multi-factor auth

[Carl Mehner via dev-security-policy]

On Friday, May 19, 2017 at 7:19:27 AM UTC-5, Gervase Markham wrote:
> "enforce multi-factor authentication for all accounts capable of causing
> certificate issuance or performing validation functions"

Should we specify somewhere that multi-factor auth encompasses two _different_ 
factors and not simply multiple authenticators?

It seems possible that some could (or possibly do) interpret multi-factor as 
including 'double-single-factor' or 'multi-step' using something like a client 
cert (something you have) and a TOTP like Google Authenticator (something you 
have). Taken to the extreme, this could include two 4-digit pins (something you 
know and something you know).

If that's not the intent, then something such as the following may be more 
clear:
"enforce multi-factor authentication (using 2 or more factors from NIST 
800-63-2) for all accounts capable of causing certificate issuance or 
performing validation functions"
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

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

[Gervase Markham via dev-security-policy]

On 19/05/17 15:16, Inigo Barreira wrote:
> What about those for gmail, Hotmail, etc.? Are out of scope?

I'm not sure what you mean. If Gmail wants a TCSC for @gmail.com, they
can have one. They would presumably need to set the dirName to "" or
null, because no dirName can cover all of their customers, as their
customerd don't represent Google?

Gerv

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

Re: Symantec: Update

[Gervase Markham via dev-security-policy]

On 19/05/17 15:28, Peter Bowen wrote:
> This is not accurate.  They have indicated that the SSP customers have
> some level of issuance capability.

Oops. Well, they said that a while back, but yes indeed, since then we
have discovered the above fact.

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

Re: Policy 2.5 Proposal: Clarify requirement for multi-factor auth

[Gervase Markham via dev-security-policy]

On 19/05/17 14:26, Kurt Roeckx wrote:
> I'm wondering why something like this should be in the Mozilla policy
> and not be part of something else that they get audited for.

Section 6.5.1 of the BRs states:

"The CA SHALL enforce multi‐factor authentication for all accounts
capable of directly causing certificate issuance."

I'm not sure whether that came from the Mozilla policy or vice versa,
but it appeared in the Mozilla policy in version 2.1, and was
communicated as a requirement in a CA Communication in September 2011,
in response to DigiNotar. It was also in draft 34 of the BRs, written in
May 2011. So it may be we got it from them.

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

Re: Symantec: Update

[Peter Bowen via dev-security-policy]

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 its hard to keep track of who could issue as an RA. I know
>> quite a few got killed, but I'm not sure if there are any other subCAs
>> based off re-reading posts in this thread.
>
> Symantec say they have closed their RA program, only Apple and Google
> are left in their GeoRoot program, and they have no other programs which
> allow third parties to have issuance capability.

This is not accurate.  They have indicated that the SSP customers have
some level of issuance capability.

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

Re: Symantec: Update

[Gervase Markham via dev-security-policy]

On 15/05/17 21:06, Michael Casadevall wrote:
> Sorry, I could have been more clear here. What I'm proposing is that
> after a specific TBD NotBefore date, we require SCTs to be in place on
> the certificate to be trusted. Certificates from before that date
> would remain trusted as-is (pending any reduction of expiration time).
> 
> I don't know if NSS has support for checking of SCTs (I can't pull the
> source at the moment to check), but it should fail if the SCT is
> missing, and otherwise behave like OCSP validation.

Embedding SCTs is not the only way SCTs can be delivered - they can come
in the SSL handshake or via OCSP. Requiring them to be embedded does
have the advantage that certificates now carry an unforgeable timestamp,
and it was something I proposed in a version of Mozilla's now-dormant CT
policy. But for various reasons, it's not necessarily practical to
require it in all circumstances (which is why the CT RFC defines
multiple mechanisms).

Firefox does have some support for checking SCT presence and validity,
but it's not turned on.

>> Are there any RA's left for Symantec?
> 
> TBH, I'm not sure. I think Gervase asked for clarification on this
> point, but its hard to keep track of who could issue as an RA. I know
> quite a few got killed, but I'm not sure if there are any other subCAs
> based off re-reading posts in this thread.

Symantec say they have closed their RA program, only Apple and Google
are left in their GeoRoot program, and they have no other programs which
allow third parties to have issuance capability.

>> I believe the only reasonable interpretation of the "new root"
>> plan would be based on cross signing for trust by old Mozilla
>> browsers and other root programs.
> 
> Won't the cross signature though have to be embedded in Firefox, or
> included in a server's SSL bundle for it to actually work?

The latter, yes. This is not difficult nor that unusual.

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

Re: [EXT] Re: Draft further questions for Symantec

[Gervase Markham via dev-security-policy]

On 15/05/17 22:08, Michael Casadevall wrote:
> RA & EV:
> Were all the certificates issued by the RAs uploaded to a CT log? If
> not, what, if any, subsets were uploaded?
>
> I'm aware Symantec was required to upload certificates to CT or if it
> was retroactive, but I'm unsure if that requirement was extended to the RAs.

Google required Symantec to do this after a date in mid-2016. I would
assume it extended to the RAs because otherwise their new certs would
not be trusted in Chrome.

There was no requirement on Symantec to CT-log all their previous
certificates, either issued by themselves or their RAs.

> I'm not sure if the green bar requires OIDs in all points along the
> certificate chain or if this Florida CA could have issued an leaf
> certificate by adding the OIDs there.

It only requires the OID in the leaf.

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

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

[Inigo Barreira via dev-security-policy]

What about those for gmail, Hotmail, etc.? Are out of scope?

Best regards

Iñigo Barreira
CEO
StartCom CA Limited


-Original Message-
From: dev-security-policy
[mailto:dev-security-policy-bounces+inigo=startcomca@lists.mozilla.org]
On Behalf Of Gervase Markham via dev-security-policy
Sent: viernes, 19 de mayo de 2017 15:13
To: mozilla-dev-security-pol...@lists.mozilla.org
Subject: Re: Policy 2.5 Proposal: Fix definition of constraints for
id-kp-emailProtection

On 12/04/17 10:47, Gervase Markham wrote:
> We don't have any "Email BRs" to refer to, but I think we want 
> something like this:
> 
> "If the certificate includes the id-kp-emailProtection extended 
> key usage, it MUST include the Name Constraints X.509v3 extension with 
> constraints on rfc822Name, with at least one name in permittedSubtrees."

Updated language:

"If the certificate includes the id-kp-emailProtection extended key usage,
it MUST include the Name Constraints X.509v3 extension with constraints on
rfc822Name, with at least one name in permittedSubtrees, each such name
having its ownership validated according to section
3.2.2.4 of the BRs."

Gerv

___
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: Policy 2.5 Proposal: Fix definition of constraints for id-kp-emailProtection

[Gervase Markham via dev-security-policy]

On 19/05/17 14:58, Jakob Bohm wrote:
> Because the O and other dirname attributes may be shown in an e-mail
> client (current or future) as a stronger identity than the technical
> e-mail address.

Do you know of any such clients?

> Imagine a certificate saying that ge...@wosign.cn is "CN=Gervase
> Markham, O=Mozilla Corporation, ST=California, CN=US", issued by a
> SubCA name constrained to "@wosign.cn", but not to any range of DNs.

Surely such a certificate would be misissued? Although I guess the issue
here is that we are excluding them from scope...

So the idea would be to say that dirName had to be constrained to either
be empty (is that possible?) or to contain a dirNames validated as
correctly representing an organization owning at least one of the domain
name(s) in the cert?

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

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

[Jakob Bohm via dev-security-policy]

On 19/05/2017 15:13, Gervase Markham wrote:

On 08/05/17 11:32, Dimitris Zacharopoulos wrote:

On 8/5/2017 1:18 μμ, Gervase Markham wrote:

  + dirName entries scoped in the Organizational name and
location

Help me understand how dirName interacts with id-kp-emailProtection?


When the Subscriber belongs to an Organization that needs to be included
in the subjectDN.


Right, but why do we need name constraints here?

It seems to me that positive constraints on rfc822Name are sufficient
for an intermediate to be a TCSC.

Gerv



Because the O and other dirname attributes may be shown in an e-mail
client (current or future) as a stronger identity than the technical
e-mail address.

Imagine a certificate saying that ge...@wosign.cn is "CN=Gervase
Markham, O=Mozilla Corporation, ST=California, CN=US", issued by a
SubCA name constrained to "@wosign.cn", but not to any range of DNs.

It would be problematic for such a SubCA to be considered a TCSC
excluded from all usual checks and balances.



Enjoy

Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S.  https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark.  Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Mozilla Policy and CCADB Disclosure scope

[Gervase Markham via dev-security-policy]

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 related, with 2) obviously being a subset of 1).
It's also possible we might decide that for some certificates, some
subset of the Mozilla policy applies, but not all of it.

I'm not even sure how best to frame this discussion, so let's have a go
from this angle, and if it runs into the weeds, we can try again another
way.

The goal of scoping the Mozilla policy is, to my mind, to have Mozilla
policy sufficiently broadly applicable that it covers all
publicly-trusted certs and also doesn't leave unregulated sufficiently
large number of untrusted certs inside publicly-trusted hierarchies that
it will hold back forward progress on standards and security.

The goal of CCADB disclosure is to see what's going on inside the WebPKI
in sufficient detail that we don't miss important things. Yes, that's vague.

Here follow a list of scenarios for certificate issuance. Which of these
situations should be in full Mozilla policy scope, which should be in
partial scope (if any), and which of those should require CCADB
disclosure? Are there scenarios I've missed?

A) Unconstrained intermediate
  AA) EE below
B) Intermediate constrained to id-kp-serverAuth
  BB) EE below
C) Intermediate constrained to id-kp-emailProtection
  CC) EE below
D) Intermediate constrained to anyEKU
  DD) EE below
E) Intermediate usage-constrained some other way
  EE) EE below
F) Intermediate name-constrained (dnsName/ipAddress)
  FF) EE below
G) Intermediate name-constrained (rfc822Name)
  GG) EE below
H) Intermediate name-constrained (srvName)
  HH) EE below
I) Intermediate name-constrained some other way
  II) EE below

If a certificate were to only be partially in scope, one could imagine
it being exempt from one or more of the following sections of the
Mozilla policy:

* BR Compliance (2.3)
* Audit (3.1) and auditors (3.2)
* CP and CPS (3.3)
* CCADB (4)
* Revocation (6)

It's also further possible that BR Compliance could be split, requiring
compliance to some parts of the BRs but not others.

So this is a complicated question!

One reasonable enquiry would be: what is the status quo? I _think_ it's
as follows:

1) Applicability (Mozilla Root Store Policy section 1.1):
   all except E), EE), I) and II), but only those EE certs with no EKU,
   or at least one of serverAuth, emailProtection or anyEKU.
2) Disclosure (CCADB Common Policy section 4):
   A), B), D), possibly H) and I) depending on EKU.

Is that right?

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

Re: Policy 2.5 Proposal: Clarify requirement for multi-factor auth

[Kurt Roeckx via dev-security-policy]

On 2017-05-19 14:18, Gervase Markham wrote:

Ryan Sleevi suggested a wording clarification/policy extension to the
multi-factor auth requirement, from:

"enforce multi-factor authentication for all accounts capable of
directly causing certificate issuance"

to

"enforce multi-factor authentication for all accounts capable of causing
certificate issuance or performing validation functions"

The goal here was to cover RAs performing validation functions. Although
we are moving towards not permitting third parties to perform domain or
IP address ownership validation, it still seems to be to be a good
improvement that accounts involving certificate issuance or the input of
data into what will become an issued certificate should be multi-factor
protected.


I'm wondering why something like this should be in the Mozilla policy 
and not be part of something else that they get audited for.



Kurt


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

Re: Hunting for intermediates that still haven't been disclosed to CCADB

[Rob Stradling via dev-security-policy]

On 17/05/17 15:12, Gervase Markham wrote:

On 17/05/17 15:08, Rob Stradling wrote:

Incidentally, it's true that Mozilla have said that they don't care
about the Code Signing trust bit any more, but the
CKA_TRUST_CODE_SIGNING haven't yet been removed from certdata.txt.  Bug?


Yes, but a low priority one. Feel free to file :-)


Filed.

https://bugzilla.mozilla.org/show_bug.cgi?id=1366243

--
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

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

[Gervase Markham via dev-security-policy]

On 08/05/17 11:32, Dimitris Zacharopoulos wrote:
> On 8/5/2017 1:18 μμ, Gervase Markham wrote:
>>>   + dirName entries scoped in the Organizational name and
>>> location
>> Help me understand how dirName interacts with id-kp-emailProtection?
> 
> When the Subscriber belongs to an Organization that needs to be included
> in the subjectDN.

Right, but why do we need name constraints here?

It seems to me that positive constraints on rfc822Name are sufficient
for an intermediate to be a TCSC.

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

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

[Gervase Markham via dev-security-policy]

On 12/04/17 10:47, Gervase Markham wrote:
> We don't have any "Email BRs" to refer to, but I think we want something
> like this:
> 
> "If the certificate includes the id-kp-emailProtection extended key
> usage, it MUST include the Name Constraints X.509v3 extension with
> constraints on rfc822Name, with at least one name in permittedSubtrees."

Updated language:

"If the certificate includes the id-kp-emailProtection extended key
usage, it MUST include the Name Constraints X.509v3 extension with
constraints on rfc822Name, with at least one name in permittedSubtrees,
each such name having its ownership validated according to section
3.2.2.4 of the BRs."

Gerv

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

Policy 2.5 Proposal: Require all CAs to have appropriate network security

[Gervase Markham via dev-security-policy]

At the moment, the CAB Forum's Network Security guidelines are audited
as part of an SSL BR audit. This means that CAs or sub-CAs which only do
email don't technically have to meet them. However, they also have a
number of deficiencies, and the CAB Forum is looking at replacing them
with something better, ideally maintained by another organization. So
just mandating that everyone follow them doesn't seem like the best thing.

Nevertheless, I think it's valuable to make it clear in our policy that
all CAs are expected to follow best practices for network security. I
suggest this could be done by adding a bullet to section 2.1:

"CAs whose certificates are included in Mozilla's root program MUST:

* follow industry best practice for securing their networks, for example
by conforming to the CAB Forum Network Security Guidelines or a
successor document;"

This provides flexibility in exactly what is done, while making it
reasonably clear that leaving systems unpatched for 5 years would not be
acceptable.

This is: https://github.com/mozilla/pkipolicy/issues/70

---

This is a proposed update to Mozilla's root store policy for version
2.5. Please keep discussion in this group rather than on Github. Silence
is consent.

Policy 2.4.1 (current version):
https://github.com/mozilla/pkipolicy/blob/2.4.1/rootstore/policy.md
Update process:
https://wiki.mozilla.org/CA:CertPolicyUpdates
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Policy 2.5 Proposal: Clarify requirement for multi-factor auth

[Gervase Markham via dev-security-policy]

Ryan Sleevi suggested a wording clarification/policy extension to the
multi-factor auth requirement, from:

"enforce multi-factor authentication for all accounts capable of
directly causing certificate issuance"

to

"enforce multi-factor authentication for all accounts capable of causing
certificate issuance or performing validation functions"

The goal here was to cover RAs performing validation functions. Although
we are moving towards not permitting third parties to perform domain or
IP address ownership validation, it still seems to be to be a good
improvement that accounts involving certificate issuance or the input of
data into what will become an issued certificate should be multi-factor
protected.

This is: https://github.com/mozilla/pkipolicy/issues/60

---

This is a proposed update to Mozilla's root store policy for version
2.5. Please keep discussion in this group rather than on Github. Silence
is consent.

Policy 2.4.1 (current version):
https://github.com/mozilla/pkipolicy/blob/2.4.1/rootstore/policy.md
Update process:
https://wiki.mozilla.org/CA:CertPolicyUpdates
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Policy 2.5 Proposal: Add anyEKU to scope

[Gervase Markham via dev-security-policy]

On 12/05/17 14:00, Gervase Markham wrote:
> Because the Mozilla root store is used by more people than Mozilla,
> Kathleen would like to put anyEKU in scope even though Firefox ignores it.

Implemented as specced.

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

Re: Policy 2.5 Proposal: Require CAs to operate in accordance with their CPs and CPSes

[Gervase Markham via dev-security-policy]

On 12/05/17 14:21, Gervase Markham wrote:
> Specifically, we could add text to the top of section 5.2 ("Forbidden
> and Required Practices"):
> 
> "CA operations MUST at all times be in accordance with the applicable CP
> and CPS."

Implemented as specced.

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

Re: Policy 2.5 Proposal: Require CAs to operate in accordance with their CPs and CPSes

[Gervase Markham via dev-security-policy]

On 12/05/17 18:54, Jakob Bohm wrote:
> Perhaps tweak the wording to make the document submitted to the CCADB
> binding, rather than any CP/CPS published elsewhere.

While that certainly seems attractive, changing the location of the
canonical CP/CPS from the CA's repository to Mozilla's repository seems
to be rather taking over a CA function. If many or most root programs
were using the CCADB, this might be more justifiable. What if several
root programs said the applicable version was the one they held in their
systems? That doesn't sound like a great outcome.

CAs are required to keep the CCADB up to date anyway.

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

Re: Policy 2.5 Proposal: Clarify requirements for reporting of security failures/policy violations

[Gervase Markham via dev-security-policy]

On 12/05/17 14:18, Gervase Markham wrote:
> I propose instead:
> 
> "Changes that are motivated by a security concern such as certificate
> misissuance or a root or intermediate compromise MUST be treated as a
> security-sensitive, and a secure bug filed in Bugzilla.

Implemented as proposed.

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

Re: TrustCor root inclusion request

[Gervase Markham via dev-security-policy]

On 18/05/17 23:40, Nick Lamb wrote:
> Mmmm. I believe only 3.2.2.4 is acceptable to Mozilla, am I wrong
> here? Judging from self-assessment document, TrustCor's actual
> practices are all intended to be 3.2.2.4 compliant (I will examine in
> more detail later) but the language here suggests it might be
> possible for applicants to successfully validate for DV by some other
> means not listed in 3.2.2.4, which (again unless I'm mistaken)
> Mozilla considers always to be mis-issuance.

As of 21st July 2017, yes :-) The language should be clear that only
3.2.2.4-conforming methods are allowed, and each documented method
should say which subsection of 3.2.2.4 it is complying with.

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