Subject: [Trans] Proposal to modularize pre certificate transformation

From: Tarah Wheeler <[email-masked]>
Date: Wed, 22 Mar 2017 19:31:43 +0000

Peter Bowen and I have been collaborating on a possible solution for certificate privacy. Thoughts?

++++++++++

Precertificate Transformation Extension

Many of the concerns around certificate privacy (the ability to privatize some certificate fields) are due to fears that multiple final certs could be generated for the same precertificate. This solution uses a random key in the final certificate which can be matched against the hashed redacted information in the precertificate to demonstrate that the precertificate was unique. The precert contains a hash of the original information; without the key in the full certificate, the hash is not transformable, and if the key works to transform the hash (as a one way function), the pre certificate can be proven to have been the correct one issued for the full cert. This solves the difficult problem of ensuring that a given precert is the one that was indeed issued for the full certificate.

In order to give domain registrants options for what domain name labels are disclosed in precertificates, we propose a new certificate extension: Precertifcate Transformation.  This extension is found in both the final certificate and in the precertificate.  The extension specifies a transformation algorithm, genneral parameters for the algorithm, and a count of disclosed component per subject alternative name.

There are two transformation algorithms initially defined.  The basic algorithm is as described in 6962 and 6962bis.  It has no parameters and the sanDisclosedComponents component is not used. This algorithm is the default.

The second is the partialhm256 algorithm.  This extends the basic algorithm by including transformation of the subjectAlternativeName extension.  The Parms is a 128-bit value that is used as K for a HMAC (cf RFC 2104) that uses H = SHA256.  For each entry in the subjectAlternativeName extension, an entry in the sanPartialComponents sequence must exist.  Matching is done by order.  Let the disclosed components count for the entry in question be N.  If N is -1, then the SAN entry is unmodified.  If it is greater than or equal to zero, then the following transformations occur:

(1) If the GeneralName type is not dNSName or iPAddress, the result is undefined and an error must be thrown

(2) If the GeneralName type is dNSName, then the entry is replaced with an otherName entry of type id-ct-partialGN-dNSName with a value created by copying the N labels closest to the root to the new name and prepending them with a value created by taking the remaining labels and calculating the HMAC-SHA256 value and hex encoding it and prepending '#'.  Note that a '*.' prefix on a name is not considered a label; it must be copied to the output as is.

For example, if the input is "*.beta.group.secret.demo.test" with key 0x4fa1cb4ce23db6e45caf727b0b1d85ed and the number of disclosed labels is 2, then the resulting name is "*.#4d240f70beb97f4c402984e94ac6e1c8351c89ff13e8a94dabfbc474ded4d3d4.demo.test"

(3) If the GeneralName type is iPAddress, then the entry is replaced with an otherName entry of type id-ct-partialGN-iPAddress.  The value is a IA5String in the format <partial> + "|" + <hashed>.   For the hashed part, the address first is converted to a text string.  The format is dotted decimal, with no leading zeroes, for IPv4 addresses and is as described in Section 4 of RFC 5952 for IPv6 addresses (section 5 is not used in this case).  The HMAC-SHA256 value is calculated of this string as in (2) and <hashed> is the hex encoding of the result.  Partial is formed by setting the bits other than N most significant bits to zero and the converting to string as described above.

For example, if the input is "198.51.100.47" with key 0x4fa1cb4ce23db6e45caf727b0b1d85ed and the number of disclosed labels is 27, then the resulting name is "198.51.100.32|8e38c51f339de29c05e543a099ba76468367043d5bc167c801ae0330a648925d".

In the precertificate the transformation parameter is set to a zero length bit string.

If the subject contains a commonName type attribute and the value of the commonName attribute value matches a dNSName in the SAN and the precertificate contains a partialGN otherName in place of that entry, then the commonName attribute is replaced with a id-ct-partialGN-replacedCN type attribute with the value being the otherName value.

This algorithm provides the recipient of a full certificate the ability to deterministically create the precertificate.  It also ensures that the precertificate can only reasonably match one full certificate.

id-ct-precertificateTransformation ID ::= {1 3 187 97 1}

id-ct-partialGN ID ::= {1 3 187 97 10}

id-ct-partialGN-dNSName ID ::= {id-ct-redactedGN 2} # type IA5String

id-ct-partialGN-iPAddress ID ::= {id-ct-redactedGN 7} # type IA5String

id-ct-partialGN-replacedCN ID ::= {id-ct-redactedGN 127} # type IA5String

id-ct-taAlgorithm ::= {1 3 187 97 20}

id-ct-taAlgorithm-basic ::= {id-ct-taAlgorithm 1}

id-ct-taAlgorithm-partialhm256 ::= {id-ct-taAlgorithm 2}

precertificateTransformation EXTENSION ::= {

  SYNTAX PrecertificateTransformation

  IDENTIFIED BY id-ct-precertificateTransformation

}

PrecertificateTransformation ::= SEQUENCE {

  transformationAlgorithm TransformationAlgorithm DEFAULT id-ct-taAlgorthim-basic,

  transformationParms TransformationParms BIT STRING OPTIONAL,

  sanPartialCount SEQUENCE SIZE (1..MAX) OF NamePartialCount OPTIONAL

}

TransformationAlgorithm ::= OBJECT IDENTIFIER

TransformationParms ::= ANY

