On Mon, 11 Apr 2016 21:17:44 +0100 Eran Messeri <[email protected]> wrote:
> 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. 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 _______________________________________________ Trans mailing list [email protected] https://www.ietf.org/mailman/listinfo/trans
