Subject: [pkix] comments on draft-pritikin-est-02.txt

From: Sean Turner <[email-masked]>
Date: Fri, 30 Sep 2011 14:11:52 -0400

Max,

Here's some comments on the est-02 draft.  I just embedded them in the 
in the .txt file.  Hopefully, this won't cause issues for anybody.

spt

---

From: Anders Rundgren <[email-masked]>
Date: Fri, 30 Sep 2011 23:33:10 +0200

On 2011-09-30 20:11, Sean Turner wrote:
>   This specification provides proof-of-possession by including
>   information specific to the current TLS session within the signed
>   certification request.  This proves to the server that the TLS client
>   has possession of the private key associated with the certification
>   request and that the client was able to sign the certification
>   request after the TLS session was established.  The value included
>   within the certification request is very similar to "tls-unique" as
>   defined in Channel Bindings for TLS [RFC5929].  The value is defined
>   as:

>[spt] !!ACK!! This is a *NEW* TLS extension?  This can't happen
>in this document it'll have to be in a different doc that gets run
> through the TLS WG.  Also is relying on this going to ensure that
> it'll be a while before this gets adopted?
>
>      tls-unique-securerenegotiation: The first TLS Finished message
>      sent in the _first_ TLS handshake of the TLS connection that is
>      being bound to is the TLS "channel binding" value.  Any TLS
>      renegotiation MUST use "secure_renegotiation" [RFC5746] (thus
>      maintaining the binding).  Mandating secure renegotiation allows
>      implementations to avoid the synchronization issues encountered
>      with tls-unique.

IMO, the whole foundation of using TLS is problematic because it would
in an E2ES (End-to-End Secured) enrollment to for example a smart card
require that the card speaks TLS.  In addition, the use of TLS also makes
user-interaction like assigning PIN-code infeasible in an E2ES setup.

I believe the card industry's use of shared keys (static or dynamically
created) represent a better way achieving TLS-like qualities and much
more.  I'm pretty sure that most new enrollment schemes like for example

            http://mail.google.com/wallet

builds on symmetric-key schemes for enrollment.  I this particular case
I'm just guessing since most of the wallet is secret including the NXP chip.

Anders