NamePartialCount ::= INTEGER (-1..127) DEFAULT -1

--
Tarah M. Wheeler

Principal Security Advocate and Sr Director of Engineering - Website Security -
Delivering Confidence for Customers and Consumers by Securing Websites and Applications
Symantec Corporation
www.symantec.com<http://www.symantec.com/>
________________________________
(206) 276-4920
[email-masked]
________________________________
<http://www.symantec.com/>
________________________________

This message (including any attachments) is intended only for the use of the individual or entity to which it is addressed and may contain information that is non-public, proprietary, privileged, confidential, and exempt from disclosure under applicable law or may constitute as attorney work product. If you are not the intended recipient, you are hereby notified that any use, dissemination, distribution, or copying of this communication is strictly prohibited. If you have received this communication in error, notify us immediately by telephone and (i) destroy this message if a facsimile or (ii) delete this message immediately if this is an electronic communication.

---

From: Melinda Shore <[email-masked]>
Date: Wed, 22 Mar 2017 11:50:09 -0800

> certificate privacy. Thoughts?

We've allocated time on Tuesday to a discussion of redaction
and privacy-preserving logging mechanisms.  Will either you or
Peter be there to discuss this proposal?

Thanks,

Melinda

---

From: Peter Bowen <[email-masked]>
Date: Wed, 22 Mar 2017 13:44:59 -0700

> Peter be there to discuss this proposal?

I cannot make it to the meeting in person due to a family commitment
but can likely join remotely. We know this is after the deadline for
submittals, hence the rather quick note rather than proposed changes
to a draft.

---

From: Melinda Shore <[email-masked]>
Date: Wed, 22 Mar 2017 13:14:05 -0800

> submittals, hence the rather quick note rather than proposed changes

Remote participation is fine - I'd just like to make
sure that we've got a handle on which proposals are
out there during the discussion.

Melinda

---

From: Tarah Wheeler <[email-masked]>
Date: Wed, 22 Mar 2017 21:41:15 +0000

Thanks, Melinda--unfortunately I won't be there in person but if I'm not on a plane I will be remotely participating as well. 

Tarah Wheeler
Principal Security Advocate
Senior Director of Engineering, Website Security
Symantec
[email-masked]

> On Mar 22, 2017, at 5:14 PM, Melinda Shore <[email-masked]> wrote:
> 
> _______________________________________________
> Trans mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/trans

---

From: Andrew Ayer <[email-masked]>
Date: Mon, 27 Mar 2017 15:39:07 -0700

On Wed, 22 Mar 2017 19:31:43 +0000

> certificate privacy. Thoughts?

Hi Tarah and Peter,

Your proposal is very similar to the original redaction mechanism
that existed in draft-ietf-trans-rfc6962-bis-16, the main differences
being your proposal also supports IP address redaction and solves the
multiple-certs-per-precert problem.

Like the original redaction mechanism, your proposal imposes a high
complexity cost on TLS clients by forcing them to do a lot of decoding
and re-encoding of a certificate in order to reconstruct the
pre-certificate. This problem was discussed here:

        https://mailarchive.ietf.org/arch/msg/trans/WU_XveDh0GmyyiQbmqEr1SVuC84
        https://mailarchive.ietf.org/arch/msg/trans/eOHPqmAskBXMrGzSJAFzT9dzwOQ

It led to the solution in draft-ietf-trans-rfc6962-bis-17 (now in
draft-strad-trans-redaction-00), described here:

        https://mailarchive.ietf.org/arch/msg/trans/gGWZhqCXG0wlkktB_d0a2fPM4VU

I think that any new redaction proposal should address the problem of
client complexity at least as well as draft-strad-trans-redaction-00
does.

Regards,
Andrew

---

From: Peter Bowen <[email-masked]>
Date: Tue, 28 Mar 2017 06:32:11 -0700

> client complexity at least as well as draft-strad-trans-redaction-00

Andrew,

Thank you for the feedback.  I take full responsibility for the
failure to make the tech spec as friendly to clients as the
strad-trans-redaction draft.
When I was drafting this proposal, I ended up covering two related but
distinct issues, which I think muddies the water.

First, I think it would be good to have an explicit precertificate
transformation algorithm called out.  6962 and 6962bis both have
algorithms discussed in the text for how to go from a final
certificate to a precertificate.  The two algorithms are slightly
different.  From an implementer's perspective, I would prefer to have
a clear statement of that algorithm being used which then also allows
for clear introduction of new algorithms, instead of relying upon
hints such as the presence of a new extension.

Second is a proposal for an algorithm for precertificate
transformation that occludes discovery of full SANs from
precertificates.  This proposal needs a few tweaks to hit the points
covered in the discussions above and strad-trans-redaction draft; I'll
work on revising it to address these.

Thanks,
Peter

---

From: Eran Messeri <[email-masked]>
Date: Tue, 28 Mar 2017 09:36:12 -0500

On 28 Mar 2017 8:32 am, "Peter Bowen" <[email-masked]> wrote:

Andrew,

That's a concern Richard Barnes brought up as well. Assuming we'll get the
green light to make further changes to 6962-bis, I'm hoping to describe a
clearer, more accurate algorithm to re-construct the data structure which
the signature in the SCT covers (as well as reconstructing the Log Entry).

Saba's presentation on the meeting today should describe something for that
purpose.

Thanks,
Peter