Re: Safely testing TLS in dev & test environments

[Walter Goulet via dev-security-policy]

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.
> 
> > - Certificates issued for testing purposes would contain a clear 'For 
> > testing purposes only' string in issued certificate OU fields.
> > - Test PKI infrastructure, while issuing test-only certificates, would 
> > still be run as production infrastructure, meaning that proper security 
> > controls that would be expected of any production-worthy CA are in place.
> >
> > Any thoughts from the group on this approach? Note that this requires a 
> > pretty significant mindset change in what it means to test 
> > applications/systems, most notably because of the use of reserved, 
> > test-only domains. But I'd be really interested in what others think.
> >
> 
> 
> 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



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 

Re: Safely testing TLS in dev & test environments

[Jakob Bohm via dev-security-policy]

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.


- Certificates issued for testing purposes would contain a clear 'For testing 
purposes only' string in issued certificate OU fields.
- Test PKI infrastructure, while issuing test-only certificates, would still be 
run as production infrastructure, meaning that proper security controls that 
would be expected of any production-worthy CA are in place.

Any thoughts from the group on this approach? Note that this requires a pretty 
significant mindset change in what it means to test applications/systems, most 
notably because of the use of reserved, test-only domains. But I'd be really 
interested in what others think.




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: Next CA Communication

[Kathleen Wilson via dev-security-policy]

On Tuesday, March 21, 2017 at 11:34:30 AM UTC-7, Gervase Markham wrote:
> On 21/03/17 10:16, Gervase Markham wrote:
> > On 17/03/17 11:30, Gervase Markham wrote:
> >> The URL for the draft of the next CA Communication is here:
> >> https://mozilla-mozillacaprogram.cs54.force.com/Communications/CACommunicationSurveySample?CACommunicationId=a050S00G3K2
> > 
> > A few more wording tweaks on the current version:
> 
> In Action 1, we should replace:
> 
> "However, if additional methods of domain validation are added to
> section 3.2.2.4 of the BRs in the future, they will also be permitted."
> 
> with:
> 
> "Mozilla expects that all missing methods will be restored to the
> Baseline Requirements in the near future. Once that happens, we will
> return to the practice of requiring conformance to the latest version of
> the BRs."
> 
> (The CAB Forum PAG is about to resolve itself; happily, all participants
> have agreed to license their patents under a CAB Forum RF license. It's
> now just a question of getting a ballot done to add back the missing
> methods. Yay :-)
> 
> Gerv


Glad to hear that.

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

Thanks,
Kathleen



___
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 Tuesday, March 21, 2017 at 7:17:26 AM UTC-7, Gervase Markham wrote:
> On 17/03/17 11:30, Gervase Markham wrote:
> > The URL for the draft of the next CA Communication is here:
> > https://mozilla-mozillacaprogram.cs54.force.com/Communications/CACommunicationSurveySample?CACommunicationId=a050S00G3K2
> 
> A few more wording tweaks on the current version:
> 
> * Action 1 says: "Date must be before June 1, 2017". That gives CAs 2
> months to make a CP/CPS update. Do we normally allow a bit more than
> that for non-urgent updates? Say, 3 months?

Updated to "Date must be before July 21, 2017." (3 months from when survey must 
be completed)

> 
> * "I understand that our CP/CPS documents shall be updated each year" ->
> "I understand that our CP/CPS documents should be reviewed and the
> version number incremented each year"

Action 2 option updated to: 
"I understand that our CP/CPS documents must be reviewed annually to ensure 
continued compliance with the CA/Browser Forum's Baseline Requirements, and 
that at least the version number should be incremented each year."


> 
> * Action 8: "Our current policy is...". In hindsight, this is ambiguous
> - it could be Mozilla's policy, and the CA is just affirming they
> understand it. Instead say "The current policy of our CA is...".

Done.

Thanks,
Kathleen
___
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 Tuesday, March 21, 2017 at 5:51:29 AM UTC-7, Kurt Roeckx wrote:
> On 2017-03-21 12:51, Jakob Bohm wrote:
> > On 21/03/2017 10:09, Kurt Roeckx wrote:
> >> Action 6 says:


I've updated action #6, but it still might not be clear.

Here's the new draft:
ACTION 6: QUALIFIED AUDIT STATEMENTS

When an auditor finds non-compliance with the audit criteria, the audit 
statement should clearly indicate the word “qualified”, and clearly identify 
the controls that failed. The auditor should provide qualified reports for all 
time periods until the problems have been fixed.

