If a client can un-redact, what's the point of redaction? Kind regards, Steve
On Tue, Jun 21, 2016, 12:35 AM Andrew Ayer <[email protected]> wrote: > Hi Rob, > > On Mon, 20 Jun 2016 14:39:00 +0100 > Rob Stradling <[email protected]> wrote: > > > 1. When redacting a LABEL in the "redacted SAN" extension, the issuer > > replaces LABEL with "?"||HEX(HASH(SERIAL_NUMBER||LABEL)) instead of > > just "?". > > > > 2. If the client desires stronger SCT matching, it checks that each > > redacted label in the redacted SAN extension matches the > > corresponding label in the SAN extension, by computing HASH > > (SERIAL_NUMBER||LABEL), where SERIAL_NUMBER is the serial number of > > the certificate. > > I'm a little uneasy about using the serial number, because of > the ways that serial numbers can be, and are, incorrectly encoded (e.g. > not minimally encoded, or a "positive" integer with the MSB set). I > think it's simpler and more robust for the client to take the salt out > of an extension, so it can be treated as an opaque blob and therefore > be unaffected by the vagaries of parsers. > > > - Provides a (partial) technical solution to 'un'redaction (which is > > something that needs to be addressed before Chrome will ever support > > redaction [1]): If a domain owner's certificate team observes an > > unexpected precertificate, they can calculate HASH(SERIAL_NUMBER|| > > LABEL) for all of the LABELs they manage. > > Another way to support "un-redaction" is to just leave the salt > extension in the pre-certificate instead of removing it. I'd prefer > that approach if this style of un-redaction is desired. > > Regards, > Andrew > > _______________________________________________ > Trans mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/trans >
_______________________________________________ Trans mailing list [email protected] https://www.ietf.org/mailman/listinfo/trans
