Re: [EXT] Mozilla requirements of Symantec

2017-06-20 Thread Jakob Bohm via dev-security-policy

On 20/06/2017 09:05, Ryan Sleevi wrote:

On Mon, Jun 19, 2017 at 7:01 PM, Jakob Bohm via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:


NSS until fairly recently was in fact used for code signing of Firefox
extensions using the public PKI (this is why there is a defunct code
signing trust bit in the NSS root store).



This is not an accurate representation on why there is a code signing trust
bit in the NSS root store.



Then what is an accurate representation?

I am of cause aware that before the xpi format was even invented,
Netscape, Mozilla and Sun/Oracle used the NSS key store and possibly the
NSS code to validate signatures on Java applets.  But I am unsure if and
when they stopped doing that.




I also believe that the current checking of "AMO" signatures is still
done by NSS, but not using the public PKI.



If you mean with respect to code, sure, but that is a generic signature
checking.



Really?  I would have thought it was the same validation code previously
used for public PKI signatures on the same file types.

Anyway, it is most certainly checking signatures on code in a way
consistent with the general concept of "code signing" (the exact
placement and formatting of "code signing" signatures is extremely
vendor and file format dependent).




This makes it completely reasonable for other users of the NSS libraries
to still use it for code signing, provided that the "code signing" trust
bits in the NSS root store are replaced with an independent list,
possibly based on the CCADB.



This is not correct. The NSS team has made it clear the future of this code
with respect to its suitability as a generic "code signing" functionality -
that is, that it is not.



Pointer?

Was this communicated in a way visible to all NSS using software?




It also makes it likely that systems with long development / update
cycles have not yet deployed their own replacement for the code signing
trust bits in the NSS root store, even if they have a semi-automated
system importing changes to the NSS root store.  That would of cause be
a mistake on their part, but a very likely mistake.



This was always a mistake, not a recent one. But a misuse of the API does
not make a valid use case.



How was it a mistake back when Mozilla was using NSS for "code signing"?
(Whenever that was).

P.S.

I am following the newsgroup, no need to CC me on replies.


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: [EXT] Mozilla requirements of Symantec

2017-06-20 Thread Ryan Sleevi via dev-security-policy
On Mon, Jun 19, 2017 at 7:01 PM, Jakob Bohm via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> NSS until fairly recently was in fact used for code signing of Firefox
> extensions using the public PKI (this is why there is a defunct code
> signing trust bit in the NSS root store).
>

This is not an accurate representation on why there is a code signing trust
bit in the NSS root store.


> I also believe that the current checking of "AMO" signatures is still
> done by NSS, but not using the public PKI.
>

If you mean with respect to code, sure, but that is a generic signature
checking.


> This makes it completely reasonable for other users of the NSS libraries
> to still use it for code signing, provided that the "code signing" trust
> bits in the NSS root store are replaced with an independent list,
> possibly based on the CCADB.
>

This is not correct. The NSS team has made it clear the future of this code
with respect to its suitability as a generic "code signing" functionality -
that is, that it is not.


> It also makes it likely that systems with long development / update
> cycles have not yet deployed their own replacement for the code signing
> trust bits in the NSS root store, even if they have a semi-automated
> system importing changes to the NSS root store.  That would of cause be
> a mistake on their part, but a very likely mistake.


This was always a mistake, not a recent one. But a misuse of the API does
not make a valid use case.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy


Re: [EXT] Mozilla requirements of Symantec

2017-06-19 Thread Jakob Bohm via dev-security-policy

On 12/06/2017 22:12, Nick Lamb wrote:

On Monday, 12 June 2017 17:31:58 UTC+1, Steve Medin  wrote:

We think it is critically important to distinguish potential removal of support 
for current roots in Firefox versus across NSS. Limiting Firefox trust to a 
subset of roots while leaving NSS unchanged would avoid unintentionally 
damaging ecosystems that are not browser-based but rely on NSS-based roots such 
as code signing, closed ecosystems, libraries, etc.


Abusing NSS to support code signing or "closed ecosystems" would be an error 
regardless of what happens to Symantec, it makes no real sense for us to prioritize 
supporting such abuse. To the extent that m.d.s.policy represents consumers of NSS 
certdata other than Firefox, they've _already_ represented very strongly that what they 
want is for this data to follow Mozilla's trust decisions more closely not less.



I believe you are exaggerating in that assertion.

NSS until fairly recently was in fact used for code signing of Firefox
extensions using the public PKI (this is why there is a defunct code
signing trust bit in the NSS root store).

I also believe that the current checking of "AMO" signatures is still
done by NSS, but not using the public PKI.

This makes it completely reasonable for other users of the NSS libraries
to still use it for code signing, provided that the "code signing" trust
bits in the NSS root store are replaced with an independent list,
possibly based on the CCADB.

It also makes it likely that systems with long development / update
cycles have not yet deployed their own replacement for the code signing
trust bits in the NSS root store, even if they have a semi-automated
system importing changes to the NSS root store.  That would of cause be
a mistake on their part, but a very likely mistake.


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: [EXT] Mozilla requirements of Symantec

2017-06-12 Thread Nick Lamb via dev-security-policy
On Monday, 12 June 2017 17:31:58 UTC+1, Steve Medin  wrote:
> We think it is critically important to distinguish potential removal of 
> support for current roots in Firefox versus across NSS. Limiting Firefox 
> trust to a subset of roots while leaving NSS unchanged would avoid 
> unintentionally damaging ecosystems that are not browser-based but rely on 
> NSS-based roots such as code signing, closed ecosystems, libraries, etc.

Abusing NSS to support code signing or "closed ecosystems" would be an error 
regardless of what happens to Symantec, it makes no real sense for us to 
prioritize supporting such abuse. To the extent that m.d.s.policy represents 
consumers of NSS certdata other than Firefox, they've _already_ represented 
very strongly that what they want is for this data to follow Mozilla's trust 
decisions more closely not less.

I have no doubt that Symantec believes it could make more money if archaic 
Symantec-controlled CA roots remain in NSS certdata forever but it doesn't 
serve Mozilla's wider purpose to allow that, nor does it serve the purpose of 
the non-Mozilla people on m.d.s.policy.

Further the use of NSS certdata in libraries is absolutely key to a secure Web 
PKI. I spent a good portion of last week and will probably spend more time yet 
chasing problems with such libraries. It may well suit Symantec to be able to 
tell their customers "We can issue you anything [for a fee] and it'll be 
trusted by libraries" knowing you've advocated for this, but it hurts the 
Relying Parties because it exposes them to unlimited risk which will be 
disclaimed later as "not affecting Firefox".
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy


RE: [EXT] Mozilla requirements of Symantec

2017-06-12 Thread Steve Medin via dev-security-policy
> -Original Message-
> From: Gervase Markham [mailto:g...@mozilla.org]
> Sent: Wednesday, June 07, 2017 2:51 PM
> To: Steve Medin <steve_me...@symantec.com>; mozilla-dev-security-
> pol...@lists.mozilla.org
> Cc: Kathleen Wilson <kwil...@mozilla.com>
> Subject: [EXT] Mozilla requirements of Symantec
>
> 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.
>

Symantec supports creation of a new PKI. Limiting Firefox trust of new 
certificates to those issued off of the new PKI is a practical path forward, 
due to Firefox’s contained scope and auto-update capabilities.

The same does not hold true for the removal of current PKI roots from NSS and 
the entirety of NSS dependents.

We understand the cutoff date to mean that any end entity cert issued after 
that date from the current PKI would not be trusted, but this date would have 
no effect on the trust of existing current PKI certs, their issuers, or their 
roots. Mozilla has not yet chosen the notBefore milestone date, and we 
interpret your proposal as intent to set a date and announce that date with 
enough advance notice to support public notice to affected parties. To that 
end, based on our research, we believe the 2017-08-08 date is not achievable 
given the magnitude of the transition that would need to occur and we propose 
that Mozilla not conclude on final dates for Symantec certificates at this time.

In response to the Google proposal, Symantec is currently evaluating a third 
party “SubCA” approach, which requires substantial operational changes. We have 
conducted outreach to candidate partners (SubCAs) to understand the potential 
constraints, timelines and the integration work that might be needed. We have 
also formalized and issued an RFP with specific questions around timing, 
logistics and dependencies. We expect to have the required feedback to inform a 
project plan by the end of June, at which time we will come back to Mozilla and 
the community regarding suggested dates that are both aggressive and achievable 
under this approach, by Symantec and the SubCA(s).

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

We think it is critically important to distinguish potential removal of support 
for current roots in Firefox versus across NSS. Limiting Firefox trust to a 
subset of roots while leaving NSS unchanged would avoid unintentionally 
damaging ecosystems that are not browser-based but rely on NSS-based roots such 
as code signing, closed ecosystems, libr

Re: Mozilla requirements of Symantec

2017-06-08 Thread Jakob Bohm via dev-security-policy

On 08/06/2017 18:52, Peter Bowen wrote:

On Thu, Jun 8, 2017 at 9:38 AM, Jakob Bohm via dev-security-policy
 wrote:


As the linked proposal was worded (I am not on Blink mailing lists), it
seemed obvious that the original timeline was:

   Later: Once the new roots are generally accepted, Symantec can actually
issue from the new SubCAs.

   Long term: CRL and OCSP management for the managed SubCAs remain with the
third party CAs.  This continues until the managed SubCAs expire or are
revoked.


I don't see this last part in the proposal.  Instead the proposal
appears to specifically contemplate the SubCAs being transferred to
Symantec once the new roots are accepted in the required trust stores.



That last part was derived purely from the logistical difficulty of
moving private keys compared to just keeping CRL and OCSP running in an
infrastructure that would keep running anyway (for the hosting CAs own
CA 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: Mozilla requirements of Symantec

2017-06-08 Thread Peter Bowen via dev-security-policy
On Thu, Jun 8, 2017 at 9:38 AM, Jakob Bohm via dev-security-policy
 wrote:
>
> As the linked proposal was worded (I am not on Blink mailing lists), it
> seemed obvious that the original timeline was:
>
>   Later: Once the new roots are generally accepted, Symantec can actually
> issue from the new SubCAs.
>
>   Long term: CRL and OCSP management for the managed SubCAs remain with the
> third party CAs.  This continues until the managed SubCAs expire or are
> revoked.

I don't see this last part in the proposal.  Instead the proposal
appears to specifically contemplate the SubCAs being transferred to
Symantec once the new roots are accepted in the required trust stores.

Additionally, there is no policy, as far as I know, that governs
transfer of non-Root CAs.  This is possibly a gap, but an existing
one.

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


Re: Mozilla requirements of Symantec

2017-06-08 Thread Jakob Bohm via dev-security-policy

On 08/06/2017 11:09, Gervase Markham wrote:

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.



As the linked proposal was worded (I am not on Blink mailing lists), it 
seemed obvious that the original timeline was:


  August 2017: All new certs issued by Managed SubCAs that chain to the 
old Symantec roots.  Private keys for these SubCAs reside an the third 
party CAs in secure hardware which will presumable prevent sharing them 
with Symantec.


  Much later: The new infrastructure passes all readiness audits.

  Then: A signing ceremony creates the new roots and their first set of 
SubCAs.  Cross signatures are created from the old roots to the new 
roots.   Maybe/Maybe not cross signatures are also created from the new 
roots to the managed SubCAs.


  Next: Symantec reapplies for inclusion with the new roots.

  Later: Once the new roots are generally accepted, Symantec can 
actually issue from the new SubCAs.


  Long term: CRL and OCSP management for the managed SubCAs remain with 
the third party CAs.  This continues until the managed SubCAs expire or 
are revoked.



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: Mozilla requirements of Symantec

2017-06-08 Thread 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: Mozilla requirements of Symantec

2017-06-07 Thread Jakob Bohm via dev-security-policy

Hi Gervase,

there seems to be a slight inconsistency between the terminology in the 
plan posted at


https://groups.google.com/a/chromium.org/d/msg/blink-dev/eUAKwjihhBs/ovLalSBRBQAJ

And the official letter quoted below.  I have added potential 
clarifications to fix this, please indicate, for the benefit of the 
community and Symantec if those clarifications are correct interpretations.


On 07/06/2017 20:51, Gervase Markham wrote:

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.



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



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.



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



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

With best wishes,

Gerv




Enjoy

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


Mozilla requirements of Symantec

2017-06-07 Thread 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