Period-of-time audit statements are required to cover audit periods that are 
less than one year and are contiguous. In other words, there should never be a 
time gap between the audit periods indicated in period-of-time audit statements.

Point-in-time audit statements may be used to confirm that all of the problems 
that the auditor previously identified in a qualified audit statement have been 
corrected. However, a point-in-time assessment does *not* replace the 
period-of-time assessment. (Required)

~~

Please let me know if you have suggestions about how to make this more clear.

Thanks,
Kathleen
___
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

[Peter Bowen via dev-security-policy]

On Thu, Mar 23, 2017 at 12:54 PM, Jakob Bohm via dev-security-policy
 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.

Jakob,

Maybe I missed it, but I don't think that Mozilla is involved in this
proposal.  The blink-dev mailing list has an open membership policy
and public anonymously accessible archives.  Obviously anyone can copy
m.d.s.p, as it doesn't have posting restrictions, but it seems
reasonable that Chrom(ium|e)-only discussions would be on a chromium
mailing list.

Thanks,
Peter
___
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

[Ryan Sleevi via dev-security-policy]

(Posting in an official capacity)

Jakob,

As the initial message said:
"You can participate in this discussion at
https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/eUAKwjihhBs
"

I've removed the cross-post, to ensure that threads do not fork due to
members being subscribed to one list versus the other.

I know this is a new approach, and appreciate your understanding as we try
to work through the challenges.


On Thu, Mar 23, 2017 at 3:54 PM, Jakob Bohm via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> On 23/03/2017 20:27, Ryan Sleevi wrote:
>
>> On Thu, Mar 23, 2017 at 1:38 PM, Jakob Bohm via dev-security-policy <
>> dev-security-policy@lists.mozilla.org> wrote:
>>
>> On 23/03/2017 17:09, Ryan Sleevi wrote:
>>>
>>> (Posting in a Google Capacity)

 I just wanted to notify the members of this Forum that we have started
 an
 Intent to Deprecate and Remove, consistent with our Blink process,
 related
 to certain certificates issued by Symantec Corporation.

 This is a proposed plan, not a final commitment, and we welcome all
 feedback from members of this Forum to understand the risks and
 challenges.
 To understand the goals of this process, you can find more details at
 https://www.chromium.org/blink

 You can participate in this discussion at
 https://groups.google.com/a/ch
 romium.org/forum/#!topic/blink-dev/eUAKwjihhBs


 According to the linked document, Google is intending to distrust *all*
>>> Symantec issued certificates with a validity longer than 9 months,
>>> which is less that the 12 month validity normally being the minimum
>>> that site operators can purchase from CAs such as Symantec.
>>>
>>> It is also worth noting that this is apparently scheduled to occur less
>>> than 12 months from now (The document refers to Chrome/Blink version
>>> numbers with no associated dates, but contains a mention that one of
>>> the relevant releases would happen over the "winter holiday",
>>> presumably Christmas 2017).
>>>
>>> Since I know of no commercial (as opposed to free) CAs that routinely
>>> sell certificates with a duration of less than 12 months, this seems
>>> highly draconian and designed to drive Symantec out of the CA business.
>>>
>>> It also seems to ignore every mitigating factor discussed in this
>>> group, including those posted by Symantec themselves.
>>>
>>> For example the cited number of "30,000" affected certificates seems to
>>> come from the number of certificates that Symantec is actively double
>>> checking to ensure they were *not* misissued in a way similar to the
>>> original 127.
>>>
>>> It would seem that the only way to remain interoperable with both
>>> Chrome and the legacy devices and systems that trust only Symantec
>>> owned roots, would be if Chrome's TLS implementation somehow identified
>>> itself to servers as being a Chrome-based implementation before servers
>>> present their certificate.
>>>
>>> The computing world at large would be significantly inconvenienced if
>>> Symantec was forced to close down its CA business, in particular the
>>> parts of that business catering to other markets than general WebPki
>>> certificates.
>>>
>>
>>
>>
> 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.
>
>
>
>
> 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
>
___
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

[Jakob Bohm via dev-security-policy]

On 23/03/2017 20:27, Ryan Sleevi wrote:

On Thu, Mar 23, 2017 at 1:38 PM, Jakob Bohm via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:


On 23/03/2017 17:09, Ryan Sleevi wrote:


(Posting in a Google Capacity)

I just wanted to notify the members of this Forum that we have started an
Intent to Deprecate and Remove, consistent with our Blink process, related
to certain certificates issued by Symantec Corporation.

This is a proposed plan, not a final commitment, and we welcome all
feedback from members of this Forum to understand the risks and challenges.
To understand the goals of this process, you can find more details at
https://www.chromium.org/blink

You can participate in this discussion at https://groups.google.com/a/ch
romium.org/forum/#!topic/blink-dev/eUAKwjihhBs



According to the linked document, Google is intending to distrust *all*
Symantec issued certificates with a validity longer than 9 months,
which is less that the 12 month validity normally being the minimum
that site operators can purchase from CAs such as Symantec.

It is also worth noting that this is apparently scheduled to occur less
than 12 months from now (The document refers to Chrome/Blink version
numbers with no associated dates, but contains a mention that one of
the relevant releases would happen over the "winter holiday",
presumably Christmas 2017).

Since I know of no commercial (as opposed to free) CAs that routinely
sell certificates with a duration of less than 12 months, this seems
highly draconian and designed to drive Symantec out of the CA business.

It also seems to ignore every mitigating factor discussed in this
group, including those posted by Symantec themselves.

For example the cited number of "30,000" affected certificates seems to
come from the number of certificates that Symantec is actively double
checking to ensure they were *not* misissued in a way similar to the
original 127.

It would seem that the only way to remain interoperable with both
Chrome and the legacy devices and systems that trust only Symantec
owned roots, would be if Chrome's TLS implementation somehow identified
itself to servers as being a Chrome-based implementation before servers
present their certificate.

The computing world at large would be significantly inconvenienced if
Symantec was forced to close down its CA business, in particular the
parts of that business catering to other markets than general WebPki
certificates.





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.



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: Notice of Intent to Deprecate and Remove: Trust in Symantec-issued Certificates

[Ryan Sleevi via dev-security-policy]

On Thu, Mar 23, 2017 at 1:38 PM, Jakob Bohm via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> On 23/03/2017 17:09, Ryan Sleevi wrote:
>
>> (Posting in a Google Capacity)
>>
>> I just wanted to notify the members of this Forum that we have started an
>> Intent to Deprecate and Remove, consistent with our Blink process, related
>> to certain certificates issued by Symantec Corporation.
>>
>> This is a proposed plan, not a final commitment, and we welcome all
>> feedback from members of this Forum to understand the risks and challenges.
>> To understand the goals of this process, you can find more details at
>> https://www.chromium.org/blink
>>
>> You can participate in this discussion at https://groups.google.com/a/ch
>> romium.org/forum/#!topic/blink-dev/eUAKwjihhBs
>>
>>
> According to the linked document, Google is intending to distrust *all*
> Symantec issued certificates with a validity longer than 9 months,
> which is less that the 12 month validity normally being the minimum
> that site operators can purchase from CAs such as Symantec.
>
> It is also worth noting that this is apparently scheduled to occur less
> than 12 months from now (The document refers to Chrome/Blink version
> numbers with no associated dates, but contains a mention that one of
> the relevant releases would happen over the "winter holiday",
> presumably Christmas 2017).
>
> Since I know of no commercial (as opposed to free) CAs that routinely
> sell certificates with a duration of less than 12 months, this seems
> highly draconian and designed to drive Symantec out of the CA business.
>
> It also seems to ignore every mitigating factor discussed in this
> group, including those posted by Symantec themselves.
>
> For example the cited number of "30,000" affected certificates seems to
> come from the number of certificates that Symantec is actively double
> checking to ensure they were *not* misissued in a way similar to the
> original 127.
>
> It would seem that the only way to remain interoperable with both
> Chrome and the legacy devices and systems that trust only Symantec
> owned roots, would be if Chrome's TLS implementation somehow identified
> itself to servers as being a Chrome-based implementation before servers
> present their certificate.
>
> The computing world at large would be significantly inconvenienced if
> Symantec was forced to close down its CA business, in particular the
> parts of that business catering to other markets than general WebPki
> certificates.


(In Google Capacity)

By no means do I want to insist you must discuss on blink-...@chromium.org,
but I do want to highlight that the process follows our Blink Process for
assessing risk, and you're more than welcome and encouraged to share this
feedback there to ensure it's considered in relation to the proposed plan
for Chrome.

If you wish to only address this relative to the Mozilla community, please
feel free to do so here, and I in no means want to tell you where or how to
do so. I can only state that communication to blink-...@chromium.org is
what will inform Google Chrome's approach to this matter.

All the best,
Ryan
___
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

[Jakob Bohm via dev-security-policy]

On 23/03/2017 17:09, Ryan Sleevi wrote:

(Posting in a Google Capacity)

I just wanted to notify the members of this Forum that we have started an 
Intent to Deprecate and Remove, consistent with our Blink process, related to 
certain certificates issued by Symantec Corporation.

This is a proposed plan, not a final commitment, and we welcome all feedback 
from members of this Forum to understand the risks and challenges. To 
understand the goals of this process, you can find more details at 
https://www.chromium.org/blink

You can participate in this discussion at 
https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/eUAKwjihhBs



According to the linked document, Google is intending to distrust *all*
Symantec issued certificates with a validity longer than 9 months,
which is less that the 12 month validity normally being the minimum
that site operators can purchase from CAs such as Symantec.

It is also worth noting that this is apparently scheduled to occur less
than 12 months from now (The document refers to Chrome/Blink version
numbers with no associated dates, but contains a mention that one of
the relevant releases would happen over the "winter holiday",
presumably Christmas 2017).

Since I know of no commercial (as opposed to free) CAs that routinely
sell certificates with a duration of less than 12 months, this seems
highly draconian and designed to drive Symantec out of the CA business.

It also seems to ignore every mitigating factor discussed in this
group, including those posted by Symantec themselves.

For example the cited number of "30,000" affected certificates seems to
come from the number of certificates that Symantec is actively double
checking to ensure they were *not* misissued in a way similar to the
original 127.

It would seem that the only way to remain interoperable with both
Chrome and the legacy devices and systems that trust only Symantec
owned roots, would be if Chrome's TLS implementation somehow identified
itself to servers as being a Chrome-based implementation before servers
present their certificate.

The computing world at large would be significantly inconvenienced if
Symantec was forced to close down its CA business, in particular the
parts of that business catering to other markets than general WebPki
certificates.



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: Notice of Intent to Deprecate and Remove: Trust in Symantec-issued Certificates

[Ryan Sleevi via dev-security-policy]

On Thu, Mar 23, 2017 at 12:54 PM, tarah.symantec--- via dev-security-policy
 wrote:

> What will be the process for critical infrastructure such as medical
> devices and payment systems when they're affected by this?


To avoid fragmentation of discussion, would it be possible to reply to the
blink-dev@ list?

I totally realize the overhead for participants on either side - Mozilla
dev.security.policy members having to post to a different list vs blink-dev
members potentially needing to post to this list. We've opted for blink-dev@
in this case, and welcome feedback on how to improve this process in the
future.

Given the interest and role this community has played in these issues, we
wanted to inform and solicit feedback, but we're not quite to the point
where the primary discussion would happen on this list.

Thanks for understanding
___
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

[tarah.symantec--- via dev-security-policy]

On Thursday, March 23, 2017 at 12:09:23 PM UTC-4, Ryan Sleevi wrote:
> (Posting in a Google Capacity)
> 
> I just wanted to notify the members of this Forum that we have started an 
> Intent to Deprecate and Remove, consistent with our Blink process, related to 
> certain certificates issued by Symantec Corporation.
> 
> This is a proposed plan, not a final commitment, and we welcome all feedback 
> from members of this Forum to understand the risks and challenges. To 
> understand the goals of this process, you can find more details at 
> https://www.chromium.org/blink
> 
> You can participate in this discussion at 
> https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/eUAKwjihhBs

What will be the process for critical infrastructure such as medical devices 
and payment systems when they're affected by this? 
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

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

[Ryan Sleevi via dev-security-policy]

(Posting in a Google Capacity)

I just wanted to notify the members of this Forum that we have started an 
Intent to Deprecate and Remove, consistent with our Blink process, related to 
certain certificates issued by Symantec Corporation.

This is a proposed plan, not a final commitment, and we welcome all feedback 
from members of this Forum to understand the risks and challenges. To 
understand the goals of this process, you can find more details at 
https://www.chromium.org/blink

You can participate in this discussion at 
https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/eUAKwjihhBs
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Google Trust Services roots

[Ryan Sleevi via dev-security-policy]

On Thu, Mar 23, 2017 at 8:37 AM, Peter Kurrasch via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> ‎I would be interested in knowing why Google felt it necessary to purchase
> an existing root instead of, for example, pursuing a "new root" path along
> the lines of what Let's Encrypt did? All I could gather from the Google
> security blog is that they really want to be a root CA and to do it in a
> hurry. ‎Why the need to do it quickly, especially given the risks (attack
> surface)?


Clarification: I'm not speaking on behalf of Google

I think this demonstrates a lack of understanding of what Let's Encrypt
did. Let's Encrypt obtained a cross-signed certificate (from IdenTrust),
which is "purchasing" a signature for their key. This is one approach.
Purchasing a pre-existing signature (and key) is another. They are
functionally equivalent.

