Re: Policy 2.7.1:MRSP Issue #205: Require CAs to publish accepted methods for proving key compromise

[Dimitris Zacharopoulos via dev-security-policy]

On 12/11/2020 10:51 μ.μ., Ryan Sleevi via dev-security-policy wrote:

On Thu, Nov 12, 2020 at 1:39 PM Ben Wilson via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:


On Thu, Nov 12, 2020 at 2:57 AM Dimitris Zacharopoulos 
wrote:


I believe this information should be the "minimum" accepted methods of
proving that a Private Key is compromised. We should allow CAs to accept
other methods without the need to first update their CP/CPS. Do people
think that the currently proposed language would forbid a CA from
accepting methods that are not explicitly documented in the CP/CPS?

I also think that "parties" is a bit ambiguous, so I would suggest
modifying that to follow the language of the BRs section 4.9.2
"Subscribers, Relying Parties, Application Software Suppliers, and other
third parties". Here is my proposed change:

"Section 4.9.12 of a CA's CP/CPS MUST clearly specify the methods (at a
minimum) that Subscribers, Relying Parties, Application Software
Suppliers, and other third parties may use to demonstrate private key
compromise."

Dimitris,

Instead, what about something like,  "Section 4.9.12 of a CA's CP/CPS MUST
clearly specify its accepted methods that Subscribers, Relying Parties,
Application Software Suppliers, and other third parties may use to
demonstrate private key compromise. A CA MAY allow additional, alternative
methods that do not appear in section 4.9.12 of its CP/CPS." ?


I understand and appreciate Dimitris' concern, but I think your original
language works better for Mozilla users in practice, and sadly, moves us
back in a direction that the trend has been to (carefully) move away from.

I would say the first goal is transparency, and I think that both proposals
try to accomplish that baseline level of providing some transparency. Where
I think it's different is that the concern Dimitris raised about
"minimums", and the proposed language here, is that it discourages
transparency. "We accept X or Y", and a secret document suggesting "We also
accept Z", makes it difficult to evaluate a CA on principle.


There is transparency that the CA has evaluated some reporting 
mechanisms and these will be documented in the CPS. However, on an issue 
like compromised key reporting, there is no single recipe that covers 
all possible and secure ways for a third-part to report a key 
compromise. This has already been demonstrated in the various 
discussions on this Forum. In such time-sensitive issues, where 
certificates must be revoked within 24 hours, CAs should have the 
liberty to accept a key compromise being reported by a method that might 
be considered acceptable but which the CA's engineers didn't think about 
when drafting the CPS. We can't expect a CA to update a CPS within 24 
hours to allow additional reporting methods before accepting them.


For CAs that want to do the right thing with this flexibility, the 
original language Ben proposed seems to be problematic, which is why I 
highlighted it in the discussion. The updated language keeps all the 
"good" things from the original language, and allows the CA to accept a 
reporting method that they may have not considered. Obviously, the 
logical thing is that once this new method is accepted, the CPS should 
be updated to include that additional method but that might take place 
later, after the report was accepted and certificates revoked.


I can't think of a bad scenario with this added language.



The second goal is auditability: whether or not the CP/CPS represents a
binding commitment to the community. This is why they exist, and they're
supposed to help relying parties not only understand how the CA operates,
but how it is audited. If a CA has a secret document Foo that discloses
secret method Z, is the failure to actually support secret method Z worth
noting within the audit? I would argue yes, but this approach would
(effectively) argue no.


This makes no sense to me. We're not discussing secrets here. Say a 
third party reports a key compromise by sending a signed plaintext 
message, and the CA has only indicated as accepting a CSR with a 
specific string in the CN field. The updated proposal would allow the CA 
to evaluate this "undocumented" (in the CPS) reporting method, check for 
its credibility/accuracy and proceed with accepting it or not.


The original proposal seems to forbid this and forces the CA instructing 
the reporter to create a CSR with a specific string because that's the 
only thing allowed in the CPS.


I hope this makes it clearer.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Policy 2.7.1:MRSP Issue #205: Require CAs to publish accepted methods for proving key compromise

[Nick Lamb via dev-security-policy]

On Thu, 12 Nov 2020 15:51:55 -0500
Ryan Sleevi via dev-security-policy
 wrote:

> I would say the first goal is transparency, and I think that both
> proposals try to accomplish that baseline level of providing some
> transparency. Where I think it's different is that the concern
> Dimitris raised about "minimums", and the proposed language here, is
> that it discourages transparency. "We accept X or Y", and a secret
> document suggesting "We also accept Z", makes it difficult to
> evaluate a CA on principle.

[...]

> Yes, this does mean they would need to update their CP/CPS as they
> introduce new methods, but this seems a net-positive for everyone.

I think the concern about defining these other than as minimums is
scenarios in which it's clear to us that key compromise has taken place
but your preferred policy forbids a CA from acting on that knowledge on
the grounds that doing so isn't "transparent" enough for your liking
because their policy documents did not spell out the method which
happened to be used.

The goal of this policy change is to avoid the situation where a
researcher has one or more compromised keys and, rather than being able
to quickly and securely set in motion the process of revoking relevant
certificates and forbidding more being issued they end up in a game of
telephone (perhaps literally) with a CA because its policies are
unclear or unworkable.

You seem to anticipate a quite different environment in which "secret
documents" are used to justify revocations which you presumably see as
potentially illegitimate. I haven't seen any evidence of anything like
that happening, or of anybody seeking to make it happen - which surely
makes a Mozilla policy change to try to prevent it premature.


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

Re: Policy 2.7.1: MRSP Issue #192: Require information about auditor qualifications in the audit report

[Kathleen Wilson via dev-security-policy]

PS: In the meantime, we will continue to verify auditor qualifications 
as described here:

https://wiki.mozilla.org/CA/Audit_Statements#Auditor_Qualifications


On 11/12/20 4:27 PM, Kathleen Wilson wrote:

 > It is proposed in Issue #192
 >  that information about
 > individual auditor's qualifications be provided--identity, competence,
 > experience and independence. (For those interested as to this 
independence

 > requirement, Mozilla Policy v.1.0 required either disclosure of the
 > auditor's compensation or the establishment that the auditor "is 
bound by
 > law, government regulation, and/or a professional code of ethics to 
render

 > an honest and objective judgement regarding the CA.")


I am very much in favor of increasing transparency about the 
qualifications of the auditors providing audit statements for CAs in our 
program. However, I think that we need to spend more time figuring out a 
few things before adding such a requirement to our policy. Therefore, I 
think we should add this to our list of things to spend some focused 
time to figure out in early 2021, and move this item to the next version 
of Mozilla’s root store policy.


Below are some of the questions we need to be able to answer before 
adding this requirement to Mozilla's root store policy.


Please do NOT respond to these questions now. We will have future 
discussions about this when we are ready.


- What information is needed and in what format to demonstrate each 
individual auditor's qualifications?
- What are the criteria to be considered and what is sufficient to be 
considered a qualified auditor?

- How do auditors apply to be considered qualified auditors?
- How can new participants become involved in this space and become 
qualified auditors?

- What is the process to determine if an auditor is qualified?
- Does every auditor signing their name or listed in an audit statement 
need to be verified as a qualified auditor? Or just the lead auditor?
- How are the qualifications of the auditors communicated in conjunction 
with the audit statement(s)?

- Who is responsible for verifying auditor qualifications?
- Who is responsible for maintaining the list of known qualified auditors?
- How do CAs find out if their auditors are qualified?

I look forward to having these discussions in full later, but I think 
this effort is too large in scope for version 2.7.1 of Mozilla's Root 
Store Policy.


Thanks,
Kathleen



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

Re: Policy 2.7.1: MRSP Issue #192: Require information about auditor qualifications in the audit report

[Kathleen Wilson via dev-security-policy]

> It is proposed in Issue #192
>  that information about
> individual auditor's qualifications be provided--identity, competence,
> experience and independence. (For those interested as to this 
independence

> requirement, Mozilla Policy v.1.0 required either disclosure of the
> auditor's compensation or the establishment that the auditor "is bound by
> law, government regulation, and/or a professional code of ethics to 
render

> an honest and objective judgement regarding the CA.")


I am very much in favor of increasing transparency about the 
qualifications of the auditors providing audit statements for CAs in our 
program. However, I think that we need to spend more time figuring out a 
few things before adding such a requirement to our policy. Therefore, I 
think we should add this to our list of things to spend some focused 
time to figure out in early 2021, and move this item to the next version 
of Mozilla’s root store policy.


Below are some of the questions we need to be able to answer before 
adding this requirement to Mozilla's root store policy.


Please do NOT respond to these questions now. We will have future 
discussions about this when we are ready.


- What information is needed and in what format to demonstrate each 
individual auditor's qualifications?
- What are the criteria to be considered and what is sufficient to be 
considered a qualified auditor?

- How do auditors apply to be considered qualified auditors?
- How can new participants become involved in this space and become 
qualified auditors?

- What is the process to determine if an auditor is qualified?
- Does every auditor signing their name or listed in an audit statement 
need to be verified as a qualified auditor? Or just the lead auditor?
- How are the qualifications of the auditors communicated in conjunction 
with the audit statement(s)?

- Who is responsible for verifying auditor qualifications?
- Who is responsible for maintaining the list of known qualified auditors?
- How do CAs find out if their auditors are qualified?

I look forward to having these discussions in full later, but I think 
this effort is too large in scope for version 2.7.1 of Mozilla's Root 
Store Policy.


Thanks,
Kathleen

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

Re: Policy 2.7.1:MRSP Issue #205: Require CAs to publish accepted methods for proving key compromise

[Ryan Sleevi via dev-security-policy]

On Thu, Nov 12, 2020 at 1:39 PM Ben Wilson via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> On Thu, Nov 12, 2020 at 2:57 AM Dimitris Zacharopoulos 
> wrote:
>
> >
> > I believe this information should be the "minimum" accepted methods of
> > proving that a Private Key is compromised. We should allow CAs to accept
> > other methods without the need to first update their CP/CPS. Do people
> > think that the currently proposed language would forbid a CA from
> > accepting methods that are not explicitly documented in the CP/CPS?
> >
> > I also think that "parties" is a bit ambiguous, so I would suggest
> > modifying that to follow the language of the BRs section 4.9.2
> > "Subscribers, Relying Parties, Application Software Suppliers, and other
> > third parties". Here is my proposed change:
> >
> > "Section 4.9.12 of a CA's CP/CPS MUST clearly specify the methods (at a
> > minimum) that Subscribers, Relying Parties, Application Software
> > Suppliers, and other third parties may use to demonstrate private key
> > compromise."
> >
> > Dimitris,
> Instead, what about something like,  "Section 4.9.12 of a CA's CP/CPS MUST
> clearly specify its accepted methods that Subscribers, Relying Parties,
> Application Software Suppliers, and other third parties may use to
> demonstrate private key compromise. A CA MAY allow additional, alternative
> methods that do not appear in section 4.9.12 of its CP/CPS." ?
>

I understand and appreciate Dimitris' concern, but I think your original
language works better for Mozilla users in practice, and sadly, moves us
back in a direction that the trend has been to (carefully) move away from.

I would say the first goal is transparency, and I think that both proposals
try to accomplish that baseline level of providing some transparency. Where
I think it's different is that the concern Dimitris raised about
"minimums", and the proposed language here, is that it discourages
transparency. "We accept X or Y", and a secret document suggesting "We also
accept Z", makes it difficult to evaluate a CA on principle.

The second goal is auditability: whether or not the CP/CPS represents a
binding commitment to the community. This is why they exist, and they're
supposed to help relying parties not only understand how the CA operates,
but how it is audited. If a CA has a secret document Foo that discloses
secret method Z, is the failure to actually support secret method Z worth
noting within the audit? I would argue yes, but this approach would
(effectively) argue no.

I think your original language was better suited for this, and is
consistent with the view that the CP/CPS is both the primary document that
becomes part of the auditable controls, and is the primary document for
reviewing how well a CA aligns with Mozilla's practices, needs, and users.

Yes, this does mean they would need to update their CP/CPS as they
introduce new methods, but this seems a net-positive for everyone. Getting
CAs more attuned into updating their CP/CPS, to provide adequate
disclosure, seems like a net-win, even though I'm sure some CAs have
designed processes and contracts that make this difficult. However, the
industry of the past 10 years has shown the importance of being able to
update the CP/CPS, and clearly document it, so I think we should
increasingly be skeptical about statements about the challenges.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Policy 2.7.1: MRSP Issue #186: Requirement to Disclose Self-signed Certificates

[Ben Wilson via dev-security-policy]

Jakob,

On Thu, Nov 12, 2020 at 10:39 AM Jakob Bohm via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

>
> How would that phrasing cover doppelgangers of intermediary SubCAs under
> an included root CA?
>
>
> To clarify, the title of section 5.3 is "Intermediate Certificates".
Also, both subsection (1) and (2) under the proposed amendment reference
"intermediate certificates" -  "(1) ...the Subject Distinguished Name in a
CA certificate or *intermediate certificate* that is in scope according to
section 1.1 of this Policy" and "(2)... corresponding Public Key is encoded
in the SubjectPublicKeyInfo of that CA certificate or *intermediate
certificate*." And finally, additional
language would try and make this clear by saying, "Thus, these requirements
also apply to so-called reissued/doppelganger CA certificates (roots *and
intermediates*) and to cross-certificates."

I hope this answers your question.

Sincerely,

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

Re: Policy 2.7.1:MRSP Issue #205: Require CAs to publish accepted methods for proving key compromise

[Dimitris Zacharopoulos via dev-security-policy]

On 2020-11-12 8:38 μ.μ., Ben Wilson wrote:


On Thu, Nov 12, 2020 at 2:57 AM Dimitris Zacharopoulos 
mailto:ji...@it.auth.gr>> wrote:



I believe this information should be the "minimum" accepted
methods of
proving that a Private Key is compromised. We should allow CAs to
accept
other methods without the need to first update their CP/CPS. Do
people
think that the currently proposed language would forbid a CA from
accepting methods that are not explicitly documented in the CP/CPS?

I also think that "parties" is a bit ambiguous, so I would suggest
modifying that to follow the language of the BRs section 4.9.2
"Subscribers, Relying Parties, Application Software Suppliers, and
other
third parties". Here is my proposed change:

"Section 4.9.12 of a CA's CP/CPS MUST clearly specify the methods
(at a
minimum) that Subscribers, Relying Parties, Application Software
Suppliers, and other third parties may use to demonstrate private key
compromise."

Dimitris,
Instead, what about something like,  "Section 4.9.12 of a CA's CP/CPS 
MUST clearly specify its accepted methods that Subscribers, Relying 
Parties, Application Software Suppliers, and other third parties may 
use to demonstrate private key compromise. A CA MAY allow additional, 
alternative methods that do not appear in section 4.9.12 of its CP/CPS." ?

Ben


That works better. Thank you.

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

Re: Policy 2.7.1:MRSP Issue #205: Require CAs to publish accepted methods for proving key compromise

[Ben Wilson via dev-security-policy]

On Thu, Nov 12, 2020 at 2:57 AM Dimitris Zacharopoulos 
wrote:

>
> I believe this information should be the "minimum" accepted methods of
> proving that a Private Key is compromised. We should allow CAs to accept
> other methods without the need to first update their CP/CPS. Do people
> think that the currently proposed language would forbid a CA from
> accepting methods that are not explicitly documented in the CP/CPS?
>
> I also think that "parties" is a bit ambiguous, so I would suggest
> modifying that to follow the language of the BRs section 4.9.2
> "Subscribers, Relying Parties, Application Software Suppliers, and other
> third parties". Here is my proposed change:
>
> "Section 4.9.12 of a CA's CP/CPS MUST clearly specify the methods (at a
> minimum) that Subscribers, Relying Parties, Application Software
> Suppliers, and other third parties may use to demonstrate private key
> compromise."
>
> Dimitris,
Instead, what about something like,  "Section 4.9.12 of a CA's CP/CPS MUST
clearly specify its accepted methods that Subscribers, Relying Parties,
Application Software Suppliers, and other third parties may use to
demonstrate private key compromise. A CA MAY allow additional, alternative
methods that do not appear in section 4.9.12 of its CP/CPS." ?
Ben
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: MRSP Issue #147 - Require EV audits for certificates capable of issuing EV certificates

[Ben Wilson via dev-security-policy]

On Thu, Nov 12, 2020 at 2:03 AM Dimitris Zacharopoulos via
dev-security-policy  wrote:

> I see that this is related to
> https://github.com/mozilla/pkipolicy/issues/152, so I guess Mozilla
> Firefox does not enable "EV Treatment" if an Intermediate CA Certificate
> does not assert the anyPolicy or the CA's EV policy OID, including the
> CA/B Forum EV OID, regardless of what the end-entity certificate asserts.
>
> That's correct.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: TLS certificates for ECIES keys

[Bailey Basile via dev-security-policy]

Sorry! It looks like the attachments didn't come through. Here's each chain:

Prio Statistics Facilitator_ XX.chain.pem
-BEGIN CERTIFICATE-
MIIDmTCCAz+gAwIBAgIQVUMIP1vPOWm3Rozjmb8qYzAKBggqhkjOPQQDAjBZMTUw
MwYDVQQDDCxUZXN0IEFwcGxlIEFwcGxpY2F0aW9uIEludGVncmF0aW9uIENBIDYg
LSBHMTETMBEGA1UECgwKQXBwbGUgSW5jLjELMAkGA1UEBhMCVVMwHhcNMjAxMTA1
MTc0MTU0WhcNMjExMjA1MTc0MTU0WjBEMSgwJgYDVQQDDB9QcmlvIFN0YXRpc3Rp
Y3MgRmFjaWxpdGF0b3I6IFhYMRgwFgYDVQQKDA9FeHRlcm5hbCBFbnRpdHkwWTAT
BgcqhkjOPQIBBggqhkjOPQMBBwNCAARFcpbRk+3269K4gP+jBR0my2KYnGwDmBY/
ruIvbV/VZkn7qPdh+de+tXMy2s374RBbwtzEcOwiSikCGQW43Y4fo4IB/DCCAfgw
DAYDVR0TAQH/BAIwADAfBgNVHSMEGDAWgBSphcEaCuXYec3we0b6me9LYUdzhDBQ
BggrBgEFBQcBAQREMEIwQAYIKwYBBQUHMAGGNGh0dHA6Ly9vY3NwLXVhdC5jb3Jw
LmFwcGxlLmNvbS9vY3NwMDMtdGVzdGFhaWNhNmcxMDIwggEdBgNVHSAEggEUMIIB
EDCCAQwGCSqGSIb3Y2QFATCB/jCBwwYIKwYBBQUHAgIwgbYMgbNSZWxpYW5jZSBv
biB0aGlzIGNlcnRpZmljYXRlIGJ5IGFueSBwYXJ0eSBhc3N1bWVzIGFjY2VwdGFu
Y2Ugb2YgdGhlIHRoZW4gYXBwbGljYWJsZSBzdGFuZGFyZCB0ZXJtcyBhbmQgY29u
ZGl0aW9ucyBvZiB1c2UsIGNlcnRpZmljYXRlIHBvbGljeSBhbmQgY2VydGlmaWNh
dGlvbiBwcmFjdGljZSBzdGF0ZW1lbnRzLjA2BggrBgEFBQcCARYqaHR0cHM6Ly93
d3cuYXBwbGUuY29tL2NlcnRpZmljYXRlYXV0aG9yaXR5MBQGA1UdJQQNMAsGCSqG
SIb3Y2QEEjAdBgNVHQ4EFgQUQfM6gfYThdT25wd3RxbSmuX9Ic8wDgYDVR0PAQH/
BAQDAgMIMA8GCSqGSIb3Y2QPAgQCBQAwCgYIKoZIzj0EAwIDSAAwRQIgPk1q++Hg
MorAeWyxJrATByoMUCpFGBhgP3/IdCyhv+QCIQC14+ROFCD8fVRSvtJ8IpvxiR21
f3HfQ72hwcH23jEFQg==
-END CERTIFICATE-
-BEGIN CERTIFICATE-
MIIC7zCCAnWgAwIBAgIITkSG+diMnpkwCgYIKoZIzj0EAwMwbDEgMB4GA1UEAwwX
VGVzdCBBcHBsZSBSb290IENBIC0gRzMxJjAkBgNVBAsMHUFwcGxlIENlcnRpZmlj
YXRpb24gQXV0aG9yaXR5MRMwEQYDVQQKDApBcHBsZSBJbmMuMQswCQYDVQQGEwJV
UzAeFw0yMDA2MjUyMzQxMjdaFw0zNTA2MjIyMzQxMjdaMFkxNTAzBgNVBAMMLFRl
c3QgQXBwbGUgQXBwbGljYXRpb24gSW50ZWdyYXRpb24gQ0EgNiAtIEcxMRMwEQYD
VQQKDApBcHBsZSBJbmMuMQswCQYDVQQGEwJVUzBZMBMGByqGSM49AgEGCCqGSM49
AwEHA0IABBPPW0nKWVaSPVxG1XqV5KCwhB5oPiwTsdxOJqxyahGTd+Og429IC5b1
/tW9pbxPdAPxCfO/ww24m2IrwNNKBpWjggESMIIBDjAPBgNVHRMBAf8EBTADAQH/
MB8GA1UdIwQYMBaAFPxG2INsH+by3N+nmReuC0RnFxtGMFMGCCsGAQUFBwEBBEcw
RTBDBggrBgEFBQcwAYY3aHR0cDovL29jc3AtdWF0LmNvcnAuYXBwbGUuY29tL29j
c3AwMy10ZXN0YXBwbGVyb290Y2FnMzBEBgNVHR8EPTA7MDmgN6A1hjNodHRwOi8v
Y3JsLXVhdC5jb3JwLmFwcGxlLmNvbS90ZXN0YXBwbGVyb290Y2FnMy5jcmwwHQYD
VR0OBBYEFKmFwRoK5dh5zfB7RvqZ70thR3OEMA4GA1UdDwEB/wQEAwIBBjAQBgoq
hkiG92NkBgIaBAIFADAKBggqhkjOPQQDAwNoADBlAjAosWWcj/xO+fMYIfAAt3Yj
V3ixGnEV0O97PK9PxhxNVRZdG5Lel0yI5Iothth5LbUCMQD0vLB44Q71ik+5I9d1
a4gj3e3K0aAnxIbtS4wkImFsVkJf+isQQ/qg6Cewy1/qy/s=
-END CERTIFICATE-
-BEGIN CERTIFICATE-
MIICTDCCAdOgAwIBAgIIeDYL9LfItrAwCgYIKoZIzj0EAwMwbDEgMB4GA1UEAwwX
VGVzdCBBcHBsZSBSb290IENBIC0gRzMxJjAkBgNVBAsMHUFwcGxlIENlcnRpZmlj
YXRpb24gQXV0aG9yaXR5MRMwEQYDVQQKDApBcHBsZSBJbmMuMQswCQYDVQQGEwJV
UzAeFw0xNTA0MjIwMzE3NDRaFw00MDEyMjYwMzEzMzdaMGwxIDAeBgNVBAMMF1Rl
c3QgQXBwbGUgUm9vdCBDQSAtIEczMSYwJAYDVQQLDB1BcHBsZSBDZXJ0aWZpY2F0
aW9uIEF1dGhvcml0eTETMBEGA1UECgwKQXBwbGUgSW5jLjELMAkGA1UEBhMCVVMw
djAQBgcqhkjOPQIBBgUrgQQAIgNiAASpGmM077ymitYqajgi6SWt2iigScVk/l2R
w2z3meS65CpfYdK/O2yoYRG14Gb3IhGGl13DuhttVX/Q+YDg/9kFrVpbvzp6pwlS
GjF/DKLoEPU208jqoFsKKIUwKF+U9pSjQjBAMB0GA1UdDgQWBBT8RtiDbB/m8tzf
p5kXrgtEZxcbRjAPBgNVHRMBAf8EBTADAQH/MA4GA1UdDwEB/wQEAwIBBjAKBggq
hkjOPQQDAwNnADBkAjAaFDgk/7QIy+rJO9rMgvPZDdErbr8fxBUURN+Ym9fduhu+
T58XpNICdZB9dsyTFi8CMALX2gu+3T3t+aMGkKlYvWt8fOXFTg5EopQvtASazZtp
jSrGHVj/4zK22z40/2dw8Q==
-END CERTIFICATE-

