[TLS] RE: Comments on draft-santesson-tls-ume-04/draft-santesson-tls-supp-00

"Stefan Santesson" <stefans@microsoft.com> Tue, 18 April 2006 23:32 UTC

Received: from [] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FVzgn-0000iF-8c; Tue, 18 Apr 2006 19:32:57 -0400
Received: from [] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FVzgl-0000hr-Qw; Tue, 18 Apr 2006 19:32:55 -0400
Received: from mail-eur1.microsoft.com ([]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FVzgk-0006Bp-Gv; Tue, 18 Apr 2006 19:32:55 -0400
Received: from EUR-MSG-11.europe.corp.microsoft.com ([]) by mail-eur1.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 19 Apr 2006 00:32:53 +0100
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Wed, 19 Apr 2006 00:32:51 +0100
Message-ID: <BF9309599A71984CAC5BAC5ECA62994404AA2967@EUR-MSG-11.europe.corp.microsoft.com>
In-Reply-To: <>
Thread-Topic: Comments on draft-santesson-tls-ume-04/draft-santesson-tls-supp-00
Thread-Index: AcZjP0oOrzf6gkLXReaRGULPAmLD6wAAIvhQ
From: Stefan Santesson <stefans@microsoft.com>
To: Russ Housley <housley@vigilsec.com>, Eric Rescorla <ekr@networkresonance.com>
X-OriginalArrivalTime: 18 Apr 2006 23:32:53.0755 (UTC) FILETIME=[6A34F4B0:01C66340]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c
Cc: iesg@ietf.org, tls@ietf.org
Subject: [TLS] RE: Comments on draft-santesson-tls-ume-04/draft-santesson-tls-supp-00
X-BeenThere: tls@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.lists.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@lists.ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/tls>
List-Post: <mailto:tls@lists.ietf.org>
List-Help: <mailto:tls-request@lists.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@lists.ietf.org?subject=subscribe>
Errors-To: tls-bounces@lists.ietf.org

This is a text outline for what I propose to add at the end of the
message flow section.

"The server MUST expect and gracefully handle the case where the client
chooses to not send any supplementalData handshake message even after
successful negotiation of extensions. The client MAY at its own
discretion decide that the user mapping hint it initially intended to
send no longer is relevant for this session. One such reason could be
that the server certificate fails to meet certain requirements."

It may need some improvements but I don't see any need for an error
The server will simply proceed as if no hint negotiation was initiated.

Stefan Santesson
Program Manager, Standards Liaison
Windows Security

> -----Original Message-----
> From: Russ Housley [mailto:housley@vigilsec.com]
> Sent: den 18 april 2006 12:50
> To: Eric Rescorla
> Cc: iesg@ietf.org; tls@ietf.org; Stefan Santesson
> Subject: Re: Comments on
> supp-00
> Eric:
> > > >S 4:
> > > >You can do the UPN hint extension exchange and then NOT
> > > >send supp_data? That seems wrong.
> > >
> > > I agree, if the negotiation is successful, then the supplemental
> > > should be sent.
> >
> >This should be a MUST, IMO. I.e., the peer can and probably
> >should detect it and throw an error. If it's a SHOULD,
> >then the document needs to explain how.
> I have no problem with the requirement that there be a fatal
> alert.  Do we need to specify a new AlertDescription value for this
> situation?
> Russ

TLS mailing list