Re: TLS certificates for ECIES keys

[Nick Lamb via dev-security-policy]

On Thu, 29 Oct 2020 11:06:43 -0700
Jacob Hoffman-Andrews via dev-security-policy
 wrote:

> I also have a concern about ecosystem impact. The Web PKI and
> Certificate Transparency ecosystems have been gradually narrowing
> their scope - for instance by requiring single-purpose TLS issuance
> hierarchies and planning to restrict CT logs to accepting only
> certificates with the TLS EKU. New key distribution systems will find
> it tempting to reuse the Web PKI by assigning additional semantics to
> certificates with the TLS EKU, but this may make the Web PKI less
> agile.

This is my main concern too.

I think this is something I would be annoyed to discover some CA has
decided it's allowed to do, even if I wasn't able to come up with a
tortured rationale for why it's prohibited. "It wasn't prohibited" is
not the standard Mozilla asks root programme participants to aim for.
So since I'm being asked, no, I think this is a bad idea.

If we were talking about a subscriber it seems obvious that ISRG needn't
try to police what they get up to, but ISRG itself is different.

> I've discussed the plan with Apple, and they're fully aware this is an
> unusual and non-ideal use of the Web PKI, and hope to propose a
> timeline for a better system soon. One of the constraints operating
> here is that Apple has already shipped software implementing the
> system described above, and plans to use it in addressing our
> current, urgent public health crisis. As far as I know, no publicly
> trusted Web PKI certificates are currently in use for this purpose.

The problem with such timelines is they are too often wishful thinking.
Once the immediate need abates, further action is de-prioritised and
often never happens at all. I suspect we've all experienced this.

ISRG could perhaps avoid that de-prioritization by committing up
front to ceasing the "unusual and non-ideal use" by some specific point
in time agreed with Apple, I don't know whether Apple would be at all
interested in doing that, but it might be enough to ensure that
resources remain properly focused on actually deploying the "better
system" in a timely fashion.


This "urgent public health crisis" is presumably the COVID-19
pandemic. Action in November 2020 or later hardly seems an "urgent"
response to the pandemic and at this point it seems clear that mostly
what matters is political direction rather than IT innovation.

That is to say, I think New Zealand has elimination whereas the USA
has tens of thousands of new cases every day because New Zealand's
political leadership pursued an elimination strategy and the American
government did not, rather than because the NZ COVID Tracer app is
markedly better than similar American software.


Back to the application. I think the desire here is to have
anonymisation because intellectually it seems as though users would be
satisfied that collecting anonymised aggregate statistics is OK where
they'd be trepidatious about any other data collection. Without robust
studies showing this to be true I very much doubt it. Users are not
much impressed by facts, their gut feeling is that collecting data
violates their privacy and the facts won't change that feeling.


> So, mdsp folks and root programs: Can a CA or a Subscriber
> participate in the above system without violating the relevant
> requirements?

I'm not an expert, but I suspect the answer for a CA is that yes, they perhaps 
can
BUT however they should not.


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

[Matthew Hardeman via dev-security-policy]

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

[Matt Palmer via dev-security-policy]

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

[Matthew Hardeman via dev-security-policy]

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

To the extent that there is misuse in the described use-case, it would be
"misuse" on the part of the relying party software agent (which would be
trusting the certificate with a purpose and role in conflict with the
EKUs), but not misuse on the part of the certificate subscriber.
Publication of a leaf certificate (via various mechanisms) is not unusual
nor cause for alarm or revocation.  People public key PIN, though unwise
people also certificate PIN.  A key compromise would be different, but
that's not described here.

Would you revoke a properly issued certificate upon proof that some
new-fangled scheme employed by a third-party application acquires a copy of
a TLS Server leaf certificate, chases its validity (save for EKU
impropriety) correctly, and then utilizes the certificate's subject public
key in an unanticipated way?  Any competent software developer with basic
PKI understanding and some rules lawyering could get any certificate
revoked at any time in that picture.  I would submit that this can not be
the correct analysis, not pragmatically.

The mere fact that a single entity is both the Subscriber and the author of
the Relying Party agent is inconsequential, is it not?

Quite separately, I'm most confused by what kind of aggregate statistics
Prio is purported to be sending and its urgency as a public health matter.
I think I am likely to be unpleased by whatever this thing is, but I
suppose that's not at all germane to the WebPKI question.

On Thu, Oct 29, 2020 at 1:07 PM Jacob Hoffman-Andrews via
dev-security-policy  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
> certificate for a purpose not indicated by that certificate's EKUs. RFC
> 5280 says 

Re: TLS certificates for ECIES keys

[Jakob Bohm via dev-security-policy]

On 2020-10-29 19:06, 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
certificate for a purpose not indicated by that certificate's EKUs. RFC
5280 says (https://tools.ietf.org/html/rfc5280#section-4.2.1.12):



Maybe allocate your own OID (within ISRGs own OID space) for this 
purpose and put it in the EKU.  Something like


iso.org.dod.internet.private.enterprise(1.3.6.1.4.1).isrg(44947).isrg-divisionX(???).priu-processor(1)


4.2.1.12.  Extended Key Usage
If the extension is present, then the certificate MUST only be used
   for one of the purposes indicated.


The BRs say (
https://cabforum.org/wp-content/uploads/CA-Browser-Forum-BR-1.7.3.pdf):


4.9.1.1 Reasons for Revoking a Subscriber Certificate
The CA SHOULD revoke a certificate within 24 hours and MUST revoke a

Certificate within 5 days if one or more of the following occurs:

2. The CA obtains evidence that the Certificate was misused;


"Misused" is not defined here but I think a reasonable interpretation would
be that a Subscriber would trigger the revocation requirement by violating
the EKU MUST from RFC 5280.

I also have a concern about ecosystem impact. The Web PKI and Certificate
Transparency ecosystems have been gradually narrowing their scope - for
instance by requiring single-purpose TLS issuance hierarchies and planning
to restrict CT logs to accepting only certificates with the TLS EKU. New
key distribution systems will find it tempting to reuse the Web PKI by
assigning additional semantics to certificates with the TLS EKU, but this
may make the Web PKI less agile.

I've discussed the plan with Apple, and they're fully aware this is an
unusual and non-ideal use of the Web PKI, and hope to propose a timeline
for a better system soon. One of the constraints operating here is that
Apple has already shipped software implementing the system described above,
and plans to use it in addressing our current, urgent public health crisis.
As far as I know, no publicly trusted Web PKI certificates are currently in
use for this purpose.

So, mdsp folks and 

TLS certificates for ECIES keys

[Jacob Hoffman-Andrews via dev-security-policy]

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
certificate for a purpose not indicated by that certificate's EKUs. RFC
5280 says (https://tools.ietf.org/html/rfc5280#section-4.2.1.12):

> 4.2.1.12.  Extended Key Usage
>If the extension is present, then the certificate MUST only be used
>   for one of the purposes indicated.

The BRs say (
https://cabforum.org/wp-content/uploads/CA-Browser-Forum-BR-1.7.3.pdf):

> 4.9.1.1 Reasons for Revoking a Subscriber Certificate
> The CA SHOULD revoke a certificate within 24 hours and MUST revoke a
Certificate within 5 days if one or more of the following occurs:
> 2. The CA obtains evidence that the Certificate was misused;

"Misused" is not defined here but I think a reasonable interpretation would
be that a Subscriber would trigger the revocation requirement by violating
the EKU MUST from RFC 5280.

I also have a concern about ecosystem impact. The Web PKI and Certificate
Transparency ecosystems have been gradually narrowing their scope - for
instance by requiring single-purpose TLS issuance hierarchies and planning
to restrict CT logs to accepting only certificates with the TLS EKU. New
key distribution systems will find it tempting to reuse the Web PKI by
assigning additional semantics to certificates with the TLS EKU, but this
may make the Web PKI less agile.

I've discussed the plan with Apple, and they're fully aware this is an
unusual and non-ideal use of the Web PKI, and hope to propose a timeline
for a better system soon. One of the constraints operating here is that
Apple has already shipped software implementing the system described above,
and plans to use it in addressing our current, urgent public health crisis.
As far as I know, no publicly trusted Web PKI certificates are currently in
use for this purpose.

So, mdsp folks and root programs: Can a CA or a Subscriber participate in
the above system without violating the relevant requirements?

Thanks,
Jacob
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org

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

[Jakob Bohm via dev-security-policy]

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