Re: Suspicious test.com Cert Issued By GlobalSign

[Nick Lamb via dev-security-policy]

On Friday, 24 March 2017 10:11:36 UTC, Gervase Markham  wrote:
> I spoke about this with Doug at the CAB Forum meeting. The system which
> collects the data is not integrated with the system to which the domains
> are added. The validation specialist concerned, contrary to policy
> ("it's just a test"), simply did not add any data to the data recording
> system relating to the addition of this domain to the authorized list
> for the account.
> 
> This raises the question of whether Mozilla should attempt to require
> such linkage by policy

I agree with you Gerv that it seems impractical to fix this with Mozilla policy.

There are a number of things CAs can and should be doing here to reduce the 
chance that they're put in the same position as GlobalSign, but I don't know if 
any of them are amenable to being specified by policy.

Good software engineering principles can help. There should be a simple, 
documented process for testing things, including certificate issuance. If there 
are ad hoc processes, it's really easy for those to end up infringing policy. 
But I can't see Mozilla legislating some particular software engineering 
process.

Good HR can help too. "Don't walk past" rules are appropriate, every employee 
is entitled to identify something as a security problem, and to see it get 
solved, covering up problems has to be what gets you in trouble, not telling 
people about them. But this needs morale, and it's just not practical for 
Mozilla to control the morale at a programme member CA.

Finally though, and maybe there is an opportunity to write policy here but I'm 
not sure how, the CA needs to be proactively monitoring its own systems for 
anomalies and outliers. The test.com certificate was an outlier because there 
was no data in the data recording system about it. That had a perfectly 
sensible, but BR defying, explanation. It doesn't need a team of people, or 
even a whole full-time employee, but _somebody_ at the CA should be looking for 
this type of problem so they find it before everybody else does.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Symantec: Next Steps

[Jakob Bohm via dev-security-policy]

On 24/03/2017 21:03, Jakob Bohm wrote:

On 24/03/2017 19:08, Ryan Sleevi wrote:

On Fri, Mar 24, 2017 at 1:30 PM, Jakob Bohm via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:


Examples discussed in the past year in this group include the Taiwan
GRCA roots and several of the SubCAs hosted by Verizon prior to the
DigiCert transition.



Apologies for not remembering, but I don't recall the relationship of
either of those discussions to what you described. However, it's very
easy
I'm wrong.

Could you link to the threads (ideally, the messages) you believe that
captures this description, so that I can better understand?



For Taiwan GRCA (Government Root CA) apparently operated by Chungwa
Telecom, this seems most obvious from:

Message-ID:

Date: Sat, 3 Dec 2016 00:34:12 -0800 (PST)
From: lcchen.ci...@gmail.com
Subject: Re: Taiwan GRCA Root Renewal Request

For the Verizon rooted tree of multiple CAs, some hosted by Verizon,
some not, look at the long report that is:

Message-ID:

Date: Thu, 3 Nov 2016 18:28:10 +
From: Jeremy Rowley 
Subject: Update on transition of the Verizon roots and issuance of SHA1
certificates



Peter is correct, we discussed something slightly different, so apologies
for misunderstanding what you were proposing versus what we discussed. It
sounds like what you're describing is what we discussed (white-label),
except the person signing the management assertion is also acting as a
Delegated Third Party for validation. However, because they're the ones
signing the assertion, they're the ones in scope for the audit
presented to
root stores - correct?



On this second point, there really should be two signed management
assertions and two public audit reports:

One for the "CA Operator", who needs to comply with every bit of the
BR, security and root program policy requirements.  The "CA Operator"
must have a CP/CPS for the CA which is verbatim identical to the one
provided by the "CA Owner" and part of the audited CA Operation.
In practice, this would often be a "master" assertion and audit for all
the CAs hosted by that "CA Operator".

One for the "CA Owner", who needs to have a compliant CP/CPS, outsource
to a compliant "CA Operator", meet "Delegated Third Party" audit
requirements for any self-performed functions and provide a management
assertion and other evidence that they don't interfere with the
compliance of the "CA Operator" for their CA(s).

Both parties would have audit reports etc. submitted to the root
programs.

