On 21/06/16 05:35, Andrew Ayer 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.
Hi Andrew. I agree that incorrect encodings of the serial number are a
concern.
What if we say that SERIAL_NUMBER must consist of the INTEGER tag,
length and contents (rather than just the
potentially-encoded-differently contents)?
- 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.
--
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online
_______________________________________________
Trans mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/trans
