Re: [TLS] Last Call: draft-ietf-tls-rfc4346-bis (The TransportLayer Security (TLS) Protocol Version 1.2) to Proposed Standard

[<Pasi.Eronen at nokia.com>]

The text you're quoting is unchanged from TLS 1.1, and RFC 4680 is
clearly a version-independent feature. So yes, you can use it with TLS
1.2 as well.

(The text about ordering handshake messages in TLS 1.0/1.1/1.2 is
intended to apply only to handshake messages defined in those
documents; the intent is not to prevent other documents from defining
new handshake messages that get added somewhere in the middle.)

Best regards,
Pasi 

> -----Original Message-----
> From: ext Mark Brown [mailto:mark at redphonesecurity.com] 
> Sent: 29 February, 2008 18:38
> To: Eronen Pasi (Nokia-NRC/Helsinki); tls at ietf.org
> Subject: RE: [TLS] Last Call: draft-ietf-tls-rfc4346-bis (The 
> TransportLayer Security (TLS) Protocol Version 1.2) to 
> Proposed Standard
> 
> Ok, thanks.  
> 
> So, my understanding is that TLS Supplemental Data [RFC4680] is 
> Ok & Standard to use even though it violates the prohibitions 
> below.  Is that right?  (Neither 4366-bis nor 5077 violate 
> prohibitions...)
> 
> --mark
> 
> > -----Original Message-----
> > From: Pasi.Eronen at nokia.com [mailto:Pasi.Eronen at nokia.com]
> > Sent: Friday, February 29, 2008 5:29 AM
> > To: mark at redphonesecurity.com; tls at ietf.org
> > Subject: RE: [TLS] Last Call: draft-ietf-tls-rfc4346-bis (The
> > TransportLayer Security (TLS) Protocol Version 1.2) to 
> Proposed Standard
> > 
> > 
> > I wouldn't say it was overlooked; it's simply not in scope of
> > this document. There are other documents that define new TLS
> > handshake messages (at least RFC 4366(bis) and RFC 5077
> > in addition to RFC 4680), and those messages are not mentioned
> > here either (and don't have to be).
> > 
> > Best regards,
> > Pasi
> > 
> > > -----Original Message-----
> > > From: Mark Brown
> > > Sent: 28 February, 2008 22:57
> > > To: tls at ietf.org
> > > Subject: Re: [TLS] Last Call: draft-ietf-tls-rfc4346-bis (The
> > > TransportLayer Security (TLS) Protocol Version 1.2) to
> > > Proposed Standard
> > >
> > > TLS Supplemental Data [RFC4680] was overlooked, e.g. in 
> section 7.4.2.
> > > Server Certificate,
> > >
> > >       The server MUST send a certificate whenever the 
> agreed-upon key
> > >       exchange method uses certificates for authentication (this
> > >       includes all key exchange methods defined in this
> > > document except
> > >       DH_anon).  This message will always immediately follow
> > > the server
> > >                                    ^--No
> > >       hello message.
> > >
> > > Also in section 7.4.7. Client Key Exchange Message,
> > >
> > >       This message is always sent by the client. It MUST 
> immediately
> > >                                                     ^--No
> > >       follow the client certificate message, if it is sent.
> > > Otherwise it
> > >       MUST be the first message sent by the client after it
> > > receives the
> > >       ^--No
> > >       server hello done message.
> > >
> > > Instead, per [RFC4680], ServerCertificate may follow a server's
> > > SupplementalData message.  Also, Client Key Exchange follows
> > > the client
> > > Certificate message and/or the client SupplementalData
> > > message, if these
> > > messages are sent.
> > >
> > > [RFC4680] should also be added to the references section.  It
> > > may be helpful
> > > to add SupplementalData to Figure 1 on page 34 of 
> rfc4346-bis as well,
> > > marked with an asterisk *, following Figure 1 in [RFC4680].
> > >
> > > --mark
> > >
> > > _______________________________________________
> > > TLS mailing list
> > > TLS at ietf.org
> > > https://www.ietf.org/mailman/listinfo/tls
> > >
> 
> 
_______________________________________________
TLS mailing list
TLS at ietf.org
https://www.ietf.org/mailman/listinfo/tls