Subject: [Trans] Proposal: Allow redaction of exactly one DNS-ID

From: Eran Messeri <[email-masked]>
Date: Mon, 11 Apr 2016 21:17:44 +0100

I'm looking for feedback on limiting the name redaction mechanism specified
in section 4.2 of RFC6962-bis
<https://tools.ietf.org/html/draft-ietf-trans-rfc6962-bis-14#section-4.2>.

My proposal is to allow redaction exactly only of the first DNS-ID in the
subjectAltName extension.
Right now 6962-bis allows redaction of multiple DNS-IDs by requiring an
extension with repeating integer values, each indicating the number of
redacted labels in the corresponding DNS-ID entry.

I am proposing this to simplify implementing clients - not having loop over
one extension, match it with fields in another extension and dealing with
the edge cases where there's a mismatch is one less source of bugs.

However it may enforce certain limitations on CAs / domain owners that are
fundamental to this feature (each redacted domain name will need to be in a
separate certificate, for a start, or not being able to redact a CN-ID).
Hence feedback is appreciated.

Eran

---

From: Andrew Ayer <[email-masked]>
Date: Wed, 13 Apr 2016 10:04:17 -0700

On Mon, 11 Apr 2016 21:17:44 +0100
Eran Messeri <[email-masked]> wrote:

> I'm looking for feedback on limiting the name redaction mechanism
> specified in section 4.2 of RFC6962-bis
> My proposal is to allow redaction exactly only of the first DNS-ID in
> the subjectAltName extension.
> Right now 6962-bis allows redaction of multiple DNS-IDs by requiring
> an extension with repeating integer values, each indicating the
> number of redacted labels in the corresponding DNS-ID entry.
> 
> I am proposing this to simplify implementing clients - not having
> loop over one extension, match it with fields in another extension
> and dealing with the edge cases where there's a mismatch is one less
> source of bugs.
> 
> However it may enforce certain limitations on CAs / domain owners
> that are fundamental to this feature (each redacted domain name will
> need to be in a separate certificate, for a start, or not being able
> to redact a CN-ID). Hence feedback is appreciated.

 From an implementer's perspective, I like the idea of changing the
redaction extension to contain a single integer.  Why not have it apply
to all DNS-IDs in the certificate (including CN-ID) instead of just the
first? I think this would make client implementations slightly simpler
(since clients could apply the redaction uniformly to all DNS-IDs), and
satisfy more use cases (since all names could be redacted).  However,
this would not work if a domain owner wanted to redact both
secret.example.com and subservice.secret.example.com to ?.example.com
and ?.?.example.com.

Another possibility is for the extension to instead specify the number
of *un*redacted labels at the end of the DNS-ID, which I suspect would
satisfy almost all use cases.  If a domain owner wants to redact,
they probably want to redact all hostnames under a particular domain,
and counting the number of unredacted labels would make this possible.
The downside is that it's messy to think in terms of unredacted labels,
and a naive implementation might perform the calculation number_of_labels
- number_of_unredacted_labels, which could cause trouble if the cert is
malformed and number_of_unredacted_labels > number_of_labels.

Regards,
Andrew

---

From: Paul Wouters <[email-masked]>
Date: Wed, 13 Apr 2016 16:25:37 -0400 (EDT)

> they probably want to redact all hostnames under a particular domain,

(no hats on)

I don't think that is true. A big use case I think is to have
certificates within and outside the split DNS view for the corporate
versus public DNS. Eg *.nohats.ca and intranet.nohats.ca. Although
I agree that an organisation should probably get two certificates in
such a case.

Is the implementation of the current text really that much harder? I
think it would be better if the specification would not be limited,
unless it is a significant continious cost (eg extra load on servers).

The one-time programming cost seems less important[*]

Paul
[*] I am an implementor of RFCs too :)