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

["Mark Brown" <mark at redphonesecurity.com>]

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