Opened 8 years ago

Closed 8 years ago

#1 closed defect (fixed)

Need options for avoiding logging private subdomains

Reported by: eranm@… Owned by: draft-ietf-trans-rfc6962-bis@…
Priority: major Milestone:
Component: rfc6962-bis Version:
Severity: - Keywords:
Cc: rob.stradling@…, benl@…, pzbowen@…


Migrated from

The gist:
Original report by Rob Stradling:
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).
  1. Allow masking of private subdomains in PreCertificates?.

The PreCertificate? could contain SAN:dNSName=<PRIVATE> (I mean the literal string "<PRIVATE>"), and the real certificate could contain:

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

Comment by eranm following discussion with benl:

Compare two cases:
A cert with * SAN:
TLS client with CT support will see *, TLS client without CT support will see * and a CT log will see * TLS clients in practice reject these certificates (after comparison against a list of known top-level domains).
A cert with SAN and <PRIVATE> logged:
The CT Log sees <PRIVATE>, TLS clients without CT support will see, TLS clients with CT support will see <PRIVATE> 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.

Change History (6)

comment:1 in reply to: ↑ description Changed 8 years ago by rob.stradling@…

  • Cc rob.stradling@… added

comment:2 Changed 8 years ago by benl@…

  • Cc benl@… added

comment:3 Changed 8 years ago by rob.stradling@…

See also ticket #10, which proposes a way to make Option 2 also work with OCSP Stapling and the signed_certificate_timestamp TLS Extension.

comment:4 Changed 8 years ago by pzbowen@…

  • Cc pzbowen@… added

comment:5 Changed 8 years ago by rob.stradling@…

Rick Andrews suggests using parentheses instead of angle brackets (i.e. "(PRIVATE)" instead of "<PRIVATE>"), because angle brackets cannot appear in an ASN.1 PrintableString? value.

comment:6 Changed 8 years ago by rob.stradling@…

  • Resolution set to fixed
  • Status changed from new to closed
Note: See TracTickets for help on using tickets.