Re: FW: Complying with Mozilla policy on email validation

[Adrian R. via dev-security-policy]

On Thursday, 5 April 2018 03:08:44 UTC+3, Wayne Thayer  wrote:
[...]
> If a CA first confirms that it is a condition of a
> particular federated authentication system that a user must have proven
> control over the email account that constitutes their username to activate
> their account, then requires that user to prove they can authenticate in to
> the account, I think that meets the "reasonable" standard, even though a
> threat analysis might determine that the method is insufficient for various
> reasons.
> 

As you said, the S/MIME Working Group would be a better venue to define these, 
because the email username used for email authentication is not always 
identical to the email address. 

I might send a message to bob[at]example.com but they could actually use 
alice[at]example.com as username for authentication when accessing their 
messages or sending messages from the bob@ address.
The same RFC 5321 section 2.3.11 allows this.

> If the problem is that the user is not the "entity submitting the request",
> could that be changed?
> 
> Alternately, maybe you can suggest a change to 2.2(2) that achieves your
> goals without going so far as permitting "business controls" for validation?

If the federated auth username is different, but from the same domain as the 
intended email address, then require mandatory DNSSEC and CAA for the domain 
and also require email validation?

This might actually be easier to deploy than "business controls" when 
provisioning multiple S/MIME certificates for users, because DNSSEC and CAA 
need to be configured only once (in DNS) and then each user only has to do the 
email address validation part.


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

RE: Policy 2.6 Proposal: Require English Language Audit Reports

[Tim Hollebeek via dev-security-policy]

Call me crazy, but for this particular requirement, I think simple sentences
might
be better.

"The audit information MUST be publicly available.  An English version MUST
be provided.  The English version MUST be authoritative."

-Tim

> -Original Message-
> From: dev-security-policy [mailto:dev-security-policy-
> bounces+tim.hollebeek=digicert@lists.mozilla.org] On Behalf Of Ryan
> Hurst via dev-security-policy
> Sent: Wednesday, April 4, 2018 7:19 PM
> To: mozilla-dev-security-pol...@lists.mozilla.org
> Subject: Re: Policy 2.6 Proposal: Require English Language Audit Reports
> 
> 
> > An authoritative English language version of the publicly-available
> > audit information MUST be supplied by the Auditor.
> >
> > it would be helpful for auditors that issue report in languages other
> > than English to confirm that this won't create any issues.
> 
> That would address my concern.
> ___
> dev-security-policy mailing list
> dev-security-policy@lists.mozilla.org
> https://clicktime.symantec.com/a/1/qGy7WL45gRate5ccNJV7plt7IjXPV-pd-
> LTa9gPkQc8=?d=fgUiNjCpj8UK6ue4NShfzLGHGzkJWwPb3tOchiTvGntTxuK9bVX
> 5aMMPzBijLrabsuGnsFF4O9QSQsBjPBTpEb0gpSmHGiantqc2OcSQ0D4jZ5aLA1u
> eomyRD8-dNmIp4I87-T1G40WpIGyLEnm-
> Z2ye83FoVpIrjeWcM6ujsgxkvPTYEEPgJJ5S8QA9fQctHsjXIyT8HT8j6vDTknG1enh
> GZ_T_dA6JBbp81zJ4L1Ca2eX6aXcvz5BgcHvS6yotf6bd2EfLLWJKAZnR6o1yRxbzw
> lGl0_7xHVJs8xbMEdUuaI4b4pcup6QbPJsW1UQHIPAR6GFsxCauMSz5EJ-
> 5c38HJOLDPZLF5Tj0N6r-
> JIozX3YVUyZqRdSb4iIILNv8LsXVCwyud6ALgaqx4PJwF_leqzOCmmHBoYDZqI9z0
> 932I7QTktLec_1ZHGSkFGA664AXspslouRvtqP4eZfikJgsBoxEO1G2a2tx6n5uwZle
> -vFX=https%3A%2F%2Flists.mozilla.org%2Flistinfo%2Fdev-security-policy


smime.p7s
Description: S/MIME cryptographic signature
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: FW: Complying with Mozilla policy on email validation

[Wayne Thayer via dev-security-policy]

On Wed, Apr 4, 2018 at 3:44 PM, Ryan Hurst via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> On Wednesday, April 4, 2018 at 3:39:46 PM UTC-7, Wayne Thayer wrote:
> > On Wed, Apr 4, 2018 at 2:44 PM, Ryan Hurst via dev-security-policy <
> > > My opinion on this method and on Adrian's comments is that the
> CA/Browser
> > Forum, with it's new-found ability to create an S/MIME Working Group, is
> a
> > better venue for formulating secure email validation methods. Does it
> make
> > sense for us to define more specific email validation methods in this
> forum
> > when it's likely the CA/Browser Forum will do the same in the next year
> or
> > two?
>
> I understand that position, and maybe this is acceptable, but I believe
> the removal of "business controls" (which to be clear I like) prohibits
> this practice when it is reasonable and even desirable.
>
> The "business controls" language has always been scoped to technically
constrained subordinate CAs, so nothing has changed.