Such a double auditing process would solve most of the problems
commonly caused (according to others) by auditors only dealing with one
of the two parties and the other one falling through the cracks.


Enjoy

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

Re: Symantec: Next Steps

[Jakob Bohm via dev-security-policy]

On 24/03/2017 19:08, Ryan Sleevi wrote:

On Fri, Mar 24, 2017 at 1:30 PM, Jakob Bohm via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:


Examples discussed in the past year in this group include the Taiwan
GRCA roots and several of the SubCAs hosted by Verizon prior to the
DigiCert transition.



Apologies for not remembering, but I don't recall the relationship of
either of those discussions to what you described. However, it's very easy
I'm wrong.


> Could you link to the threads (ideally, the messages) you believe that
> captures this description, so that I can better understand?
>

For Taiwan GRCA (Government Root CA) apparently operated by Chungwa
Telecom, this seems most obvious from:

Message-ID: 


Date: Sat, 3 Dec 2016 00:34:12 -0800 (PST)
From: lcchen.ci...@gmail.com
Subject: Re: Taiwan GRCA Root Renewal Request

For the Verizon rooted tree of multiple CAs, some hosted by Verizon,
some not, look at the long report that is:

Message-ID: 


Date: Thu, 3 Nov 2016 18:28:10 +
From: Jeremy Rowley 
Subject: Update on transition of the Verizon roots and issuance of SHA1
certificates



Peter is correct, we discussed something slightly different, so apologies
for misunderstanding what you were proposing versus what we discussed. It
sounds like what you're describing is what we discussed (white-label),
except the person signing the management assertion is also acting as a
Delegated Third Party for validation. However, because they're the ones
signing the assertion, they're the ones in scope for the audit presented to
root stores - correct?




Enjoy

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

Re: Symantec: Next Steps

[Ryan Sleevi via dev-security-policy]

On Fri, Mar 24, 2017 at 1:30 PM, Jakob Bohm via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> Examples discussed in the past year in this group include the Taiwan
> GRCA roots and several of the SubCAs hosted by Verizon prior to the
> DigiCert transition.


Apologies for not remembering, but I don't recall the relationship of
either of those discussions to what you described. However, it's very easy
I'm wrong.

Could you link to the threads (ideally, the messages) you believe that
captures this description, so that I can better understand?

Peter is correct, we discussed something slightly different, so apologies
for misunderstanding what you were proposing versus what we discussed. It
sounds like what you're describing is what we discussed (white-label),
except the person signing the management assertion is also acting as a
Delegated Third Party for validation. However, because they're the ones
signing the assertion, they're the ones in scope for the audit presented to
root stores - correct?
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Symantec: Next Steps

[Jakob Bohm via dev-security-policy]

On 24/03/2017 17:12, Peter Bowen wrote:

On Fri, Mar 24, 2017 at 9:06 AM, Ryan Sleevi via dev-security-policy
 wrote:

(Wearing an individual hat)

On Fri, Mar 24, 2017 at 10:35 AM, Jakob Bohm via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:


One common scenario that a new wording should allow is a "fully
outsourced CA", where all the technical activities, including CA
private key storage, CRL/OCSP distribution, ensuring policy compliance
and domain/IP validation are outsourced to a single entity which is
fully audited as a CA operator, while the entity nominally responsible
for the CA acts more like an RA or reseller.



Can you highlight why you believe this is a common scenario? During that
same conversation, only one party was identified that meets such a
definition, and CAs otherwise did not highlight any of their customers or
awareness of others.


To be fair, we didn't discuss this scenario.

The scenario raised was that CompanyX outsources _all_ CA activities
to CompanyY except for approving CPS changes, writing the management
assertion, and marketing the certificates.

What I believe Jakob is describing is one step less, where CompanyY
does some of the validation steps.



Examples discussed in the past year in this group include the Taiwan
GRCA roots and several of the SubCAs hosted by Verizon prior to the
DigiCert transition.


Enjoy

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

Re: Symantec: Next Steps

[Peter Bowen via dev-security-policy]

On Fri, Mar 24, 2017 at 9:06 AM, Ryan Sleevi via dev-security-policy
 wrote:
> (Wearing an individual hat)
>
> On Fri, Mar 24, 2017 at 10:35 AM, Jakob Bohm via dev-security-policy <
> dev-security-policy@lists.mozilla.org> wrote:
>>
>> One common scenario that a new wording should allow is a "fully
>> outsourced CA", where all the technical activities, including CA
>> private key storage, CRL/OCSP distribution, ensuring policy compliance
>> and domain/IP validation are outsourced to a single entity which is
>> fully audited as a CA operator, while the entity nominally responsible
>> for the CA acts more like an RA or reseller.
>>
>
> Can you highlight why you believe this is a common scenario? During that
> same conversation, only one party was identified that meets such a
> definition, and CAs otherwise did not highlight any of their customers or
> awareness of others.

To be fair, we didn't discuss this scenario.

The scenario raised was that CompanyX outsources _all_ CA activities
to CompanyY except for approving CPS changes, writing the management
assertion, and marketing the certificates.

What I believe Jakob is describing is one step less, where CompanyY
does some of the validation steps.

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

Re: Symantec: Next Steps

[Ryan Sleevi via dev-security-policy]

(Wearing an individual hat)

On Fri, Mar 24, 2017 at 10:35 AM, Jakob Bohm via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
>
> One common scenario that a new wording should allow is a "fully
> outsourced CA", where all the technical activities, including CA
> private key storage, CRL/OCSP distribution, ensuring policy compliance
> and domain/IP validation are outsourced to a single entity which is
> fully audited as a CA operator, while the entity nominally responsible
> for the CA acts more like an RA or reseller.
>

Can you highlight why you believe this is a common scenario? During that
same conversation, only one party was identified that meets such a
definition, and CAs otherwise did not highlight any of their customers or
awareness of others.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Next CA Communication

[Kathleen Wilson via dev-security-policy]

On Friday, March 24, 2017 at 3:11:17 AM UTC-7, Gervase Markham wrote:
> On 23/03/17 23:07, Kathleen Wilson wrote:
> > Second paragraph of Action 1 now says: ~~ Note that version 1.4.2 of
> > the BRs does not contain all 10 of these methods, but it does contain
> > section 3.2.2.4.11, "Other Methods", so the subsections of version
> > 3.2.2.4 that are marked "Reserved" in version 1.4.2 of the BRs are
> > still BR-compliant under version 1.4.2. By Mozilla policy, CAs are
> > not permitted to rely on the "Other Methods" section to use methods
> > of domain validation that are not among the 10 listed in section
> > 3.2.2.4 of version 1.4.1 of the BRs. Mozilla expects that all of the
> > methods for doing domain validation that are missing in version 1.4.2
> > of the BRs will be restored to a forthcoming version of the BRs, so
> > we will once again be able to accept all of the methods of domain
> > validation listed in the latest version of the BRs. ~~
> 
> That's not quite it, because the first bit is still confusing (my
> fault), and the last para suggests we currently don't accept all methods
> listed, which we do. Can we try the following?
> 
> 
> Note that version 1.4.2 of the BRs does not contain all 10 of these
> methods, but it does contain section 3.2.2.4.11, "Other Methods", so the
> methods that were removed in version 1.4.2 of the BRs are still
> BR-compliant under that version. By Mozilla policy, CAs are not
> permitted to rely on the "Other Methods" section to use methods of
> domain validation that are not among the 10 listed in section 3.2.2.4 of
> version 1.4.1 of the BRs. As the IPR issues relating to these missing
> methods have now been resolved, Mozilla expects that they will soon be
> restored. Once they are, our policy will once again become that "we
> accept all of the methods of domain validation explicitly listed in the
> latest version of the BRs".
> 
> Gerv

Updated.

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

Re: Symantec: Next Steps

[Jakob Bohm via dev-security-policy]

On 24/03/2017 10:56, Gervase Markham wrote:

On 07/03/17 11:37, Gervase Markham wrote:

Here are some proposals for policy change. Please do comment on these or
suggest others.


