On Fri, Apr 8, 2016 at 2:40 PM, Rob Stradling <[email protected]> wrote: > On 08/04/16 15:15, Peter Bowen wrote: >> >> On Fri, Apr 8, 2016 at 6:25 AM, Stephen Kent <[email protected]> wrote: >>> >>> It's good that this potential problem has been identified, but it >>> ought to be addressed in 6962-bis, not via an action in the CABF context. >>> I say this for a few reasons: >>> >>> - CABF cert policies do not apply to all cert that one might >>> encounter >>> in a browser >>> - 6962-bis wants to become an IETF standard and thus relying on an >>> external >>> spec to address a potential security concern is not appropriate. >>> >>> If Rob can adjust text in 6962-bis to address this problem, that's the >>> preferred approach. >> >> >> Stephen, >> >> This is obviously the correct answer. >> >> The real challenge will be determining how to map redaction info to >> the DN, given that DN is a SEQUENCE OF(SET OF(Attribute)) and that SET >> is unordered. > > > We originally said that CNs could not be redacted at all because we were > trying to avoid this complexity. > >> I'm thinking the right answer is to borrow ASN.1 >> Distinguished Encoding Rules to set the order of SET when a SET has >> more than one commonName attribute, as I think the most common state. > > > Does anyone actually need the ability to redact different numbers of labels > in multiple CNs? > > I'm guessing not, in which case let's not make this more complex than it > needs to be.
So I think the easiest method would be to append one more element to the sequence for CN redaction level. I think it should go at the end, rather than the beginning, as it should be more likely to not have a common name than not having a SAN. _______________________________________________ Trans mailing list [email protected] https://www.ietf.org/mailman/listinfo/trans