I was thinking until an S/MIME policy is established some accommodation of
> federated login in the mozilla policy accompanying the removal of "business
> controls" would address that.
>
> I think the existing language in section 2.2(2) also supports the
federated authentication system use case you described. It says that the CA
"takes reasonable measures to verify that the entity submitting the request
controls the email account associated with the email address referenced in
the certificate". If a CA first confirms that it is a condition of a
particular federated authentication system that a user must have proven
control over the email account that constitutes their username to activate
their account, then requires that user to prove they can authenticate in to
the account, I think that meets the "reasonable" standard, even though a
threat analysis might determine that the method is insufficient for various
reasons.

If the problem is that the user is not the "entity submitting the request",
could that be changed?

Alternately, maybe you can suggest a change to 2.2(2) that achieves your
goals without going so far as permitting "business controls" for validation?
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Policy 2.6 Proposal: Add prohibition on CA key generation to policy

[Wayne Thayer via dev-security-policy]

On Wed, Apr 4, 2018 at 3:15 PM, Ryan Hurst via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> Some thoughts:
>
> 1 - Should additional text be included to mandate strong cipher suites (
> http://unmitigatedrisk.com/?p=543) be used; it is not uncommon for me to
> find PKCS#12s with very weak cryptographic algorithms in use. Such guidance
> would be limited by Windows which does not support modern cryptographic
> algorithms for key protection but having some standard would be better than
> none though it would potentially hurt interoperability for those use cases
> if the chosen suites were not uniform.
>
> Do we even need the section on PKCS12? It seems like an edge case to me.

2 - Should additional text be included to mandate the that CA resellers
> cannot be used as an escape to this requirement; e.g. today A CA may simply
> rely on a third-party to implement this practice to stay in conformance
> with the policy.
>
> I'm of the opinion, as expressed by others in the Trustico thread, that we
should not attempt to set policy for resellers. It would be quite difficult
to enforce, and as you pointed out in that thread, quite difficult to
distinguish a reseller that is also managing the certificate (e.g. a
hosting provider).

3 - Should additional text be included to require that the user provide
> part or all of the secrete used as the "password" on the PKCS#12 file and
> that CA cannot store the user provided value?
> ___
> 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: Policy 2.6 Proposal: Require English Language Audit Reports

[Ryan Hurst via dev-security-policy]

> An authoritative English language version of the publicly-available audit
> information MUST be supplied by the Auditor.
> 
> it would be helpful for auditors that issue report in languages other than
> English to confirm that this won't create any issues.

That would address my concern.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Policy 2.6 Proposal: Require English Language Audit Reports

[Wayne Thayer via dev-security-policy]

On Wed, Apr 4, 2018 at 2:46 PM, Ryan Hurst via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> On Wednesday, April 4, 2018 at 1:58:35 PM UTC-7, Wayne Thayer wrote:
> > Mozilla needs to be able to read audit reports in the English language
> > without relying on machine translations that may be inaccurate or
> > misleading.
> >
> > I suggest adding the following sentence to the end of policy section
> 3.1.4
> > “Public Audit Information”:
> >
> > An English language version of the publicly-available audit information
> > MUST be supplied by the Auditor.
> >
> > This is: https://github.com/mozilla/pkipolicy/issues/106
> >
> > ---
> >
> > This is a proposed update to Mozilla's root store policy for version
> > 2.6. Please keep discussion in this group rather than on GitHub. Silence
> > is consent.
> >
> > Policy 2.5 (current version):
> > https://github.com/mozilla/pkipolicy/blob/2.5/rootstore/policy.md
>
> Should the text require the English version to be the authoritative
> version?
>
> This makes sense, and is easy to add to the proposed statement:

An authoritative English language version of the publicly-available audit
information MUST be supplied by the Auditor.

it would be helpful for auditors that issue report in languages other than
English to confirm that this won't create any issues.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: FW: Complying with Mozilla policy on email validation

[Ryan Hurst via dev-security-policy]

On Wednesday, April 4, 2018 at 3:39:46 PM UTC-7, Wayne Thayer wrote:
> On Wed, Apr 4, 2018 at 2:44 PM, Ryan Hurst via dev-security-policy <
> > My opinion on this method and on Adrian's comments is that the CA/Browser
> Forum, with it's new-found ability to create an S/MIME Working Group, is a
> better venue for formulating secure email validation methods. Does it make
> sense for us to define more specific email validation methods in this forum
> when it's likely the CA/Browser Forum will do the same in the next year or
> two?

I understand that position, and maybe this is acceptable, but I believe the 
removal of "business controls" (which to be clear I like) prohibits this 
practice when it is reasonable and even desirable.

I was thinking until an S/MIME policy is established some accommodation of 
federated login in the mozilla policy accompanying the removal of "business 
controls" would address that.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: FW: Complying with Mozilla policy on email validation

[Wayne Thayer via dev-security-policy]

On Wed, Apr 4, 2018 at 2:44 PM, Ryan Hurst via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> On Tuesday, April 3, 2018 at 1:17:50 PM UTC-7, Wayne Thayer wrote:
> > > I agree that name constraints would be difficult to implement in this
> > scenario, but I'm less convinced that section 2.2(2) doesn't permit this.
> > It says:
> >
> >
> > *For a certificate capable of being used for digitally signing or
> > encrypting email messages, the CA takes reasonable measures to verify
> that
> > the entity submitting the request controls the email account associated
> > with the email address referenced in the certificate or has been
> authorized
> > by the email account holder to act on the account holder’s behalf.*
>
> I can see that covering it. Maybe this could be provided as an explicit
> example of how that might happen?
>
> I created an issue for clarifying this language:
https://github.com/mozilla/pkipolicy/issues/127

> > Another case I think is interesting is that of a delegation of email
> > > verification to a third-party. For example, when you do a OAUTH
> > > authentication to Facebook it will return the user’s email address if
> it
> > > has been verified. The same is true for a number of related scenarios,
> for
> > > example, you can tell via Live Authentication and Google
> Authentication if
> > > the user's email was verified.
> > >
> > > The business controls text plausibly would have allowed this use case
> also.
> > >
> > > I'm not a fan of expanding the scope of such a vague requirement as
> > "business controls", and I'd prefer to have the CA/Browser Forum define
> > more specific validation methods, but if section 2.2(2) of our current
> > policy is too limiting, we can consider changing it to accommodate this
> use
> > case.
>
> I dislike business controls also, however in this case the LARGE majority
> of authentication on the web happens via OAUTH and federated user
> authentication is a thing we won't se going away.
>
> It seems broken to have a policy that prohibits this in the case of secure
> email or other related use cases of these certificates.
>
> Maybe this can be addressed through an explicit carve out for the case of
> federated authentication systems that provide a reliable verification of
> control of an email address.
>
> Alternatively, maybe Mozilla should maintain a listing common provider
> where Mozilla says this is allowable (Google, Microsoft, Facebook, and
> Twitter, for example).
>
> My opinion on this method and on Adrian's comments is that the CA/Browser
Forum, with it's new-found ability to create an S/MIME Working Group, is a
better venue for formulating secure email validation methods. Does it make
sense for us to define more specific email validation methods in this forum
when it's likely the CA/Browser Forum will do the same in the next year or
two?
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Policy 2.6 Proposal: Add prohibition on CA key generation to policy

[Ryan Hurst via dev-security-policy]

Some thoughts:

1 - Should additional text be included to mandate strong cipher suites 
(http://unmitigatedrisk.com/?p=543) be used; it is not uncommon for me to find 
PKCS#12s with very weak cryptographic algorithms in use. Such guidance would be 
limited by Windows which does not support modern cryptographic algorithms for 
key protection but having some standard would be better than none though it 
would potentially hurt interoperability for those use cases if the chosen 
suites were not uniform.

2 - Should additional text be included to mandate the that CA resellers cannot 
be used as an escape to this requirement; e.g. today A CA may simply rely on a 
third-party to implement this practice to stay in conformance with the policy.

3 - Should additional text be included to require that the user provide part or 
all of the secrete used as the "password" on the PKCS#12 file and that CA 
cannot store the user provided value?
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Policy 2.6 Proposal: Require English Language Audit Reports

[Ryan Hurst via dev-security-policy]

On Wednesday, April 4, 2018 at 1:58:35 PM UTC-7, Wayne Thayer wrote:
> Mozilla needs to be able to read audit reports in the English language
> without relying on machine translations that may be inaccurate or
> misleading.
> 
> I suggest adding the following sentence to the end of policy section 3.1.4
> “Public Audit Information”:
> 
> An English language version of the publicly-available audit information
> MUST be supplied by the Auditor.
> 
> This is: https://github.com/mozilla/pkipolicy/issues/106
> 
> ---
> 
> This is a proposed update to Mozilla's root store policy for version
> 2.6. Please keep discussion in this group rather than on GitHub. Silence
> is consent.
> 
> Policy 2.5 (current version):
> https://github.com/mozilla/pkipolicy/blob/2.5/rootstore/policy.md

Should the text require the English version to be the authoritative version?
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: FW: Complying with Mozilla policy on email validation

[Ryan Hurst via dev-security-policy]

On Tuesday, April 3, 2018 at 1:17:50 PM UTC-7, Wayne Thayer wrote:
> > I agree that name constraints would be difficult to implement in this
> scenario, but I'm less convinced that section 2.2(2) doesn't permit this.
> It says:
> 
> 
> *For a certificate capable of being used for digitally signing or
> encrypting email messages, the CA takes reasonable measures to verify that
> the entity submitting the request controls the email account associated
> with the email address referenced in the certificate or has been authorized
> by the email account holder to act on the account holder’s behalf.*

I can see that covering it. Maybe this could be provided as an explicit example 
of how that might happen?

> > Another case I think is interesting is that of a delegation of email
> > verification to a third-party. For example, when you do a OAUTH
> > authentication to Facebook it will return the user’s email address if it
> > has been verified. The same is true for a number of related scenarios, for
> > example, you can tell via Live Authentication and Google Authentication if
> > the user's email was verified.
> >
> > The business controls text plausibly would have allowed this use case also.
> >
> > I'm not a fan of expanding the scope of such a vague requirement as
> "business controls", and I'd prefer to have the CA/Browser Forum define
> more specific validation methods, but if section 2.2(2) of our current
> policy is too limiting, we can consider changing it to accommodate this use
> case.

I dislike business controls also, however in this case the LARGE majority of 
authentication on the web happens via OAUTH and federated user authentication 
is a thing we won't se going away. 

It seems broken to have a policy that prohibits this in the case of secure 
email or other related use cases of these certificates.

Maybe this can be addressed through an explicit carve out for the case of 
federated authentication systems that provide a reliable verification of 
control of an email address.

Alternatively, maybe Mozilla should maintain a listing common provider where 
Mozilla says this is allowable (Google, Microsoft, Facebook, and Twitter, for 
example).
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Policy 2.6 Proposal: For new inclusions, require all existing unexpired unrevoked certs in hierarchy to be BR compliant

[Wayne Thayer via dev-security-policy]

Last year we held a discussion on this topic [1] that concluded as follows:

It is true that in the case of a legacy root, creating a new root with a
> cross-sign is not technically all that complex (although it may take
> some time organizationally) and then we could embed that new one.
>
> Given that option, perhaps a blanket statement of BR compliance for all
> unexpired and unrevoked certificates is OK - allowing the CA to choose
> how best to meet the requirement.
>

I believe that the solution I proposed for issue 113 [2] (Require audits
back to first issuance) also takes care of this issue. Here is what I
proposed:

In section 2.3 (Baseline Requirements Conformance), add a new bullet that
> states "Before being included, CAs MUST provide evidence that their root
> certificates have, from the time of creation and continually thereafter,
> complied with the then current Mozilla Root Store Policy and CA/Browser
> Forum Baseline Requirements."
>

Once again, I'd appreciate everyone's input on this topic.

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

[1]
https://groups.google.com/forum/#!topic/mozilla.dev.security.policy/2vBlRyfwxEs
[2]
https://groups.google.com/d/msg/mozilla.dev.security.policy/rR9g5BJ6R8E/TPgol2fcBwAJ

---

This is a proposed update to Mozilla's root store policy for version
2.6. Please keep discussion in this group rather than on GitHub. Silence
is consent.

Policy 2.5 (current version):
https://github.com/mozilla/pkipolicy/blob/2.5/rootstore/policy.md
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Policy 2.6 Proposal: Add prohibition on CA key generation to policy

[Wayne Thayer via dev-security-policy]

This issue is titled “Make sure Forbidden practices are forbidden” - in
other words, make sure they are banned in our policy. The only forbidden
practice on our list [1] that’s not already covered by our policy is
“Distributing Generated Private Keys in PKCS#12 Files”. It reads:

CAs must never generate the key pairs for signer or SSL certificates. CAs
> may only generate the key pairs for SMIME certificates. Distribution or
> transfer of certificates in PKCS#12 form through unsecure electronic
> channels is not allowed. If a PKCS#12 file is distributed via a physical
> data storage device, then:
> The storage must be packaged in a way that the opening of the package
> causes irrecoverable physical damage. (e.g. a security seal)
> The PKCS#12 file must have a sufficiently secure password, and the
> password must not be transferred together with the storage.
>

This practice was recently questioned [2] and generated lots of discussion
[3], with the conclusion being that our prohibition on this practice should
remain at least until a comprehensive plan for CA key generation is
presented and reviewed.

Given that background, please do not use this discussion thread to reopen
the debate on changing our policy on CA key generation. The scope here is
limited to the specifics of the existing requirements (e.g. the exception
for email encryption certificates), and moving them into policy.

I propose adding the following paragraphs to section 5.3 “Forbidden and
Required Practices”:

CAs MUST not generate the key pairs for end-entity certificates, except for
> email encryption certificates meeting the following criteria:
> 1. The Extended Key Usage extension is present and set to
> id-kp-emailProtection; and,
> 2. The Key Usage extension is present and does not include either
> digitalSignature or nonRepudiation.
>

>
CAs MUST not distribute or transfer certificates in PKCS#12 form through
> insecure electronic channels. If a PKCS#12 file is distributed via a
> physical data storage device, then:
> * The storage must be packaged in a way that the opening of the package
> causes irrecoverable physical damage. (e.g. a security seal)
> * The PKCS#12 file must have a sufficiently secure password, and the
> password must not be transferred together with the storage.
>

I would appreciate everyone's input on this topic.

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

[1] https://wiki.mozilla.org/CA/Forbidden_or_Problematic_Practices
[2]
https://groups.google.com/d/msg/mozilla.dev.security.policy/UnPOf5WIpXM/SbmSD5eCAgAJ
[3]
https://groups.google.com/d/msg/mozilla.dev.security.policy/MRd8gDwGGA4/AC4xgZ9CBgAJ

---

This is a proposed update to Mozilla's root store policy for version
2.6. Please keep discussion in this group rather than on GitHub. Silence
is consent.

Policy 2.5 (current version):
https://github.com/mozilla/pkipolicy/blob/2.5/rootstore/policy.md
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Policy 2.6 Proposal: Audit requirements for new subCA certificates

[Wayne Thayer via dev-security-policy]

In a recent discussion [1] we decided to clarify the audit requirements for
new subordinate CA certificates. I’ve  drafted a change that requires the
new certificate to appear in the next periodic audits and in the CP/CPS
prior to issuance:

https://github.com/mozilla/pkipolicy/commit/09867ef4a0db3b1cab162930c0326c84d272ec10

We also discussed requiring root key generation ceremony (RKGC) audit
reports, but I have since realized that the BRs (section 6.1.1.1) only
require these audit reports for new root certificates. I’m not convinced
that we should begin requiring an auditor’s report every time a new
subordinate CA certificate is created.

I would appreciate everyone's comments on this proposed change.

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

[1]
https://groups.google.com/d/msg/mozilla.dev.security.policy/CAaC2a2HMiQ/IKimeW4NBgAJ
---

This is a proposed update to Mozilla's root store policy for version
2.6. Please keep discussion in this group rather than on GitHub. Silence
is consent.

Policy 2.5 (current version):
https://github.com/mozilla/pkipolicy/blob/2.5/rootstore/policy.md
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Policy 2.6 Proposal: Require English Language Audit Reports

[Wayne Thayer via dev-security-policy]

Mozilla needs to be able to read audit reports in the English language
without relying on machine translations that may be inaccurate or
misleading.

I suggest adding the following sentence to the end of policy section 3.1.4
“Public Audit Information”:

An English language version of the publicly-available audit information
MUST be supplied by the Auditor.

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

---

This is a proposed update to Mozilla's root store policy for version
2.6. Please keep discussion in this group rather than on GitHub. Silence
is consent.

Policy 2.5 (current version):
https://github.com/mozilla/pkipolicy/blob/2.5/rootstore/policy.md
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Policy 2.6 Proposal: Require audits back to first issuance

[Wayne Thayer via dev-security-policy]

On Mon, Apr 2, 2018 at 9:28 PM, tom.prince--- via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> On Monday, April 2, 2018 at 7:12:19 PM UTC-6, Wayne Thayer wrote:
> > In section 2.3 (Baseline Requirements Conformance), add a new bullet that
> > states "Before being included, CAs MUST provide evidence that their root
> > certificates have continually, from the time of creation, complied with
> the
> > then current Mozilla Root Store Policy and CA/Browser Forum Baseline
> > Requirements."
>
> When I first read this, I parsed it as saying that the only root needs to
> comply with the policy at the time of creation (and not at later points in
> time). I don't have any suggestions on how to make it clear that the root
> needs to have complied at each time with the policy in force at that time.
> 
>

Maybe this is clearer?

In section 2.3 (Baseline Requirements Conformance), add a new bullet that
states "Before being included, CAs MUST provide evidence that their root
certificates have, from the time of creation and continually thereafter,
complied with the then current Mozilla Root Store Policy and CA/Browser
Forum Baseline Requirements."
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: AC Camerfirma Chambers of Commerce and Global Chambersign 2016 Root Inclusion Request

[Wayne Thayer via dev-security-policy]

Thanks everyone for your input. This discussion has reached the conclusion
that Mozilla should deny the inclusion request for the AC Camerfirma
CHAMBERS OF COMMERCE ROOT - 2016 (CCR2016) and GLOBAL CHAMBERSIGN ROOT -
2016

As suggested, AC Camerfirma is welcome to submit a new inclusion request
for a newly generated root using a new key pair.

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

ACES Sunset

[Peter Bachman via dev-security-policy]

https://www.idmanagement.gov/wp-content/uploads/sites/1171/uploads/gsa-aces-sunset-guide.pdf
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Audits for new subCAs

[Ryan Sleevi via dev-security-policy]

On Tue, Apr 3, 2018 at 11:42 AM, Jakob Bohm via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> On 03/04/2018 14:57, Ryan Sleevi wrote:
>
>> On Mon, Apr 2, 2018 at 9:03 PM, Jakob Bohm via dev-security-policy <
>> dev-security-policy@lists.mozilla.org> wrote:
>>
>> On 03/04/2018 02:15, Wayne Thayer wrote:
>>>
>>> On Mon, Apr 2, 2018 at 4:36 PM, Jakob Bohm via dev-security-policy <
 dev-security-policy@lists.mozilla.org> wrote:


 While Entrust happens to do this, as a relying party, I dislike frequent
> updates to CP/CPS documents just for such formal changes.
>
> This creates a huge loophole. The CP/CPS is the master set of policies
> the
>
> TSP agrees to be bound by and audited against. If a TSP doesn't
 include a
 new subCA certificate in the scope of their CP/CPS, then from an audit
 perspective  there is effectively no policy that applies to the subCA.
 Similarly, if the TSP claims to implement a new policy but doesn't
 include
 it in their CP/CPS, then the audit will not cover it (unless it's a BR
 requirement that has made it into the BR audit criteria).


 If the CP/CPS states as an auditable requirements that all SubCAs are
>>> logged in the trusted hardware of the root CA HSM, listed in the
>>> dedicated public document and audited, there is no need for that list to
>>> be included verbatim in the CP/CPS any more than there is a need for
>>> most other routine activities to change the CP/CPS.
>>>
>>>
>> This is not true. A CP/CPS is not bound to the organization, it's bound to
>> specific operations, and as such, the creation of a subCA by an
>> organization has no implicit binding to a CP/CPS.
>>
>>
> A CP/CPS covers (by its very nature) all SubCA signing operations
> by a covered CA private key and as others have pointed out, each
> compliant SubCA is required to contain an OID identifying the applicable
> CP/CPS.
>
> Thus a CP/CPS can state that it covers all CA keys and certs listed in
> public document X and that all SubCAs referencing that CP/CPS and issued
> by a covered CA key must be added to public document X, which shall be
> published and archived in a specific way, such as in the CA
> organizations public repository, sent to all enrolled root programs and
> logged to CT.
>
> The CP/CPS can also state that the CA HSM must store, in a secured
> hardware log, all signed SubCA certs (or even all issued certs), this
> log will be one of the key things checked by auditors (it already is in
> the current WebTrust and ETSI auditing standards, as part of the
> sampling of previously issued end entity certs).
>

This all sounds good, but it does not reflect reality.

Consider a sub-CA whose control has been transferred - as has recently been
discussed here. The certificate does not magically change Policy OIDs, it
does not get revoked and reissued with a new policy OID, and yet, it is
operated under a distinct, new, and different CP/CPS.

As such, the proposed solution is fundamentally flawed, and resting on a
flawed assumption about how both CP/CPS works and the ecosystem works. For
this very reason, it seems extremely valuable - if not vitally necessary -
to ensure the scope is clearly and fairly stated, particularly when
engaging auditors who themselves will be bound by the scope of the publicly
stated documents, to the extent permitted within the scope of the audit.

Let's close a loophole. Not introduce more.


>
>
>
>>
>>> This is because the CP/CPS is a lengthy legal document which relying
>>>

 parties are "supposed to" read and understand.  Thus each such needless
> change generates a huge wave of millions of relying parties being
> supposed to obtain and read through that document, a complete waste of
> our time as relying parties.
>
> I think you're confusing the Relying Party Agreement with the CP/CPS.
> Even
>
> so, you've pointed out that it is absurd to use this as an argument
 against
 regular CP/CPS updates.


 Relying party agreements (and subscriber agreements too) often
>>> incorporate the CP/CPS by reference.
>>>
>>
>>
>> Can you point out to where that's required by Mozilla policy or by the
>> Baseline Requirements?
>>
>>
> It is not a BR, it is an observation of common practice.
>

I disagree even to the claim that it's "common" practice. There is only one
CA that has ever raised this as a practical matter of concern, but their
practices are so fundamentally outmoded that it's hardly to be considered
the model of a good CA operation.


> It is much more reasonable, from a relying party perspective, for such
>>>

 informational details to be in a parallel document and/or be postponed
> until a scheduled annual or rarer document update (Yes I am aware of
> the
> BR that such needless updates be done annually for no reason at all).
>
> How would you distinguish between details and 

Re: AC Camerfirma Chambers of Commerce and Global Chambersign 2016 Root Inclusion Request

[ramirommunoz--- via dev-security-policy]

El miércoles, 4 de abril de 2018, 4:10:16 (UTC+2), Matt Palmer  escribió:
> On Tue, Apr 03, 2018 at 05:19:32AM -0700, ramirommunoz--- via 
> dev-security-policy wrote:
> > Completely agree with you about that a new root by itself do not solve the 
> > problem.
> 
> The phrase you're looking for is "necessary but not sufficient".  That is,
> it is necessary to create new roots to restore trust, but not sufficient to
> do so.  You also have to demonstrate a high degree of competence in running
> a CA, and understanding and responding to legitimate concerns.
> 
> > The issue now is choosing the starting point.
> > 
> > 1.- New root 2018
> > 
> > 2.- 2016 root, after revoke all certificates (< 100 units) and pass an
> > "Point in Time" BR compliant audit.  (Camerfirma proposal)
> 
> The problem with the 2016 roots is that there is no way to rehabilitate them
> to the point that they will be as worthy of trust as new, fresh roots, for
> several reasons.
> 
> Firstly, revocation is "fail open".  Not every relying party checks
> revocation information, and when the checks are made but they fail, it is
> *usually* OK to continue, so user agents do so.
> 
> Revocation is the ejection seat of PKI.  It's the option of last resort when
> everything else has gone to hell, and you can only hope it does the job. 
> You don't build a crappy fighter aircraft whose wings fall off periodically,
> and then justify it by saying "oh, it's OK, it's got an ejection seat".  No,
> you build the best 'plane you can, and you add the ejection seat as the
> "well, it's *slightly* better than nothing" final option.  Because they hurt
> to use.  A lot.  And for various reasons they don't always work quite right. 
> But they give you a better chance of survival than a crash.
> 
> However, back to the point at hand: even if revocation were 100% reliable,
> there's still the possibility of incomplete enumeration of certificates.  I
> cannot think of a way you could possibly prove that there is zero chance of
> there being undisclosed certificates chaining to the old roots.  New roots,
> on the other hand, have that zero chance, because they're new, and have been
> under effective audited control since day zero.  So, again, new roots would
> be more trustworthy than the old roots.
> 
> - Matt

Thanks for your comments Matt

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

Re: AC Camerfirma Chambers of Commerce and Global Chambersign 2016 Root Inclusion Request

[ramirommunoz--- via dev-security-policy]

El martes, 3 de abril de 2018, 23:48:32 (UTC+2), okaphone.e...@gmail.com  
escribió:
> On Tuesday, 3 April 2018 14:19:43 UTC+2, ramiro...@gmail.com  wrote:
> > El martes, 3 de abril de 2018, 11:58:49 (UTC+2), okaphone.e...@gmail.com  
> > escribió:
> > > On Monday, 2 April 2018 19:22:02 UTC+2, ramiro...@gmail.com  wrote:
> > > > El lunes, 2 de abril de 2018, 3:53:08 (UTC+2), Tom Prince  escribió:
> > > > > On Sunday, April 1, 2018 at 4:16:47 AM UTC-6, ramiro...@gmail.com 
> > > > > wrote:
> > > > > > I fully understand the proposed solution about 2018 roots but as I 
> > > > > > previously said some concerns arise, [...]
> > > > > 
> > > > > 
> > > > > That is unfortunate for Camerfirma, but it is not Mozilla or this 
> > > > > lists issue. While people have provided some suggestions on how you 
> > > > > can create a root that *might* be acceptable, I don't think any of 
> > > > > the participants care if Camerfirma has a root accepted; given the 
> > > > > issues previously identified and the responses to those issues, I 
> > > > > think a number of participants would be just as happy if Camerfirma 
> > > > > doesn't get accepted.
> > > > > 
> > > > 
> > > > Hi Tom
> > > > I'm just trying to provide a different scenario than create a new root. 
> > > > Sure that many participants do not care about our particular 
> > > > situation:-(, but this make a big difference for us and also for our 
> > > > customers. If the only way to going forward is to create a new root, we 
> > > > will do it, but our obligation is trying to provide a more convenient 
> > > > solution for Camerfirma without jeopardize the trustworthiness of the 
> > > > ecosystem.
> > > 
> > > Creating a new root by itself will not solve anything. The problem you 
> > > have is with trust. It's up to you to offer a root that can be used as a 
> > > trust anchor. Reasons why the 2016 root has become unsuitable for this 
> > > have been discussed in detail.
> > > 
> > > The way out can be creating a new root, but that makes only sense if/when 
> > > you are sure all problems have been solved and will not happen with the 
> > > certificates that would be issued from this new root. If you are not 100% 
> > > sure about this, the new root will most likely soon become as useless 
> > > (for thrust) as the old one. Please don't do it before you are ready.
> > > 
> > > CU Hans
> > 
> > Thank Hans for your comments.
> > 
> > Completely agree with you about that a new root by itself do not solve the 
> > problem.
> > 
> > We have been working on those aspect detected by Wayne at the beginning of 
> > this thread. CPS issues, CAA issues..etc. So we think we are now ready to 
> > keep on with the root inclusion. Are we 100% sure ?, No one can assure that 
> > of their own systems, but we have placed controls to avoid the known 
> > problems, and detect the unknown ones.
> > 
> > The issue now is choosing the starting point.
> > 
> > 1.- New root 2018
> > 
> > 2.- 2016 root, after revoke all certificates (< 100 units) and pass an 
> > "Point in Time" BR compliant audit. (Camerfirma proposal)
> > 
> > 3.- We have send two root to the inclusion process. "Chambers of commerce 
> > root 2016", this is the root which has issue a few(4) missunsed 
> > certificates 
> > https://crt.sh/?cablint=273=50473=2011-01-01, all of 
> > them revoked. But we have sent "Chambersign Global Root 2016" as well, and 
> > this root is free of issuing errors.
> > 
> > Our claim to the community is to use as starting point option 2 or option 3.
> 
> You still don't seem to understand. This is not about hoops you need to jump 
> through to get your root included. It is about trust and it is entirely up to 
> you to do whatever is needed to (re)gain that.
> 
> You won't get any "requirements" other than the ones you already know all 
> about. Some people here may offer you advice they think will help you move 
> forward with this. But if that doesn't suit you for one reason or another 
> then that is just your choice, no problem. And if you do choose to follow 
> somebody's advice, that doesn't imply your root will be included. It's just 
> what they think is your best option. But as I said, creating a new root won't 
> help you one bit if the problems have not been solved in a way that makes 
> sure they won't happen again. Or if further problems will surface.
> 
> The bottom line is nothing more and nothing less than making it sufficiently 
> plausible as a CA that the root you would like to see included is (and will 
> stay) a suitable trust anchor. How you want to do that is your decision. The 
> community will and can not make that decision for you. All they have for you 
> is feedback (see above).
> 
> (Actually I have no idea why I'm telling you all this. You should already 
> understand it as a CA. Anyway, just trying to help... ;-)
> 
> CU Hans

Thanks for you help Hans

Regards
Ramiro
___
dev-security-policy mailing list

Re: FW: Complying with Mozilla policy on email validation

[Adrian R. via dev-security-policy]

On Tuesday, 3 April 2018 20:19:40 UTC+3, Ryan Hurst  wrote:
> 
> Reading this thread and thinking the current text, based on the 
> interpretation discussed, does not accommodate a few cases that I think are 
> useful.
> 
> For example, if we consider a CA supporting a large mail provider in 
> providing S/MIME certificates to all of its customers. In this model, the 
> mail provider is the authoritative namespace owner.  
> 
> In the context of mail, you can imagine gmail.com or peculiarventures.com as 
> examples, both are gmail (as determined by MX records). It seems reasonable 
> to me (Speaking as Ryan and not Google here) to allow a CA to leverage this 
> internet reality (expressed via MX records) to work with a CA to get S/MIME 
> certificates for all of its customers without forcing them through an email 
> challenge. 
> 
> In this scenario, you could not rely on name constraints because the 
> onboarding of custom domains (like peculiarventures.com) happens real time as 
> part of account creation. The prior business controls text seemed to allow 
> this case but it seems the interpretation discussed here would prohibit it.
> 
> 
> Another case I think is interesting is that of a delegation of email 
> verification to a third-party. For example, when you do a OAUTH 
> authentication to Facebook it will return the user’s email address if it has 
> been verified. The same is true for a number of related scenarios, for 
> example, you can tell via Live Authentication and Google Authentication if 
> the user's email was verified.
> 
> The business controls text plausibly would have allowed this use case also.
> 
> I think a policy that does not allow a CA to support these use cases would 
> severly limit the use cases in which S/MIME could be used and I would like to 
> see them considered.
> 
> Ryan Hurst



There's also  (1) the case of wildcard/catch-all email addresses and (2) that 
of the email provider for hosted domains, provider that has access to the 
postmaster account.

case (1) wildcard/catch-all addresses ( *@example.com ) are allowed by some 
services (even Google's G Suite) as a delivery method when an email address 
does not map to a traditional email account.
RFC 5321 section 2.3.11. (Mailbox and Address) allows such usage of wildcard 
email addresses and they are VERY useful when used as receive-only addresses 
for anti-spam usage and as indicators of compromise in case of data leaks in 
3rd party databases.

S/MIME certificates for such wildcard addresses should not be allowed without 
strict verification - such certificates should require at least Domain 
Validation or a validation method of equal strength to what the domain already 
has (if it has a cert already). If the domain has an OV or EV certificate then 
the S/MIME certificate for the wildcard should use, in addition to DV, at least 
the same validation rules.

 I use a wildcard configuration with receive-only addresses tailored to the 
service that asks them and made up on the spot (e.g. 
--- @ domain), for almost anything 
that asks me for an email address. This way i can even use a pen on a 
traditional paper form and make up an unique email address JUST for filling on 
that form. 
 If that address starts to receive unsolicited mail from anywhere else except 
the site/company it was designed for then that means that they either sold my 
data to a 3rd party or they had a data leak and the EU GDPR is very unforgiving 
with such usage.
 GMail's traditional plus-aliased addresses are not really usable anymore 
because many sites do not allow "plus" characters in email addresses. Wildcards 
are much more flexible for this. 



case (2): that of the email provider for hosted domains, provider that has 
access to the postmaster account - this is a form of delegation of email 
verification to a third-party.
In this case the postmaster account used by the email provider for technical 
management of the service should not be allowed to be used to obtain wildcard 
S/MIME certificates (but they can obtain regular, non-wildcard ones). root or 
webmaster would be more suitable as contact addresses in this case.

Again, i use G Suite as an example why: when using email for domains hosted at 
GMail then the domain owner must give access to the abuse and postmaster 
accounts to Google Support.
In my opinion this access is ok for managing the service, but is not ok when 
performing validations to obtain S/MIME certs for wildcard catch-all addresses.


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