Re: BR compliance of legacy certs at root inclusion time

[Gervase Markham via dev-security-policy]

On 21/08/17 06:20, Peter Kurrasch wrote:
> The CA should decide what makes the most sense for their particular
> situation, but I think they‎ should be able to provide assurances that
> only BR-compliant certs will ever chain to any roots they submit to the
> Mozilla root inclusion program.

So you are suggesting that we should state the goal, and let the CA work
out how to achieve it? That makes sense.

I agree with Nick that transparency is important.

Is there room for an assessment of risk, or do we need a blanket
statement? If, say, a CA used short serials up until 2 years ago but has
since ceased the practice, we might say that's not sufficiently risky
for them to have to stand up and migrate to a new cross-signed root. I
agree that becomes subjective.

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

BR compliance of legacy certs at root inclusion time

[Gervase Markham via dev-security-policy]

Sometimes, CAs apply for inclusion with new, clean roots. Other times,
CAs apply to include roots which already have a history of issuance. The
previous certs issued by that CA aren't always all BR-compliant. Which
is in one sense understandable, because up to this point the CA has not
been bound by the BRs. Heck, the CA may never even have heard of the BRs
until they come to apply - although this seems less likely than it would
once have been.

What should our policy be regarding BR compliance for certificates
issued by a root requesting inclusion, which were issued before the date
of their request? Do we:

A) Require all certs be BR-compliant going forward, but grandfather in
   the old ones; or
B) Require that any non-BR-compliant old certs be revoked; or
C) Require that any seriously (TBD) non-BR-compliant old certs be
   revoked; or
D) something else?

Gerv


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

Re: Responding to a misissuance

[Gervase Markham via dev-security-policy]

On 18/08/17 13:03, Doug Beattie wrote:
> And if there is any guidance on processing misissuance reports for
> Name constrained sub-CA vs. not name constrained, that would be
> helpful also.

What parts of a response do you think might be different for
name-constrained sub-CAs?

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

Re: Responding to a misissuance

[Gervase Markham via dev-security-policy]

Hi Rich,

On 18/08/17 12:51, richmoor...@gmail.com wrote:
> Perhaps some explicit statements about sub-CAs would be helpful -
> detailing where responsibility lies and how a CA is required to deal
> with a sub-CA who is found to have misissued.

Do you specifically mean sub-CAs which are run by someone other than the
CA (and so have their own audits etc.)?

Good idea. What do you think we should say? :-)

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

Re: Bugzilla Bugs re CA issuance of non-compliant certs

[Gervase Markham via dev-security-policy]

On 17/08/17 00:18, Kathleen Wilson wrote:
> == Let’s Encrypt == 
> RESOLVED (no bug needed)

> == Staat der Nederlandend / PKIoverheid ==
> RESOLVED (no bug needed)

While the timely responses and performance of these CAs is commendable,
it may be worth opening a bug and recording the events and the outcome,
so that our bug database remains the canonical source of information
regarding misissuances that Mozilla knows about.

Kathleen: If your bug-filing fingers are not yet entirely worn out,
could they stretch to two more? :-)

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

Re: O=U.S. Government for non-USG entity (IdenTrust)

[Gervase Markham via dev-security-policy]

On 17/08/17 20:31, Jeremy Rowley wrote:
> Without an FQDN, I doubt they are in scope for the baseline requirements. 

Not according to the BRs themselves. However, the Mozilla Policy 2.5
specifically says:

"Insofar as the Baseline Requirements attempt to define their own scope,
the scope of this policy (section 1.1) overrides that. Mozilla thus
requires CA operations relating to issuance of all SSL certificates in
the scope of this policy to conform to the Baseline Requirements."

Now, whether we are right to include anyEKU in scope, given that it
pulls in certs such as those in question, is still something I am unsure
about :-) But the current policy says what it says.

> They are in scope for the Mozilla policy. The BRs require the cert to 
> be intended for web tls. These are not. 

But the Mozilla Policy re-scopes the BRs to remove the ambiguous
language about "intent".

> The Mozilla policy covers client certs as well as tls.

Er, no it doesn't (except insofar as we make anyEKU in scope)? Our
policy covers server certs and email certs.

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

Re: Certificate with invalid dnsName issued from Baltimore intermediate

[Gervase Markham via dev-security-policy]

On 15/08/17 16:53, Ben Wilson wrote:
> Attached is an audit from 2016.  They are due for another one for 2017.

Attachments don't appear on this list, but I have the docs. Please email
me if you'd like them. I've asked Ben to update CCADB to point to them,
and to also update any other entries where it is written "available on
request". That is not a valid value for that field.

Gerv

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

Responding to a misissuance

[Gervase Markham via dev-security-policy]

I've started a wiki page giving Mozilla expectations and best practices
for CAs responding to a misissuance report. (No idea why I decided to
write that now...)

https://wiki.mozilla.org/CA/Responding_To_A_Misissuance

Comments on whether the content is correct, and what might be missing,
are most welcome.

The idea might be for us (or anyone else, for that matter) to send a
link to this document to CAs along with any misissuance reports.

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

Re: Bugzilla Bugs re CA issuance of non-compliant certs

[Gervase Markham via dev-security-policy]

On 15/08/17 21:24, Kathleen Wilson wrote:
> Mozilla's Root Store policy says: "CAs MUST follow and be aware of
> discussions in the mozilla.dev.security.policy forum, where Mozilla's
> root program is coordinated."
> 
> There is no indication about how frequently a representative of the
> CA must check the m.d.s.policy discussions. And what about when a
> CA's representative is on vacation? (e.g. the month of August for
> many CAs) Do we really expect them to monitor m.d.s.policy while on
> vacation?  (I don't even monitor it myself while I'm on vacation.)

Yes, indeed. That stipulation was more to prevent CAs claiming lack of
awareness of issues which had been discussed at length, rather than
making it so people can report issues here and count them as properly
reported to the CA. There are no SLAs for CAs reviewing m.d.s.policy,
although ignoring it entirely for a month would suggest to me that the
absent employee should have delegated.

Gerv

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

Re: Certificates issued with HTTPS OCSP responder URL (IdenTrust)

[Gervase Markham via dev-security-policy]

On 07/08/17 22:30, Jakob Bohm wrote:
> Since the CT made it possible, I have seen an increasing obsession with
> enforcing every little detail of the BRs, things that would not only
> have gone unnoticed, but also been considered unremarkable before CT.

I am firmly of the opinion that all BR and RFC violations are of
interest to the community. That is a separate question from what should
be done about them.

> Do we really want the CA community to be filled with bureaucratic
> enforcement of harsh punishments for every slight misstep?

