Re: TLS certificates for ECIES keys

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

Hi Bailey,

You mention that all certificates involved in this design are checked for 
expiration, revocation, and Certificate Transparency using all of the same 
logic that verifies TLS certificates on Apple platforms, but notably, the 
custom evaluation policy for the Apple-issued certificate can't require a 
id-kp-serverAuth EKU since none are present. 

Does the policy that evaluates the ISRG-issued processor certificate require 
any particular EKUs, (e.g. id-kp-serverAuth)? 

Would issuing the processor a non-TLS certificate require a change to Apple 
clients, and if so, would such a change be a blocker to shipping this feature?

-Devon

On Friday, October 30, 2020 at 12:35:15 PM UTC-7, Bailey Basile wrote:
> Ryan, 
> 
> Thank you for the questions. Answers in line. 
> 
> Bailey
> On Friday, October 30, 2020 at 8:43:46 AM UTC-7, Ryan Sleevi wrote: 
> > On Thu, Oct 29, 2020 at 2:07 PM Jacob Hoffman-Andrews via 
> > dev-security-policy  wrote: 
> > 
> > > 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. 
> > Jacob, 
> > 
> > I'm hoping you could help clarify this, as the "This certificate" remark in 
> > the last sentence leaves me a little confused. 
> > 
> > I understand the flow is: 
> > A) "Someone" requests ISRG generate a TLS-capable certificate from a 
> > TLS-capable root (whether that someone is ISRG or Apple is, I think, 
> > largely inconsequential for this question) 
> > B) That TLS-capable certificate is disclosed via CT and has SCTs embedded 
> > within it, as ISRG/LE already does 
> > C That TLS-capable certificate is then sent to Apple 
> > D) Apple generates a second certificate from an Apple-controlled root. 
> > E) This second certificate contains an extension with an Apple-specific OID 
> > that contains the hash of the ISRG certificate 
> > 
> > Concretely: 
> > 1) Is this Apple-controlled CA TLS capable? 
> > 2) Is this Apple-controlled CA subject to the Baseline Requirements? 
> > 
> > These first two questions are trying to understand why this root is present 
> > within CT logs, and whether CT logs are free to remove this Apple root. 
> > Apple has, in the past, had issues with inappropriate audits and controls, 
> > as a result of being improperly supervised [1]. I'm trying to understand 
> > whether it is from these BR-audited and BR-subjected certificates that 
> > Apple is proposing issuing, or from one of its other certificates not part 
> > of those audits. Most importantly, however, it's necessary to determine 
> > whether or not the Apple-controlled CA is trusted for TLS, as that impacts 
> > whether or not Apple's use of their CA like this is permitted.
> The Apple CA being used is the "Apple Application Integration CA 6 - G1" 
> issued from the Apple Root CA - G3 (https://crt.sh/?id=12728973). The CPS for 
> that CA is here 
> (https://images.apple.com/certificateauthority/pdf/Apple_AAI_Sub-CA_CPS_v6.7.pdf).
>  
> It is technically TLS-capable (ie. does not contain any EKU constraints that 
> would prevent it from issuing TLS certificates), but it is only trusted by 
> Apple platforms, so is not subject to the BRs or Mozilla requirements. We 
> designed the certificate profile for these leaf certificates to be TLS 
> incapable: 
> 1) It has no TLS Server Auth EKU 
> 2) It has no SANs 
> 3) The common names are of the form: "Apple CT Log Assurance for blinding 
> factors server: " or "Apple CT Log Assurance for 
> blinded value statistics server: ".
> > 
> > 3) Is "This certificate is submitted to CT" referring to A) (ISRG cert) or 
> > E) (Apple cert)? 
> > 
> > It seems like you're describing E), with the expectation CT logs will 
> > accept that certificate. However, Apple also recently shared [2] plans to 
> > allow CT logs to reject non-TLS certificates. 
> > 
> > If the answer to 1/2 is "Yes", then this scheme clearly violates the BRs 
> > and E) cannot be issued. 
> > If the answer to 1/2 is "No", then it would seem like CT logs would be free 
> > to reject E) from being logged, and to reject this Apple-operated CA in the 
> > first place (and would benefit the security of users and the WebPKI by 
> > doing so). 
> > 
> > Because it seems these are inherently contradictory, I'm hoping the answer 
> > to 3 is that "This certificate" is "A", 

Re: TLS certificates for ECIES keys

[Matthew Hardeman via dev-security-policy]

On Fri, Oct 30, 2020 at 10:49 AM Bailey Basile via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

>
> We specifically chose not to issue Apple certificates for these keys
> because we did not want users to have to trust only Apple's assertion that
> this key is for a third party.
>
>
I understand the goal of having an external CA certify the domain name of
the data processing participants' certificate (and associated key), but...
What UI experience makes any of this relevant to the user?  Is there going
to be a UI screen in the platform in which the user can view and/or choose
what parties (presumably by domain name) they will be submitting data
shares to?  Will that UI be displaying any of the certificates, key hashes,
or public keys involved?

I think domain validation for this kind of thing is pretty weak
regardless.  If Apple wanted to, they could just register
super-trusted-data-process-namealike.com, get ISRG to issue a WebPKI cert
for that and then incorporate that certificate in this scheme.  DNS based
validations don't demonstrate that the target is truly independent of Apple.
___
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]

Ryan,

Thank you for the questions. Answers in line.

Bailey

On Friday, October 30, 2020 at 8:43:46 AM UTC-7, Ryan Sleevi wrote:
> On Thu, Oct 29, 2020 at 2:07 PM Jacob Hoffman-Andrews via 
> dev-security-policy  wrote: 
> 
> > 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.
> Jacob, 
> 
> I'm hoping you could help clarify this, as the "This certificate" remark in 
> the last sentence leaves me a little confused. 
> 
> I understand the flow is: 
> A) "Someone" requests ISRG generate a TLS-capable certificate from a 
> TLS-capable root (whether that someone is ISRG or Apple is, I think, 
> largely inconsequential for this question) 
> B) That TLS-capable certificate is disclosed via CT and has SCTs embedded 
> within it, as ISRG/LE already does 
> C That TLS-capable certificate is then sent to Apple 
> D) Apple generates a second certificate from an Apple-controlled root. 
> E) This second certificate contains an extension with an Apple-specific OID 
> that contains the hash of the ISRG certificate 
> 
> Concretely: 
> 1) Is this Apple-controlled CA TLS capable? 
> 2) Is this Apple-controlled CA subject to the Baseline Requirements? 
> 
> These first two questions are trying to understand why this root is present 
> within CT logs, and whether CT logs are free to remove this Apple root. 
> Apple has, in the past, had issues with inappropriate audits and controls, 
> as a result of being improperly supervised [1]. I'm trying to understand 
> whether it is from these BR-audited and BR-subjected certificates that 
> Apple is proposing issuing, or from one of its other certificates not part 
> of those audits. Most importantly, however, it's necessary to determine 
> whether or not the Apple-controlled CA is trusted for TLS, as that impacts 
> whether or not Apple's use of their CA like this is permitted. 

The Apple CA being used is the "Apple Application Integration CA 6 - G1" issued 
from the Apple Root CA - G3 (https://crt.sh/?id=12728973). The CPS for that CA 
is here 
(https://images.apple.com/certificateauthority/pdf/Apple_AAI_Sub-CA_CPS_v6.7.pdf).
It is technically TLS-capable (ie. does not contain any EKU constraints that 
would prevent it from issuing TLS certificates), but it is only trusted by 
Apple platforms, so is not subject to the BRs or Mozilla requirements. We 
designed the certificate profile for these leaf certificates to be TLS 
incapable:
1) It has no TLS Server Auth EKU
2) It has no SANs
3) The common names are of the form: "Apple CT Log Assurance for blinding 
factors server: " or "Apple CT Log Assurance for 
blinded value statistics server: ".

> 
> 3) Is "This certificate is submitted to CT" referring to A) (ISRG cert) or 
> E) (Apple cert)? 
> 
> It seems like you're describing E), with the expectation CT logs will 
> accept that certificate. However, Apple also recently shared [2] plans to 
> allow CT logs to reject non-TLS certificates. 
> 
> If the answer to 1/2 is "Yes", then this scheme clearly violates the BRs 
> and E) cannot be issued. 
> If the answer to 1/2 is "No", then it would seem like CT logs would be free 
> to reject E) from being logged, and to reject this Apple-operated CA in the 
> first place (and would benefit the security of users and the WebPKI by 
> doing so). 
> 
> Because it seems these are inherently contradictory, I'm hoping the answer 
> to 3 is that "This certificate" is "A", which makes your later questions 
> more relevant and understandable. But, on the whole, I suspect I'm missing 
> something, because it seems that you might mean "E". And if E is meant, 
> then I think it has significant CT implications that need to also be worked 
> out, separate from the BR question here. 

It is both E and A. All certificates in this scheme are verified to be 
CT-qualified. Yes, we are aware that CT logs may choose to reject such 
certificates in the future and are working towards improved solutions.
> 
> [1] https://bugzilla.mozilla.org/show_bug.cgi?id=1575125 
> [2] 
> https://groups.google.com/a/chromium.org/g/ct-policy/c/JWVVhZTL5RM/m/HVZdSH4hAQAJ
___
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

[Ryan Sleevi via dev-security-policy]

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


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

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

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 chain
building)
___
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 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).


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?


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





From: Jakob Bohm via dev-security-policy 
Sent: 29 October 2020 14:57
To: mozilla-dev-security-pol...@lists.mozilla.org 

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


On 2020-10-29 01:25, 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.



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




Enjoy

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

Re: TLS certificates for ECIES keys

[Bailey Basile via dev-security-policy]

Hi, Matt,

We thought hard about the agility concerns for this particular application and 
the impact to the WebPKI and CT ecosystems. First, all certificates involved in 
this design are checked for expiration, revocation, and Certificate 
Transparency using all of the same logic that verifies TLS certificates on 
Apple platforms. Second, we are automating the entire process by which partners 
can submit their third-party-issued TLS certificates and the configuration is 
deployed to clients. Furthermore, the clients are able to get updated 
configuration within twenty-four hours. Additionally, as Jacob indicated, we 
consider this a relatively short-term solution in order to provide Public 
Health Authorities necessary statistics to respond to the current public health 
crisis and will be adopting a different solution in a future release. If you 
have specific question or concerns about how the agility of this architecture 
would negatively impact the WebPKI, I am happy to answer those.

We specifically chose not to issue Apple certificates for these keys because we 
did not want users to have to trust only Apple's assertion that this key is for 
a third party.

Bailey

On Thursday, October 29, 2020 at 4:30:19 PM UTC-7, Matt Palmer wrote:
> On Thu, Oct 29, 2020 at 01:56:53PM -0500, Matthew Hardeman via 
> dev-security-policy wrote: 
> > IFF the publicly trusted certificate for the special domain name is 
> > acquired in the normal fashion and is issued from the normal leaf 
> > certificate profile at LE, I don't see how the certificate could be claimed 
> > to be "misused" _by the subscriber_.
> The way I read Jacob's description of the process, the subscriber is 
> "misusing" the certificate because they're not going to present it to TLS 
> clients to validate the identity of a TLS server, but instead they (the 
> subscriber) presents the certificate to Apple (and other OS vendors?) when 
> they know (or should reasonably be expected to know) that the certificate is 
> not going to be used for TLS server identity verification -- specifically, 
> it's instead going to be presented to Prio clients for use in some sort of 
> odd processor identity parallel-verification dance. 
> 
> Certainly, whatever's going on with the certificate, it most definitely 
> *isn't* TLS, and so absent an EKU that accurately describes that other 
> behaviour, 
> I can't see how it doesn't count as "misuse", and since the subscriber has 
> presented the certificate for that purpose, it seems reasonable to describe 
> it as "misuse by the subscriber". 
> 
> Although misuse is problematic, the concerns around agility are probably 
> more concerning, IMO. There's already more than enough examples where 
> someone has done something "clever" with the WebPKI, only to have it come 
> back and bite everyone *else* in the arse down the track -- we don't need to 
> add another candidate at this stage of the game. On that basis alone, I 
> think it's worthwhile to try and squash this thing before it gets any more 
> traction. 
> 
> Given that Apple is issuing another certificate for each processor anyway, I 
> don't understand why they don't just embed the processor's SPKI directly in 
> that certificate, rather than a hash of the SPKI. P-256 public keys (in 
> compressed form) are only one octet longer than a SHA-256 hash. But 
> presumably there's a good reason for not doing that, and this isn't the 
> relevant forum for discussing such things anyway. 
> 
> - Matt
___
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

[Ryan Sleevi via dev-security-policy]

On Thu, Oct 29, 2020 at 2:07 PM Jacob Hoffman-Andrews via
dev-security-policy  wrote:

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


Jacob,

I'm hoping you could help clarify this, as the "This certificate" remark in
the last sentence leaves me a little confused.

I understand the flow is:
A) "Someone" requests ISRG generate a TLS-capable certificate from a
TLS-capable root (whether that someone is ISRG or Apple is, I think,
largely inconsequential for this question)
B) That TLS-capable certificate is disclosed via CT and has SCTs embedded
within it, as ISRG/LE already does
C That TLS-capable certificate is then sent to Apple
D) Apple generates a second certificate from an Apple-controlled root.
E) This second certificate contains an extension with an Apple-specific OID
that contains the hash of the ISRG certificate

Concretely:
1) Is this Apple-controlled CA TLS capable?
2) Is this Apple-controlled CA subject to the Baseline Requirements?

These first two questions are trying to understand why this root is present
within CT logs, and whether CT logs are free to remove this Apple root.
Apple has, in the past, had issues with inappropriate audits and controls,
as a result of being improperly supervised [1]. I'm trying to understand
whether it is from these BR-audited and BR-subjected certificates that
Apple is proposing issuing, or from one of its other certificates not part
of those audits. Most importantly, however, it's necessary to determine
whether or not the Apple-controlled CA is trusted for TLS, as that impacts
whether or not Apple's use of their CA like this is permitted.

3) Is "This certificate is submitted to CT" referring to A) (ISRG cert) or
E) (Apple cert)?

It seems like you're describing E), with the expectation CT logs will
accept that certificate. However, Apple also recently shared [2] plans to
allow CT logs to reject non-TLS certificates.

If the answer to 1/2 is "Yes", then this scheme clearly violates the BRs
and E) cannot be issued.
If the answer to 1/2 is "No", then it would seem like CT logs would be free
to reject E) from being logged, and to reject this Apple-operated CA in the
first place (and would benefit the security of users and the WebPKI by
doing so).

Because it seems these are inherently contradictory, I'm hoping the answer
to 3 is that "This certificate" is "A", which makes your later questions
more relevant and understandable. But, on the whole, I suspect I'm missing
something, because it seems that you might mean "E". And if E is meant,
then I think it has significant CT implications that need to also be worked
out, separate from the BR question here.

[1] https://bugzilla.mozilla.org/show_bug.cgi?id=1575125
[2]
https://groups.google.com/a/chromium.org/g/ct-policy/c/JWVVhZTL5RM/m/HVZdSH4hAQAJ
___
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

[Rob Stradling via dev-security-policy]

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

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?


From: dev-security-policy  on 
behalf of Jakob Bohm via dev-security-policy 

Sent: 29 October 2020 14:57
To: mozilla-dev-security-pol...@lists.mozilla.org 

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

CAUTION: This email originated from outside of the organization. Do not click 
links or open attachments unless you recognize the sender and know the content 
is safe.


On 2020-10-29 01:25, 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.
>

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


Enjoy

Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S.  
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.wisemo.com%2Fdata=04%7C01%7Crob%40sectigo.com%7C3bdb53393f1f4056b59e08d87c1aff51%7C0e9c48946caa465d96604b6968b49fb7%7C0%7C0%7C637395802683146795%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=sJ1Ar%2BE7qnVvPTdqdGEIKj25tRlyDLX%2F2sbqj4v9%2BlY%3Dreserved=0
Transformervej 29, 2860 Søborg, Denmark.  Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded

Re: TLS certificates for ECIES keys

[Jakob Bohm via dev-security-policy]

On 2020-10-30 01:50, Matthew Hardeman wrote:

On Thu, Oct 29, 2020 at 6:30 PM Matt Palmer via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

The way I read Jacob's description of the process, the subscriber is

"misusing" the certificate because they're not going to present it to TLS
clients to validate the identity of a TLS server, but instead they (the
subscriber) presents the certificate to Apple (and other OS vendors?) when
they know (or should reasonably be expected to know) that the certificate
is
not going to be used for TLS server identity verification -- specifically,
it's instead going to be presented to Prio clients for use in some sort of
odd processor identity parallel-verification dance.



To my knowledge, caching/storing a leaf certificate isn't misuse.  While
they appear to be presenting it in some manner other than via a TLS
session, I don't believe there's any prohibition against such a thing.
Would it cure the concern if they also actually ran a TLS server that does
effectively nothing at the host name presented in the SAN dnsName?




Certainly, whatever's going on with the certificate, it most definitely
*isn't* TLS, and so absent an EKU that accurately describes that other
behaviour,
I can't see how it doesn't count as "misuse", and since the subscriber has
presented the certificate for that purpose, it seems reasonable to describe
it as "misuse by the subscriber".



Not all distribution of a leaf certificate is "use", let alone "misuse".
There are applications which certificate PIN rather than key PIN.  Is that
misuse?




Although misuse is problematic, the concerns around agility are probably
more concerning, IMO.  There's already more than enough examples where
someone has done something "clever" with the WebPKI, only to have it come
back and bite everyone *else* in the arse down the track -- we don't need
to
add another candidate at this stage of the game.  On that basis alone, I
think it's worthwhile to try and squash this thing before it gets any more
traction.



My question is by what rule do you squash this thing that doesn't also
cover a future similar use by a third-party relying party that makes
"additional" use of some subscriber's certificate.




Given that Apple is issuing another certificate for each processor anyway,
I
don't understand why they don't just embed the processor's SPKI directly in
that certificate, rather than a hash of the SPKI.  P-256 public keys (in
compressed form) are only one octet longer than a SHA-256 hash.  But
presumably there's a good reason for not doing that, and this isn't the
relevant forum for discussing such things anyway.



Presumably this is so that the data processors can choose a key for the
encryption of their data shards and bind that to a DNS name demonstrated to
be under the data processor's control via a standard CA issuance process
without abstracting the whole thing away to certificates controlled by
Apple and/or Google.  To demonstrate that the fractional data shard
holder's domain was externally validated by a party that isn't Apple or
Google.

People scrape and analyze other parties' leaf certificates all the time.
What those third parties do with those certificates (if anything) is up to
those third parties.

If a third party can do things which causes a subscriber's certificate to
be revokable for misuse without having derived or acquired the private key,
I hesitate to call that ridiculous, but it is probably unsustainable.
Extending upon that, if the mere fact that the subscriber and the author of
the relying party validation agent are part of the same corporate hierarchy
changes the decision for the same set of circumstances, that's suspect.



Cryptographically, I think the concern is this:

In this scheme, the authenticated server B will use the corresponding
private key in a mathematically complex protocol that is neither TLS nor
CMS.  It is conceivable that said protocol may have a weakness that
allows a clever opponent M to exchange traffic with B in order to 
discover B's private key.


Thus using a WebPKI "Server Authentication" certificate to bind a public
key used by party A to identify party B in the "prio" protocol creates a
potential risk of creating a family of certificates with easily
compromised keys.

Thus it makes sense for the involved CAs (such as Let's Encrypt) to 
issue these certificates with a unique EKU other than the generic 
"Server Authentication" traditionally associated with TLS.



Enjoy

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