I can report that at the CAB Forum face-to-face in Raleigh, NC, USA this
week, there was broad consensus to draw up a ballot which prevents CAs
from (to summarise broadly) outsourcing BR 3.2.2.4 and 3.2.2.5 - domain
name and IP address ownership - validation to third parties, and that
this restriction would be enacted at the level of the BRs, not the level
of Mozilla policy. So I will be working with interested parties from the
Forum to draft some wording that achieves that, as there are various
cases to consider to make sure we don't forbid certain common and secure
activities by accident.



One common scenario that a new wording should allow is a "fully
outsourced CA", where all the technical activities, including CA
private key storage, CRL/OCSP distribution, ensuring policy compliance
and domain/IP validation are outsourced to a single entity which is
fully audited as a CA operator, while the entity nominally responsible
for the CA acts more like an RA or reseller.

That "CA operator" might be an actual related CA in good standing, or
might be a professional company created solely for doing this job for
other CAs (such as the private companies that run some government CAs
around the world).

For the "fully outsourced CA" scenario, the things that a normal CA
cannot outsource to a third party would in this case not be allowed to
be "insourced" from the "CA operator" to the nominally responsible
organization.

Enjoy

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

Re: Google action related to Symantec

[Gervase Markham via dev-security-policy]

On 23/03/17 16:09, Ryan Sleevi wrote:
> You can participate in this discussion at
> https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/eUAKwjihhBs

Participants who want to discuss Google's action should, of course,
visit the Blink forum above as Ryan has requested. However, the
discussion about what action Mozilla should take regarding Symantec
remains open. (My apologies for not driving it forward; it was CAB Forum
this week.)

Here are some additional thoughts I have on this topic, but I have not
yet reached a conclusion to recommend to Kathleen.

The root stores tend to actively avoid coordinating enforcement actions
ahead of any public announcement, to avoid accusations of impropriety.
But now that Google have announced their action, it is unavoidable to
note that it can be preferable for two root stores considering action
against a CA to take broadly parallel approaches, so that the CA is not
doubly penalised for the same actions.

Google's communication has two parts (which are intermingled in the
message as written) - a summary of Symantec's issues as they see them,
and then a plan of action for changes they want to make in response to
those issues. As far as the summary of issues goes, my understanding of
the situation is broadly the same - that is, Google has correctly
identified the things that have gone wrong, and appropriately assessed
the severity of the problems. It is particularly concerning to me that
Symantec discovered that one of their RAs was doing a terrible job and,
while they demanded remediation, did nothing about existing certificates
issued by that RA.

An additional consideration in deciding on what action to take is
whether a particular incident fits into a pattern for a particular CA.
In the case of WoSign, while there were one or two unusually bad things
about what they did, once we started investigating it became clear that
these fit into a persistent pattern of ongoing problems. In the case of
Symantec, it is borderline whether that test has been met. It is true
that this incident and the previous "test cert" one are both serious,
and both involved test certs - although this most recent one then turned
up other problems. And they also have, like several CAs, managed to
issue some unpermitted SHA-1 in 2016 despite attempting to update their
systems to stop it. But we have not seen the sheer number of different
problems that we saw with WoSign.

Considering all that, calibrating a level of response is a difficult
question. It is important to be consistent with previous precedent (with
some consideration given to the fact that a second or third CA to take
some bad action should have taken warning from the fate of the first)
but there are few enough precedents in this area that any choice of
level of action will always be open to both "you should do more" and
"you should do less" criticism. Google's plan is, in my personal
opinion, at the "strong" end of the options I was considering.

Google's gradated distrust plan aims to minimise or spread the
compatibility risk. Emulating it exactly would be difficult in any case,
due to the fact that our releases do not line up with theirs. However, a
simpler version may have the same effect in practice, given Chrome's
ability to drive the market alone.

Further comments and thoughts on the above are welcome.

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

Re: Suspicious test.com Cert Issued By GlobalSign

[Gervase Markham via dev-security-policy]

On 17/03/17 16:28, douglas.beat...@gmail.com wrote:
>> If the addition is so gated, what did the employee in this case do? Did
>> they upload bogus data?
> 
> No bogus data was uploaded.