So what Google has done is what is what Let's Encrypt did.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Google Trust Services roots

[Peter Kurrasch via dev-security-policy]

‎So this is the third of my 3 sets of criticisms regarding the acquisition of 
the GlobalSign roots by Google Trust Services. I apologize for the significant 
delay between the first 2 sets and this one. Hopefully people in the forum 
still feel this discussion relevant going forward even though the matter is 
considered resolved.

Several of the comments I made regarding GlobalSign also apply to Google, 
especially the intermingling of the two brands. The implications of the 
confusion and uncertainty leading to an exploitable attack are just as 
applicable to Google as they are to GlobalSign. However, when you consider the 
stature of Google both on the Internet and in consumer products, the 
ramifications are more significant. Or, if you will, the attack surface is 
quite different than if GlobalSign were to purchase a root from, say, Symantec.

I do fault Google for what I consider to be inadequate communication of the 
acquisition. This is not to say there's been no communication, just that I 
don't think it's enough, especially if you are not a CABF participant or don't 
keep up with Internet security news generally. Why not publish a message last 
October that regular folks on the Internet can understand? Why wait 3 months?‎ 
Why expect people to dig through a CPS to find what should be readily available 
information? 

I would be interested in knowing why Google felt it necessary to purchase an 
existing root instead of, for example, pursuing a "new root" path along the 
lines of what Let's Encrypt did? All I could gather from the Google security 
blog is that they really want to be a root CA and to do it in a hurry. ‎Why the 
need to do it quickly, especially given the risks (attack surface)?

I also would like to know what the plan or expectation is regarding formal 
separation between the infrastructures of Google and GlobalSign. The overlap is 
an understandable necessity during the transition but nonetheless presents 
another opportunity for improper access, loss (leaking) of data, and perhaps 
other nefarious activities. And, does Google have a published policy regarding 
the information collected, stored, and analyzed when people access the CRL and 
OCSP distribution nodes?

I do want to say I appreciate that someone with Ryan H.'s level of experience 
is involved in a transaction like this. There are undoubtedly many details to 
address that ensure a secure and proper transfer. I hope that someone on the 
GlobalSign side was equally experienced? The next time someone wants to 
purchase existing roots, the people involved might not have that same level of 
experience, and that should give everyone pause.


  Original Message  
From: Ryan Hurst via dev-security-policy
Sent: Wednesday, March 8, 2017 12:02 PM
To: mozilla-dev-security-pol...@lists.mozilla.org
Reply To: Ryan Hurst
Subject: Re: Google Trust Services roots

> Jakob: An open question is how revocation and OCSP status for the 
> existing intermediaries issued by the acquired roots is handled. 

Google is responsible for producing CRLs for from these roots. We are also 
currently
relying on the OCSP responder infrastructure of GlobalSign for this root but are
In the process of migrating that inhouse.

> Jakob: Does GTS sign regularly updated CRLs published at the (GlobalSign) 
> URLs 
> listed in the CRL URL extensions in the GlobalSign operated non-expired 
> intermediaries? 

At this time Google produces CRLs and works with GlobalSign to publish those 
CRLs.

> Jakob: Hopefully these things are answered somewhere in the GTS CP/CPS for 
> the 
> acquired roots. 

This level of detail is not typically included in a CPS, for example, a service 
may change 
Which internet service provider or CDN service they use and not need update 
their CP/CPS.


> Jakob: Any relying party seeing the existing root in a chain would see the 
> name GlobalSign in the Issuer DN and naturally look to GlobalSign's 
> website and CP/CPS for additional information in trying to decide if 
> the chain should be trusted. 

The GlobalSign CPS indicates that the R2 and R4 are no longer under their 
control.

Additionally given the long term nature of CA keys, it is common for the DN not 
to accurately 
represent the organization that controls it. As I mentioned in an earlier 
response in the 90’s I 
created roots for a company called Valicert that has changed hands several 
times, additionally
Verisign, now Symantec in this context has a long history of acquiring CAs and 
as such they 
have CA certificates with many different names within them.

> Jakob: A relying party might assume, without detailed checks, that these 
> roots 
> are operated exclusively by GlobalSign in accordance with GlobalSign's 
> good reputation. 

As the former CTO of GlobalSign I love hearing about their good reputation ;)

However I would say the CP/CPS is the authoritative document here and since
GMO GlobalSign CP/CPS clearly states the keys are no longer in their control I 
believe