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

[Peter Kurrasch via dev-security-policy]

  Fair enough. This is absolutely the sort of stuff that needs to be part of regular auditing. I was wondering what sort of checking or enforcement you had in mind by including it in the Mozilla policy now? Perhaps you just want the CA's to be reminded that cybersecurity issues are important despite the CABF docs on the matter being too weak?I have no qualms using "for example". I would like for more to be mentioned than just software updates but even there I don't feel too strongly about it.From: Gervase MarkhamSent: Wednesday, May 24, 2017 9:56 AMTo: Peter Kurrasch; mozilla-dev-security-pol...@lists.mozilla.orgSubject: Re: Policy 2.5 Proposal: Require all CAs to have appropriate network securityOn 24/05/17 15:31, Peter Kurrasch wrote:> It might be fair to characterize my position as "vague but> comprehensive"...if that's even possible? There are some standard-ish> frameworks that could be adopted:I think we would prefer to wait for the CAB Forum to adopt somethingrather than attempting to define and enforce our own. If for no otherreason than the CAB Forum thing is more likely to be audited andtherefore to have actual teeth.> If you'd like to keep the policy to a sentence or so, perhaps we could> use some "including but not limited to" verbiage? Well, the draft wording we started with used "for example"... :-)Gerv
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

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

[Kathleen Wilson via dev-security-policy]

I've been receiving questions about this update, so hopefully the following 
will clarify...

CAs now login to the CCADB at this URL:
https://ccadb.force.com


There is no login required to view the public-facing reports and the responses 
to the CA Communications. The links to those have been updated in the following 
wiki pages:
https://wiki.mozilla.org/CA/Included_Certificates
https://wiki.mozilla.org/CA/Intermediate_Certificates
https://wiki.mozilla.org/CA/Removed_Certificates
https://wiki.mozilla.org/CA/Communications

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

Re: Google Plan for Symantec posted

[Peter Bowen via dev-security-policy]

On Mon, May 22, 2017 at 9:33 AM, Gervase Markham via
dev-security-policy  wrote:
> On 19/05/17 21:04, Kathleen Wilson wrote:
>> - What validity periods should be allowed for SSL certs being issued
>> in the old PKI (until the new PKI is ready)?
>
> Symantec is required only to be issuing in the new PKI by 2017-08-08 -
> in around ten weeks time. In the mean time, there is no restriction
> beyond the normal one on the length they can issue. This makes sense,
> because if certs issued yesterday will expire 39 months from yesterday,
> then certs issued in 10 weeks will only expire 10 weeks after that - not
> much difference.

Can you clarify the meaning of "new PKI"?  I can see two reasonable
interpretations:

1) The systems and processes used to issue end-entity certificates
(server authentication and email protection) must be distinct from the
existing systems.  This implies that a new set of subordinate CAs
under the existing Symantec-owned roots would meet the requirements.
These new subordinate CAs could be owned and operated by either
Symantec or owned and operated by a third party who has their own
WebTrust audit.

2) The new PKI includes both new offline CAs that meet the
requirements to be Root CAs and new subordinate CAs that issue
end-entity certificates. the The new root CAs could be cross-signed by
existing CAs (regardless of owner), but the new subordinate CAs must
not be directly signed by any Symantec-owned root CA that currently
exists.

Can you also clarify the expectations with regards to the existing
roots?  You say "only to be issuing in the new PKI".  Does Mozilla
intend to require that all CAs that chain to a specific set of roots
cease issuing all server authentication and email protection after a
certain date, unless they are also under one of the "new" roots?  If
so, will issuance be allowed from CAs that chain to the "old" roots
once certain actions take place (e.g. removed from the trust stores in
all supported versions of Mozilla products)?

>> - I'm not sold on the idea of requiring Symantec to use third-party
>> CAs to perform validation/issuance on Symantec's behalf. The most
>> serious concerns that I have with Symantec's old PKI is with their
>> third-party subCAs and third-party RAs. I don't have particular
>> concern about Symantec doing the validation/issuance in-house. So, I
>> think it would be better/safer for Symantec to staff up to do the
>> validation/re-validation in-house rather than using third parties. If
>> the concern is about regaining trust, then add auditing to this.
>
> Of course, if we don't require something but Google do (or vice versa)
> then Symantec will need to do it anyway. But I will investigate in
> discussions whether some scheme like this might be acceptable to both
> the other two sides and might lead to a quicker migration timetable to
> the new PKI.

