[TLS] RE: Last call comments for draft-santesson-tls-(ume-04, supp-00)

<Pasi.Eronen@nokia.com> Tue, 04 April 2006 09:18 UTC

Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQhfn-0003MU-5u; Tue, 04 Apr 2006 05:18:03 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQhfl-0003MP-Og for tls@ietf.org; Tue, 04 Apr 2006 05:18:01 -0400
Received: from mgw-ext12.nokia.com ([131.228.20.171]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FQhfl-0004Hv-9N for tls@ietf.org; Tue, 04 Apr 2006 05:18:01 -0400
Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext12.nokia.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k349Ghh6006433; Tue, 4 Apr 2006 12:16:44 +0300
Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 4 Apr 2006 12:17:18 +0300
Received: from esebe105.NOE.Nokia.com ([172.21.143.53]) by esebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 4 Apr 2006 12:17:17 +0300
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: Tue, 04 Apr 2006 12:17:15 +0300
Message-ID: <B356D8F434D20B40A8CEDAEC305A1F240278B6E4@esebe105.NOE.Nokia.com>
In-Reply-To: <BF9309599A71984CAC5BAC5ECA629944048E9907@EUR-MSG-11.europe.corp.microsoft.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: Last call comments for draft-santesson-tls-(ume-04,supp-00)
Thread-Index: AcZXMNuFCJ5G2HbVRSS7TaRmlAeEswAQZuvgABV7OUA=
From: Pasi.Eronen@nokia.com
To: stefans@microsoft.com, housley@vigilsec.com
X-OriginalArrivalTime: 04 Apr 2006 09:17:17.0998 (UTC) FILETIME=[91ED94E0:01C657C8]
X-Spam-Score: 0.2 (/)
X-Scan-Signature: b5d20af10c334b36874c0264b10f59f1
Cc: tls@ietf.org
Subject: [TLS] RE: Last call comments for draft-santesson-tls-(ume-04, 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

Stefan,

Thanks for the clarification. Please include text about this 
in the draft as well.

Best regards,
Pasi 

> -----Original Message-----
> From: ext Stefan Santesson [mailto:stefans@microsoft.com] 
> Sent: 04 April, 2006 02:08
> To: Russ Housley; Eronen Pasi (Nokia-NRC/Helsinki)
> Cc: tls@ietf.org
> Subject: RE: Last call comments for 
> draft-santesson-tls-(ume-04,supp-00)
> 
> Sometimes it is sufficient to specify the domain as the user name is
> provided by the cert but that cert is used to access multiple accounts
> in different domains. In other cases the full name@domain is needed.
> 
> We chose to provide for both alternatives using the same hint type.
> This works well and I would prefer to keep it that way.
> 
> 
> Stefan Santesson
> Program Manager, Standards Liaison
> Windows Security
> 
> 
> > -----Original Message-----
> > From: Russ Housley [mailto:housley@vigilsec.com]
> > Sent: den 3 april 2006 17:10
> > To: Pasi.Eronen@nokia.com; Stefan Santesson
> > Cc: tls@ietf.org
> > Subject: RE: Last call comments for
> draft-santesson-tls-(ume-04,supp-00)
> > 
> > Pasi:
> > 
> > My comments were with respect to the user_principal_name within the
> > UpnDomainHint.  Sorry for being ambiguous.
> > 
> > Russ
> > 
> > 
> > >Russ Housley wrote:
> > > >
> > > > Pasi:
> > > >
> > > > >4) tls-ume: Would it make sense to define two UserMappingData
> types,
> > > > >    one for "user@domain" and another one for just "domain",
> instead
> > > > >    of combining them in one type?
> > > >
> > > > I do not think so.  The name is user@domain.  It would be
> meaningless
> > > > if only user was present, and t would me meaningless if only
> domain
> > > > was present.
> > >
> > >I don't know if it's meaningless or not, but the current draft does
> > >say that
> > >
> > >    The UpnDomainHint MUST at least contain a non empty
> > >    user_principal_name or a non empty domain_name. The 
> UpnDomainHint
> > >    MAY contain both user_principal_name and domain_name.
> > >
> > >In other words, one of the fields can be empty. And since the
> > >user_principal_name field is of the form "user@domain",
> > >it looks like the UpnDomainHint structure can actually contain
> > >two _different_ domain names. In other words, the spec does
> > >allow things like:
> > >
> > >   UserMappingData {
> > >     user_mapping_version = upn_domain_hint(0)
> > >     UpnDomainHint {
> > >       user_principal_name = "foo@example.com"
> > >       domain_name = "bar.example.net"
> > >     }
> > >   }
> > >
> > >But the draft currently does not explain what this would mean,
> > >or what the domain-name-only hints are (perhaps they're 
> "Host Mapping
> > >Data" for host certificates instead of user certs, or something).
> > >This needs to be clarified.
> > >
> > >Best regards,
> > >Pasi
> 
> 

_______________________________________________
TLS mailing list
TLS@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/tls