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

Russ Housley <housley@vigilsec.com> Tue, 04 April 2006 11:17 UTC

Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQjWw-0005nY-S6; Tue, 04 Apr 2006 07:17:02 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQjWv-0005nT-KH for tls@ietf.org; Tue, 04 Apr 2006 07:17:01 -0400
Received: from woodstock.binhost.com ([144.202.243.4]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FQjWv-0000OK-D1 for tls@ietf.org; Tue, 04 Apr 2006 07:17:01 -0400
Received: (qmail 20318 invoked by uid 0); 4 Apr 2006 11:17:00 -0000
Received: from unknown (HELO Russ-Laptop.vigilsec.com) (71.246.201.221) by woodstock.binhost.com with SMTP; 4 Apr 2006 11:17:00 -0000
Message-Id: <7.0.0.16.2.20060404071509.061c2fc8@vigilsec.com>
X-Mailer: QUALCOMM Windows Eudora Version 7.0.0.16
Date: Tue, 04 Apr 2006 07:16:59 -0400
To: stefans@microsoft.com
From: Russ Housley <housley@vigilsec.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format="flowed"
X-Spam-Score: 0.1 (/)
X-Scan-Signature: a2c12dacc0736f14d6b540e805505a86
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,

Nothing in the document explains this use case.  So, you need to add 
text that explains the processing in each possible case.  Are there 
two cases or three?

Russ

 > -----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