I spoke about this with Doug at the CAB Forum meeting. The system which
collects the data is not integrated with the system to which the domains
are added. The validation specialist concerned, contrary to policy
("it's just a test"), simply did not add any data to the data recording
system relating to the addition of this domain to the authorized list
for the account.

This raises the question of whether Mozilla should attempt to require
such linkage by policy, so that domains cannot be added unless domain
validation has been performed. It would not be a totally unprecendented
mandate (at the moment we e.g. require 2-factor auth, which is a direct
mandate for how CA systems operate). However, not all methods of domain
validation are automated. Given that if someone wants to work around the
system, it's not really possible to programmatically check that e.g.
someone's write-up of a phone conversation is genuine or not, I am
minded not to attempt this.

Comments?

Gerv

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

Re: Notice of Intent to Deprecate and Remove: Trust in Symantec-issued Certificates

[Gervase Markham via dev-security-policy]

On 23/03/17 19:54, Jakob Bohm wrote:
> The above message (and one by Symantec) were posted to the
> mozilla.dev.security.policy newsgroup prior to becoming aware of
> Google's decision to move the discussion to its own private mailing
> list and procedures.  I would encourage everyone concerned to keep the
> public Mozilla newsgroup copied on all messages in this discussion,
> which seems to have extremely wide repercussions.

Actually, could I encourage everyone _not_ to do that? Ryan has
requested this discussion happen on the blink-dev list. Not everyone who
is a member here is a member there, or vice versa, and attempting to
have the discussion across both lists is likely to lead to significant
fragmentation and confusion.

Thanks,

Gerv

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

Re: Symantec: Next Steps

[Gervase Markham via dev-security-policy]

On 07/03/17 11:37, Gervase Markham wrote:
> Here are some proposals for policy change. Please do comment on these or
> suggest others.

I can report that at the CAB Forum face-to-face in Raleigh, NC, USA this
week, there was broad consensus to draw up a ballot which prevents CAs
from (to summarise broadly) outsourcing BR 3.2.2.4 and 3.2.2.5 - domain
name and IP address ownership - validation to third parties, and that
this restriction would be enacted at the level of the BRs, not the level
of Mozilla policy. So I will be working with interested parties from the
Forum to draft some wording that achieves that, as there are various
cases to consider to make sure we don't forbid certain common and secure
activities by accident.

This would be stronger than and therefore supercede:

> Policy Proposal 1: require all CAs to arrange it so that certs validated
> by an RA are issued from one or more intermediates dedicated solely to
> that RA, with such intermediates clearly labelled with the name of the
> RA in the Subject.

Other forms of validation will continue to be outsourceable. Mozilla
does not recognise OV certificates, but when it comes to EV, we do need
to make sure that any outsourcing is properly audited and those audit
findings are properly communicated. How we do this remains an open and
difficult question; however, domain/IP ownership validation is so core
to a CA's activity that it seems wise to remove it from the scope of
this wider problem by banning outsourcing it outright.

I will take up the topic of possible action against Symantec in the
other thread.

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

Re: Next CA Communication

[Gervase Markham via dev-security-policy]

On 23/03/17 23:07, Kathleen Wilson wrote:
> Second paragraph of Action 1 now says: ~~ Note that version 1.4.2 of
> the BRs does not contain all 10 of these methods, but it does contain
> section 3.2.2.4.11, "Other Methods", so the subsections of version
> 3.2.2.4 that are marked "Reserved" in version 1.4.2 of the BRs are
> still BR-compliant under version 1.4.2. By Mozilla policy, CAs are
> not permitted to rely on the "Other Methods" section to use methods
> of domain validation that are not among the 10 listed in section
> 3.2.2.4 of version 1.4.1 of the BRs. Mozilla expects that all of the
> methods for doing domain validation that are missing in version 1.4.2
> of the BRs will be restored to a forthcoming version of the BRs, so
> we will once again be able to accept all of the methods of domain
> validation listed in the latest version of the BRs. ~~

That's not quite it, because the first bit is still confusing (my
fault), and the last para suggests we currently don't accept all methods
listed, which we do. Can we try the following?