No. I would expect responses (I wouldn't use the word 'punishments') to
be appropriate to the level of problem they are addressing. However,
there is a cumulative element to CA problems because it speaks to
competence.

A CA's job, in the abstract, is to read a large number of documents full
of rules and build a system which keeps those rules and doesn't allow
them to be broken. Therefore, instances of rule-breaking are of interest
to those whom the CA would like to trust their system, because they
indicate either a lack of comprehension of the rules or a lack of
ability to write code that follows them, both of which are of interest.

This is not to say that we expect perfection from every CA. But when
things do go wrong we expect a particular sort of reaction (more on that
soon, I hope), and we don't expect different things to be going wrong
every month, or the same thing to be going wrong multiple times.

Gerv

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

Re: Expired Certificates Listed by Certificate Manager

[Gervase Markham via dev-security-policy]

On 15/08/17 13:59, Ryan Sleevi wrote:
> Note: adding to certdata.txt, at present, will have various undesirable
> side-effects:
> 
> - Distrust records, without associated certs, can present UI issues when
> viewing and editing (which is why the associated certs are included in
> certdata.txt)

The current distrust records do have associated certs, right?

> - Distrust records, _with_ associated certs, can present UI issues when
> viewing and editing (yes, it's a no-win, and that's the point)

I assume you mean UI issues in Firefox/Thunderbird specifically?

> - Distrust records, _with_ associated certs, can present new challenges for
> distributions that patch (failing to include a new root = things don't work
> that should. failing to distrust an old certificate = things that shouldn't
> work, do)

However, these are existing rather than new challenges, given that we
already have such certificates in the store.

> Could you indicate what you believe 'big' distrusts are versus 'little'
> distrusts? Are we talking root vs subordinate CA? Something else?

"Big" probably means Diginotar-scale Internet hoo-ha.

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

Re: Certificate issued by D-TRUST SSL Class 3 CA 1 2009 with short SerialNumber

[Gervase Markham via dev-security-policy]

On 14/08/17 16:44, Arno Fiedler wrote:
> fulfilled. On 20-07-17 Mozilla asked D-TRUST for clarification, due
> to the holiday period this message reached us on 07-08-17, AF
> answered on 08-08-17

I was going to complain about this but, re-reviewing the CCADB Common
Policy[0], it says:

"Notification of security and audit-related issues will be emailed to
all POCs and the email aliases; CAs are advised to supply sufficient
POCs that will enable them to respond to an issue promptly."

As I only sent the notification to Arno alone (the primary PoC) then I
have to take responsibility for not providing sufficient notification.
My apologies.

Gerv

[0] http://ccadb.org/policy
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Misissued certificates

[Gervase Markham via dev-security-policy]

On 10/08/17 19:35, Jeremy Rowley wrote:
> This is interesting.  We had one Sub CA who mis-issued some pre-certs but
> then never issued an actual certificate tied to the pre-certificate.  There
> was a previous Mozilla discussion (link coming) where mis-issuance of a
> pre-certificate was akin to mis-issuance of the certificate itself.  The
> pre-certificates were later revoked at our request.  If no actual
> certificate issued, the pre-cert falls out of scope of the BRs right? Since
> it can't be used for actual server transactions thanks to the poison
> extensions? Obviously they still fall within the Mozilla policy as they
> contain serverAuth in the EKU.  However, should they be reported as issues
> and should they be revoked in accordance with the BR?

I'm having trouble disentangling your questions from each other :-) But
yes, our position (and that of the CT RFC) is that "mis-issuance of a
pre-certificate is equivalent to mis-issuance of the certificate
itself", and therefore should be reported and dealt with just as if a
cert was mis-issued.

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

Re: CA Problem Reporting Mechanisms

[Gervase Markham via dev-security-policy]

On 08/08/17 20:02, Jeremy Rowley wrote:
> +1. CAs should be required to support certificate problem reports
> sent through a specified email address. It simplifies the process a
> lot if CAs use at least one common mechanism.

https://github.com/mozilla/pkipolicy/issues/98

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

Re: Miss-issuance: URI in dNSName SAN

[Gervase Markham via dev-security-policy]

On 08/08/17 14:33, Alex Gaynor wrote:
> Following up on this thread, 8 days ago I emailed Camerfirma, I have not
> heard back from them, nor have they taken any action. What is the
> appropriate next step here?

I have emailed the primary Point of Contact at Camerfirma to enquire as
to what is going on.

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

Re: Miss-issuance: URI in dNSName SAN

[Gervase Markham via dev-security-policy]

On 31/07/17 15:14, Alex Gaynor wrote:
> So far I've encountered issues with:
> 
> - DocuSign (OpenTrust/Keynectis) - who neglected to fill out that field
> - StartCom - who filled out "web publication", I don't know what that means

I have emailed both of these CAs to request that they provide this
information. Once they have done so, you will be able to find the
updated values in this live report:

https://ccadb-public.secure.force.com/mozilla/CAInformationReport

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

Re: English translation for Certinomis root CP/CPS?

[Gervase Markham via dev-security-policy]

On 04/08/17 16:11, Jonathan Rudenberg wrote:
>> CAs must provide English versions of any Certificate Policy,
>> Certification Practice Statement and Audit documents which are not
>> originally in English, with version numbers matching the document
>> they are a translation of.

Note that this becomes true only when new documents are provided after
the date on which this policy requirement became active, which was June
1st 2017. So I would expect Certnomis to be providing English versions
of their CP and CPS at the time of their next annual update of the
CCADB, if not before.

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

Re: Certificate with invalid dnsName issued from Baltimore intermediate

[Gervase Markham via dev-security-policy]

Hi Ben,

On 03/08/17 15:38, Ben Wilson wrote:
> Here is the response from Intesa Sanpaolo concerning the disruption that
> revocation will cause to their banking operations:

I've looked up the certs relating to this sub-CA in the CCADB. The key
in question:

https://crt.sh/?caid=1698=cablint,x509lint

appears to be in two certs, which are:

https://crt.sh/?id=18068159=cablint,x509lint
and
https://crt.sh/?id=6158202=cablint,x509lint

They have CCADB entries here (note: these links work for me, but AIUI CA
links are different):

https://ccadb.my.salesforce.com/001o00dsANG
https://ccadb.my.salesforce.com/001o00dsAlD

The audit fields for both of these say "Available on request". I'm not
sure that's a valid value for that field; it's supposed to link to the
actual audit. Nevertheless, I am now requesting. Can you please provide
the audits for this subCA?

Thanks,

Gerv

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

Re: Certificate with invalid dnsName issued from Baltimore intermediate

[Gervase Markham via dev-security-policy]

Hi Ben,

On 03/08/17 14:32, Ben Wilson wrote:
> That would be fine.  Also, we have given Intesa Sanpaolo a scheduled
> revocation date of 15 August 2017, and I'm waiting to hear back.

That's today; is it still the plan to revoke their intermediate?

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

Re: TunRootCA2 root inclusion request

[Gervase Markham via dev-security-policy]

On 03/08/17 08:01, Olfa Kaddachi wrote:
> ==> Some of these controls are already in place (such as the field CN and 
> Subject Alternative Name that does not contain a private IP address). 

That doesn't quite answer my question.

Let me ask another way: for how long has the Government of Tunisia CA
been aware of the Baseline Requirements? From what date do you assert
that you have been compliant with these requirements?

> 4-Validation of the technical data included in the CSR: The RA operator 
> checks :
> 
> Digital Signature Algorithm: SHA256
> Key Algorithm: RSA
> Key Size: 2048

Why can such things not be checked programmatically? It seems you are
opening yourselves up to the possibility of human error.

> Moreover, the NDCA is now implementing a new Managed PKI platform which will 
> be in production by the end of September 2017.  For the moment, the only 
> improvement done, is the printing of all the subject alternative names in the 
> certificate for the RA operators, in addition to the other fields (CN, O, OU, 
> mail) in such a way that they can visually check all the fields before the 
> delivery of the certificate.

A visual check may not catch every problem. For example, would it catch
a trailing space?

>>From what date would you say that your CA has been compliant with the CAB 
>>Forum Baseline Requirements? 
> ==> The TunRootCA2 and TunServerCA2 passed two successive external audit 
> performed by LSTI. The last audit took place from 27th to 30th September 2016 
> in applying the relevant ETSI Technical Specifications ETSI TS 102042v2.4.1. 

And that audit includes a BR audit?

Did the audit report have any qualifications?

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

Re: Expired Certificates Listed by Certificate Manager

[Gervase Markham via dev-security-policy]

On 01/08/17 09:21, userwithuid wrote:
> In this context @Mozilla: Those additional distrust entries are
> coming from NSS, but they are all pre-OneCRL afaics. Is this
> coincidence (= there wasn't any "high-profile" enough distrust
> warranting nss addition) or has the certdata-based distrust been
> entirely obsoleted by OneCRL (= there will never be any new distrust
> entries in certdata)?

OneCRL does not obsolete certdata.txt-based distrust because not
everyone checks OneCRL. While we can't add every cert in OneCRL to
certdata.txt, we should add the big dis-trusts to it. Do you think
there's anything missing?

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

Re: Bad characters in dNSNames

[Gervase Markham via dev-security-policy]

Hi Rob,

On 26/07/17 11:21, Rob Stradling wrote:
> https://docs.google.com/spreadsheets/d/1IACTYMDXcdz4DoMKxkHfePfb5mv2XN68BcB7p6acTqg/edit?usp=sharing

Thanks for this. Any chance of saving me a bit of time by
cross-referencing each line with the "CA owner" from the CCADB? If
that's too much work, no problem, let me know and I can do it myself by
hand.

Gerv

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

Re: SRVNames in name constraints

[Gervase Markham via dev-security-policy]

On 06/07/17 16:56, Ryan Sleevi wrote:
> Relevant to this group, id-kp-serverAuth (and perhaps id-kp-clientAuth)

So what do we do? There are loads of "name-constrained" certs out there
with id-kp-serverAuth but no constraints on SRVName. Does that mean they
can issue for any SRVName they like? Is that a problem once we start
allowing it?

I've filed:
https://github.com/mozilla/pkipolicy/issues/96
on this issue in general.

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

Re: FW: P-521

[Gervase Markham via dev-security-policy]

On 05/07/17 11:40, Arkadiusz Ławniczak wrote:
> As CERTUM, we are not aware of any implementations which do not
> support P-521 (with the exception of BoringSSL where P-512 is
> disabled but not unsupported).

Yes, but that means that whenever Chrome uses BoringSSL, your roots
won't work, right? Is that not a problem for you?

>> From a cryptosystem security point of view - especially rootCA and
>> ARL - P384 to P521 is like "day to night". This is particularly
>> important for crypto-systems to be safe for decades.

As noted in my previous message, you need to provide some backup for
that assertion.

> The key is: "or higher". The thing is the vendors'/browsers' policies
> should be consistent with the functioning of the market and therefore
> we belive that removing P-521 from Mozilla Policy was not a good
> thing.

"The market" is overwhelmingly not using P-521, according to the
statistics quoted in this discussion.

If we allow it and it starts being used, every web client SSL
implementation will need to carry this algorithm for the forseeable
future. Given that there are other new, probably-better curves and
algorithms coming down the pipe, it seems unwise to pad out the
compulsory set with yet more variants on the same thing.

So pending a very good argument why P-521 provides something that
neither the existing algorithms nor the new class of pending algorithms
can provide, I think we will leave the policy as-is.

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

Re: High traffic on this list, and Mozilla root program involvement

[Gervase Markham via dev-security-policy]

Hi Jeremy,

On 09/08/17 21:57, Jeremy Rowley wrote:
> I was thinking you should just have the Cas add them all for you.  Makes it
> easier on you and demonstrates they are tracking and remediating these
> issues.  If I were going to create a bug for these in Mozilla would you
> prefer to see one bug per issue on one bug per CA. For example, should there
> be a bug for all DigiCert issues or should there be one that describes too
> long of serial number and another that says the field contains meta-data? 

That is a good point. Thank you for the suggestion.

I would like one bug per root cause, ideally, but as bugs can be more
easily duplicated against each other than split, err on the side of one
bug per issue if the root causes have not been determined with
sufficient clarity yet.

If CAs wish to file bugs about their own issues, they should do so here:

https://bugzilla.mozilla.org/enter_bug.cgi?product=NSS=CA%20Certificate%20Mis-Issuance

(We use the term "mis-issuance" broadly here.) Please include in the
initial comment at least a full copy of the original report from this
group, although you may elide details of certificates from other CAs.

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

Re: High traffic on this list, and Mozilla root program involvement

[Gervase Markham via dev-security-policy]

On 09/08/17 00:12, Jeremy Rowley wrote:
> Do you want that added as a new bug for all the issues listed?

I'm not sure I follow. Do I want what added?

I will be filing any additional appropriate bugs when I get around to
triaging all the messages in this forum.

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

Re: Final Decision by Google on Symantec

[Gervase Markham via dev-security-policy]

On 28/07/17 07:14, Gervase Markham wrote:
> I would like to make a decision on this matter on or before July 31st,

After listening to the opinions here on m.d.s.p., and consultation
within Mozilla and with our engineering teams, on the matter of when to
distrust various bits of the existing Symantec PKI we have decided to
match the dates proposed by Google for Chrome (within a few weeks; exact
Firefox releases will be determined nearer the time).

This is not the outcome we would have preferred (clearly, as it doesn't
match our earlier proposal) but, given the choice before us, the
benefits of a consistent cross-browser approach have been judged to be
greater than the benefits of Mozilla unilaterally setting an earlier date.

We expect these dates to be hit; we would look dimly on any last-minute
requests to move them. I would also reiterate, in case it becomes
relevant, that any change of control of some or all of Symantec's roots
would not be grounds for a renegotiation of these dates.

We hope that we can now move swiftly to the implementation phase, and
that as it progresses we will see improved levels of security for web
users and improved confidence in the WebPKI. We will be expecting and
looking for exemplary standards of CA best practice from Symantec in
general, and their new PKI in particular, going forward.

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

Re: Final Decision by Google on Symantec

[Gervase Markham via dev-security-policy]

On 31/07/17 15:17, Jakob Bohm wrote:
> I am referring to the fact that EV-trust is currently assigned to roots,
> not to SubCAs, at least as far as visible root store descriptions go.

You said the problem was Mozilla-specific; do other root stores not do
it this way?

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

Re: Miss-issuance: URI in dNSName SAN

[Gervase Markham via dev-security-policy]

On 25/07/17 18:13, Jeremy Rowley wrote:
> I would also love to see a more standardized notice mechanism that is
> universal to all CAs. Right now, notifying CAs is a pain as some have
> different webforms, some use email, and some don't readily tell you how to
> contact them about certificate problems.  

"Not readily telling" is a BR violation; if you come across a CA like
that, please do let us know. The info should be in the CCADB and in the
CAs report.

I agree it would be nice to have something more standard, but we have
what we have right now.

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

Re: Final Decision by Google on Symantec

[Gervase Markham via dev-security-policy]

On 29/07/17 23:45, Peter Bowen wrote:
> First, when the server authentication trust will bits be removed from
> the existing roots.  This is of notable importance for non-Firefox
> users of NSS.  Based on the Chrome email, it looks like they will
> remove trust bits in their git repo around August 23, 2018.  When will
> NSS remove the trust bits?

The NSS trust store represents Mozilla's decisions about what is
trustworthy. However, particularly if we match Chrome's dates, there is
a slightly unusual situation as we have taken a decision on
trustworthiness but, for other reasons, Firefox still trusts those certs
for a period. So one might well ask, should the decision be implemented
in NSS earlier than, or at the same time as, or even later than, Firefox
implements it? A good question.

> Second, how the dates apply to email protection certificates, if at
> all.  Chrome only deals with server authentication certificates, so
> their decision does not cover other types of certificates.  Will the
> email protection trust bits be turned off at some point?

Absent the bandwidth to spend more time on email-specific issues with
our root store, I would expect to stop trusting all the same roots for
email as well, at the same time.

> Third, what the requirements are for Symantec to submit new roots,
> including any limit to how many may be submitted.
> https://ccadb-public.secure.force.com/mozilla/IncludedCACertificateReport
> shows that there are currently 20 Symantec roots included.  Would it
> be reasonable for them to submit replacements on a 1:1 basis -- that
> is 20 new roots?

No. A new submission would be treated as any new submission. My guess
without talking to Symantec was that they might want four roots, for a
2x2 matrix of {RSA, ECC} and {EV, non-EV}. A figure in that ballpark
would be acceptable.

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

Re: TunRootCA2 root inclusion request

[Gervase Markham via dev-security-policy]

Hi Olfa,

On 31/07/17 11:55, Olfa Kaddachi wrote:
> 2) The deficiencies identified in those controls after the misissuance of 
> each of these certificates are essentially:
> •controls on the field subject alternative names :
> o this field must not contains private addresses
> o this filed must not contain 127.0.0.1 address
> o this filed must not contain a  local FQDN
> o this field must at least contain the CN

Given that some of these are BR requirements, why were these controls
not in place already?

From what date would you say that your CA has been compliant with the
CAB Forum Baseline Requirements?

> 3) The implemented and planned improvements to the technical controls to 
> prevent these errors from happening again:

When will these improvements be implemented? And, given that these are
only four possible ways a certificate can be messed up, what other
checks are going to be implemented at the same time?

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

Final Decision by Google on Symantec

[Gervase Markham via dev-security-policy]

Google have made a final decision on the various dates they plan to
implement as part of the consensus plan in the Symantec matter. The
message from blink-dev is included below.

Most of the dates have consensus - the dates for Symantec to implement
the Managed CA infrastructure are agreed by all, and the date for final
distrust of the old Symantec PKI is agreed by Google and Mozilla (to
within a week, at any rate). I proposed November 1st 2018. Google has
gone for October 23rd 2018; in practical terms, we would implement that
using Firefox 63 (October 16th) or 64 (November 27th).

However, there is some difference in the proposals for the date on which
browsers should dis-trust Symantec certificates issued before June 1st,
2016. This date is significant because after that, Symantec have been
required to log all their certs to CT and so there is much better
transparency of issuance practice. I proposed December 1st 2017. Google
strongly considered late January, but have finally chosen April 17th 2018.

We now have two choices. We can accept the Google date for ourselves, or
we can decide to implement something earlier. Implementing something
earlier would involve us leading on compatibility risk, and so would
need to get wider sign-off from within Mozilla, but nevertheless I would
like to get the opinions of the m.d.s.p community.

I would like to make a decision on this matter on or before July 31st,
as Symantec have asked for dates to be nailed down by then in order for
them to be on track with their Managed CA implementation timetable. If
no alternative decision is taken and communicated here and to Symantec,
the default will be that we will accept Google's final proposal as a
consensus date.

Gerv

 Forwarded Message 
Subject:Re: [blink-dev] Intent to Deprecate and Remove: Trust in
existing Symantec-issued Certificates
Date:   Thu, 27 Jul 2017 17:16:06 -0700
From:   Darin Fisher 
To: Darin Fisher 
CC: blink-dev 



Representing Google Chrome and the Chromium open source project, what
follows is our final proposal on this matter.


We’d like to first thank the blink-dev community for your input on this
discussion. After taking this input into consideration along with the
latest responses from Symantec and Mozilla, we have produced the
following proposal that is intended to be our final plan of action on
this matter.


Chrome 66 will distrust Symantec-issued TLS certificates issued before
June 1, 2016:

Chrome 66 will distrust Symantec-issued TLS certificates issued before
June 1, 2016, which is tentatively scheduled to hit Canary on January
19, 2018; Beta on March 15, 2018; and Stable (the vast majority of
Chrome users) on April 17, 2018. Affected site operators are strongly
encouraged to replace their TLS certificates before March 15, 2018 to
prevent breakage. Although this is significantly later than our initial
proposal of August 2017 and Mozilla’s proposal for late 2017
,
we think it hits an appropriate balance between the security risk to
Chrome users and minimizing disruption to the ecosystem. This time will
allow clear messaging and scheduling for site operators to update
certificates.


We considered a number of alternative dates for distrusting this subset
of existing certificates before landing on Chrome 66. Given the scale of
Symantec’s existing PKI and the impact to the ecosystem that these
mitigations pose, one of our goals was to consider dates that gave site
operators enough lead time, as well as to try to clear end-of-year time
periods where production freezes are typically in place. Chrome 62 which
comes out in October 2017 was seriously considered, but was rejected due
to concerns around not giving enough lead time for site operators.
Chrome 63 which comes out in December was rejected due to overlapping
with end-of-year freezes. Chrome 64 which comes out in late January 2018
was strongly considered, but its early release channels also overlap
with holiday and end of year freezes.  Chrome 65’s branch point is close
to the new year, and could present a challenge for some site operators.
Hence, Chrome 66 was chosen as the final approach.


Site operators currently using Symantec-issued TLS server certificates
that were issued before June 1, 2016 need to replace these certificates
as soon as possible to avoid disruption to their users. The distrust of
these certificates is necessary and is specifically targeted at removing
the risk of trusting old certificates that were issued under an
inadequately controlled infrastructure. Site operators can choose to
obtain their certificates from any trusted Certificate Authority.
Although the old infrastructure will be distrusted in the future (see
below), site operators with critical dependencies on Symantec’s current
infrastructure may also obtain replacement 

Re: Symantec Update on SubCA Proposal

[Gervase Markham via dev-security-policy]

Hi Rick,

Some more thoughts on your post. I continue to invite community
commentary on the issues we are discussing.

On 21/07/17 07:00, Rick Andrews wrote:
> In our June 1 post, we stated that we would update the community after the 
> end of the month. 

Indeed. I was more referring to the suggestions made in the meeting with
Mozilla about when the public statement would be forthcoming. But no matter.

> Correct. However, as we indicated in our update, with a change of
> this magnitude we believe that there will likely be material
> compatibility and interoperability issues that will only come to
> light once server operators begin the transition to the Managed CA
> issued certificates. Recognizing this, we recommend that we establish
> a clear process to evaluate exception requests that includes
> consultations with the browsers to handle such corner cases.
Operators who have initial difficulty with the transition can, of
course, stay on their certificates issued from the old infrastructure.
(It's worth noting that if all of those customers had recently renewed
their certificates, as my proposal suggests, then there would not be a
problem with their existing-infra certs expiring while they were
attempting to make the transition.)

How would you see such an exception process working, and how would it be
implemented technically?

> While this is true under the terms of the SubCA proposal, we do not
> believe this is consistent with the spirit of Google’s and Mozilla’s
> prior commentary on their intent regarding the SubCA proposal, which
> is to limit the issuance of Symantec certificates under Symantec’s
> existing infrastructure and governance.
I'm not sure how you reach that conclusion. We want to end new issuance
in December, you want it to continue until next May. How are our dates
more inconsistent than yours with a desire to limit the issuance of
Symantec certificates under the existing infrastructure and governance?
We want to limit it earlier.

> dates.  Accordingly, our intention and expectation is that the
> majority of certificates issued before June 1, 2016 that will need to
> be replaced before their expiration under the current SubCA proposal
> will occur after the Managed CA is implemented. This will ensure
> there are no limitations on the replacement certificates that are
> issued to affected customers, which limits the substantial risks of
> implementation problems if our customers are not given the
> appropriate time to plan and execute their certificate replacements.
It may be appropriate for the limitations on current-infra issuance
lifetime in the plan to be adjusted by a few months such that a
certificate issued now can continue to work until the full distrust date
of November 1st, 2018. This would effectively mean that there are no
(additional) limitations on the replacement certificates.

> In our post we explained our rationale of why this period needs to be
> a minimum of 9 months. It is important for the community to note the
> significant operational burden and compatibility / interoperability
> risks that our customers will face if they have to replace their
> certificates once, let alone twice.
Why do you see a compatibility and interoperability risk in the process
of replacing a certificate with an identical certificate except that is
a) definitely logged to CT, and b) has a later expiry date?

You may argue that it's a customer operational burden but again, if
customers have difficulty replacing their SSL certs in a 4-month
timeframe, then they are not well positioned to deal with a number of
potential crises in the SSL system, such as compromise (and distrust) of
an intermediate, or compromise of their webservers.

> Our recommendation for replacing certificates issued before June 1,
> 2016 by May 1, 2018 (and preferably by February 1, 2019) enables a
> single shift to our new PKI for SSL/TLS certificates and eliminates
> any necessity for organizations to replace their certificates
> multiple times.
As noted above, I am not particularly impressed by arguments that
"replacing our certificates twice in 2-3 years is too hard".

It's also worth noting that in the timeline you propose, organizations
would have only 5 months (Dec 1 2017 - May 1 2018), including the
holiday period, to test and deploy the actual certificates they would be
using from the Managed CAs - those which do carry compatibility risk.
And it's only 3 months if they want to replace with fully-validated
non-DV certificates. My plan allows 9 uninterrupted months for that,
which gives significantly more scope to deal with unexpected
compatibility problems caused by new algorithms, new chains, etc. etc.
If customers are asking for time to manage a transition to a new
hierarchy, and that is your key concern, the plan I am proposing gives
them significantly more of it than yours does.

> The practical effect of this suggestion is to require up to two early
> replacements for affected customers of certificates 

Re: Regarding CA requirements as to technical infrastructure utilized in automated domain validations, etc. (if any)

[Gervase Markham via dev-security-policy]

On 20/07/17 21:31, Ryan Sleevi wrote:
> Broadly, yes, but there's unfortunately a shade of IP issues that make it
> more difficult to contribute as directly as Gerv proposed. Gerv may accept
> any changes to the Mozilla side, but if the goal is to modify the Baseline
> Requirements, you'd need to sign the IPR policy of the CA/B Forum and join
> as an Interested Party before changes.

I'm on holiday at the moment but, as Ryan says, this particular part of
what CAs do is the part most subject to IPR restrictions and so work on
it is probably best done in a CAB Forum context rather than a more
informal process.

I will attempt to respond to your messages in more depth when I return.

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

Re: Symantec Update on SubCA Proposal

[Gervase Markham via dev-security-policy]

On 21/07/17 07:00, Rick Andrews wrote:
> In light of all of these implications, we respectfully request that Mozilla, 
> Google and the community consider the dates Symantec has proposed, which are 
> the results of our earnest and extensive efforts to implement the spirit of 
> the SubCA proposal. 

Thank you for the timeliness and completeness of your response. I am
travelling today, but will try and consider it over the weekend.

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

Re: Symantec Update on SubCA Proposal

[Gervase Markham via dev-security-policy]

Hi Steve,

Thanks for posting this. I appreciate the level of detail provided,
which is useful in giving us a basis for discussion. It's a little
regrettable, though, that it was published a couple of weeks after we
were led to expect it...

One note before we start: Symantec's business dealings regarding its CA
business are not of concern to Mozilla other than relating to the
"change of ownership or control" provisions in Mozilla policy (policy
2.5 section 8). However, if dates are proposed or agreed for
implementation of the consensus plan, we would not expect those dates to
be renegotiated because of a change of ownership or control.

Am I right in saying that, in order to hit these dates you are
proposing, you would strongly desire to get consensus on them by August 1st?

On 18/07/17 19:22, Steve Medin wrote:
> New Certificate Issuance: We believe the dates for transition of validation 
> and issuance to the Managed CA that are both aggressive and achievable are as 
> follows:
> 
> - Implement the Managed CA by December 1, 2017 (changed from August 8, 2017);
> 
> - Managed CA performs domain validation for all new certificates by December 
> 1, 2017 (changed from November 1, 2017); and
> 
> - Managed CA performs full validation for all certificates by February 1, 
> 2018. Prior to this date, reuse of Symantec authenticated organization 
> information would be allowable for certificates of <13 months in validity.

To summarise for those reading along: this represents a change of a
little less than 4 months for the first date, 1 month for the second
date, and the third date is as originally proposed.

Steve: to be clear, this means that browsers could implement a block on
certificates from Symantec's existing PKI as follows: after December
1st, 2017, they could dis-trust all certificates with a notBefore
greater than December 1st 2017?

Given the explanations Symantec has given as to why these dates are
reasonable, and the effort required to stand up the new PKI, I am minded
to accept them, particularly as they have managed to hit the third
originally-proposed date on the nose. However, I am still open to
community input.

> Replacement of Unexpired Certificates Issued Before June 1, 2016: There are 
> two major milestones that must be achieved after implementation of the 
> Managed CA in order to replace unexpired certificates issued before June 1, 
> 2016 that do not naturally expire before the distrust date(s) in the SubCA 
> proposal. Those include the full revalidation of certificate information and 
> then the customer replacement of those certificates. 

That is not necessarily so. The customers could replace their
certificates using new, CT-logged certificates from Symantec's old
infrastructure. This doesn't require any revalidation or any change in
the certificate chain, so should have excellent compatibility
properties, and it's something that could begin today. In fact, as I
understand it, Symantec has already been encouraging their customers to
do exactly this.

This would, of course, mean, that those certificates would need
replacing again at some point before the final total dis-trust of the
current Symantec PKI.

This activity would need to start during the December holiday season
when many organizations impose infrastructure blackout periods.  As
such, we believe that the only achievable timing for this transition is
after the holiday season. We understand that browsers may want to
technically enforce this transition and that multiple milestones may be
undesirable from a coding perspective. In order to accommodate a
simplified and cost efficient transition schedule (especially for
organizations that currently have certificates with notBefore dates of
both June 1, 2015 and June 1, 2016) and to allow impacted organizations
the time, as they will likely need to replace, test and operationalize
these replacement certificates in their infrastructure, we recommend
consolidating Chrome's distrust dates to a single date of May 1, 2018.
This would mean that Chrome's distrust of Symantec certificates issued
before June 1, 2015 would change from August 31, 2017 to May 1, 2018,
and that Chrome's distrust of Symantec certificates issued before June
1, 2016 would change from January 18, 2018 to May 1, 2018.

A key date for Mozilla is when we can tell our software to dis-trust any
certificate issued by the Symantec current PKI which was issued before
June 1st 2016, because certificates issued after that are guaranteed
(pretty much) to be in CT, and therefore are a bounded and known set.
Therefore pushing that date out to May 1st 2018 seems like a negative
from our perspective.

A two-stage strategy such as the one outlined above seems to us to be
worth investigating, as it would allow us to give Symantec more time to
transition its customers from the current to the new PKI (something
which might come with compatibility risk, as you have correctly noted)
without having to bear the risk of continuing to 

Re: Validation of Domains for secure email certificates

[Gervase Markham via dev-security-policy]

Hi Doug,

On 20/07/17 13:04, Doug Beattie wrote:
> Since there is no BR equivalent for issuance of S/MIME certificates (yet), 
> this is all CAs have to go on.  I was curious if you agree that all of these 
> methods meet the above requirement:

As you might imagine, this question puts me in a difficult position. If
I say that a certain method does meet the requirement, I am making
Mozilla policy up on the fly (and while on holiday ;-). If I say it does
not, I would perhaps panic a load of CAs into having to update their
issuance systems for fear of being dinged for misissuance.

It is unfortunate that there is no BR equivalent for email. However, I'm
not convinced that the best way forward is for Mozilla to attempt to
write one by degrees in response to questioning from CAs :-) I think the
best thing for you to do is to look at your issuance processes and ask
yourself whether you would be willing to stand up in a court of law and
assert that they were "reasonable measures". When thinking about that,
you could perhaps ask yourself whether you were doing any things which
had been specifically outlawed or deprecated in an SSL context by the
recent improvements in domain validation on that side of the house.

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

Re: Miss-issuance: URI in dNSName SAN

[Gervase Markham via dev-security-policy]

On 19/07/17 14:53, Alex Gaynor wrote:
> I'd like to report the following instance of miss-issuance:

Thank you. Again, I have drawn this message to the attention of the CAs
concerned (Government of Venezuela and Camerfirma).

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

Re: dNSName containing '/' / low serial number entropy

[Gervase Markham via dev-security-policy]

On 18/07/17 23:25, Charles Reiss wrote:
> https://crt.sh/?id=174827359 is a certificate issued by D-TRUST SSL



I'm supposed to be on holiday :-), but I have emailed the 3 CAs
concerned drawing these issues to their attention, and asking them to
comment here when they have discovered the cause.

Perhaps we need a wiki page on "how to best respond to an incident
report from Mozilla"? :-)

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

Re: Regarding CA requirements as to technical infrastructure utilized in automated domain validations, etc. (if any)

[Gervase Markham via dev-security-policy]

On 18/07/17 17:51, Matthew Hardeman wrote:
> The broader point I wish to make is that much can be done do improve the 
> strength of the various subset of the 10 methods which do rely solely on 
> network reliant automated validation methodologies.  The upside would be a 
> significant, demonstrable increase in difficulty for even well placed ISP 
> admins to compromise a compliant CAs validation processes.  The downside 
> would be increases in cost and complexity borne by the compliant CA.

Your point, in the abstract, is a reasonable one, but so is your further
point about trade-offs. The only way we can really make progress is for
you to propose specific changes to the language, and we can then discuss
the trade-offs of each.

> I noticed that too.  I assume it is still tied up in IPR hell?

No. IPR issues are solved. We are currently in arguments about what, if
any, additional necessary fixes to the text should go into the "restore
the text" ballot and what should go into a subsequent ballot, along with
the question of whether and which existing domain validations to
grandfather in and which to require that they be redone.

> I would advocate a level playing field here.  This would have the bonus 
> upside of helping to fix bad DNSSEC deployments.  If broken DNSSEC broke 
> ability to get a certificate anywhere, either the incorrect deployment would 
> likely be rolled back in the worst case or fixed in the best.

Certainly for CAA, we don't allow broken DNSSEC to fail open. I hope
that will be true of DNS-based validation methods - either after 190
passes, or soon after that.

> I believe there would be a massive improvement in the security of DNS query 
> and HTTP client fetch type validations if the CA were required to execute 
> multiple queries (ideally at least 3 or 4), sourced from different physical 
> locations (said locations having substantial network and geographic distance 
> between them) and each location utilizing significantly different internet 
> interconnection providers.

How could such a requirement be concretely specced in an auditable way?

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

Re: How long to resolve unaudited unconstrained intermediates?

[Gervase Markham via dev-security-policy]

On 12/07/17 21:18, Ben Wilson wrote:
> For CAs with emailProtection and proper name constraints, where would such 
> CAs appear in   
> https://crt.sh/mozilla-disclosures?   
>  
> https://crt.sh/mozilla-disclosures#constrainedother ? Or a new section of the 
> list, yet to be determined?

I believe Rob has now split the list into two.

> And for CAs where EKU contains emailProtection, what are the programmatic 
> criteria that determine whether the CA will be in such list as properly name 
> constrained, since the Baseline Requirements don’t cover email certificates?  
> (Presumably, a properly name-constrained email CA would not require any 
> audit.)

Rob would be able to say. But the criteria for whether an email
intermediate is properly name constrained are in Mozilla policy 2.5.

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

Re: WoSign new system passed Cure 53 system security audit

[Gervase Markham via dev-security-policy]

On 13/07/17 04:43, Matt Palmer wrote:
> Who should we contact at Cure 53?  Or should we just use the "business
> enquiries" contact address on their website?

I doubt Cure53 would be able to tell you anything more than what has
been said in the released summary document.

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

Re: Leaking private keys through web servers

[Gervase Markham via dev-security-policy]

On 12/07/17 15:47, Ryan Sleevi wrote:
> One challenge to consider is how this is quantified. Obviously, if you
> reported to Comodo the issue with the key, and then they issued another
> certificate with that key, arguably that's something Comodo should have
> caught. 

I'd say so.

> However, if you reported the compromise to, say, ACME CA, and then
> Comodo issued an equivalent cert, that's questionable. 

Sure. This would be a provision to deter accidental stupidity, not
wilful stupidity. The common case is a clueless person just resubmits
the same keypair to their current CA.

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

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

[Gervase Markham via dev-security-policy]

On 06/07/17 16:31, Doug Beattie wrote:
> Moving to a new CA within 6 months is certain reasonable, but having 
> enterprise customers also replace all certificates so the CA can be revoked 
> within 6 months might be a bit short, especially since several of those 
> months are over the holidays.  Would you consider an approach were the CAs 
> MUST not issue new certificates after 15 November (4 months) and the CAs 
> SHALL be revoked no later than 15 April (9 months)?

Yeah, OK. A bit late for this feedback :-), but I'll make a fix when I
get back. Can you file a bug, please?
https://github.com/mozilla/pkipolicy/issues

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

Re: FW: P-521

[Gervase Markham via dev-security-policy]

On 06/07/17 16:20, Ryan Sleevi wrote:
> compelling to add support for, and the security boundary between 192-bits
> and 256-bits is somewhere in the "heat death of the universe" level
> security (see
> https://www.imperialviolet.org/2014/05/25/strengthmatching.html )

Perhaps this is the discussion we need to be having, because Arkadiusz
asserted the difference was "night and day". Arkadiusz: do you have
backing for your assertion that P-521 has meaningfully improved levels
of security over P-384?

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]

On 05/07/17 18:08, Ryan Sleevi wrote:
> That is, the difference between, say:
> "label": "Verisign/RSA Secure Server CA"
> And
> CKA_LABEL "Verisign/RSA Secure Server CA"

Not much, but you've picked the clearest part of certdata.txt to compare :-)

> It isn't, because JSON can't.

As Rob notes, you can basically have them in all but name.

> I'm thinking you may have misunderstood? Are you suggesting certdata.txt is
> canonical or not? Otherwise, they can't continue doing it hat way - they
> would have to use whatever format you adopt, and whatever new tools.

I apologise that I seem not to have made this clear; my suggestion is
that the new file is canonical and (near-)complete, and certdata.txt,
ExtendedValidation.cpp and other files get generated from it, whenever
NSS/Firefox want to take a new release of the root store.

> Would you see it being as independent, or subservient to Firefox? If you
> saw it as independent, then you would presumably need to ensure that - like
> today - Firefox-specific needs, like EV or trust restrictions, did not
> creep into the general code.

I don't think that follows. EV trustworthiness is a property of the root
store. The root program makes those decisions, and it's entirely
appropriate that they be encoded in root program releases. We also make
decisions on "trust restrictions", so I'm not sure why you call that a
"Firefox-specific need".

> Of course, it seems like your argument is you want to express the Firefox
> behaviors either directly in NSS (as some trust restrictions are, via code)
> or via some external, shared metafile, which wouldn't be relevant to
> non-Firefox consumers.

Perhaps this is the disconnect. Several non-Firefox consumers have said
they are very interested in an encoding of the root program's partial
trust decisions.

> doing - they're interested in what Firefox is doing, and to get that, they
> would need to consume certdata.txt as well.

No, because they could consume whatever copy of the upstream file
Firefox had imported.

I don't expect "Mozilla's root store's trust view" and "Trusted by
Firefox" ever to diverge, apart from due to time skew, and perhaps
occasionally due to unencodeable restrictions.

Anyway, off on holiday, back in 3 weeks :-)

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]

On 06/07/17 14:44, Kai Engert wrote:
> My response was based on my interpretation of Gerv's suggestion, which I
> understood as follows:
> - certdata.txt remains the master, keeps maintained and published with NSS
> - we define a new file format that's accepted as the standard for several
>   root stores
> - we convert certdata.txt to that interchange format
> - we publish the conversion result (the Artifact)

My apologies. My suggestion is almost what you say, but with the
difference that the new format is the master (as it contains more info
than certdata.txt does) and certdata.txt gets regenerated whenever NSS
takes a new release of the root list, rather than the other way around.

So in this scenario the EV C++ file would be directly generated from the
new format; certdata.txt would not need to carry EV info. In fact, the
file format of certdata.txt would be unchanged.

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

Re: SRVNames in name constraints

[Gervase Markham via dev-security-policy]

On 05/07/17 15:10, Peter Bowen wrote:
> The second bullet says “any”.  As the rule for name constraints is that if 
> they are not present for a type, then any name is allowed, you have to 
> include name constraints for all four types.  The issue comes down to the 
> definition of “working server” certificates.  Mozilla does not use either 
> rfc822names or SRVName for name validation for server authentication, but you 
> could have a valid server certificate that has only these names.  Is 
> NSS/Firefox code considered a “technical constraint”?  If not, then all 
> technically constrained CA certificates need to have constraints on SRVName 
> and rfc822Name type General Names in addition to what they have now.

You are right; this is a bug. Server certs need to have constraints on
dNSName and ipAddress (v4 and v6), and email certs need to have
constraints on rfc822Name. It is not intended to require that e.g.
server certs have rfc822Name constraints in order to be considered
technically constrained.

What EKU(s) get used with certs containing SRVName? I confess I don't
understand this technology as well as I might.

Note that I'm going on holiday for 3 weeks; further engagement may have
to wait until I return.

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

Re: FW: P-521

[Gervase Markham via dev-security-policy]

On 05/07/17 14:49, Alex Gaynor wrote:
> Is it really true that additional curves are just additional parameters? I

That was my assumption; additional clue on this point would be welcome.

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

Re: FW: P-521

[Gervase Markham via dev-security-policy]

I agree crypto algorithms are not "gotta catch 'em all", but the
algorithm is ECDH, which NSS must implement anyway to support P-256 and
P-384, and a curve is just another set of parameters to it. I also think
that there is little value and there is potential confusion (as we have
seen) in Mozilla mandating a more restrictive set than the BRs and than
Microsoft:

> NIST FIPS PUB 186-4 recommends 4 curves over Prime Fields for use in US 
> public administration. These are:
> P-192, P-256, P-384, P-521
> 
> Baseline Requirements require:
> P-256,P-384 or  P-521
> 
> Key Requirements for Microsoft Trusted Root Program:
> P-256, P-384, P-521
> 
> Mozilla Root Store Policy:
> P-256, P-384

If there are, or become, interoperability issues in practice, then I
think we can leave that as the CA's lookout.

So I am currently minded to restore P-521 to the Mozilla permitted list.

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]

On 03/07/17 16:09, Kai Engert wrote:
> 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.

Of course.

> If the intention is to define a file format that is shared with other groups,
> who would be the owner of the file format? 

Good question.

> What if another group needs to
> introduce additional fields into the file format, that aren't of interest to
> Mozilla or NSS?

Using something like JSON means that people can add arbitrary keys for
their own use that everyone else can ignore. We'd need a lightweight
mechanism for how to do that, but it's not an uncommon pattern.

>> 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:
>   https://bugzilla.mozilla.org/show_bug.cgi?id=1294150

I think that having a new file format which encoded more or all of the
restrictions on CAs would mitigate some of the issues raised in that bug.

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]

On 03/07/17 16:53, Kai Engert wrote:
> 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.

Yes, apologies. I guess I meant $MODERN_VCS.

>>> I suspect, means anyone could plug
>>> in a modern CI
> 
> CI meaning Continuous Integration ?

Yes.

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]

On 29/06/17 16:27, Ryan Sleevi wrote:
> Well, the current certdata.txt is a text file. Do you believe it's 
> human-readable, especially sans-comments?

Human readability is, of course, a little bit of a continuum. You can
open it in a text editor and get some sense of what's going on, but it's
far from ideal.

How it is sans-comments is irrelevant, because it has comments. :-)

(For those not familiar, here's a sample from certdata.txt:

# Trust for Certificate "Verisign/RSA Secure Server CA"
CKA_CLASS CK_OBJECT_CLASS CKO_NETSCAPE_TRUST
CKA_TOKEN CK_BBOOL CK_TRUE
CKA_PRIVATE CK_BBOOL CK_FALSE
CKA_MODIFIABLE CK_BBOOL CK_FALSE
CKA_LABEL UTF8 "Verisign/RSA Secure Server CA"
CKA_CERT_SHA1_HASH MULTILINE_OCTAL
\104\143\305\061\327\314\301\000\147\224\141\053\266\126\323\277
\202\127\204\157
END
CKA_CERT_MD5_HASH MULTILINE_OCTAL
\164\173\202\003\103\360\000\236\153\263\354\107\277\205\245\223
END


> Please realize that this makes it impossible to effectively test changes, 
> without running said tool. This is, again, why certdata.txt being generated 
> is part of the build - so that when you change a file, it's reflected in the 
> build and code and you can effectively test.

Of course, those changing the root store might need access to the
compilation tool. But from a Mozilla PoV, that's just Kai normally. And
if people were used to editing and consuming certdata.txt, they could
continue to do it that way.

Thought experiment for you: if we decided to make the root store its own
thing with its own repo and its own release schedule, and therefore NSS
became a downstream consumer of it, where on occasion someone would
"take a release" by generating and checking in certdata.txt from
whatever format we decided to use, what problems would that cause?

> That's why "machine-readable" is, in effect, a must-have.

I'm not sure anyone is arguing with that.

> So clearly, we get in situations where not all restrictions are expressible.

Sure. As I said, I'm not interested in an arbitrarily complex file
format, so it will always be possible to come up with restrictions we
can't encode. But whatever format Apple chooses, unless they go the
"arbitrary complexity" path, they will have that problem, no?

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

Re: SRVNames in name constraints

[Gervase Markham via dev-security-policy]

On 03/07/17 17:44, Peter Bowen wrote:
> We still need to get the policy changed, even with the ballot.  As
> written right now, all name constrained certificates are no longer
> considered constrained.

I'm not sure what you mean... What's the issue you are raising here?

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

Re: SRVNames in name constraints

[Gervase Markham via dev-security-policy]

On 03/07/17 17:29, Peter Bowen wrote:
> "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.

Clearly, the set of things CAs must abide by is the restrictive union of
the BRs and all the browser policies. So this is in the nature of an
"unusable permission". So I don't think it's doing any harm.

Are there any plans for a ballot to enable this? I thought that perhaps
there might be. If so, it seems easiest to just leave it.

Gerv

___
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

[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

Re: P-521

[Gervase Markham via dev-security-policy]

On 29/06/17 00:11, Arkadiusz Ławniczak wrote:
> P-256, P-384 and P-521 curves are commonly implemented in all popular 
> cryptographic libraries such as OpenSSL, Microsoft Crypto API NB (CNG) or 
> Bouncy Castle, popular web browsers and FIPS 140-2 certified hardware 
> cryptographic modules.

Are you aware of any libraries or browsers which do not support P-521?

> But it seems that Mozilla (like the NSA in its "Suite B" recommendation) has 
> limited its policy to only two curves P-256 and P-384. 
> The reasons for this decision are known only to this agency and Mozilla. It 
> can be assumed that stronger cryptography is currently embarrassing for the 
> NSA, and the safety margin over the operation time is low. 

Do you believe that P-521 is usefully stronger than P-384?

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]

On 28/06/17 15:08, Ryan Sleevi wrote:
> It already (effectively) requires a tool to make sure it's done right, AIUI :)

Well, we should ask Kai what methods he uses to maintain it right now,
and whether he uses a tool.

> You can have a JSON file, but that doesn't mean it's human-readable in the 
> least.

You mean you can stick it all one one line? Or you can choose opaque key
and value names? Or something else?

> The CI tools don't check in artifacts. You're proposing giving some piece of 
> infrastructure the access to generate and check in files?

I am led to understand this is a fairly common pattern these days.

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

Because certdata.txt's format is not rich enough to support all the data
we would want to encode in a root store. We could consider extending it,
but why would we roll our own container format when there exist
perfectly good ones?

>> 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. Certainly, Google cannot and would not be able to 
> find an acceptable solution on #3, just looking at things like CT, without 
> introducing otherwise meaningless ontologies such as "Follows implementation 
> #37 for this root".

There are seven items on the list in #3. The first one is item 2, above.
The second is not a root store modification, technically. The third,
fifth and sixth would be accommodated if the new format had a "notAfter"
field. The fourth and seventh would be accommodated if the new format
had a "name constraints" field.

So putting all of #3, as it currently stands, into a new format seems
eminently doable. That doesn't mean every restriction we ever think of
could be covered, but the current ones (which are ones I can see us
using again in the future) could be.

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]

On 28/06/17 06:38, Ryan Sleevi wrote:
> Not really, at least from the NSS perspective. There's been the CVS ->
> Mercurial -> Git(ish) transitions, but otherwise, the tools and
> dependencies have largely remained the same.

Well, the fact that we now use Git, I suspect, means anyone could plug
in a modern CI 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.

> Put differently: If a human-readable version could be generated from a
> machine-readable file, is the objective met or not?

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.

> For example, you highlight that computer-readable only requires other tools
> to maintain, but that's not intrinsically true (you can have
> machine-readable text files, for example), and one in which you're just
> shifting the tooling concern from "NSS maintainers" to "NSS consumers"
> (which is worth calling out here; it's increasing the scale and scope of
> impact).

No, because NSS consumers could choose to continue consuming the
(autogenerated by the CI tool) certdata.txt.

> You've proposed solutions and goals that appear to align with "We want
> Apple to use our format", and are explicitly rejecting "We will
> interoperate with Microsoft using their format", while presenting it as "We
> want interoperability"

You want me to rank my goals in order of preference? :-)

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?".

> 3) If neither party arrives at an interoperable solution, are your goals
> met and is the work justified?

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.

> Well, regardless, you need the C file, unless you're also supposing that
> NSS directly consume the computer-readable file (adding both performance
> and security implications).

The C file I meant was ExtendedValidation.cpp.

> The wiki page you mention is already automatically generated (by virtue of
> Salesforce), 

No. The wiki page I meant was
https://wiki.mozilla.org/CA/Additional_Trust_Changes . Sorry for not
being clear on this.

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

It's these 3 files I'm hoping could be combined (almost totally or
totally) into one machine-readable store.

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]

On 27/06/17 12:17, Ryan Sleevi wrote:
> This was something the NSS developers explicitly moved away from with
> respect to certdata.c

It would be interesting to know the history of that; but we are in a
different place now in terms of the SCM system we use and the CI tools
available, versus what we were a few years ago.

If you were able to elaborate on the relevant history here, as you
obviously know it, that would be helpful.

>> That's one option. I would prefer something which is both human and
>> computer-readable, as certdata.txt (just about) is.
> 
> Why? Opinions without justification aren't as useful ;)

:-) Because human-readable only is clearly silly, and computer-readable
only is harder to maintain (requires tools other than a text editor). I
want it to be easily maintainable, easily browseable and also
unambiguously consumable by tools.

> Apple suggested they'd like to make this data available; my hope would
>> be that if a format could be defined, they might be persuaded to adopt it.
> 
> And if they can't, is that justified?
> 
> That is, it sounds like you're less concerned about cross-vendor
> interoperability, and only concerned with Apple interoperability. Is that
> correct?

I'm after interoperability with whoever wants to interoperate. The other
benefits I see for Mozilla are being able to better (if not perfectly)
express our root store's opinions on our level of trust for roots in a
single computer-readable file, rather than the combination of a text
file, a C++ file and a wiki page.

Given that the plan is to auto-generate the old formats when necessary,
I didn't think that maintaining the data in a different format would
cause anyone significant difficulty or hardship.

>> Like, really? Developing a set of JSON name-value pairs to encode some
>> fairly simple structured data has potential IP issues? What kind of mad
>> world do we live in?
> 
> It doesn't matter the format - it matters how and where it was developed.

As in, if I just make it up and start using it, people will be scared
I'm going to sue them over its use?

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]

On 27/06/17 10:35, Ryan Sleevi wrote:
> If that is the goal, it may be useful to know what the proposed limitations
> / dependencies are. For example, the translation of the txt to the c file
> generated non-trivial concern among the NSS development team to support.

I propose it be part of the checkin process (using a CI tool or similar)
rather than part of the build process. Therefore, there would be no new
build-time dependencies for NSS developers.

> For example, one possible suggestion is to adopt a scheme similar to, or
> identical to, Microsoft's authroot.stl, which is PKCS#7, with attributes
> for indicating age and expiration, and the ability to extend with
> vendor-specific attributes as needed. One perspective would be to say that
> Mozilla should just use this work.

That's one option. I would prefer something which is both human and
computer-readable, as certdata.txt (just about) is.

> Yet if the goal is cross-vendor compatibility, one can argue that is the
> best approach, as t changes the number of vendors implementing it to 2,
> from the present 1, and thus achieves that goal. As you introduce the
> concept of Apple, but which has historically been a non-participant here,
> it makes it hard to design a system acceptable to them.

Apple suggested they'd like to make this data available; my hope would
be that if a format could be defined, they might be persuaded to adopt it.

> Further, one could
> reasonably argue that an authroot.stl approach would trouble Apple, much as
> other non-SDO driven efforts have, due to IP concerns in the space.
> Presumably, such collaboration would need to occur somewhere with
> appropriate IP protections.

Like, really? Developing a set of JSON name-value pairs to encode some
fairly simple structured data has potential IP issues? What kind of mad
world do we live in?

> These criticisms are not meant to suggest I disagree with your goal, merely
> that it seems there would be a number of challenges in achieving your goal
> that discussion on m.d.s.p. would not resolve. The way to address these
> challenges seems to involve getting firm commitments and collaboration with
> other vendors (since that is your primary goal), 

Well, if there was some chance of someone taking on the work - which
perhaps there seems to be, based on other replies - then that would be a
good next step. But there's no point in me having those discussions if
there's no-one willing to do the work. Hence my original question.

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

Re: P-521

[Gervase Markham via dev-security-policy]

On 27/06/17 07:17, Kurt Roeckx wrote:
> I suggest you keep it for now.

An opinion without a rationale is not all that useful :-)

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]

On 27/06/17 04:16, Rob Stradling wrote:
> If the aim is to replace certdata.txt, authroot.stl, etc, with this new
> format, then I'm more interested.

I can't speak for other providers, but if such a spec existed, I would
be pushing for Mozilla to maintain our root store in that format, and
auto-generate certdata.txt (and perhaps ExtendedValidation.cpp) on
checkin for legacy uses.

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]

On 26/06/17 17:36, Ryan Sleevi wrote:
> Do you anticipate this being used to build trust decisions in other
> products, or simply inform what CAs are trusted (roughly)?

I don't have strong opinions about what people use the data for; I would
hope it would be usable for either purpose. After all, people use
certdata.txt for the latter purpose even though
https://wiki.mozilla.org/CA/Additional_Trust_Changes
exists...

> My understanding from the discussions is that this is targeted at the
> latter - that is, informative, and not to be used for trust decision
> capability - rather than being a full expression of the policies and
> capabilities of the root store.

I want it to be at least as capable as certdata.txt; I agree with the
issues raised in previous discussions about a domain-specific language,
and I don't want to go down the route of attempting something which can
specify arbitrarily-complex restrictions. But it could certainly have
reasonably simple mods like "only trusted for certs issued before date
X", or "name constrained in this way".

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

P-521

[Gervase Markham via dev-security-policy]

This issue seems to come up regularly, and I can never find the
discussion I'm sure we had about it, so I'm starting a thread here with
"P-521" in the subject so it'll be clear.

Should we be permitting use of this curve in our policy?

I removed it from the policy in
https://github.com/mozilla/pkipolicy/issues/5 because I was under the
impression that Firefox and/or NSS didn't support it. But I now see (not
sure how I didn't notice before) that the relevant bugs are unfixed or
WONTFIXed:
https://bugzilla.mozilla.org/show_bug.cgi?id=1129077
https://bugzilla.mozilla.org/show_bug.cgi?id=1128792

And I notice that the P-521/SHA-512 combination is recommended, or at
least specced, in TLS 1.3:
https://tools.ietf.org/html/draft-ietf-tls-tls13-20#section-4.2.3

But it seems like BoringSSL doesn't support it:
https://boringssl.googlesource.com/boringssl/+/e9fc3e547e557492316932b62881c3386973ceb2

So what should we be doing in our policy (which, by principle, looks to
Mozilla's needs first)? Banning it? Discouraging it but allowing it?
Permitting it? Something else?

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

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

[Gervase Markham via dev-security-policy]

A few root store operators at the recent CAB Forum meeting informally
discussed the idea of a common format for root store information, and
that this would be a good idea. More and more innovative services find
it useful to download and consume trust store data from multiple
parties, and at the moment there are various hacky solutions and
conversion scripts in use.

Apple are already moving to publish their trust store in
machine-readable form (at the moment, the most machine-readable version
is in their open source repo, and that's often out of date). I'm not
sure what format they are planning, but it may not be too late to sell
them on something common. We currently have certdata.txt, which is
perhaps not ideal as a format; if we moved to something better, we could
always generate certdata.txt from that for those who still needed that form.

I'm told there are a couple of formats out there, including one in XML
(urk). But it would be nice to have something which was both machine and
human readable and writeable; in the age where the bar is set by JSON,
I'm not sure XML counts as that any more.

The trouble is, I'm not sure anyone in those conversations was also
musing about how much free time they had for such work. Is anyone here
interested in taking on the task of gathering requirements and editing a
spec for an (e.g.) JSON root store format?

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

Mozilla Root Store Policy 2.5 Published

[Gervase Markham via dev-security-policy]

Version 2.5 of Mozilla's CA Policy has now been published. You can
find it here:
https://github.com/mozilla/pkipolicy/blob/2.5/rootstore/policy.md

This document incorporates by reference the Common CCADB Policy 1.0.1:
https://github.com/mozilla/pkipolicy/blob/2.5/ccadb/policy.md
or
http://ccadb.org/policy
The previous Mozilla CCADB Policy document, which was very short, is now
part of the main policy.

Other than the requirement for using the Ten Blessed Methods (July 21
2017), and the requirement for constraints on email intermediates
(January 15 2018 for existing intermediates), all of the new provisions
are effective immediately. You can see the differences here:
https://github.com/mozilla/pkipolicy/compare/2.4.1...2.5

There were a couple of changes post-review; I added a deadline, and we
also made it clear in our policy what is clear elsewhere, that audits
must be yearly, period-of-time, and contiguous.

The copy of the policy on www.mozilla.org will be updated soon; this can
take a few days.
https://bugzilla.mozilla.org/show_bug.cgi?id=1375881

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

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

[Gervase Markham via dev-security-policy]

On 21/06/17 16:58, Doug Beattie wrote:
>> It's worth noting that if we had discovered this situation for SSL - that an
>> unconstrained intermediate or uncontrolled power of issuance had been
>> given to a company with no audit - we would be requiring the intermediate
>> be revoked today, and probably taking further action as well.
> 
> Agree

After consultation, I have decided to implement this requirement with a
phase-in period of six months, for already-existing intermediates. So
before 15th January 2018 (add a bit because of Christmas) these
customers, and any others like them at any other CA, need to have audits
(over at least 30 days of operations), move to a name-constrained
intermediate, or move to a managed service which does domain ownership
validation on each domain added to the system. I expect these two
intermediates to be revoked on or before 15th January 2018.

I realise this is not what you were hoping for, but it's not reasonable
to leave unconstrained intermediates in the hands of those not qualified
to hold them for a further 2 years. I am allowing six months because,
despite the weakness of the previous controls, you were in compliance
with them and so it's not reasonable to ask for a super-quick move.

https://github.com/mozilla/pkipolicy/commit/44ae763f24d6509bb2311d33950108ec5ec87082

(ignore the erroneously-added logfile).

> Are there any other CAs or mail vendors that have tested name constrained 
> issuing CAs? If using name constrained CAs don’t work with some or all of the 
> mail applications, it seems like we might as well recommend a change to the 
> requirement.

I am open to hearing further evidence on this point.

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

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

[Gervase Markham via dev-security-policy]

On 21/06/17 13:13, Doug Beattie wrote:
>> Do they have audits of any sort?
> 
> There had not been any audit requirements for EKU technically 
> constrained CAs, so no, there are no audits.

In your view, having an EKU limiting the intermediate to just SSL or to
just email makes it a technically constrained CA, and therefore not
subject to audit under any root program?

I ask because Microsoft's policy at http://aka.ms/auditreqs says:

"Microsoft requires that every CA submit evidence of a Qualifying Audit
on an annual basis for the CA and any non-limited root within its PKI
chain."

In your view, are these two intermediates, which are constrained only by
having the email and client auth EKUs, "limited" or "non-limited"?

>>> The other customer complies the prior words in the Mozilla policy
>> regarding "Business Controls".

By implication, and reading your previous emails, are you saying that
the first customer does not comply with those words?

> That is correct.  Enforcement is via contractual/business controls which is 
> compliant with the current policy, as vague and weak as that is (and you've 
> previously acknowledged).  Moving from this level of control to being audited 
> or having name constraints will take more time that just a couple of months.  

Leaving aside the requirements of other root programs, I agree this
arrangement with the second customer is compliant with our current
policy. For the new policy, they have 3 options: a) get an audit, b) use
a name-constrained intermediate, or c) move to a hosted service which
limits them to an approved set of domains.

Consistent with the principles outlined for Symantec regarding business
continuity, the fact that GlobalSign does not have the capability to
provide c) should not be a factor in us determining how long we should
allow this particular situation to continue.

It's worth noting that if we had discovered this situation for SSL -
that an unconstrained intermediate or uncontrolled power of issuance had
been given to a company with no audit - we would be requiring the
intermediate be revoked today, and probably taking further action as well.

> Two  further points:
> 1) It’s not clear of email applications work with name constrained CAs.  Some 
> have reported email applications do not work, however, I have not tested this 
> case. 

That sounds like something you might want to investigate as a matter of
urgency :-)

> Both of the customers are large US based companies with contractual 
> obligations to only issue secure email certificates to domains which they own 
> and control so I hope we can come to an agreement on the phased plan.

The size or geographic location of a company is not necessarily
correlated to their competence in handling unconstrained (for email)
intermediate CAs correctly. Our default assumption must be that, without
audit, they don't know how to handle it properly.

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

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

[Gervase Markham via dev-security-policy]

Hi Doug,

On 20/06/17 16:31, Doug Beattie wrote:
> I'd like to recommend a phase in of the requirement for technically 
> constrained CAs that issue Secure email certificates.

For those following along at home, that is this change:
https://github.com/mozilla/pkipolicy/issues/69
https://github.com/mozilla/pkipolicy/commit/f96076a01ef10e5d6a84fa4b042227512925cb7c

> We have 2 customers that can issue Secure Email certificates that are
> not technically constrained with name Constraints (the EKU is
> constrained to Secure Email and ClientAuth).>
> One customer operates the CA within their environment and has been
> doing so for several years. Even though we've been encouraging them to
> move back to a Name Constrained CA or a hosted service, 

To be clear: this customer has the ability to issue email certificates
for any email address on the planet, and they control their own
intermediate in their own infrastructure?

Do they have audits of any sort?

What are their objections to moving to a hosted service?

> The other customer complies the prior words in the Mozilla policy regarding 
> "Business Controls".  We have an agreement with them where we issue them 
> Secure Email certificates from our Infrastructure for domains they host and 
> are contractually bound to using those certificates only for the matching 
> mail account.  Due to the number of different domains managed and fact they 
> obtain certificates on behalf of the users, it's difficult to enforce 
> validation of the email address.  We have plans to add features to this 
> issuance platform that will resolve this, but not in the near term.

So even though this issuance is from your infrastructure, there are no
restrictions on the domains they can request issuance from?

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

Re: Symantec response to Google proposal

[Gervase Markham via dev-security-policy]

On 20/06/17 01:21, Jakob Bohm wrote:
> 2. For any certificate bundle that needs to be incorporated into the
>   Mozilla root stores, a significant period (3 to 6 months at least)
>   will be needed between acceptance by Mozilla and actual trust by
>   Mozilla users.

Not if the roots were cross-signed by the old PKI.

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

Principles and Goals

[Gervase Markham via dev-security-policy]

I think it might be useful to take a step back and remind ourselves of
Mozilla's mission, principles and goals with regard to resolving the
situation with Symantec. These will be useful as we flesh out the
details of the consensus proposal, particularly concerning dates.

First, a quick reminder on goals, anti-goals and non-goals.

Goal:  something you specifically want to achieve.
Anti-goal: something you specifically want to not achieve.
Non-goal:  something you are explicitly not trying to achieve.

Non-goals differ from anti-goals in that you will try hard not to
achieve an anti-goal, but you don't mind either way whether a non-goal
happens or not.

In deciding what is a goal, anti-goal or non-goal, we need to establish
our principles, which in this case I will define as higher-level things
we believe and are trying to achieve with our root program which are not
specific to this particular situation. Mozilla's principles relating to
this situation all flow from our overarching mission to do good to and
for the Web, and the manifesto principle that the security of web
citizens is essential. More specifically, I would characterise our
principles here as follows:

Root Program Principles
---

1) Maintain the public's trust in the WebPKI as a whole.

2) In any change, minimise disruption to websites and web end-users.

3) Make decisions for the benefit of Mozilla and its mission first.

4) Operate in a transparent, consultative and open way.


In this case, we are attempting to maintain trust in the WebPKI by
executing the sub-task of eliminating hierarchies, systems and/or
issuers who have lost trust. So our goals in this particular situation,
where we no longer have trust in Symantec's "old" (current) PKI, are
therefore:

Symantec Remediation Goals
--

A) Remove the roots relating to the old Symantec PKI from our root store
as quickly as possible.

B) Before we can do so, take interim steps to minimise risk by reducing
the scope of trust in their old PKI, such as:

* not trusting new Symantec-controlled issuance;
* not trusting certs without proof of publication; and/or
* not trusting certs issued before a certain date;

all as quickly as possible.

C) Make sure that those certificate users with a hard dependency on
Symantec's old PKI and also a requirement for public trust have, or
mostly have, sufficient transition time to eliminate that dependency.


Something which is a non-goal is that Symantec be able to continue
issuing all the same types of certs at the same volumes to all of their
customers without interruption. This will almost certainly be a goal for
Symantec, but it's not a goal for Mozilla. It must be pointed out that
it's not an anti-goal either - we are not _aiming_ to affect Symantec's
business. But we are not going to take decisions which treat maintaining
those capabilities unchanged as a goal.

This point will become important when Symantec publishes the results of
the process they are currently going through to find CAs to work with
them on taking over issuance from their old PKI. Their plans and the
dates associated with them will, no doubt, be predicated on that goal,
which is not our goal (but to repeat, is not an anti-goal), and will
need to be evaluated in that light. Symantec also need to be clear that
"we signed a contract to meet this goal" is not an argument which will
cause that goal to become Mozilla's goal.

Any set of dates we require which are not "as long as you need" will
inevitably have a level of arbitrariness about them. Why not a week
more? Why not a week less? I think it would be unhelpful, therefore, to
get into a date-based "negotiation". We need to make our best estimate
of how long it would take Symantec and their partners to put in place
systems which allow our goals to be met, and choose deadlines accordingly.

The only other thing which might modify our requirements is the fact
that this is a consensus proposal we are implementing. Consensus is a
good thing for the WebPKI and for Symantec, who I'm sure would not
welcome the prospect of implementing several different remediation plans
at the same time. Therefore, we should also take into account the
published principles and goals of other root store operators who are
part of the consensus, and how the proposal might need to be written to
also meet their goals.

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

Re: New undisclosed intermediates

[Gervase Markham via dev-security-policy]

On 09/06/17 16:37, Jakob Bohm wrote:
> This seems to directly violate the often proposed (but apparently not
> yet enacted) rule that different root certs must have different keys
> (if that rule has been incorporated into a current policy).

This has come up enough times now that I've filed an issue for it:
https://github.com/mozilla/pkipolicy/issues/88

People with opinions on one side or the other should feel free to add
comments.

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

Re: New undisclosed intermediates

[Gervase Markham via dev-security-policy]

On 09/06/17 11:29, Rob Stradling wrote:
> These two certs share the same Name and Key.  Therefore, the signature
> on the first can be verified by the public key in the second; and vice
> versa.  And clearly the Subject Name in each one matches the Issuer Name
> in the other.  This means that the first chains to the second, and also
> that the second chains to the first.

And a certificate issued by either can chain to either?

Do we have any idea what NSS does with a cert like
https://crt.sh/?id=149444544 when it's presented in a bundle by a
webserver which includes an EE cert which chains up to
https://crt.sh/?id=12977063 ?

It seems like one potential (if perhaps never build path) might be:

EE -> 149444544 -> 149444544 -> 149444544 ... -> 149444544 -> 12977063

?

I sort of seem to remember Brian or someone saying that mozilla::pkix
ignores self-issued certificates, but I'd like to have a definitive word.

> The policy says:
> "All certificates that are capable of being used to issue new
> certificates, and which directly or transitively chain to a certificate
> included in Mozilla's CA Certificate Program, MUST be operated in
> accordance with this policy and MUST either be technically constrained
> or be publicly disclosed and audited."

How would you reword the policy to exclude self-issued certificates?

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

Re: New undisclosed intermediates

[Gervase Markham via dev-security-policy]

On 08/06/17 15:37, Jeremy Rowley wrote:
> If you added them automatically to OneCRL, how would you create new
> intermediates? Would it be anything over X days old and undisclosed is
> automatically added? 

Yes, that :-) Sorry if that wasn't clear. The deadline, as of policy
2.5, is a week (section 5.3.2).

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: Make it clear that Mozilla policy has wider scope than the BRs

[Gervase Markham via dev-security-policy]

On 08/06/17 19:46, Jakob Bohm wrote:
> How about the following, which seems more correct

Yes; I'm not sure why David thought the original version's two sentences
were contradicting rach other.

> Insofar as the Baseline Requirements attempt to define their own scope,
> the scope of this policy (section 1.1) overrides that. Mozilla
> thus requires CA operations relating to issuance of all SSL certificates
> in the scope of this policy to conform to the Baseline Requirements.

This is marginally better; wording updated :-)

Gerv

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

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

[Gervase Markham via dev-security-policy]

Hi everyone,

I've made the last change I currently intend to make for version 2.5 of
Mozilla's Root Store Policy. The last task before shipping it is to
assess whether any of the changes require a phase-in period, i.e. for
some reason, they can't be applicable immediately.

CAs and others are requested to comment, with rationale, as to why
particular changes will need a phase-in period and what period they are
proposing as appropriate. This is also an opportunity for interested
parties to do a general final review.

I hope to ship the policy immediately after the CAB Forum meeting in
Berlin, which is happening from the 20th to the 22nd of June.

You can see the differences between version 2.4.1 and version 2.5 here
in diff format (click "Files Changed" and then "Load Diff"):
https://github.com/mozilla/pkipolicy/compare/2.4.1...master

or here in a more rich format:
https://github.com/mozilla/pkipolicy/compare/2.4.1...master?short_path=b7447c8
(click "Files Changed" and scroll down).

The CCADB Policy changes are trivial and can be ignored.

Here is my summary of what's changed that's significant (with section
numbers in brackets), although you should not rely on it to be complete:


1) Certificates with anyEKU have been added to the scope. (1.1)

2) CAs are required to "follow industry best practice for securing their
networks, for example by conforming to the CAB Forum Network Security
Guidelines or a successor document". (2.1)

3) Accounts which perform "Registration Authority or Delegated Third
Party functions" are now also required to have multi-factor auth. (2.1)

4) CAs are required to follow, but not required to contribute to,
mozilla.dev.security.policy. (2.1)

5) CAs are required to use only the 10 Blessed Methods for domain
validation. (2.2) This requirement has already had a deadline set for it
in the most recent CA Communication; that deadline is 21st July 2017.

6) WebTrust BR audits must now use version 2.2 or later of the audit
criteria. (3.1.1)

7) The ETSI audit criteria requirements have been updated to be
accurate. (3.1.2.2). ETSI TS 102 042 and TS 101 456 audits will only be
accepted for audit periods ending in July 2017 or earlier.

8) There are further requirements on the information that needs to be
contained in publicly-available audit information. (3.1.3)

9) Mozilla now requires that auditors be qualified in the scheme they
are using, unless agreed in writing beforehand. (3.2)

10) When CAs do their BR-required yearly update of their CPs and CPSes,
they MUST indicate this by incrementing the version number and adding a
dated changelog entry. (3.3)

11) The Mozilla CCADB Policy has been merged into the Root Store Policy,
but the requirements have not changed. (4.1/4.2)

12) CA are required at all times to operate in accordance with the
applicable CP and CPS. (5.2)

13) The requirements for what constitutes a TCSC for email have been
reformed to actually make some sense - the cert now has to have
meaningful technical constraints on rfc822Name. (5.3.1)

14) New intermediates must be disclosed in the CCADB within a week. (5.3.2)

15) Requirements for revocation are now delegated to the BRs rather than
being explicitly enumerated. (6)

16) Section 7.4 ("Transfers") has been replaced by a new section 8 which
requires CAs to notify of various operational changes. This is a
merge-in of text equivalent to the existing Root Transfer Policy which
was documented on our wiki. (8)


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: Make it clear that Mozilla policy has wider scope than the BRs

[Gervase Markham via dev-security-policy]

On 02/06/17 11:28, Gervase Markham wrote:
> Proposal: add a bullet to section 2.3, where we define BR exceptions:
> 
> "Insofar as the Baseline Requirements attempt to define their own scope,
> the scope of this policy (section 1.1) overrides that. Mozilla expects
> CA operations relating to issuance of all SSL certificates in the scope
> of this policy to conform to the Baseline Requirements."

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: Add definition of "mis-issuance"

[Gervase Markham via dev-security-policy]

On 04/06/17 03:03, Matt Palmer wrote:
> For whatever it is worth, I am a fan of this way of defining "misissuance".

This is an "enumerating badness" vs. "enumerating goodness" question. My
original draft attempted to (without limitation) enumerate some badness,
and you and Ryan are suggesting that it would be better instead to
enumerate goodness.

I agree. However, enumerating goodness is a bit harder because you need
to make sure you get all the goodness, so as not to accidentally ban
something you want. This we could do, but I feel it would require
consultation with CAs.

Therefore, I will add the non-limiting enumerating badness version to
the policy, as an improvement on the current wording which also
enumerates badness, but I've filed these two issues:

https://github.com/mozilla/pkipolicy/issues/86
https://github.com/mozilla/pkipolicy/issues/85

on improving this further in the future.

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

Re: New undisclosed intermediates

[Gervase Markham via dev-security-policy]

On 08/06/17 10:17, Gervase Markham wrote:
> What downsides would there be, other than the obvious "some sites might
> break", to us just adding any such intermediate certs directly to OneCRL?

We provide reports which allow CAs to download the stored intermediate
cert data:

https://ccadb-public.secure.force.com/mozilla/PublicAllIntermediateCertsCSV

So if they don't want this to happen to them, all they need to do is
write a script to download the data daily, compare it with their
internal records, and send out an alert when it finds a discrepancy.

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

Re: New undisclosed intermediates

[Gervase Markham via dev-security-policy]

On 08/06/17 00:42, Jonathan Rudenberg wrote:
> Yet another batch of undisclosed intermediates has shown up in CT:

Like, seriously?

Every CA in our program indicated that they would disclose all their
intermediates by June 30th, 2016:

https://ccadb-public.secure.force.com/mozillacommunications/CACommResponsesOnlyReport?CommunicationId=a05o00iHdtx=Q4

I don't really want to switch to an intermediate whitelist because that
requires coding.

My patience is expiring. What CA can't keep track of the intermediates
it issues? How hard is that, really?

What downsides would there be, other than the obvious "some sites might
break", to us just adding any such intermediate certs directly to OneCRL?

Gerv

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

Re: Mozilla requirements of Symantec

[Gervase Markham via dev-security-policy]

On 07/06/17 22:30, Jakob Bohm wrote:
> Potential clarification: By "New PKI", Mozilla apparently refers to the
> "Managed CAs", "Transition to a New Symantec PKI" and related parts of
> the plan, not to the "new roots" for the "modernized platform" / "new
> infrastructure".

I expect those things to be interlinked; by "New PKI" I was referring to
them both.

Symantec has not yet stated how they plan to structure their new
arrangements, but I would expect that the intermediate certs run by the
managed CAs would in some way become part of Symantec's new PKI,
operated by them, once it was up and running. Ryan laid out a way
Symantec could structure this on blink-dev, I believe, but the final
structure is up to them.

> Potential clarification: Mozilla's #3 requirement applies to both the
> "new PKI" and the "new roots" for the "new infrastructure".

Yes, I suppose so, although I would expect such an extra-detailed audit
to be done on the new infrastructure rather than on the Managed CA
infrastructure which is owned by another CA.

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

Re: An alternate perspective on Symantec

[Gervase Markham via dev-security-policy]

On 07/06/17 06:14, userwithuid wrote:
> 2. Having Symantec inform their subscribers, as David mentions, is a great 
> idea.

I believe Ryan has pointed out, here or elsewhere, why "must notify
customers" requirements are problematic.

Gerv


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

Re: Symantec response to Google proposal

[Gervase Markham via dev-security-policy]

