Opened 7 years ago

Closed 7 years ago

#54 closed enhancement (invalid)

Simplify name redaction

Reported by: rob.stradling@… Owned by: rob.stradling@…
Priority: major Milestone:
Component: rfc6962-bis Version:
Severity: - Keywords:


The name redaction mechanism, as currently defined, does not reveal how many labels have been redacted. This seems unnecessary. If we're happy to reveal the number of redacted labels, then we could simplify the name redaction mechanism by...

  • scrapping the "redactedLabels" Certificate extension (
  • stating that the literal string "(PRIVATE)" always covers precisely _one_ label.

So for example, if you wanted to redact 3 components, you'd put "SAN:dNSName=(PRIVATE).(PRIVATE).(PRIVATE)" in the Precertificate.

To reduce bloat, I think we should also change "(PRIVATE)" to "?".
e.g. "SAN:dNSName=?.?.?"

This simplification would make ticket #17 easier to resolve. i.e. We could permit "CN=?.?.?".

When I proposed this on the TRANS list back in September, Eran commented:
"+1 to that - seems like it would significantly simplify the implementation of redacted domain name label: The risk of misalignment between the values in the extension that counts the number of redacted subdomains for each SAN and the actual SANs goes away."

Change History (4)

comment:1 Changed 7 years ago by rob.stradling@…

  • Owner changed from draft-ietf-trans-rfc6962-bis@… to rob.stradling@…

comment:2 Changed 7 years ago by rob.stradling@…

I've just spotted the glaring error in this proposal. Without the "redactedLabels" extension in the Certificate, it would be rather hard to reconstruct the TBSCertificate and verify the SCT signature(s) because you'd have to guess which labels need to be changed to "?"s.

Let's leave this ticket open for now, in the hope that we can find some other way to reduce the "risk of misalignment" that Eran mentioned. If we can't, then I suppose this ticket will need to be resolved as invalid.

comment:3 follow-up: Changed 7 years ago by rob.stradling@…

Alternative "redactedLabels" extension proposal:

Instead of the SEQUENCE OF INTEGERs extension in the current draft, I think we should define an extension that's more similar in syntax to the RFC5280 nameConstraints extension. Instead of "permittedSubtrees" and/or "excludedSubtrees", we'd be listing "redactedSubtrees". I think this approach would reduce the "risk of misalignment".

Here's a rough example of how it could work...


Subject:CN = ?

SAN:dNSName = ?
SAN:dNSName = ?
SAN:dNSName =
SAN:dNSName = ?
SAN:dNSName = ?
SAN:dNSName =


Subject:CN =

SAN:dNSName =
SAN:dNSName =
SAN:dNSName =
SAN:dNSName =
SAN:dNSName =
SAN:dNSName =

Extension:redactedSubtrees =

comment:4 in reply to: ↑ 3 Changed 7 years ago by rob.stradling@…

  • Resolution set to invalid
  • Status changed from new to closed

FWIW, the last line in that example should be "" rather than "".

I've discussed my comment:3 proposal with Ben and Eran. We've decided to not use it. We'll stick with the SEQUENCE OF INTEGERs extension in the current draft. So, since the idea of simplifying name redaction seems to have reached a dead end, I'm marking this ticket as INVALID.

I've just created ticket #60 to salvage the idea of revealing the number of redacted labels. In a recent discussion on the list, there was clear support for this, albeit for security reasons rather than for simplification reasons.

Note: See TracTickets for help on using tickets.