Note that version 1.4.2 of the BRs does not contain all 10 of these
methods, but it does contain section 3.2.2.4.11, "Other Methods", so the
methods that were removed in version 1.4.2 of the BRs are still
BR-compliant under that version. By Mozilla policy, CAs are not
permitted to rely on the "Other Methods" section to use methods of
domain validation that are not among the 10 listed in section 3.2.2.4 of
version 1.4.1 of the BRs. As the IPR issues relating to these missing
methods have now been resolved, Mozilla expects that they will soon be
restored. Once they are, our policy will once again become that "we
accept all of the methods of domain validation explicitly listed in the
latest version of the BRs".

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

Re: Safely testing TLS in dev & test environments

[Jakob Bohm via dev-security-policy]

On 24/03/2017 05:54, Walter Goulet wrote:

On Thursday, March 23, 2017 at 8:13:38 PM UTC-5, Jakob Bohm wrote:

On 23/03/2017 22:59, Walter Goulet wrote:

Hi all,

This is not directly related to Mozilla policy, CA issues or really any of the 
normal discussions that I typically see in the group. However, I think that my 
question may be relevant in helping to understand what a 'policy' for an 
internal, non-publicly trusted PKI might look like.

While considering the problem of how to let developers, devops teams and 
traditional system administrators to adequately test TLS in lab environments, 
in my experience I've seen a variety of practices, some very poor, others 
questionable and some that seem reasonable.

These include:
- Using externally resolvable DNS names for test/staging environments and using 
certificates issued by publicly trusted CAs for testing.
- Using certificates from a 'test-only' PKI infrastructure that runs in a lab 
environment, usually with little to no security controls of any kind whatsoever.
- Using self-signed certificates for testing, then finding when deploying 
applications in production you end up debugging certificate path building 
errors.

So a solution that I've been considering is to develop an approach for what a 
'Test PKI' infrastructure should look like. At a high level, my idea for what a 
secure 'Test PKI' infrastructure would look like is:
- Root CA certificate is not publicly trusted by any browsers/OSs.
- Certificates issued for test purposes may not be issued for any valid 
domains, but instead may only be issued for IANA reserved domains (those 
documented here: 
https://www.iana.org/assignments/special-use-domain-names/special-use-domain-names.xhtml.
 So if an organization called 'mycompany.com' wants to test PKI securely in 
their lab, the only certificates that could be issued would be 'mycompany.test, 
mycompany.local, mycompany.invalid and so on).


For this item, another practical solution is to limit it to a subdomain
of whatever domain is used for internal systems, (e.g. an AD subdomain
for Windows environments or a traditional organizational subdomain in a
non-Windows environment).

For example, if regular internal department machines are under
math.campus.example.edu, then the test machines could be under
lab3.math.campus.example.edu.




That's true Jakob, but I'm trying to take this process even a step further. I'm 
trying to get away from users testing with valid domains, so that even if the 
TestCA root is trusted by other users, certificates issued to it won't be valid 
for use on any external networks. That's why I'm focused on eliminating the use 
of valid TLDs in test certificates.

This is a pretty big shift from a typical testing approach, so I see some 
resistance. Is anyone aware of pitfalls when using the reserved TLDs for 
internal testing?



Not valid TLDs are not the only domain names that are not valid on the
public Internet.  Deliberately reserved names can exist at every level
of the DNS, including below a real domain.

DNS and network policies may easily prevent the use of "unauthorized"
domains, even in a test environment.

Also some system vendors may introduce stupid rules for the reserved
TLDs, such as when someone stole the "local." domain for broadcast DNS,
which was a real pain in the rear for existing networks.

Also, some tests need to be conducted over the public Internet to get
realistic test results, at least without expensive "network problem
simulation" hardware.

In terms of security:

Limiting who trusts your test CA root is the first and strongest line
of defense.

Limiting what names your test CA can issue certificates from is the
second line of defense.

Firewalling access to your test machines from most of the public
Internet is the third line of defense.

Limiting public visibility of the DNS zones that hold your test
environment (DNS split horizon etc.) is the fourth line of defense.

Using names that cannot even be propagated through the public DNS due
to global limitations (your suggestion) is a fifth layer of defense
that is not always attainable or desirable.


Enjoy

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