On 06/06/17 19:59, Jakob Bohm wrote:
> I don't see a problem in access to this being subject to a reasonable
> NDA that allows Mozilla to show it to their choice of up to 50 external
> experts (I don't expect to be one of those 50).

The problem with an NDA is that if the audit reports significant holes
in Symantec's security story, we can't talk about them here.

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

Mozilla requirements of Symantec

[Gervase Markham via dev-security-policy]

Hi Steve,

I'm writing to you in your role as the Primary Point of Contact for
Symantec with regard to the Mozilla Root Program. I am writing with a
list of Mozilla-specific additions to the consensus remediation proposal
for Symantec, as documented by Google.

We note that you have raised a number of objections and queries with
regard to the consensus proposal. As you know, we are considering our
responses to those. We reserve the right to make additional requests of
Symantec in relation to any changes which might be made to that
proposal, or for other reasons.

However, we have formulated an initial list of Mozilla-specific addenda
to the consensus proposal and feel now is a good time to pass them on to
Symantec for your official consideration and comment. We would prefer
comments in mozilla.dev.security.policy (to which this notice has been
CCed), and in any event by close of business on Monday 12th June.

1) Mozilla would wish, after the 2017-08-08 date as documented in the
consensus proposal, to alter Firefox such that it trusts certificates
issued in the "new PKI" directly by embedding a set of certs or trust
anchors which are part of that PKI, and can therefore distrust any new
cert which is issued by the old PKI on a "notBefore" basis. We therefore
require that Symantec arrange their new PKI and provide us with
sufficient information in good time to be able to do that.

2) Mozilla would wish, at some point in the future sooner than November
2020 (39 months after 2017-08-08, the date when Symantec need to be
doing new issuance from the new PKI), to be certain that we are fully
distrusting the old PKI. As things currently stand technically,
distrusting the old PKI would mean removing the roots, and so Symantec
would have to move their customers to the new PKI at a rate faster than
natural certificate expiry. Rather than arbitrarily set a date here, we
are willing to discuss what date might be reasonable with Symantec, but
would expect it to be some time in 2018.

As you know, Firefox currently does not act upon embedded CT
information, and so CT-based mechanisms are not a suitable basis for us
to determine trust upon. Were that to change, we may be able to consider
a continued trust of CT-logged certs, but would still want to dis-trust
non-CT-logged certs sooner than November 2020.

3) If any additional audit is performed by Symantec, including but not
limited to one that "that includes a description of the auditor’s tests
of controls and results", then the intended users of the audit report
must also include persons who assist in decisions related to the trusted
status of Certification Authorities within Mozilla products. For any
audit to unusually detailed criteria, it is permitted to place this
information behind a login (or require it to be so placed) as long as
Mozilla is allowed to give access to any member of our community that we
wish.

We look forward to hearing Symantec's response to these requirements.

With best wishes,

Gerv

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

Re: Symantec response to Google proposal

[Gervase Markham via dev-security-policy]

Here are some thoughts from me:

On 06/06/17 15:02, Gervase Markham wrote:
> 1) Scope of Distrust

I have sought more information from Google on this.

> 2) Timeline

I think the question here is, what is our position, and on what basis do
we decide it? If we want to impose an aggressive but achievable
timeline, how do we determine what that is? Who do we ask for a second
opinion? How do we evaluate statements from Symantec?

> 3) SubCA Audit Type

This would be very difficult to agree to without good rationale; section
8 audits are very weak things compared to the normal ones.

> 4) Validation Task Ownership

I have sought more information from Google on this.

> 5) Use of DTPs by SubCA
> 
> Google proposal: SubCAs may not use Delegated Third Parties in the
> validation process for domain names or IP addresses.
> Symantec proposal: SubCAs should be allowed to continue to use them in
> situations where they already do.

Our research in the last CA Communication suggests that only two small
CAs do any form of delegation of domain name or IP address ownership
validation. Therefore, it's not clear why Symantec would need this
ability, and my sense is to say No.

> 6) SubCA Audit Timing

I have sought more information from Google on this.

> 7) Detailed Audits
> 
> Google proposal: Symantec may be requested to provide "SOC2" (more
> detailed) audits of their new infrastructure prior to it being ruled
> acceptable for use.
> Symantec proposal: such audits should be provided only under NDA.
> Rationale: they include detailed information of a sensitive nature.

If these audits are to be useful to Mozilla, we need to be able to make
them available to people of our choosing. They can be behind a login
system, if we are able to give out access credentials as we choose. But
an NDA is not acceptable.

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: Add definition of "mis-issuance"

[Gervase Markham via dev-security-policy]

On 04/06/17 03:03, Matt Palmer wrote:
> For whatever it is worth, I am a fan of this way of defining "misissuance".

So you think we should use the word "misissuance" for all forms of
imperfect issuance, and then have a gradated reaction depending on the
type and circumstances, rather than use the word "misissuance" for a
security problem, and another word (e.g. "misconstructed") for the other
ones?

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

Re: New undisclosed intermediates

[Gervase Markham via dev-security-policy]

On 05/06/17 14:29, Alex Gaynor wrote:
> As I've expressed before, I find it baffling that this still happens.

I am also disappointed. I have half a mind to keep track of how often
this happens per CA, and impose a mandatory delay of 1 month per
incident to that CA's next attempt to include a new root or get a trust
bit or EV change in our store. :-)

Aside from taking a note of how often this happens and it perhaps
appearing in a future CA investigation as part of evidence of
incompetence, does anyone else have ideas about how we can further
incentivise CA compliance with a requirement which was promulgated some
time ago, for which all the deadlines have passed, and which should be a
simple matter of paperwork?

> To
> approach this more productively, I'd be very appreciative if someone from a
> CA could describe how they approach disclosing intermediates, where it fits
> into their process, how they track progress, etc.

Well, I suspect the processes are different per-CA, and if you get such
an explanation, it'll be from a CA which doesn't make this sort of
mistake :-)

Also, different CAs have different PKI complexities. While the deadline
we imposed on them for getting things in order has passed, I would be a
bit less grumpy about DigiCert discovering a 'new' old intermediate in
their Verizon-inherited mess that they didn't know about before, than if
some small CA with a simple PKI doesn't disclose one they issued a
couple of months ago.

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

Re: On remedies for CAs behaving badly

[Gervase Markham via dev-security-policy]

On 05/06/17 16:52, Matthew Hardeman wrote:
> Has there ever been an effort by the root programs to directly assess
> monetary penalties to the CAs -- never for inclusion -- but rather as
> part of a remediation program?

Another fact to bear in mind when discussing this is that, for a number
of reasons, and unlike e.g. Microsoft, Mozilla has no formal contract
with the CAs in its program. The relevance of that to this idea should
be reasonably obvious. :-)

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: Make it clear that Mozilla policy has wider scope than the BRs

[Gervase Markham via dev-security-policy]

On 02/06/17 17:07, Peter Bowen wrote:
> Should Mozilla include a clear definition of "SSL certificates" in the
> policy?  And should it be based on technical attributes rather than
> intent of the issuer?

Absolutely Yes to your second sentence :-). We do have a clear
definition of what's in scope; however, we don't subclassify
specifically into "SSL" and "email" except by implication from the EKU.
And that leaves the question of what to do with anyEKU.

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: Make it clear that Mozilla policy has wider scope than the BRs

[Gervase Markham via dev-security-policy]

On 02/06/17 17:24, Kurt Roeckx wrote:
> On Fri, Jun 02, 2017 at 04:50:44PM +0100, Gervase Markham wrote:
>> On 02/06/17 12:24, Kurt Roeckx wrote:
>>> Should that be "all certificates" instead of "all SSL certificates"?
>>
>> No; the Baseline Requirements apply only to SSL certificates.
> 
> Then I don't understand what you're trying to do. If the BR
> already apply to all SSL certificates, 

No. The Baseline Requirements state that they apply to _some_ SSL
certificates. Exactly which ones is not clear because the BRs use
language of intent. From section 1.1: "These Requirements only address
Certificates intended to be used for authenticating servers accessible
through the Internet."

Mozilla does not believe the language of intent is useful, and wants to
use language of capability to define scope. Therefore, we have our own
scope statement for our policy, and now want to make it clear that
there's no such thing as an SSL certificate which falls under the
Mozilla policy but does not fall under the BRs, despite the differing
and unclear scope statement in the BRs.

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 02/06/17 12:29, Ryan Sleevi wrote:
> 2) "performing RA or DTP functions"

I'll go with that :-)

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: Make it clear that Mozilla policy has wider scope than the BRs

[Gervase Markham via dev-security-policy]

On 02/06/17 12:24, Kurt Roeckx wrote:
> Should that be "all certificates" instead of "all SSL certificates"?

No; the Baseline Requirements apply only to SSL certificates.

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

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

[Gervase Markham via dev-security-policy]

The scope of the BRs is ambiguous, and almost certainly smaller than the
scope of the Mozilla policy. It might be useful to explicitly draw
attention to that fact, for the avoidance of doubt.

Proposal: add a bullet to section 2.3, where we define BR exceptions:

"Insofar as the Baseline Requirements attempt to define their own scope,
the scope of this policy (section 1.1) overrides that. Mozilla expects
CA operations relating to issuance of all SSL certificates in the scope
of this policy to conform to the Baseline Requirements."

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

---

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: Clarify requirement for multi-factor auth

[Gervase Markham via dev-security-policy]

On 01/06/17 13:59, Gervase Markham wrote:
> Perhaps this leads to the solution? We say:
> 
> "enforce multi-factor authentication for all accounts capable of causing
> certificate issuance or performing RA or DTP functions as defined by the
> Baseline Requirements"

or "enforce multi-factor authentication for all accounts capable of
either causing certificate issuance or performing validation functions,
for certificates containing domains not owned or controlled by the
account holder"

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 01/06/17 14:22, Doug Beattie wrote:
> If this is the case, then in what cases do you see 2-factor auth being a 
> requirement where it was not before?

Well, Mozilla policy didn't require that all RA accounts had
multi-factor, only those directly capable of causing certificate
issuance. Maybe there was some other requirement somewhere which means
this addition is redundant?

An example of someone who didn't require it before who requires it now
would be someone who did EV research into the correctness of the company
information as supplied by the applicant, and marked it as "confirmed"
in the system. This is "performing a validation function", but it's not
"directly causing certificate issuance".

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: Add definition of "mis-issuance"

[Gervase Markham via dev-security-policy]

On 01/06/17 13:49, Ryan Sleevi wrote:
> I would encourage you to reconsider this, or perhaps I've misunderstood
> your position. To the extent that Mozilla's mission includes "The
> effectiveness of the Internet as a public resource depends upon
> interoperability (protocols, data formats, content) ", the
> well-formedness and encoding directly affects Mozilla users (sites working
> in Vendors A, B, C but not Mozilla) and the broader ecosystem (sites
> Mozilla users are protected from that vendors A, B, C are not).

My point is not that we are entirely indifferent to such problems, but
that perhaps the category of "mis-issuance" is the wrong one for such
errors. I guess it depends what we mean by "mis-issuance" - which is the
entire point of this discussion!

So, if mis-issuance means there is some sort of security problem, then
my original definition still seems like a good one to me. If
mis-issuance means any problem where the certificate is not as it should
be, then we need a wider definition.

I wonder whether we need a new word for certificates which are bogus for
a non-security-related reason. "Mis-constructed"?

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 01/06/17 13:45, Ryan Sleevi wrote:
> The reason why I don't think it's a valid reasoning is that if we accept
> that this provision in the policy could be read to cover such emails, then
> we're implicitly agreeing that the act of clicking that email is performing
> a validation function pursuant to 3.2.2.4 of the Baseline Requirements.

Well, yes, probably. This text is in the Mozilla policy and the above is
in the Baseline Requirements, but I can see how this logic works.

> Ergo, every customer of that CA who uses that method is acting as a
> Delegated Third Party, performing the validation functions of 3.2.2.4 -
> since, by logical extension, they're performing the validation function of
> 3.2.2.4 on their account - and all the attendant mess that it entails.

That's a good point.

Perhaps this leads to the solution? We say:

"enforce multi-factor authentication for all accounts capable of causing
certificate issuance or performing RA or DTP functions as defined by the
Baseline Requirements"

?

Gerv

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