Hi Wang,
The purpose of the draft is to extend TLS 1.3 to support IEEE 1609.2/ETSI TS
103 097 certificates for authentication in addition to X.509 certificate and
raw public keys.
Kind Regards
Mounira
- Mail original -
De: "Wang Haiguang"
À: "Mounira Msahli" , "Ilari Liusvaara"
Hi, Mounira
Thanks for the clarification. That means both explicit and implicit
certificates will be supported.
Regards.
Haiguang
-Original Message-
From: Mounira Msahli [mailto:mounira.msa...@telecom-paristech.fr]
Sent: Monday, August 27, 2018 4:32 PM
To: Wang Haiguang
Cc: Ilari Li
Hi Wang,
The 1609.2 certificate format consists of both explicit and implicit
certificates. The explicit certificates are in 1609.2 format, not in X.509
format.
Cheers,
William
On Mon, Aug 27, 2018 at 4:43 AM, Wang Haiguang <
wang.haiguang.shield...@huawei.com> wrote:
> Hi, Mounira
>
> Thanks
On Friday, 24 August 2018 19:44:36 CEST Mounira Msahli wrote:
> - You should also specify use in TLS 1.2 in the same draft (or say that
> is prohibited). This is so one only needs one reference for the
> codepoint allocation.
>
> >>> It is not prohibited, for TLS 1.2 the extension is already speci
Hi Hubert,
I can do the exercise but the result will be two sections totally decorrelated:
one for TLS 1.3 and one for TLS 1.2. Two drafts in one document.
- The handshake phase in TLS 1.2 is different from handshake/TLS1.3
- The certificate type is different. One uses cert_type and the other u
On Mon, Aug 27, 2018 at 06:21:15PM +0200, Mounira Msahli wrote:
> Hi Hubert,
>
> I can do the exercise but the result will be two sections totally
> decorrelated: one for TLS 1.3 and one for TLS 1.2. Two drafts in
> one document.
The certificate message might be bit annoying as it has different
On Mon, Aug 27, 2018, 8:21 AM Mounira Msahli <
mounira.msa...@telecom-paristech.fr> wrote:
> Hi Hubert,
>
> I can do the exercise but the result will be two sections totally
> decorrelated: one for TLS 1.3 and one for TLS 1.2. Two drafts in one
> document.
>
> - The handshake phase in TLS 1.2 is d
One could abbrevate the handshake traces to just show the relevant
parts (which could also cut some clutter)? I think the relevant
messages always occur in the same order (clienthello, serverhello/
encryptedextensions, certificate, certificate).
Yes, so we can neglect the ServerHelloDone for
Why does the first point matter? And the certificates are embedded pretty
opaquely in TLS.
I think, I answered your question in my last mail?
Kind Regards
Mounira
- Mail original -
De: "Watson Ladd"
À: "Mounira Msahli"
Cc: "Hubert Kario" , "tls"
Envoyé: Lundi 27 Août 2018 18:37:
On Monday, 27 August 2018 19:24:34 CEST Mounira Msahli wrote:
> One could abbrevate the handshake traces to just show the relevant
> parts (which could also cut some clutter)? I think the relevant
> messages always occur in the same order (clienthello, serverhello/
> encryptedextensions, certificat
The Transport Layer Security (tls) Working Group will hold
a virtual interim meeting on 2018-09-14 from 10:00 to 12:00 America/Los_Angeles.
Agenda:
Next steps for draft-ietf-tls-dnssec-chain-extension.
Information about remote participation:
Remote participation information will be obtained at th
The following errata report has been submitted for RFC8446,
"The Transport Layer Security (TLS) Protocol Version 1.3".
--
You may review the report below and at:
http://www.rfc-editor.org/errata/eid5483
--
Type: Technical
Rep
12 matches
Mail list logo
