Re: TLS certificates for ECIES keys

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

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

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: Let's Encrypt: 302 total OCSP responses served beyond acceptable timelines

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

On Sat, Sep 26, 2020 at 9:09 PM Nick Lamb via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> Let's Encrypt provides a community mutual assistance site (with
> contributions from staff) on which a large volume of messages are
> posted each day.
>
> https://community.letsencrypt.org/
>
> Once the problem was identified did you check to see if any messages to
> that site were likely related to this issue? I guess it's not very
> likely with a small number of deviations.
>

We did not check the Let's Encrypt community site for reports about this
issue. There's more detail in the linked Bugzilla issue: the nature of the
bug was that it would only occur for certificates that never made it into
users' hands, so no one would have seen OCSP errors. Additionally, the OCSP
responses did not exceed their NotAfter date, so they would not have
produced errors even if they were fetched by user agents.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Plans for new ECDSA root and new intermediates from Let's Encrypt

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

Update on this: Thanks to the excellent zmap/zlint tool, we realized we
were missing the digitalSignature keyUsage on our planned new
intermediates. We've updated the demo repo and our forum post (
https://community.letsencrypt.org/t/detailed-2020-hierarchy/131019) to
indicate that we plan to include digitalSignature on these intermediates,
so we can sign OCSP directly from them.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Plans for new ECDSA root and new intermediates from Let's Encrypt

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

Let’s Encrypt is planning to issue a new root and new intermediates soon.
The new root will be an ECDSA one, to augment our existing RSA root. The
new intermediates will be part of our regular replacement of intermediates.
Our RSA root will cross-sign the ECDSA root.

We’re sharing our detailed issuance plans, including certificate profiles
and the tools we will use to generate the certificates. This is in the
spirit of transparency and also to get feedback from the community about
our plans.

Originally posted at
https://community.letsencrypt.org/t/detailed-2020-hierarchy/131019:

I’ve put together a detailed demonstration at
https://github.com/letsencrypt/2020-hierarchy-demo. I’ve attached sample
output from a run here, along with OpenSSL textual output. If you see any
flaws, please let us know!


Notable things:

   -

   We’re continuing to use X1 / X2 to identify roots.
   -

   We’re using O=Let’s Encrypt, CN=E1, E2, R3, and R4 to identify
   intermediates, where E/R indicates the key type, and we chose
   non-overlapping numbers across key types to make the names even easier to
   visually distinguish.
   -

   We’re using P-384 for our ECDSA hierarchy. We will continue to issue
   both P-256 and P-384 end-entity (leaf) certificates.
   -

   Per Ballot SC31 , we are
   not including OCSP URLs in our intermediates. This makes them smaller (for
   faster handshakes) and also simplifies our operations. The ballot has
   passed. We plan to perform the ceremony after the ballot’s review period
   has also passed and it takes effect.
   -

   We’re adopting a new domain for URLs in certificates: lencr.org. This
   saves some bytes.
   -

   For intermediates, we are just including CPS OIDs, not CPS URLs. Our
   end-entity certificates contain our CPS URL, so including it in the
   intermediates uses bytes unnecessarily.


The below is sample output from our demonstration:

root-x2.cert.pem.txt:

```text

Certificate:

Data:

Version: 3 (0x2)

Serial Number:

0d:e3:b6:d6:c3:12:af:10:9c:8b:74:de:8b:3a:97:a0

Signature Algorithm: ecdsa-with-SHA384

Issuer: C = US, O = Let's Encrypt, CN = (FAKE) Let's Encrypt Root X2

Validity

Not Before: Sep  4 00:00:00 2020 GMT

Not After : Sep 17 16:00:00 2040 GMT

Subject: C = US, O = Let's Encrypt, CN = (FAKE) Let's Encrypt Root
X2

Subject Public Key Info:

Public Key Algorithm: id-ecPublicKey

Public-Key: (384 bit)

pub:

04:aa:a9:a7:6e:c0:cd:01:16:af:60:ba:35:ea:d9:

02:8e:fb:ec:b8:c9:9f:a6:5c:50:f4:fc:25:99:af:

76:4c:22:50:8d:62:86:1d:51:58:b9:2d:39:dc:1a:

ca:76:1d:44:83:6c:93:94:01:b1:e3:9c:27:d6:e8:

61:ac:ab:bc:7f:4e:7f:d9:8a:43:d5:57:dd:72:87:

70:1c:25:c7:41:78:ad:ce:58:86:79:61:ff:ee:a3:

2b:9c:c3:5f:9d:b7:36

ASN1 OID: secp384r1

NIST CURVE: P-384

X509v3 extensions:

X509v3 Key Usage: critical

Certificate Sign, CRL Sign

X509v3 Basic Constraints: critical

CA:TRUE

X509v3 Subject Key Identifier:

5B:BC:E1:46:F2:7B:A4:61:96:FA:28:A8:23:10:F5:BD:C2:CA:8F:E0

Signature Algorithm: ecdsa-with-SHA384

 30:65:02:31:00:d2:6c:91:04:a7:d6:21:73:d0:52:f1:68:eb:

 4b:34:98:9a:43:57:9d:fe:d2:61:fc:c0:c1:ec:5f:58:f6:c9:

 b9:ea:84:3e:1f:3a:20:e4:85:dd:72:36:00:53:1e:30:88:02:

 30:02:25:a3:c4:ac:6e:97:70:6f:b3:cd:4f:59:95:55:b9:e7:

 52:f1:4d:a6:a0:a3:07:77:40:d4:dc:05:7b:26:9e:b9:be:05:

 b9:0f:c0:5f:9e:cc:3a:1c:de:e7:8b:2b:93

```

x2-signed-by-x1.txt

```text

Certificate:

Data:

Version: 3 (0x2)

Serial Number:

07:d7:a2:bb:0c:dc:93:25:d0:be:e2:26:39:de:7b:d0

Signature Algorithm: sha256WithRSAEncryption

Issuer: C = US, O = Internet Security Research Group, CN = (FAKE)
ISRG Root X1

Validity

Not Before: Sep  4 00:00:00 2020 GMT

Not After : Sep 15 16:00:00 2025 GMT

Subject: C = US, O = Let's Encrypt, CN = (FAKE) Let's Encrypt Root
X2

Subject Public Key Info:

Public Key Algorithm: id-ecPublicKey

Public-Key: (384 bit)

pub:

04:77:df:ec:6c:fe:22:06:aa:2e:8f:54:ce:1d:30:

60:01:85:ca:92:d6:d6:3d:21:0f:e5:18:1b:d5:35:

a4:72:ad:2d:07:56:cc:fe:0c:f5:39:2b:da:1a:83:

bf:a2:1a:9d:96:a2:74:2d:01:84:32:30:35:e0:a1:

e4:8a:fe:7f:16:58:83:13:e2:49:f2:01:84:60:98:

ef:07:4f:3c:f6:0c:86:21:22:33:aa:4e:6d:45:01:

da:8b:98:fb:c8:db:a5

ASN1 OID: secp384r1

NIST CURVE: 

Re: 2020.02.29 Let's Encrypt CAA Rechecking Bug

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

We've posted our Incident Report at 
https://bugzilla.mozilla.org/show_bug.cgi?id=1619047#c1.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: 2020.02.29 Let's Encrypt CAA Rechecking Bug

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

On Saturday, February 29, 2020 at 4:10:40 AM UTC-8, Nick Lamb wrote:
> Hi Jacob, was there a reason not to use the ordinary incident reporting
> format ? This is pretty good for ensuring you cover all the questions
> we're otherwise likely to ask anyway.

Thanks for the reminder. My goal here was to post a preliminary notification 
promptly, and follow up with more detail. I'm definitely open to hearing from 
the community, and from Mozilla, if people prefer to have the preliminary 
notification filed in the incident reporting format, even if many fields will 
have to be left blank.

> If it's not very difficult it would also be useful to have some idea
> how many certificates might be affected. That is, how many certificates
> were really issued to multiple FQDNs (if a single FQDN the bug described
> has no effect) more than 8 hours after initial correct CAA checks ?
> Intuitively this should be almost none, but intuitions can be
> misleading.

We're working on this analysis today.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

2020.02.29 Let's Encrypt CAA Rechecking Bug

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

Also posted to https://bugzilla.mozilla.org/show_bug.cgi?id=1619047

On 2020-02-29 UTC, Let’s Encrypt found a bug in our CAA code. Our CA software, 
Boulder,  checks for CAA records at the same time it validates a subscriber’s 
control of a domain name. Most subscribers issue a certificate immediately 
after domain control validation, but we consider a validation good for 30 days. 
That means in some cases we need to check CAA records a second time, just 
before issuance. Specifically, we have to check CAA within 8 hours prior to 
issuance (per BRs §3.2.2.8), so any domain name that was validated more than 8 
hours ago requires rechecking.

The bug: when a certificate request contained N domain names that needed CAA 
rechecking, Boulder would pick one domain name and check it N times. What this 
means in practice is that if a subscriber validated a domain name at time X, 
and the CAA records for that domain at time X allowed Let’s Encrypt issuance, 
that subscriber would be able to issue a certificate containing that domain 
name until X+30 days, even if someone later installed CAA records on that 
domain name that prohibit issuance by Let’s Encrypt.

We confirmed the bug at 2020-02-29 03:08 UTC, and halted issuance at 03:10. We 
deployed a fix at 05:22 UTC and then re-enabled issuance.

Our preliminary investigation suggests the bug was introduced on 2019-07-25. We 
will conduct a more detailed investigation and provide a postmortem when it is 
complete.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

2019.08.28 Let’s Encrypt OCSP Responder Returned “Unauthorized” for Some Precertificates

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

Also filed at https://bugzilla.mozilla.org/show_bug.cgi?id=1577652

On 2019.08.28 we read Apple’s bug report at 
https://bugzilla.mozilla.org/show_bug.cgi?id=1577014 about DigiCert’s OCSP 
responder returning incorrect results for a precertificate. This prompted us to 
run our own investigation. We found in an initial review that for 35 of our 
precertificates, we were serving incorrect OCSP results (“unauthorized” instead 
of “good”). Like DigiCert, this happened when a precertificate was issued, but 
the corresponding certificate was not issued due to an error.

We’re taking these additional steps to ensure a robust fix:
  - For each precertificate issued according to our audit logs, verify that we 
are serving a corresponding OCSP response (if the precertificate is currently 
valid).
  - Configure alerting for the conditions that create this problem, so we can 
fix any instances that arise in the short term.
  - Deploy a code change to Boulder to ensure that we serve OCSP even if an 
error occurs after precertificate issuance.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy