Subject: Re: [TLS] I-D Action: draft-ietf-tls-exported-authenticator-00.txt ([email-masked])

From: Sankalp Bagaria <[email-masked]>
Date: Mon, 22 May 2017 11:22:07 +0530

Hi,

I have a couple of questions:
1) How will the out-of-band request for certificate be sent by the server/
client ?
What format will be used ? (Only Reply's format is given in draft)
2a) If certificate verification is unsuccessful, will the existing
connection also be
dropped or will it be continued ?
2b) If certificate verification is successful, how will the state of the
connection
change ? Will there be a re-direction to new entity ? If yes, how will that
be
achieved ?

Regards,
Sankalp Bagaria.

>
> ------------------------------
>
> Message: 3
> Date: Thu, 18 May 2017 14:04:38 -0700
> From: [email-masked]
> To: <[email-masked]>
> Cc: [email-masked]
> Subject: [TLS] I-D Action:
>         draft-ietf-tls-exported-authenticator-00.txt
> Message-ID: <[email-masked]>
> Content-Type: text/plain; charset="utf-8"
>
>
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
> This draft is a work item of the Transport Layer Security of the IETF.
>
>         Title           : Exported Authenticators in TLS
>         Author          : Nick Sullivan
>         Filename        : draft-ietf-tls-exported-authenticator-00.txt
>         Pages           : 6
>         Date            : 2017-05-18
>
> Abstract:
>    This document describes a mechanism in Transport Layer Security (TLS)
>    to provide an exportable proof of ownership of a certificate that can
>    be transmitted out of band and verified by the other party.
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-tls-exported-authenticator/
>
> There are also htmlized versions available at:
> https://tools.ietf.org/html/draft-ietf-tls-exported-authenticator-00
> https://datatracker.ietf.org/doc/html/draft-ietf-tls-
> exported-authenticator-00
>
>
> Please note that it may take a couple of minutes from the time of
> submission
> until the htmlized version and diff are available at tools.ietf.org.
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>
>
>
>

---

From: Martin Thomson <[email-masked]>
Date: Mon, 22 May 2017 16:00:01 +1000

This defines a tool, in the same way that RFC 5705 does.  See
https://tools.ietf.org/html/draft-bishop-httpbis-http2-additional-certs
for a use of that tool.

On 22 May 2017 at 15:52, Sankalp Bagaria <[email-masked]> wrote:
>> https://datatracker.ietf.org/doc/html/draft-ietf-tls-exported-authenticator-00
>>
>>
> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls
>

---

From: Balaji Rajendran <[email-masked]>
Date: Mon, 22 May 2017 23:17:02 +0530

Hi,

   While trying to obtain an authenticator, the private key used for
signing the certificate is demanded.

   Is it safe to do such operations or is it the public key associated with
the Certificate?

--
Balaji R

---

From: Ilari Liusvaara <[email-masked]>
Date: Mon, 22 May 2017 22:17:34 +0300

>    Is it safe to do such operations or is it the public key associated with

The private key needed is the private key corresponding with the public
key in end-entity SubjectPublicKeyInfo in the exported authenticator.

This is analogous with the main TLS handshake. However, the key used
might be different with what was used for the main handshake.

Specifically, if the certificate in main handshake and exported
authenticator have the same SubjectPublicKeyInfo, then the private
keys used will be the same. If the SubjectPublicKeyInfo's are
different, then the private keys will be different.

-Ilari