Re: TLS certificates for ECIES keys

[Devon O'Brien via dev-security-policy]

Hi Jacob,

I’m chiming in in my official capacity as a member of Chrome’s root program and 
its Certificate Transparency lead.

Over the past several years, the narrowing of scope for both the web PKI and CT 
has been highly intentional. Great efforts have been made to ensure that use 
cases outside of TLS do not further ossify a system that often already 
struggles to meet the agility requirements of its primary use case. For this 
reason, we are generally opposed to adding external dependencies, such as the 
ones this feature creates, to both CT and the web PKI. With that being said, 
the specific requirements applicable to this situation include areas that are 
underspecified as well as some that are expressed in unclear terms, especially 
where the requirements involve interplay between the Baseline Requirements 
(BRs), multiple RFCs, and root program requirements.

Our high-level concerns with this proposal include:
 * Adding external (non-TLS) dependencies to CT and the web PKI, which slows 
both the adoption of ecosystem improvements as well as the deprecation of 
problematic practices.
 * Requiring CAs to knowingly issue publicly-trusted TLS certificates for a 
definitively non-TLS use, calling into question what “misuse” means in the 
context of BR section 4.9.1.1.
 * Concerns with how the proposed certificate profile, including the semantics 
for the keyUsage and extendedKeyUsage, fit within the framework of BR section 
7.1.2.4, particularly when the CA knowingly issues such certificates.

While we believe that this proposal does not align with the intent of existing 
requirements, the proposed certificate usage is not unambiguously prohibited. 
Some of these requirements, such as the BRs, are already in the process of 
being updated to provide crisper guidance on what is and is not permitted. As 
maintainers of the Chrome root program and its CT policy, we will similarly 
work to provide greater clarity going forward by continuing to improve and 
update our policies. 

-Devon


On Thursday, October 29, 2020 at 11:07:22 AM UTC-7, js...@letsencrypt.org 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 

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

[Corey Bonnell via dev-security-policy]

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. 
> 
> Thanks, 
> 
> 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 #186: Requirement to Disclose Self-signed Certificates

[Jakob Bohm via dev-security-policy]

On 2020-10-30 18:45, Ryan Sleevi wrote:

On Fri, Oct 30, 2020 at 12:38 PM Jakob Bohm via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:


On 2020-10-30 16:29, Rob Stradling wrote:

Perhaps add: "And also include any other certificates sharing the same
private/public key pairs as certificates already included in the
requirements."  (this covers the situation you mentioned where a
self-signed certificate shares the key pair of a certificate that chains
to an included root).




Already rephrased to the following in my Friday post, as you actually 
quote below.


Perhaps add: "And also include any other certificates sharing the same
private/public key pairs as CA certificates already included in the
requirements."  (this covers the situation Rob mentioned where a
self-signed certificate shares the key pair of a certificate that chains
to an included root).


Jakob,

I agree that that would cover that situation, but your proposed language

goes way, way too far.


Any private CA could cross-certify a publicly-trusted root CA.  How

would the publicly-trusted CA Operator discover such a cross-certificate?
Why would such a cross-certificate be of interest to Mozilla anyway?  Would
it really be fair for non-disclosure of such a cross-certificate to be
considered a policy violation?



I agree with Rob that, while the intent is not inherently problematic, I
think the language proposed by Jakob is problematic, and might not be
desirable.



See above (and below) rephrasing to limit to reusing the private key 
from a CA certificate.





How would my wording include that converse situation (a CA not subject
to the Mozilla policy using their own private key to cross sign a CA
subject to the Mozilla policy)?

I do notice though that my wording accidentally included the case where
the private key of an end-entity cert is used in as the key of a private
CA, because I wrote "as certificates" instead of "as CA certificates".



Because "as certificates already included in the requirements" is ambiguous
when coupled with "any other certificates". Rob's example here, of a
privately-signed cross-certificate *is* an "any other certificate", and the
CA who was cross-signed is a CA "already included in the requirements"

I think this intent to restate existing policy falls in the normal trap of
"trying to say the same thing two different ways in policy results in two
different interpretations / two different policies"

Taking a step back, this is the general problem with "Are CA
(Organizations) subject to audits/requirements, are CA Certificates, or are
private keys", and that's seen an incredible amount of useful discussion
here on m.d.s.p. that we don't and shouldn't relitigate here. I believe
your intent is "The CA (Organization) participating in the Mozilla Root
Store shall disclose every Certificate that shares a CA Key Pair with a CA
Certificate subject to these requirements", and that lands squarely on this
complex topic.



This is precisely what I am trying to state in a concise manner, to
avoid overbloating policy with wordy sentences like the one you just
used.


A different way to achieve your goal, and to slightly tweak Ben's proposal
(since it appears many CAs do not understand how RFC 5280 is specified) is
to take a slight reword:

"""
These requirements include all cross-certificates that chain to a CA
certificate that is included in Mozilla’s CA Certificate Program, as well
as all certificates (e.g. including self-signed certificates and non-CA
certificates) issued by the CA that share the same CA Key Pair. CAs must
disclose such certificates in the CCADB.
"""



The words "issued by the CA" are problematic.  I realize that you are 
trying to limit the scope to certificates generated by the 
CA-organization, but as written it could be misconstrued as 
"certificates issued by the CA certificate that share the same CA Key Pair".


Proposed better wording of your text:

These requirements include all cross-certificates that chain to a CA
certificate that is included in Mozilla's CA Certificate Program, as
wall as all certificates  (e.g. including self-signed certificates and
non-CA certificates) created by the CA organization that share the same
CA Key Pair as any CA certificate or cross-certificate that chains to an
included CA certificate.

The intent of of my final words is to also cover reuse of keys belonging
to SubCA certificates.


However, this might be easier with a GitHub PR, as I think Wayne used to
do, to try to make sure the language is precise in context. It tries to
close the loophole Rob is pointing out about "who issued", while also
trying to address what you seem to be concerned about (re: key reuse). To
Ben's original challenge, it tries to avoid "chain to", since CAs
apparently are confused at how a self-signed certificate can chain to
another variation of that self-signed certificate (it's a valid path, it's
just a path that can be eliminated as a suboptimal path during