On Mon, Mar 27, 2017 at 3:39 PM, Andrew Ayer <[email protected]> wrote:
> On Wed, 22 Mar 2017 19:31:43 +0000
> Tarah Wheeler <[email protected]> wrote:
>
>> Peter Bowen and I have been collaborating on a possible solution for
>> certificate privacy. Thoughts?
>>
> 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.

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

_______________________________________________
Trans mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/trans

Reply via email to