RFC6962-bis: Need options for avoiding logging private subdomains

[GoogleCodeExporter]

Enterprises regard some subdomains of their registered domain names as private 
and security sensitive.  Even though these subdomains are often only accessible 
within the enterprise's private network, it's common for them to be secured 
using publicly-trusted SSL certificates.  Enterprises will not want these 
private subdomains to appear in public CT logs.

One obvious solution is for the enterprise to use Wildcard SSL certificates, 
but this only works if there is precisely 1 private domain component.

I propose adding both of the following options to RFC6962-bis:

1. Allow Name-constrained Intermediate CA certificates that satisfy the 
following requirements to be logged in place of end-entity certificates:
  - The Name Constraints extension MUST include 1 or more permitted domain names, all of which MUST NOT be TLDs or public suffixes.
  - There must be new flag somewhere inside the Intermediate cert that explicitly permits it to be logged in place of the end-entity certificates it issues.  (Some parties will want to use Name-constrained Intermediate CAs _and_ require all end-entity certs to be logged).

2. Allow masking of private subdomains in PreCertificates.
The PreCertificate could contain SAN:dNSName=<PRIVATE>.customer.com (I mean the 
literal string "<PRIVATE>"), and the real certificate could contain:
  - SAN:dNSName=top.secret.customer.com
  - an extension that records the mapping between "top.secret" and "<PRIVATE>".  I suggest a SEQUENCE of INTEGERs, one for each Subject:commonName and SAN:dNSName (and in the same order that they appear in the cert), indicating how many leftmost domain components are masked.
CT-aware clients would be able to reconstruct and verify the PreCertificate's 
SCT, and they'd also need to check that the <PRIVATE> part is legitimately 
private.  e.g. don't accept <PRIVATE>.co.uk !

Original issue reported on code.google.com by robst...@gmail.com on 23 Oct 2013 at 10:37

[GoogleCodeExporter]

Original comment by er...@google.com on 17 Dec 2013 at 12:25

[GoogleCodeExporter]

On 1, I don't think the RFC should constrain the name constraint - that should 
be done by e.g. CA/BForum and monitored through CT.

On 2, seems complex - also, seems to me that you would need one of these 
<PRIVATE> certs per real cert (so timestamp, serial etc, match), right?

Original comment by benl@google.com on 28 Jan 2014 at 1:03

[GoogleCodeExporter]

Final(ish) verdict: the RFC should allow both mechanisms, but 

"  - The Name Constraints extension MUST include 1 or more permitted domain 
names, all of which MUST NOT be TLDs or public suffixes."

should not be in the RFC.

The RFC should also note that the <PRIVATE> mechanism gives as much power to an 
attacker as a name-constrained intermediate does. That is, once a single 
<PRIVATE> is issued, the CA can sign arbitrary certs within that domain.

Original comment by benl@google.com on 28 Jan 2014 at 1:28

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

(Instead of comment 4 which I deleted)
Compare two cases:
A cert with *.co.uk SAN:
TLS client with CT support will see *.co.uk, TLS client without CT support will 
see *.co.uk and a CT log will see *.co.uk. TLS clients in practice reject these 
certificates (after comparison against a list of known top-level domains).
A cert with top.secret.co.uk SAN and <PRIVATE>.co.uk logged:
The CT Log sees <PRIVATE>.co.uk, TLS clients without CT support will see 
top.secret.co.uk, TLS clients with CT support will see <PRIVATE>.co.uk and may 
use the opportunity to reject such a certificate (an opportunity to do 
additional checks over a TLS client without CT support).

So: CT-aware TLS clients MAY apply the same rules for wildcards to the SAN 
logged in the PreCertificate (which implies they may reject them).

Logs should not vet the SANs logged for such cases. 

Original comment by er...@google.com on 28 Jan 2014 at 2:00

[GoogleCodeExporter]

In comment 2, Ben wrote:
> On 2, seems complex - also, seems to me that you would need one of these 
<PRIVATE>
> certs per real cert (so timestamp, serial etc, match), right?

Yes.  (To be clear, each of the "<PRIVATE> certs" must be a Precertificate).

In comment 3, Ben wrote:
> The RFC should also note that the <PRIVATE> mechanism gives as much power to 
an
> attacker as a name-constrained intermediate does.

Sort of.  Both mechanisms permit unlimited certificate issuance within the 
domain namespace without the private subdomains being revealed.

But the difference is that, apart from the private subdomain(s), the <PRIVATE> 
mechanism logs everything and the name-constrained intermediate mechanism logs 
nothing.

The <PRIVATE> mechanism permits a Monitor to check that all of the end-entity 
certs have suitably large public keys, are signed using acceptable signature 
algorithms, don't have ridiculously long validity periods, have CRL and/or OCSP 
URLs, etc.
(But with the name-constrained intermediate mechanism, none of this is 
possible).

> That is, once a single <PRIVATE> is issued, the CA can sign arbitrary certs 
within
> that domain.

If the CA is happy to risk being caught issuing multiple "real certs" 
containing the same serial number and public key within that domain namespace, 
then yes, they could embed the same "single <PRIVATE>" Precertificate SCT in 
each one.  But what would they actually gain from doing this?

A correctly behaving CA should log a separate <PRIVATE> Precertificate for each 
"real cert".  This reveals the total number of <PRIVATE> certs that have been 
issued, but so what?

Original comment by robst...@gmail.com on 28 Jan 2014 at 3:01

[GoogleCodeExporter]

In comment 2, Ben wrote:
> On 1, I don't think the RFC should constrain the name constraint - that 
should be
> done by e.g. CA/BForum and monitored through CT.

Agreed.

Original comment by robst...@gmail.com on 28 Jan 2014 at 3:08

[GoogleCodeExporter]

Eran, I agree with comment 5.

Original comment by robst...@gmail.com on 28 Jan 2014 at 3:11

[GoogleCodeExporter]

Moved to http://trac.tools.ietf.org/wg/trans/trac/report/1 - please CC yourself 
to this issue.

Original comment by er...@google.com on 3 Mar 2014 at 7:50

• Changed state: Done