Prio Statistics Public Health Authority_ XX.chain.pem
-BEGIN CERTIFICATE-
MIIDpjCCA0ugAwIBAgIQZWCtfLnEJ/nLAn8jf4PvZTAKBggqhkjOPQQDAjBZMTUw
MwYDVQQDDCxUZXN0IEFwcGxlIEFwcGxpY2F0aW9uIEludGVncmF0aW9uIENBIDYg
LSBHMTETMBEGA1UECgwKQXBwbGUgSW5jLjELMAkGA1UEBhMCVVMwHhcNMjAxMTA1
MTc0NjMxWhcNMjExMjA1MTc0NjMxWjBQMTQwMgYDVQQDDCtQcmlvIFN0YXRpc3Rp
Y3MgUHVibGljIEhlYWx0aCBBdXRob3JpdHk6IFhYMRgwFgYDVQQKDA9FeHRlcm5h
bCBFbnRpdHkwWTATBgcqhkjOPQIBBggqhkjOPQMBBwNCAATz+VjB1rJUlyBpG2GU
zgHDxmPxlU/OUC7h1G0t2eJ+1p6YJAoKjb5StyMr1xG56jXh1hMNO2gIjR4fKLWs
0iLDo4IB/DCCAfgwDAYDVR0TAQH/BAIwADAfBgNVHSMEGDAWgBSphcEaCuXYec3w
e0b6me9LYUdzhDBQBggrBgEFBQcBAQREMEIwQAYIKwYBBQUHMAGGNGh0dHA6Ly9v
Y3NwLXVhdC5jb3JwLmFwcGxlLmNvbS9vY3NwMDMtdGVzdGFhaWNhNmcxMDIwggEd
BgNVHSAEggEUMIIBEDCCAQwGCSqGSIb3Y2QFATCB/jCBwwYIKwYBBQUHAgIwgbYM
gbNSZWxpYW5jZSBvbiB0aGlzIGNlcnRpZmljYXRlIGJ5IGFueSBwYXJ0eSBhc3N1
bWVzIGFjY2VwdGFuY2Ugb2YgdGhlIHRoZW4gYXBwbGljYWJsZSBzdGFuZGFyZCB0
ZXJtcyBhbmQgY29uZGl0aW9ucyBvZiB1c2UsIGNlcnRpZmljYXRlIHBvbGljeSBh
bmQgY2VydGlmaWNhdGlvbiBwcmFjdGljZSBzdGF0ZW1lbnRzLjA2BggrBgEFBQcC
ARYqaHR0cHM6Ly93d3cuYXBwbGUuY29tL2NlcnRpZmljYXRlYXV0aG9yaXR5MBQG
A1UdJQQNMAsGCSqGSIb3Y2QEEjAdBgNVHQ4EFgQUtU8ZKOoMjTH7wC/dbwzyADjn
PmcwDgYDVR0PAQH/BAQDAgMIMA8GCSqGSIb3Y2QPAwQCBQAwCgYIKoZIzj0EAwID
SQAwRgIhANujqz+wx8Aoyp3/dZZ1sxEezPzJyA42SC15i46ImRMrAiEAqhOjoDKf
/IAN+Qz0hKmHcIi3SErOWTgR1Fffn5cZVfE=
-END CERTIFICATE-
-BEGIN CERTIFICATE-
MIIC7zCCAnWgAwIBAgIITkSG+diMnpkwCgYIKoZIzj0EAwMwbDEgMB4GA1UEAwwX
VGVzdCBBcHBsZSBSb290IENBIC0gRzMxJjAkBgNVBAsMHUFwcGxlIENlcnRpZmlj
YXRpb24gQXV0aG9yaXR5MRMwEQYDVQQKDApBcHBsZSBJbmMuMQswCQYDVQQGEwJV

Re: Policy 2.7.1: MRSP Issue #186: Requirement to Disclose Self-signed Certificates

[Jakob Bohm via dev-security-policy]

On 2020-11-12 05:15, Ben Wilson wrote:

Here is an attempt to address the comments received thus far. In Github,
here is a markup:

https://github.com/BenWilson-Mozilla/pkipolicy/commit/ee19ee89c6101c3a6943956b91574826e34c4932

This sentence would be deleted: "These requirements include all
cross-certificates which chain to a certificate that is included in
Mozilla’s CA Certificate Program."

And the following would be added:

"A certificate is deemed to directly or transitively chain to a CA
certificate included in Mozilla’s CA Certificate Program if:

(1)   the certificate’s Issuer Distinguished Name matches (according to the
name-matching algorithm specified in RFC 5280, section 7.1) the Subject
Distinguished Name in a CA certificate or intermediate certificate that is
in scope according to section 1.1 of this Policy, and

(2)   the certificate is signed with a Private Key whose corresponding
Public Key is encoded in the SubjectPublicKeyInfo of that CA certificate or
intermediate certificate.
Thus, these requirements also apply to so-called reissued/doppelganger CA
certificates (roots and intermediates) and to cross-certificates."

I think it is important not to lose sight of the main reason for this
proposed change-- there has been confusion about whether re-issued root CA
certificates need to be disclosed in the CCADB.

I look forward to your additional comments and suggestions.

Thank you,

Ben


On Mon, Nov 2, 2020 at 11:14 AM Corey Bonnell via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:


As an alternate proposal, I suggest replacing the third paragraph of
section 5.3, which currently reads:

"These requirements include all cross-certificates which chain to a
certificate that is included in Mozilla’s CA Certificate Program."

with:

"A certificate is considered to directly or transitively chain to a
certificate included in Mozilla’s CA Certificate Program if there is a CA
or Intermediate certificate in scope (as defined in section 1.1 of this
Policy) where both of the following is true:
1)  The certificate’s Issuer Distinguished Name matches (according to
the name-matching algorithm specified in RFC 5280, section 7.1) the Subject
Distinguished Name of the certificate in scope, and
2)  The certificate is signed with a Private Key whose corresponding
Public Key is encoded in the SubjectPublicKeyInfo of the certificate in
scope."

This proposal better defines the meaning of chaining to certificates
included in the Mozilla CA program and covers the various scenarios that
have caused issues historically concerning cross-certificates and
self-signed certificates.

Thanks,
Corey

On Wednesday, October 28, 2020 at 8:25:50 PM UTC-4, Ben Wilson wrote:

Issue #186 in Github 
deals with the disclosure of CA certificates that directly or

transitively

chain up to an already-trusted, Mozilla-included root. A common scenario
for the situation discussed in Issue #186 is when a CA creates a second

(or

third or fourth) root certificate with the same key pair as the root

that

is already in the Mozilla Root Store. This problem exists at the
intermediate-CA-certificate level, too, where a self-signed
intermediate/subordinate CA certificate is created and not reported.

Public disclosure of such certificates is already required by section

5.3

of the MRSP, which reads, "All certificates that are capable of being

used

to issue new certificates, and which directly or transitively chain to a
certificate included in Mozilla’s CA Certificate Program, MUST be

operated

in accordance with this policy and MUST either be technically

constrained

or be publicly disclosed and audited."

There have been several instances where a CA operator has not disclosed

a

CA certificate under the erroneous belief that because it is self-signed

it

cannot be trusted in a certificate chain beneath the already-trusted,
Mozilla-included CA. This erroneous assumption is further discussed in

Issue

#186 .

The third paragraph of MRSP section 5.3 currently reads, " These
requirements include all cross-certificates which chain to a certificate
that is included in Mozilla’s CA Certificate Program."

I recommend that we change that paragraph to read as follows:

"These requirements include all cross-certificates *and self-signed
certificates (e.g. "Issuer" DN is equivalent to "Subject" DN and public

key

is signed by the private key) that* chain to a CA certificate that is
included in Mozilla’s CA Certificate Program*, and CAs must disclose

such

CA certificates in the CCADB*.

I welcome your recommendations on how we can make this language even

more

clear.



How would that phrasing cover doppelgangers of intermediary SubCAs under 
an included root CA?




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 

Re: TLS certificates for ECIES keys

[Bailey Basile via dev-security-policy]

Hi, all,

Thank you for your feedback on this project. In order to address your comments, 
we have adjusted our design and implementation so that publicly-trusted 
certificates are no longer used and have modified our use of Certificate 
Transparency.

All certificates for encrypting data for Prio will be issued by Apple to the 
processors under our “semi-private” roots (i.e. https://crt.sh/?id=1160190 
, https://crt.sh/?id=12727249 
, https://crt.sh/?id=12728973 
). These certificates will have a Key Usage of Key 
Agreement and an Extended Key Usage containing an Apple OID 
(1.2.840.113635.100.4.18). The Common Name will contain an entity name 
(expected to be an ISO 3166 country or region code, but will be defined by 
Apple during configuration of the processor) for the benefit of users reviewing 
the keys and certificates used to encrypt their data.

Attached are certificate chains issued from our test roots under these profiles.


The production certificates will include SCTs from CT logs usable on Apple’s 
platforms. In order to address concerns about the future direction of the CT 
ecosystem, Apple clients will maintain two distinct log lists of qualified logs 
— those that are permitted for TLS only and those that allow other EKUs. These 
new certificates will be qualified against the latter list, while TLS 
certificates will continue to be qualified against the former. Today these 
lists are the same, but we expect them to diverge as the CT ecosystem 
progresses.

Thanks,

Bailey

> On Nov 4, 2020, at 2:12 PM, Jacob Hoffman-Andrews  
> wrote:
> 
> Thanks to all here for the useful feedback. We've decided not to issue
> publicly trusted TLS certificates carrying keys for use in ECIES.
> 
> On Thu, Oct 29, 2020 at 11:06 AM Jacob Hoffman-Andrews 
> wrote:
> 
>> Hi all,
>> 
>> ISRG is working with Apple and Google to deploy Prio, a
>> "privacy-preserving system for the collection of aggregate statistics:"
>> https://crypto.stanford.edu/prio/. Mozilla has previously demonstrated
>> Prio for use with telemetry data:
>> https://hacks.mozilla.org/2018/10/testing-privacy-preserving-telemetry-with-prio/
>> and
>> https://blog.mozilla.org/security/2019/06/06/next-steps-in-privacy-preserving-telemetry-with-prio.
>> Part of the plan involves using Web PKI certificates in an unusual way, so
>> I wanted to get feedback from the community and root programs.
>> 
>> In Prio, clients (mobile devices in this case) generate "shares" of data
>> to be sent to non-colluding processors. Those processors calculate
>> aggregate statistics without access to the underlying data, and their
>> output is combined to determine the overall statistic - for instance, the
>> number of users who clicked a particular button. The goal is that no party
>> learns the information for any individual user.
>> 
>> As part of this particular deployment, clients encrypt their shares to
>> each processor (offline), and then send the resulting encrypted "packets"
>> of share data via Apple and Google servers to the processors (of which ISRG
>> would be one). The encryption scheme here is ECIES (
>> https://en.wikipedia.org/wiki/Integrated_Encryption_Scheme).
>> 
>> The processors need some way to communicate their public keys to clients.
>> The current plan is this: A processor chooses a unique, public domain name
>> to identify its public key, and proves control of that name to a Web PKI
>> CA. The processor requests issuance of a TLS certificate with
>> SubjectPublicKeyInfo set to the P-256 public key clients will use to
>> encrypt data share packets to that processor. Note that this certificate
>> will never actually be used for TLS.
>> 
>> The processor sends the resulting TLS certificate to Apple. Apple signs a
>> second, non-TLS certificate from a semi-private Apple root. This root is
>> trusted by all Apple devices but is not in other root programs.
>> Certificates chaining to this root are accepted for submission by most CT
>> logs. This non-TLS certificate has a CN field containing text that is not a
>> domain name (i.e. it has spaces). It has no EKUs, and has a special-purpose
>> extension with an Apple OID, whose value is the hash of the public key from
>> the TLS certificate (i.e. the public key that will be used by clients to
>> encrypt data share packets). This certificate is submitted to CT and uses
>> the precertificate flow to embeds SCTs.
>> 
>> The Prio client software on the devices receives both the TLS and non-TLS
>> certificate from their OS vendor, and validates both, checking OCSP and CT
>> requirements, and checking that the public key hash in the non-TLS
>> certificate's special purpose extension matches the SubjectPublicKeyInfo in
>> the TLS certificate. If validation passes, the client software will use
>> that public key to encrypt data share packets.
>> 
>> The main issue I see is that the processor (a Subscriber) is using the TLS

Re: Policy 2.7.1:MRSP Issue #205: Require CAs to publish accepted methods for proving key compromise

[Dimitris Zacharopoulos via dev-security-policy]

On 5/11/2020 10:33 μ.μ., Ben Wilson via dev-security-policy wrote:

This email begins discussion of a potential change to section 6 of the
Mozilla Root Store Policy
.


The method by which a person may provide a CA with proof of private key
compromise has been an issue discussed on the mdsp list

this past year.

According to section 4.9.1.1 of the CA/Browser Forum's Baseline Requirements
, key compromise is
one reason for certificate revocation within a 24-hour period, and section
4.9.3 of the Baseline Requirements requires that CAs provide "clear
instructions for reporting suspected Private Key Compromise ..." and that
they "publicly disclose the instructions through a readily accessible
online means and in section 1.5.2 of their CPS."  However, in many of the
CPSes reviewed by Mozilla, the only information appearing is a contact
person's street address, email address, and sometimes a telephone number.
Seldom is this information provided in the context of revocation for key
compromise, and in many situations, email is an inadequate method of
communicating key compromises, especially at scale. Some CAs have portals
(e.g. DigiCert 
and Sectigo ) in
addition to an email address to submit revocation requests. There is also
an open-source ACME server which is designed for the sole purpose of
receiving revocations: https://github.com/tobermorytech/acmevoke.

Github Issue #205  notes
that the best place for disclosure of such revocation methods would be in
section 4.9.12 of a CA's CPS. Section 4.9.12 of the RFC 3647 outline
 is titled "Special
requirements re key compromise". Not only will this requirement make it
easier for the Mozilla community to report key compromises, but it will
also help streamline key-compromise-based revocations, thereby reducing the
number of Bugzilla incidents filed for delayed revocation.

Draft language in
https://github.com/BenWilson-Mozilla/pkipolicy/commit/719b834689949e869a0bd94f7bacb8dde0ccc9e4
proposes to add a last sentence to section 6 of the MRSP reading "Section
4.9.12 of a CA's CP/CPS MUST clearly specify the methods that parties may
use to demonstrate private key compromise."

We recognize that there is some overlap with the BR 4.9.3 requirement that
certain instructions be provided in section 1.5.2 of the CPS, but we
believe that the overlap can be worked through during this discussion and,
if not, a related discussion within the CA/Browser Forum.

We look forward to your comments and suggestions on this issue.

Sincerely yours,
Ben Wilson
Mozilla Root Store Program
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org


I believe this information should be the "minimum" accepted methods of 
proving that a Private Key is compromised. We should allow CAs to accept 
other methods without the need to first update their CP/CPS. Do people 
think that the currently proposed language would forbid a CA from 
accepting methods that are not explicitly documented in the CP/CPS?


I also think that "parties" is a bit ambiguous, so I would suggest 
modifying that to follow the language of the BRs section 4.9.2 
"Subscribers, Relying Parties, Application Software Suppliers, and other 
third parties". Here is my proposed change:


"Section 4.9.12 of a CA's CP/CPS MUST clearly specify the methods (at a 
minimum) that Subscribers, Relying Parties, Application Software 
Suppliers, and other third parties may use to demonstrate private key 
compromise."


Thank you,
Dimitris.


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

Re: MRSP Issue #147 - Require EV audits for certificates capable of issuing EV certificates

[Dimitris Zacharopoulos via dev-security-policy]

On 12/11/2020 10:41 π.μ., Dimitris Zacharopoulos via dev-security-policy 
wrote:
Finally, I would like to highlight that policy OID chaining is not 
currently supported in the webPKI by Browsers, so even if a CA adds a 
particular non-EV policyOID in an Intermediate CA Certificate, this 
SubCA would still be technically capable of issuing an end-entity 
certificate asserting an EV policy OID, and that certificate would 
probably get EV treatment from existing browsers. Is this correct? 


I see that this is related to 
https://github.com/mozilla/pkipolicy/issues/152, so I guess Mozilla 
Firefox does not enable "EV Treatment" if an Intermediate CA Certificate 
does not assert the anyPolicy or the CA's EV policy OID, including the 
CA/B Forum EV OID, regardless of what the end-entity certificate asserts.


Dimitris.


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

Re: MRSP Issue #147 - Require EV audits for certificates capable of issuing EV certificates

[Dimitris Zacharopoulos via dev-security-policy]

On 6/10/2020 11:38 μ.μ., Ben Wilson via dev-security-policy wrote:

  #147  - Require EV audits
for certificates capable of issuing EV certificates – Clarify that EV
audits are required for all intermediate certificates that are technically
capable of issuing EV certificates, even when not currently issuing EV
certificates.

This issue is presented for resolution in the next version of the Mozilla
Root Store Policy.

Suggested language is presented here:
https://github.com/BenWilson-Mozilla/pkipolicy/commit/a83eca6d7d8bf2a3b30529775cb55b0c8a5f982b


The proposal is to replace "if issuing EV certificates" with "if capable of
issuing EV certificates" in two places -- for WebTrust and ETSI audits.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy



Judging from the earlier discussion that took place in September 2020, I 
understand that some CAs have an EV-enabled hierarchy (meaning that the 
Root CA is in scope of the EV Guidelines and is included in an audit 
with "EV scope"), has issued some Intermediate CAs that issue EV 
Certificates and are included in the audit with "EV scope", and some 
Intermediate CAs that have never issued EV Certificates, nor are they 
intended to issue EV Certificates and were not listed in the "EV scope" 
of the audit.


I realize that this policy change, will require Intermediate CAs that 
have never issued nor intend to issue EV Certificates, to be included in 
an EV scope audit with the sole purpose of asserting that no TLS 
Certificates have been issued in scope of the EV Guidelines, which 
translates into making sure that no end-entity certificate has been 
issued asserting the EV policy OID in the certificatePolicies extension. 
Is that a fair statement?


Is there going to be an effective date after which Intermediate CA 
Certificates which were not intended to issue EV Certificates, will be 
required to have an EV audit?


Assuming my previous statement is fair, would it suffice for an auditor 
to examine the corpus of non-expired/non-revoked Certificates off of 
these "non-EV" Issuing CAs to ensure that no end-entity certificate has 
been issued asserting the EV policy OID according to the CA's CP/CPS?


Finally, I would like to highlight that policy OID chaining is not 
currently supported in the webPKI by Browsers, so even if a CA adds a 
particular non-EV policyOID in an Intermediate CA Certificate, this 
SubCA would still be technically capable of issuing an end-entity 
certificate asserting an EV policy OID, and that certificate would 
probably get EV treatment from existing browsers. Is this correct?



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