Google has proposed adding some indication to certificates of whether
the information validation was performed by Symantec or another party.
If Mozilla does not require a third-party to perform validation, would
it make sense to have a concept of validations performed by the "new"
RA and validations performed by the "old" RA or validations performed
in the scope of Symantec audits versus validations performed in the
scope of another audit?

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

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

[Gervase Markham via dev-security-policy]

On 24/05/17 15:31, Peter Kurrasch wrote:
> It might be fair to characterize my position as "vague but
> comprehensive"...if that's even possible? There are some standard-ish
> frameworks that could be adopted:

I think we would prefer to wait for the CAB Forum to adopt something
rather than attempting to define and enforce our own. If for no other
reason than the CAB Forum thing is more likely to be audited and
therefore to have actual teeth.

> If you'd like to keep the policy to a sentence or so, perhaps we could
> use some "including but not limited to" verbiage? 

Well, the draft wording we started with used "for example"... :-)

Gerv

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

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

[Peter Kurrasch via dev-security-policy]

  It might be fair to characterize my position as "vague but comprehensive"...if that's even possible? There are some standard-ish frameworks that could be adopted:- NIST has an existing framework that is currently going through some sort of update/revisory process.  ‎http://www.nist.gov/cyberframework/- ISO has 27032:2012 which looks to have some good stuff in it.    ‎https://www.iso.org/standard/44375.html‎- Perhaps surprisingly enough, the American Institute of CPA's has a variety of information that looks to be a good starting point for anyone.  http://www.aicpa.org/interestareas/frc/assuranceadvisoryservices/pages/cyber-security-resource-center.aspxI would be interested in knowing if other people know of other frameworks and have experience using any of them. I'm certainly not advocating that any of the above be used here or that they are necessarily even good resources for folks in the CA space.Back to laughable security, my issue is that there are many ways an organization might experience a security breakdown in ways that cause severe face damage to security folks due to either excessive face palms or banging ones head against the wall or even laughing too hard. Examples include: ‎allowing week passwords (by employees), poor password management, inadequate access controls, weak network intrusion detection, insufficient protection from well-known web application vulnerabilities (e.g. SQL injection), and the list goes on.If you'd like to keep the policy to a sentence or so, perhaps we could use some "including but not limited to" verbiage? From: Gervase MarkhamSent: Tuesday, May 23, 2017 5:23 AMTo: Peter Kurrasch; mozilla-dev-security-pol...@lists.mozilla.orgSubject: Re: Policy 2.5 Proposal: Require all CAs to have appropriate network securityOn 23/05/17 04:18, Peter Kurrasch wrote:> I think the term "industry best practices" is too nebulous. For> example, if I patch some of my systems but not all of them I could> still make a claim that I am following best practices even though my> network has plenty of other holes in it.I'm not sure that "patching half my systems" would be generally acceptedas "industry best practice". But regardless, unless we are planning towrite our own network security document, which we aren't, can yousuggest more robust wording?> I assume the desire is to hold CA's to account for the security of> their networks and systems, is that correct? If so, I think we should> have something with more meat to it. If not, the proposal as written> is probably just fine (although, do you mean the CABF's "Network> Security Requirements" spec or is there another guidelines doc?).Yes, that's the doc I mean (for all its flaws).> For consideration: ‎Mozilla can--and perhaps should--require that all> CA's adopt and document a cybersecurity risk management framework for> their networks and systems (perhaps this is already mandated> somewhere?). I would expect that the best run CA's will already have> something like this in place (or something better) but other CA's> might not. There are pros and cons to such frameworks but at a> minimum it can demonstrate that a particular CA has at least> considered the cybersecurity risks that are endemic to their> business.If we are playing "too nebulous", I would point out that to meet thisrequirement, I could just write my own (very lax) cybersecurity riskmanagement framework and then adopt it.Any requirement which is only a few sentences is always going to betechnically gameable. I just want to write something which is not easilygameable without failing the "laugh test".Gerv
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy