From tls-bounces@lists.ietf.org Sat Apr 01 03:46:18 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FPbkL-0006SE-Ss; Sat, 01 Apr 2006 03:46:13 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FPbkL-0006S9-6U for tls@lists.ietf.org; Sat, 01 Apr 2006 03:46:13 -0500 Received: from zproxy.gmail.com ([64.233.162.193]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FPbkK-0003Vf-0A for tls@lists.ietf.org; Sat, 01 Apr 2006 03:46:13 -0500 Received: by zproxy.gmail.com with SMTP id x3so1130304nzd for ; Sat, 01 Apr 2006 00:46:11 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=PXxYJIabcwrViPVwcmXAKSiat+KAefrdamhCrctI7v7Gt5AfWCQCEg+PqFNvKJ9kVUKxDBN0+OYQpIP0RpYJRiTppCX9niOP4zaFxooaNt3SWe5HzjUXRfJAyCiA/FjV+OuR0AcXv7rhYq5fi+qTOoA94CIgiiOt6gmxBqPIk3I= Received: by 10.36.31.9 with SMTP id e9mr270738nze; Sat, 01 Apr 2006 00:46:11 -0800 (PST) Received: by 10.36.121.12 with HTTP; Sat, 1 Apr 2006 00:46:11 -0800 (PST) Message-ID: <7fae6f9f0604010046r4b848b66v355e6ce7103604f7@mail.gmail.com> Date: Sat, 1 Apr 2006 05:46:11 -0300 From: "Eliezio Oliveira" To: tls@lists.ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Subject: [TLS] TLS Extensions on RFC 4346 X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ebo@pobox.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org The RFC 3456 could be split in two documents, since the first part deals with a generic mechanism on how to extend the TLS protocol in a interoperable manner, while the second is comprised of six specific (why not say "fortuitous"?) extensions using that generic mechanism. The current draft for the TLS 1.2 protocol included the RFC 3546 entirely, both the generic and the specific parts. I would advocate that only the first part should be kept in the TLS specification, and move the specific extensions to one or more new RFCs. When compared against IPsec, for example, the current TLS spec does not leave room for the "a la carte approach" for the implementors. And I believe that this change will encourage this virtue on the spec of the forthcoming version of the TLS protocol. Regards, Eli=E9zio Oliveira _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Mon Apr 03 06:45:19 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQMYW-00018g-QX; Mon, 03 Apr 2006 06:45:08 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQMYV-00018Y-FP; Mon, 03 Apr 2006 06:45:07 -0400 Received: from mgw-ext14.nokia.com ([131.228.20.173]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FQMYV-0004E1-0a; Mon, 03 Apr 2006 06:45:07 -0400 Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext14.nokia.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k33AiUSj011563; Mon, 3 Apr 2006 13:44:32 +0300 Received: from esebh101.NOE.Nokia.com ([172.21.138.177]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 3 Apr 2006 13:45:05 +0300 Received: from esebe105.NOE.Nokia.com ([172.21.143.53]) by esebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 3 Apr 2006 13:45:04 +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: Mon, 3 Apr 2006 13:45:02 +0300 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Last call comments for draft-santesson-tls-(ume-04,supp-00) Thread-Index: AcZXC6k0G1x/GIYAS5STcqLB9lH1HA== From: To: , X-OriginalArrivalTime: 03 Apr 2006 10:45:04.0676 (UTC) FILETIME=[AAB31E40:01C6570B] X-Spam-Score: 0.2 (/) X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5 Cc: tls@ietf.org Subject: [TLS] 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org Some additional last call comments for draft-santesson-tls-ume-04=20 and draft-santesson-tls-supp-00: 1) The IANA considerations sections in both documents are=20 incomplete (missing the requests to assign new numbers),=20 in some details correct (number ranges overlap), and unclear. Here's a proposal for better text: draft-santesson-tls-supp: This document defines a new TLS handshake message, "supplemental_data", assigned a value of TBD-BY-IANA from the TLS HandshakeType registry defined in [RFC4346]. This document establishes a new registry, to be maintained by IANA, for TLS Supplemental Data Types. Initially, the registry is empty. Values from the range 0-16385 are assigned via Standards Action [RFC2434]. Values from the range 16386-65279 are assigned via Specification Required [RFC2434]. Values from the range 65280-65535 are reserved for Private Use [RFC2434]. draft-santesson-tls-ume: This document defines a new TLS extension, "user_mapping", assigned a value of TBD-BY-IANA1 from the TLS Extension Type registry defined in [RFC4366]. This document defines a new TLS supplemental data type, "user_mapping_data", assigned a value of TBD-BY-IANA2 from the TLS Supplemental Data Type registry defined in [draft-santesson-tls-supp]. This document establish a new registry, to be maintained by IANA, for TLS User Mapping Types. Initially, the registry contains one entry: upn_domain_hint (0). Values from the range 1-63 are assigned via Standards Action [RFC2434]. Values from the range 64-223 are assigned via Specification Required [RFC2434]. Values from the range 224-255 are reserved for Private Use [RFC2434]. 2) tls-ume, Section 5: "The client SHOULD only send the UserMappingDataList in the supplemental data message if it is=20 agreed upon in the hello message exchange" =20 This is wrong (and violates a "MUST" in tls-supp): the user=20 mapping data list MUST NOT be sent if it was not agreed in the ClientHello/ServerHello exchange. 3) Security considerations in both documents should explicitly=20 point out that the information is not encrypted (and thus visible=20 to eavesdroppers), and is sent before the peer is authenticated (unless the "double-handshake" trick is used). This may be obvious=20 to the authors, but not to everyone reading these documents... 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? 5) tls-ume, Section 3: ".. contain a domain name in the "preferred name syntax," as specified by RFC 1123". RFC 1123 never even mentions the term "preferred name syntax" (it is mentioned in RFC 1034, though).=20 6) tls-ume: The document should contain at least an informative reference to a document describing what this Microsoft UPN is. Simply saying it's of the form "user@domain" is not very helpful. For instance, does "domain" mean it's a DNS name? (Windows uses the word "domain" also for names that don't have anything to=20 do with DNS). Is the domain part an IDN-aware or IDN-unaware=20 domain name slot? (Or neither?) Are some special characters=20 (e.g., punctuation, at sign) in the "user" part forbidden, or escaped/encoded somehow specially? 7) References in tls-ume: IMHO references N7,N8,N9 seem more Informative than Normative. Reference N5 is never cited in text. RFC 1123 is cited in the text, but not included in reference list. Best regards, Pasi _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Mon Apr 03 07:16:41 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQN30-0004N6-Da; Mon, 03 Apr 2006 07:16:38 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQN2y-0004My-8Q; Mon, 03 Apr 2006 07:16:36 -0400 Received: from mail-eur1.microsoft.com ([213.199.128.139]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FQN2x-0005K7-Mx; Mon, 03 Apr 2006 07:16:36 -0400 Received: from EUR-MSG-11.europe.corp.microsoft.com ([65.53.193.196]) by mail-eur1.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 3 Apr 2006 12:16:34 +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: Mon, 3 Apr 2006 12:16:33 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Last call comments for draft-santesson-tls-(ume-04,supp-00) thread-index: AcZXC6k0G1x/GIYAS5STcqLB9lH1HAAAmV5g From: "Stefan Santesson" To: , X-OriginalArrivalTime: 03 Apr 2006 11:16:34.0663 (UTC) FILETIME=[11383F70:01C65710] X-Spam-Score: 0.0 (/) X-Scan-Signature: 3a4bc66230659131057bb68ed51598f8 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org Pasi, Thanks for the good review work. I agree to all points and requests for changes except for the following issues/concerns: 4) I would much rather keep the current user mapping hint definition. Both ways works technically and it is more a matter of taste. The current hint type form is already implemented in code and thus it would mean a lot of work for little gain to change it. 5) I do not disagree. We originally had a ref to 1034 but Kurt advised us that we should refer to 1123. Apparently this was not correct. RFC 3280 makes the same type of reference to 1024 for information contained in the dNSName subject alt name. 6) For this draft we mean that it should be a domain name according to the "preferred name syntax" as discussed before. This name form is not specific to Microsoft. If this is not enough then we could provide some information in an informational Annex as you suggested. 7) I had the same concerns. I'm not sure whether a document that is referenced in a SHOULD statements is to be considered informative or normative. I will align the document with the decision made. Stefan Santesson Program Manager, Standards Liaison Windows Security > -----Original Message----- > From: Pasi.Eronen@nokia.com [mailto:Pasi.Eronen@nokia.com] > Sent: den 3 april 2006 12:45 > To: Stefan Santesson; iesg@ietf.org > Cc: tls@ietf.org > Subject: Last call comments for draft-santesson-tls-(ume-04,supp-00) >=20 > Some additional last call comments for draft-santesson-tls-ume-04 > and draft-santesson-tls-supp-00: >=20 > 1) The IANA considerations sections in both documents are > incomplete (missing the requests to assign new numbers), > in some details correct (number ranges overlap), and unclear. > Here's a proposal for better text: >=20 > draft-santesson-tls-supp: >=20 > This document defines a new TLS handshake message, > "supplemental_data", assigned a value of TBD-BY-IANA from the TLS > HandshakeType registry defined in [RFC4346]. >=20 > This document establishes a new registry, to be maintained by IANA, > for TLS Supplemental Data Types. Initially, the registry is empty. > Values from the range 0-16385 are assigned via Standards Action > [RFC2434]. Values from the range 16386-65279 are assigned via > Specification Required [RFC2434]. Values from the range > 65280-65535 are reserved for Private Use [RFC2434]. >=20 > draft-santesson-tls-ume: >=20 > This document defines a new TLS extension, "user_mapping", assigned > a value of TBD-BY-IANA1 from the TLS Extension Type registry > defined in [RFC4366]. >=20 > This document defines a new TLS supplemental data type, > "user_mapping_data", assigned a value of TBD-BY-IANA2 from the TLS > Supplemental Data Type registry defined in > [draft-santesson-tls-supp]. >=20 > This document establish a new registry, to be maintained by IANA, > for TLS User Mapping Types. Initially, the registry contains one > entry: upn_domain_hint (0). Values from the range 1-63 are assigned > via Standards Action [RFC2434]. Values from the range 64-223 are > assigned via Specification Required [RFC2434]. Values from the > range 224-255 are reserved for Private Use [RFC2434]. >=20 > 2) tls-ume, Section 5: "The client SHOULD only send the > UserMappingDataList in the supplemental data message if it is > agreed upon in the hello message exchange" >=20 > This is wrong (and violates a "MUST" in tls-supp): the user > mapping data list MUST NOT be sent if it was not agreed in the > ClientHello/ServerHello exchange. >=20 > 3) Security considerations in both documents should explicitly > point out that the information is not encrypted (and thus visible > to eavesdroppers), and is sent before the peer is authenticated > (unless the "double-handshake" trick is used). This may be obvious > to the authors, but not to everyone reading these documents... >=20 > 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? >=20 > 5) tls-ume, Section 3: ".. contain a domain name in the "preferred > name syntax," as specified by RFC 1123". RFC 1123 never even mentions > the term "preferred name syntax" (it is mentioned in RFC 1034, > though). >=20 > 6) tls-ume: The document should contain at least an informative > reference to a document describing what this Microsoft UPN is. > Simply saying it's of the form "user@domain" is not very helpful. > For instance, does "domain" mean it's a DNS name? (Windows uses > the word "domain" also for names that don't have anything to > do with DNS). Is the domain part an IDN-aware or IDN-unaware > domain name slot? (Or neither?) Are some special characters > (e.g., punctuation, at sign) in the "user" part forbidden, > or escaped/encoded somehow specially? >=20 > 7) References in tls-ume: IMHO references N7,N8,N9 seem more > Informative than Normative. Reference N5 is never cited in text. > RFC 1123 is cited in the text, but not included in reference list. >=20 > Best regards, > Pasi _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Mon Apr 03 10:05:50 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQPgg-00025y-Ug; Mon, 03 Apr 2006 10:05:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQPgf-00025t-NR for tls@ietf.org; Mon, 03 Apr 2006 10:05:45 -0400 Received: from woodstock.binhost.com ([144.202.243.4]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FQPge-000425-G7 for tls@ietf.org; Mon, 03 Apr 2006 10:05:45 -0400 Received: (qmail 31312 invoked by uid 0); 3 Apr 2006 14:05:41 -0000 Received: from unknown (HELO Russ-Laptop.vigilsec.com) (71.246.201.221) by woodstock.binhost.com with SMTP; 3 Apr 2006 14:05:41 -0000 Message-Id: <7.0.0.16.2.20060403095031.0574bc48@vigilsec.com> X-Mailer: QUALCOMM Windows Eudora Version 7.0.0.16 Date: Mon, 03 Apr 2006 09:51:43 -0400 To: , From: Russ Housley In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.1 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org 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. Russ _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Mon Apr 03 10:46:26 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQQIW-0008UA-QY; Mon, 03 Apr 2006 10:44:52 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQQIU-0008U2-Py for tls@ietf.org; Mon, 03 Apr 2006 10:44:50 -0400 Received: from mgw-ext13.nokia.com ([131.228.20.172]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FQQIT-0005HS-Aw for tls@ietf.org; Mon, 03 Apr 2006 10:44:50 -0400 Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext13.nokia.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k33EiAEk025899; Mon, 3 Apr 2006 17:44:12 +0300 Received: from esebh101.NOE.Nokia.com ([172.21.138.177]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 3 Apr 2006 17:44:45 +0300 Received: from esebe105.NOE.Nokia.com ([172.21.143.53]) by esebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 3 Apr 2006 17:44:45 +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: Mon, 3 Apr 2006 17:44:44 +0300 Message-ID: In-Reply-To: <7.0.0.16.2.20060403095031.0574bc48@vigilsec.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Last call comments for draft-santesson-tls-(ume-04,supp-00) Thread-Index: AcZXKxwVIhUpVvlbSJqb0qZDMjQMdwAAEBBQ From: To: , X-OriginalArrivalTime: 03 Apr 2006 14:44:45.0076 (UTC) FILETIME=[26160540:01C6572D] X-Spam-Score: 0.2 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org Russ Housley wrote: >=20 > Pasi: >=20 > >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? >=20 > I do not think so. The name is user@domain. It would be meaningless=20 > if only user was present, and t would me meaningless if only domain=20 > was present. I don't know if it's meaningless or not, but the current draft does=20 say that=20 The UpnDomainHint MUST at least contain a non empty=20 user_principal_name or a non empty domain_name. The UpnDomainHint=20 MAY contain both user_principal_name and domain_name. In other words, one of the fields can be empty. And since the=20 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 =3D upn_domain_hint(0) UpnDomainHint { user_principal_name =3D "foo@example.com" domain_name =3D "bar.example.net" } } =20 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).=20 This needs to be clarified. Best regards, Pasi _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Mon Apr 03 11:10:06 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQQgu-0008UY-17; Mon, 03 Apr 2006 11:10:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQQgt-0008Ti-2v for tls@ietf.org; Mon, 03 Apr 2006 11:10:03 -0400 Received: from woodstock.binhost.com ([144.202.243.4]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FQQgr-0006Uk-RG for tls@ietf.org; Mon, 03 Apr 2006 11:10:03 -0400 Received: (qmail 11483 invoked by uid 0); 3 Apr 2006 15:09:58 -0000 Received: from unknown (HELO Russ-Laptop.vigilsec.com) (71.246.201.221) by woodstock.binhost.com with SMTP; 3 Apr 2006 15:09:58 -0000 Message-Id: <7.0.0.16.2.20060403105311.05767b78@vigilsec.com> X-Mailer: QUALCOMM Windows Eudora Version 7.0.0.16 Date: Mon, 03 Apr 2006 11:09:59 -0400 To: , From: Russ Housley In-Reply-To: References: <7.0.0.16.2.20060403095031.0574bc48@vigilsec.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.1 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org 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 From tls-bounces@lists.ietf.org Mon Apr 03 19:08:07 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQY9R-0000C5-JH; Mon, 03 Apr 2006 19:08:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQY9Q-0000Bv-OR for tls@ietf.org; Mon, 03 Apr 2006 19:08:00 -0400 Received: from mail-eur1.microsoft.com ([213.199.128.139]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FQY9O-0002pR-Ei for tls@ietf.org; Mon, 03 Apr 2006 19:08:00 -0400 Received: from EUR-MSG-11.europe.corp.microsoft.com ([65.53.193.196]) by mail-eur1.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 4 Apr 2006 00:07:57 +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: Tue, 4 Apr 2006 00:07:55 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Last call comments for draft-santesson-tls-(ume-04,supp-00) thread-index: AcZXMNuFCJ5G2HbVRSS7TaRmlAeEswAQZuvg From: "Stefan Santesson" To: "Russ Housley" , X-OriginalArrivalTime: 03 Apr 2006 23:07:57.0578 (UTC) FILETIME=[723836A0:01C65773] X-Spam-Score: 0.0 (/) X-Scan-Signature: 25620135586de10c627e3628c432b04a 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org 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) >=20 > Pasi: >=20 > My comments were with respect to the user_principal_name within the > UpnDomainHint. Sorry for being ambiguous. >=20 > Russ >=20 >=20 > >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 =3D upn_domain_hint(0) > > UpnDomainHint { > > user_principal_name =3D "foo@example.com" > > domain_name =3D "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 From tls-bounces@lists.ietf.org Tue Apr 04 05:18:09 2006 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, 4 Apr 2006 12:17:15 +0300 Message-ID: In-Reply-To: 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: To: , 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org Stefan, Thanks for the clarification. Please include text about this=20 in the draft as well. Best regards, Pasi=20 > -----Original Message----- > From: ext Stefan Santesson [mailto:stefans@microsoft.com]=20 > Sent: 04 April, 2006 02:08 > To: Russ Housley; Eronen Pasi (Nokia-NRC/Helsinki) > Cc: tls@ietf.org > Subject: RE: Last call comments for=20 > draft-santesson-tls-(ume-04,supp-00) >=20 > 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. >=20 > We chose to provide for both alternatives using the same hint type. > This works well and I would prefer to keep it that way. >=20 >=20 > Stefan Santesson > Program Manager, Standards Liaison > Windows Security >=20 >=20 > > -----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) > >=20 > > Pasi: > >=20 > > My comments were with respect to the user_principal_name within the > > UpnDomainHint. Sorry for being ambiguous. > >=20 > > Russ > >=20 > >=20 > > >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=20 > 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 =3D upn_domain_hint(0) > > > UpnDomainHint { > > > user_principal_name =3D "foo@example.com" > > > domain_name =3D "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=20 > "Host Mapping > > >Data" for host certificates instead of user certs, or something). > > >This needs to be clarified. > > > > > >Best regards, > > >Pasi >=20 >=20 _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Tue Apr 04 05:24:38 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQhm9-0006Ow-Io; Tue, 04 Apr 2006 05:24:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQhm9-0006Or-6w for tls@ietf.org; Tue, 04 Apr 2006 05:24:37 -0400 Received: from mail-eur.microsoft.com ([213.199.128.145]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FQhm8-0004OG-T1 for tls@ietf.org; Tue, 04 Apr 2006 05:24:37 -0400 Received: from EUR-MSG-11.europe.corp.microsoft.com ([65.53.193.196]) by mail-eur.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 4 Apr 2006 10:24:36 +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: Tue, 4 Apr 2006 10:24:32 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Last call comments for draft-santesson-tls-(ume-04,supp-00) thread-index: AcZXMNuFCJ5G2HbVRSS7TaRmlAeEswAQZuvgABV7OUAAAEnKQA== From: "Stefan Santesson" To: , X-OriginalArrivalTime: 04 Apr 2006 09:24:36.0009 (UTC) FILETIME=[9700C190:01C657C9] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7fa173a723009a6ca8ce575a65a5d813 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org Will do. Stefan Santesson Program Manager, Standards Liaison Windows Security > -----Original Message----- > From: Pasi.Eronen@nokia.com [mailto:Pasi.Eronen@nokia.com] > Sent: den 4 april 2006 11:17 > To: Stefan Santesson; housley@vigilsec.com > Cc: tls@ietf.org > Subject: RE: Last call comments for draft-santesson-tls-(ume-04,supp-00) >=20 > Stefan, >=20 > Thanks for the clarification. Please include text about this > in the draft as well. >=20 > Best regards, > Pasi >=20 > > -----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 =3D upn_domain_hint(0) > > > > UpnDomainHint { > > > > user_principal_name =3D "foo@example.com" > > > > domain_name =3D "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 From tls-bounces@lists.ietf.org Tue Apr 04 07:17:06 2006 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: From: Russ Housley 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 From tls-bounces@lists.ietf.org Tue Apr 04 14:20:34 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQq8j-0006qu-55; Tue, 04 Apr 2006 14:20:29 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQq8h-0006mb-4Q for tls@ietf.org; Tue, 04 Apr 2006 14:20:27 -0400 Received: from woodstock.binhost.com ([144.202.243.4]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FQq8e-0002W6-QM for tls@ietf.org; Tue, 04 Apr 2006 14:20:27 -0400 Received: (qmail 16510 invoked by uid 0); 4 Apr 2006 18:20:18 -0000 Received: from unknown (HELO Russ-Laptop.vigilsec.com) (129.6.193.7) by woodstock.binhost.com with SMTP; 4 Apr 2006 18:20:18 -0000 Message-Id: <7.0.0.16.2.20060404141120.057e5a68@vigilsec.com> X-Mailer: QUALCOMM Windows Eudora Version 7.0.0.16 Date: Tue, 04 Apr 2006 14:14:59 -0400 To: "Stefan Santesson" , From: Russ Housley In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.1 (/) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org It is okay with me, but your description does not match the text. Based on your note, the domain must be present, and the upn is optional. The text that Pasi quoted needs to be replaced with a sentence that says this. Then, you need to add a paragraph that explains the processing when only the domain is present, and then an paragraph that explains the processing when both the domain and the upn are present. Russ At 07:07 PM 4/3/2006, Stefan Santesson wrote: >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 From tls-bounces@lists.ietf.org Tue Apr 04 18:28:15 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQu0R-0004Gj-81; Tue, 04 Apr 2006 18:28:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQu0Q-0004Ge-1J for tls@ietf.org; Tue, 04 Apr 2006 18:28:10 -0400 Received: from mail-eur.microsoft.com ([213.199.128.145]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FQu0O-00045k-K4 for tls@ietf.org; Tue, 04 Apr 2006 18:28:10 -0400 Received: from EUR-MSG-11.europe.corp.microsoft.com ([65.53.193.196]) by mail-eur.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 4 Apr 2006 23:28:07 +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: Tue, 4 Apr 2006 23:28:04 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Last call comments for draft-santesson-tls-(ume-04,supp-00) thread-index: AcZYFH6yJQiIvnziS5uq+CsGNaB11QAIhSTw From: "Stefan Santesson" To: "Russ Housley" , X-OriginalArrivalTime: 04 Apr 2006 22:28:07.0688 (UTC) FILETIME=[0C25B080:01C65837] X-Spam-Score: 0.0 (/) X-Scan-Signature: 5ebbf074524e58e662bc8209a6235027 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org I'm sorry if my text was unclear. If you specify UPN, then domain is automatically included in the UPN. I'm preparing a new text proposal. I will send it tomorrow morning. That will include processing and normalization of the domain component which is Unicode UTF-8 normalized with Nameprep. Stefan Santesson Program Manager, Standards Liaison Windows Security > -----Original Message----- > From: Russ Housley [mailto:housley@vigilsec.com] > Sent: den 4 april 2006 20:15 > To: Stefan Santesson; Pasi.Eronen@nokia.com > Cc: tls@ietf.org > Subject: RE: Last call comments for draft-santesson-tls-(ume-04,supp-00) >=20 > It is okay with me, but your description does not match the > text. Based on your note, the domain must be present, and the upn is > optional. The text that Pasi quoted needs to be replaced with a > sentence that says this. >=20 > Then, you need to add a paragraph that explains the processing when > only the domain is present, and then an paragraph that explains the > processing when both the domain and the upn are present. >=20 > Russ >=20 >=20 > At 07:07 PM 4/3/2006, Stefan Santesson wrote: > >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 =3D upn_domain_hint(0) > > > > UpnDomainHint { > > > > user_principal_name =3D "foo@example.com" > > > > domain_name =3D "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 From tls-bounces@lists.ietf.org Fri Apr 07 15:21:34 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRwWD-0005z2-37; Fri, 07 Apr 2006 15:21:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRwWB-0005yx-AN for tls@ietf.org; Fri, 07 Apr 2006 15:21:15 -0400 Received: from dyn50.sunlabs.com ([204.153.12.50] helo=mail-mta.sunlabs.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FRwWA-0002qH-UM for tls@ietf.org; Fri, 07 Apr 2006 15:21:15 -0400 Received: from mail.sunlabs.com ([152.70.2.186]) by dps.sfvic.sunlabs.com (Sun Java System Messaging Server 6.1 HotFix 0.02 (built Aug 25 2004)) with ESMTP id <0IXD00KR99RDGE00@dps.sfvic.sunlabs.com> for tls@ietf.org; Fri, 07 Apr 2006 12:21:14 -0700 (PDT) Received: from [129.146.73.175] by mail.sunlabs.com (Sun Java System Messaging Server 6.1 HotFix 0.02 (built Aug 25 2004)) with ESMTPSA id <0IXD00JOQ9RDP9Q0@mail.sunlabs.com> for tls@ietf.org; Fri, 07 Apr 2006 12:21:13 -0700 (PDT) Date: Fri, 07 Apr 2006 12:21:47 -0700 From: Vipul Gupta To: tls mailing list Message-id: <3454FBAA-8DA2-4349-BBA4-9DEDF2E78EDD@sun.com> MIME-version: 1.0 X-Mailer: Apple Mail (2.746.2) Content-type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Content-transfer-encoding: 7BIT X-Spam-Score: 0.0 (/) X-Scan-Signature: a1852b4f554b02e7e4548cc7928acc1f Cc: Subject: [TLS] Re: 'ECC Cipher Suites for TLS' to Informational RFC 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org [Resending with a shortened cc list. My previous attempt 3 days bounced with a "too many recipients" message. I had cc'd both ADs, both co-chairs and the coauthors.] Here's another note in the same vein as http://www1.ietf.org/mail-archive/web/tls/current/msg00538.html http://www1.ietf.org/mail-archive/web/tls/current/msg00489.html identifying minor fixes that will be included in the ECC in TLS spec before RFC publication. Details of the change and Russ's note approving it are attached below (the change has also been approved by Eric Rescorla). The coauthors have tried their best to coordinate these changes with all known implementors of this spec (including Certicom, OpenSSL, Microsoft, Red Hat, Sun) but we apologize for any inconvenience this causes to implementors we might have overlooked. [If you have an implementation and would like to participate in interoperability testing, please send me email, see: http://www1.ietf.org/mail-archive/web/tls/current/msg00535.html ] thank you, vipul Begin forwarded message: > From: Russ Housley > Date: April 5, 2006 4:55:54 PM PDT > To: Vipul Gupta , Eric Rescorla > , hartmans-ietf@mit.edu, > Pasi.Eronen@nokia.com > Cc: Simon Blake-Wilson , Bodo Moeller > , Nelson B Bolyard , Chris > Hawk , Bob Lord , Nelson > Bolyard , Ari Medvinsky > , 'Bodo Moeller' , > Douglas Stebila , Rob Dugal > , Kenneth Zhang , Vipul > Gupta , bminard@certicom.com > Subject: Re: 'ECC Cipher Suites for TLS' to Informational RFC > > This is fine. > > At 06:00 PM 4/5/2006, Vipul Gupta wrote: > >> Hi Eric, Pasi, Sam and Russ, >> >> Thanks for your prompt response. As you suggested, >> we've posted a notification of this change (see >> http://www1.ietf.org/mail-archive/web/tls/current/msg00538.html) >> >> Subsequently, we've become aware of two other places >> (both in Section 5.4, Server Key Exchange) where the >> draft can use additional clarification: >> >> 1) On page 22, it ought to point out that the "sha_hash" >> in the "Signature" definition isn't a simple hash of the >> EC params alone. Rather, it is the data structure defined >> in Section 7.4.3 of the main TLS spec and includes >> the client and server random values in addition to the >> server params. >> >> 2) On page 22, it should say that the "r" and "s" >> components of the ECDSA signature are DER encoded >> (to be consistent with DSA). >> >> All implementations of this spec that we are aware of >> (including those from Certicom, OpenSSL, Microsoft, >> Red Hat and Sun) already encode this behavior (or plan >> to do so soon). >> >> We (the coauthors and implementers on the cc list) >> seek your permission to include these clarifications >> during AUTH48. >> >> vipul >> >> On Mar 29, 2006, at 6:36 AM, Russ Housley wrote: >> >> >>> I see no problem making this correction. However, please post a >>> message to the TLS WG mail list to notify everyone that this will >>> happen. >>> >>> Russ >>> >>> At 06:23 PM 3/24/2006, Vipul Gupta wrote: >>> >>>> Hi Eric, Pasi, Sam and Russ, >>>> >>>> We (the authors and implementers on the cc list) >>>> have recently become aware of an inconsistency >>>> in the latest version of the specification and seek >>>> your permission to fix it during the AUTH48 period. >>>> >>>> When going from draft-ietf-tls-ecc-10.txt to >>>> draft-ietf-tls-ecc-11.txt, the encoding of named >>>> curves was changed from 1 byte to 2 bytes in response >>>> to WG feedback. However, the corresponding change >>>> in the encoding of the EllipticCurveList length >>>> from 1 to 2 bytes was reflected in the examples >>>> but not in the EllipticCurveList definition. This >>>> made the examples in Section 5.1.1 inconsistent >>>> with the adjacent text. We propose fixing the text >>>> as follows: >>>> >>>> struct { >>>> - NamedCurve elliptic_curve_list<1..2^8-1> >>>> + NamedCurve elliptic_curve_list<1..2^16-1> >>>> } EllipticCurveList; >>>> >>>> This change is consistent with the implementation >>>> plans for Microsoft, Redhat, Sun and OpenSSL. >>>> >>>> We'd appreciate a quick response so we can bring >>>> this resolution to the attention of other folks who >>>> might be implementing this specification. Thank you >>>> for your time. >>>> >>>> vipul >>>> >> >> > > _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Fri Apr 07 18:15:58 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRzFC-0002iy-PQ; Fri, 07 Apr 2006 18:15:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRzFC-0002it-0B for tls@ietf.org; Fri, 07 Apr 2006 18:15:54 -0400 Received: from dyn50.sunlabs.com ([204.153.12.50] helo=mail-mta.sunlabs.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FRzF8-0008WI-Ib for tls@ietf.org; Fri, 07 Apr 2006 18:15:53 -0400 Received: from mail.sunlabs.com ([152.70.2.186]) by dps.sfvic.sunlabs.com (Sun Java System Messaging Server 6.1 HotFix 0.02 (built Aug 25 2004)) with ESMTP id <0IXD00K1EHUDGE10@dps.sfvic.sunlabs.com> for tls@ietf.org; Fri, 07 Apr 2006 15:15:49 -0700 (PDT) Received: from [152.70.69.223] by mail.sunlabs.com (Sun Java System Messaging Server 6.1 HotFix 0.02 (built Aug 25 2004)) with ESMTPSA id <0IXD00J8VHU6P9R0@mail.sunlabs.com> for tls@ietf.org; Fri, 07 Apr 2006 15:15:49 -0700 (PDT) Date: Fri, 07 Apr 2006 15:16:16 -0700 From: Vipul Gupta Subject: Re: [TLS] Re: 'ECC Cipher Suites for TLS' to Informational RFC In-reply-to: <3454FBAA-8DA2-4349-BBA4-9DEDF2E78EDD@sun.com> To: tls mailing list Message-id: <256AE9D3-9B33-4853-9AAD-3D81E97A16FB@sun.com> MIME-version: 1.0 X-Mailer: Apple Mail (2.746.2) Content-type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Content-transfer-encoding: 7BIT References: <3454FBAA-8DA2-4349-BBA4-9DEDF2E78EDD@sun.com> X-Spam-Score: 0.5 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Cc: 'Bodo Moeller' , Vipul Gupta 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org A document incorporating the changes to draft-ietf-tls-ecc-12.txt described in: http://www1.ietf.org/mail-archive/web/tls/current/msg00555.html http://www1.ietf.org/mail-archive/web/tls/current/msg00538.html http://www1.ietf.org/mail-archive/web/tls/current/msg00489.html is now available at: http://dev.experimentalstuff.com:8082/DRAFT3-draft-ietf-tls- ecc-13.txt vipul p.s. Thanks Bodo! _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Tue Apr 11 13:44:22 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTMuV-0004CQ-Qj; Tue, 11 Apr 2006 13:44:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTMuV-0004CL-07 for tls@ietf.org; Tue, 11 Apr 2006 13:44:15 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FTLI7-0007TV-24 for tls@ietf.org; Tue, 11 Apr 2006 12:00:31 -0400 Received: from smtp-out4.blueyonder.co.uk ([195.188.213.7]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FTL8N-00087b-DE for tls@ietf.org; Tue, 11 Apr 2006 11:50:28 -0400 Received: from [172.23.170.143] (helo=anti-virus02-10) by smtp-out4.blueyonder.co.uk with smtp (Exim 4.52) id 1FTL8C-0000AR-CT for tls@ietf.org; Tue, 11 Apr 2006 16:50:16 +0100 Received: from 82-42-16-20.cable.ubr01.knor.blueyonder.co.uk ([82.42.16.20] helo=[127.0.0.1]) by asmtp-out5.blueyonder.co.uk with esmtp (Exim 4.52) id 1FTL88-0007c6-Pj for tls@ietf.org; Tue, 11 Apr 2006 16:50:12 +0100 Message-ID: <443BD036.6030808@blueyonder.co.uk> Date: Tue, 11 Apr 2006 16:50:14 +0100 From: David Hopwood User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: tls@ietf.org Subject: Re: Review (Re: [TLS] I-D ACTION:draft-ietf-tls-ctr-00.txt) References: <6.2.5.6.2.20060303142705.051f7078@qualcomm.com> <20060320084527.GB30961@cs.stanford.edu> In-Reply-To: <20060320084527.GB30961@cs.stanford.edu> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: -0.4 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Cc: X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: david.nospam.hopwood@blueyonder.co.uk List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org nagendra modadugu wrote: >>On the block level counter, 3686 specifies a 32-bit counter citing >>IPv6 Jumbograms' requirement. SRTP makes a note that for multimedia >>apps, that might be safely ignored. Could you also make a similar >>note in this document, or perhaps you might also want to support >>jumbograms? (Perhaps IPv6 historians might tell us whether there are >>practical uses for jumbograms). > > The limit on the counter here is to support a TLS record of 2^14 octets. 2^14 octets is the "maximum fragment length" (TLSPlaintext.length). The maximum length of the input to encryption (TLSCompressed.length) is is 2^14 + 1024 octets. See RFC2246[bis-13] sections 6.2.2 and 6.2.3. Fragment length negotiation allow these limits to be decreased, but not increased. >From section 3.1.1 of the draft: Note that the block counter does not overflow since the maximum TLS/ DTLS record size is 14 KB and 16 bits of blk_ctr allow the generation of 1MB of keying material per record. The property needed is that 2^14 + 1024 octets <= (128/8) * 2^16 octets. Also "KB" and "MB" should not be used in IETF documents; they are not well-defined. So this paragraph should be: Note that the block counter does not overflow since the maximum size of input to the record payload protection layer in TLS or DTLS (TLSCompressed.length) is 2^14 + 1024 octets, and 16 bits of blk_ctr allow the generation of 2^20 octets (2^16 AES blocks) of keying material per record. -- David Hopwood _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Thu Apr 13 01:12:35 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTu7k-0001mA-06; Thu, 13 Apr 2006 01:12:08 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTu7i-0001lv-5n; Thu, 13 Apr 2006 01:12:06 -0400 Received: from laser.networkresonance.com ([198.144.196.2]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FTu7g-0006Du-Ru; Thu, 13 Apr 2006 01:12:06 -0400 Received: from networkresonance.com (raman.networkresonance.com [198.144.196.3]) by laser.networkresonance.com (Postfix) with ESMTP id D6B4322245C; Wed, 12 Apr 2006 22:17:57 -0700 (PDT) To: iesg@ietf.org, tls@ietf.org X-Mailer: MH-E 7.4.3; nmh 1.0.4; XEmacs 21.4 (patch 18) Date: Wed, 12 Apr 2006 22:12:04 -0700 From: Eric Rescorla Message-Id: <20060413051757.D6B4322245C@laser.networkresonance.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Cc: Subject: [TLS] 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org These drafts seem basically sound. Minor comments below. -tls-supp: You should state that only one SupplementalData field may be used per handshake. Somewhere you should note that this data SHOULD NOT be processed by TLS but just passed up to the application. -tls-ume: Why is this draft going to Proposed? ISTM that it's pretty hard to interpret without a bunch of MS-proprietary information. There's no need for it to go to Proposed, since both extensions and Supp-data allow code points to be issued via informational. S 3: Should the UMDL type be 2^24-1 rather than 2^16-1. S 4: You can do the UPN hint extension exchange and then NOT send supp_data? That seems wrong. S 5: I don't really understand this bit about "if the server belongs to a domain to which the client intends to authenticate". What does that mean in practice? How would you know? -Ekr _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Mon Apr 17 19:03:44 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FVckh-0004gG-GF; Mon, 17 Apr 2006 19:03:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FVckf-0004fC-Bv for tls@ietf.org; Mon, 17 Apr 2006 19:03:25 -0400 Received: from woodstock.binhost.com ([144.202.243.4]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FVckf-00031A-1Q for tls@ietf.org; Mon, 17 Apr 2006 19:03:25 -0400 Received: (qmail 31981 invoked by uid 0); 17 Apr 2006 23:03:13 -0000 Received: from unknown (HELO THINKPADR52.vigilsec.com) (71.246.201.196) by woodstock.binhost.com with SMTP; 17 Apr 2006 23:03:13 -0000 Message-Id: <7.0.0.16.2.20060417170510.03659fe0@vigilsec.com> X-Mailer: QUALCOMM Windows Eudora Version 7.0.0.16 Date: Mon, 17 Apr 2006 17:10:36 -0400 To: Eric Rescorla From: Russ Housley In-Reply-To: <20060413051757.D6B4322245C@laser.networkresonance.com> References: <20060413051757.D6B4322245C@laser.networkresonance.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.1 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org Eric: >These drafts seem basically sound. Minor comments below. > >-tls-supp: >You should state that only one SupplementalData field may >be used per handshake. I agree. This was pointed out by the Gen-ART reviewer too. >Somewhere you should note that this data SHOULD NOT be >processed by TLS but just passed up to the application. I agree. This was also raised by Cullen. >-tls-ume: >Why is this draft going to Proposed? ISTM that it's pretty >hard to interpret without a bunch of MS-proprietary >information. There's no need for it to go to Proposed, since >both extensions and Supp-data allow code points to be >issued via informational. This is being discussed. The reason that I would like to see it as standards-track is that the structure supports more than just Microsoft names. The Microsoft names are simply the first ones that are supported. >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 data should be sent. Russ _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Mon Apr 17 19:09:46 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FVcqm-0007Ku-O1; Mon, 17 Apr 2006 19:09:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FVcqm-0007JD-3f; Mon, 17 Apr 2006 19:09:44 -0400 Received: from laser.networkresonance.com ([198.144.196.2]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FVcqk-0003Wb-PY; Mon, 17 Apr 2006 19:09:44 -0400 Received: from networkresonance.com (raman.networkresonance.com [198.144.196.3]) by laser.networkresonance.com (Postfix) with ESMTP id 1B82B222418; Mon, 17 Apr 2006 16:15:59 -0700 (PDT) To: Russ Housley In-reply-to: Your message of "Mon, 17 Apr 2006 17:10:36 EDT." <7.0.0.16.2.20060417170510.03659fe0@vigilsec.com> X-Mailer: MH-E 7.4.3; nmh 1.0.4; XEmacs 21.4 (patch 18) Date: Mon, 17 Apr 2006 16:09:40 -0700 From: Eric Rescorla Message-Id: <20060417231559.1B82B222418@laser.networkresonance.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org Russ Housley wrote: > >-tls-ume: > >Why is this draft going to Proposed? ISTM that it's pretty > >hard to interpret without a bunch of MS-proprietary > >information. There's no need for it to go to Proposed, since > >both extensions and Supp-data allow code points to be > >issued via informational. > > This is being discussed. The reason that I would like to see it as > standards-track is that the structure supports more than just > Microsoft names. The Microsoft names are simply the first ones that > are supported. I'm sympathetic to this, but I'm also uncomfortable with having a PS that's not really implementable in part. That said, this is probably part of a higher level IETF/IESG policy discussion rather than a TLS one. > >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 data > 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. Best, -Ekr _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Tue Apr 18 13:57:17 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FVuRm-0001Rl-I3; Tue, 18 Apr 2006 13:57:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FVuRk-0001RU-J9; Tue, 18 Apr 2006 13:57:04 -0400 Received: from mail-eur1.microsoft.com ([213.199.128.139]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FVuRi-0005MA-7E; Tue, 18 Apr 2006 13:57:04 -0400 Received: from EUR-MSG-11.europe.corp.microsoft.com ([65.53.193.197]) by mail-eur1.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 18 Apr 2006 18:57:01 +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 Subject: RE: [TLS] Re: Comments on draft-santesson-tls-ume-04/draft-santesson-tls-supp-00 Date: Tue, 18 Apr 2006 18:56:59 +0100 Message-ID: In-Reply-To: <7.0.0.16.2.20060417170510.03659fe0@vigilsec.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [TLS] Re: Comments on draft-santesson-tls-ume-04/draft-santesson-tls-supp-00 Thread-Index: AcZiczQV9pG2zD0PT2aJAtK7UKL6GgAnBGRQ From: "Stefan Santesson" To: "Russ Housley" , "Eric Rescorla" X-OriginalArrivalTime: 18 Apr 2006 17:57:01.0501 (UTC) FILETIME=[7E8706D0:01C66311] X-Spam-Score: 0.0 (/) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc Cc: iesg@ietf.org, tls@ietf.org 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org In, line; Stefan Santesson Program Manager, Standards Liaison Windows Security > -----Original Message----- > From: Russ Housley [mailto:housley@vigilsec.com] > Sent: den 17 april 2006 13:11 > To: Eric Rescorla > Cc: iesg@ietf.org; tls@ietf.org > Subject: [TLS] Re: Comments on draft-santesson-tls-ume-04/draft-santesson- > tls-supp-00 >=20 > Eric: >=20 > >These drafts seem basically sound. Minor comments below. > > > >-tls-supp: > >You should state that only one SupplementalData field may > >be used per handshake. >=20 > I agree. This was pointed out by the Gen-ART reviewer too. >=20 [Stefan] I've put this on my change log. To be precise in words, should the text state that "The client and server MUST NOT send more than one supplementalData handshake message each."? > >Somewhere you should note that this data SHOULD NOT be > >processed by TLS but just passed up to the application. >=20 > I agree. This was also raised by Cullen. >=20 [Stefan] On my change log > >-tls-ume: > >Why is this draft going to Proposed? ISTM that it's pretty > >hard to interpret without a bunch of MS-proprietary > >information. There's no need for it to go to Proposed, since > >both extensions and Supp-data allow code points to be > >issued via informational. >=20 > This is being discussed. The reason that I would like to see it as > standards-track is that the structure supports more than just > Microsoft names. The Microsoft names are simply the first ones that > are supported. >=20 [Stefan] A agree to the proposed path of the reason stated by Russ. I'm willing to tune down the mentioning of Microsoft as it isn't necessary for the syntax definitions of this document. > >S 4: > >You can do the UPN hint extension exchange and then NOT > >send supp_data? That seems wrong. >=20 > I agree, if the negotiation is successful, then the supplemental data > should be sent. >=20 [Stefan] I don't see much value in this direction as the server MUST be prepared for the case where the client chooses not to send any hint. It may have come to the conclusion that this is not the right server to send the hint it intended for some reason. Another reason may be that the user has declined sending his user name to this server in a user dialog box. I view sending of hints as completely voluntary at the discretion of the client. Even after extension exchange. > Russ >=20 >=20 > _______________________________________________ > TLS mailing list > TLS@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/tls _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Tue Apr 18 14:05:33 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FVuZw-0003hi-E7; Tue, 18 Apr 2006 14:05:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FVuZv-0003gH-Dg; Tue, 18 Apr 2006 14:05:31 -0400 Received: from raman.networkresonance.com ([198.144.196.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FVuZu-00061e-2n; Tue, 18 Apr 2006 14:05:31 -0400 Received: by raman.networkresonance.com (Postfix, from userid 1001) id BED901E8C1F; Tue, 18 Apr 2006 11:05:29 -0700 (PDT) To: "Stefan Santesson" Subject: Re: [TLS] Re: Comments on draft-santesson-tls-ume-04/draft-santesson-tls-supp-00 References: From: Eric Rescorla Date: Tue, 18 Apr 2006 11:05:29 -0700 In-Reply-To: (Stefan Santesson's message of "Tue, 18 Apr 2006 18:56:59 +0100") Message-ID: <861wvubvyu.fsf@raman.networkresonance.com> User-Agent: Gnus/5.1007 (Gnus v5.10.7) XEmacs/21.4.18 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Cc: iesg@ietf.org, tls@ietf.org X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: EKR List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org "Stefan Santesson" writes: >> Eric: >> >> >These drafts seem basically sound. Minor comments below. >> > >> >-tls-supp: >> >You should state that only one SupplementalData field may >> >be used per handshake. >> >> I agree. This was pointed out by the Gen-ART reviewer too. >> > > [Stefan] I've put this on my change log. To be precise in words, should > the text state that "The client and server MUST NOT send more than one > supplementalData handshake message each."? Yes, I think that's right. >> This is being discussed. The reason that I would like to see it as >> standards-track is that the structure supports more than just >> Microsoft names. The Microsoft names are simply the first ones that >> are supported. >> > [Stefan] A agree to the proposed path of the reason stated by Russ. I'm > willing to tune down the mentioning of Microsoft as it isn't necessary > for the syntax definitions of this document. That doesn't really resolve my issue, because it still results in incompletely specified semantics. >> >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 data >> should be sent. >> > [Stefan] I don't see much value in this direction as the server MUST be > prepared for the case where the client chooses not to send any hint. It > may have come to the conclusion that this is not the right server to > send the hint it intended for some reason. Another reason may be that > the user has declined sending his user name to this server in a user > dialog box. > > I view sending of hints as completely voluntary at the discretion of the > client. Even after extension exchange. Then that that needs to be stated clearly in the specification. -Ekr _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Tue Apr 18 14:07:28 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FVubk-000451-JP; Tue, 18 Apr 2006 14:07:24 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FVubj-00044k-P9; Tue, 18 Apr 2006 14:07:23 -0400 Received: from mail-eur.microsoft.com ([213.199.128.145]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FVubh-0006Az-Dx; Tue, 18 Apr 2006 14:07:23 -0400 Received: from EUR-MSG-11.europe.corp.microsoft.com ([65.53.193.197]) by mail-eur.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 18 Apr 2006 19:07:16 +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 Subject: RE: [TLS] Re: Comments ondraft-santesson-tls-ume-04/draft-santesson-tls-supp-00 Date: Tue, 18 Apr 2006 19:07:11 +0100 Message-ID: In-Reply-To: <20060417231559.1B82B222418@laser.networkresonance.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [TLS] Re: Comments ondraft-santesson-tls-ume-04/draft-santesson-tls-supp-00 Thread-Index: AcZidAnbmQ8mvRlkQ/SN5fpLmrXUcgAnZMaA From: "Stefan Santesson" To: "Eric Rescorla" , "Russ Housley" X-OriginalArrivalTime: 18 Apr 2006 18:07:16.0912 (UTC) FILETIME=[ED574B00:01C66312] X-Spam-Score: 0.0 (/) X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d Cc: iesg@ietf.org, tls@ietf.org 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org In line; Stefan Santesson Program Manager, Standards Liaison Windows Security > -----Original Message----- > From: Eric Rescorla [mailto:ekr@networkresonance.com] > Sent: den 17 april 2006 15:10 > To: Russ Housley > Cc: iesg@ietf.org; tls@ietf.org > Subject: [TLS] Re: Comments ondraft-santesson-tls-ume-04/draft-santesson- > tls-supp-00 >=20 > Russ Housley wrote: > > >-tls-ume: > > >Why is this draft going to Proposed? ISTM that it's pretty > > >hard to interpret without a bunch of MS-proprietary > > >information. There's no need for it to go to Proposed, since > > >both extensions and Supp-data allow code points to be > > >issued via informational. > > > > This is being discussed. The reason that I would like to see it as > > standards-track is that the structure supports more than just > > Microsoft names. The Microsoft names are simply the first ones that > > are supported. >=20 > I'm sympathetic to this, but I'm also uncomfortable with having a PS > that's not really implementable in part. That said, this is probably > part of a higher level IETF/IESG policy discussion rather than > a TLS one. >=20 [Stefan] What part is not implementable? If you are referring to the fact that normalization of the user name part of the UPN hint is not fully defined, that does not make this specification un-implementable. Anny client/server based system that currently is using TLS for user authentication must have an understanding of how names they use to access accounts are formed. This standard makes it possible for them to send that username in that form. If we enforce specific character normalization on the user name then they may not be able to use this standard anymore as it may conflict with how they encode usernames. Many standards define fields that higher level protocols and apps can use in multiple ways. That does not make those standards un-implementable. It's just a limitation of scope. >=20 > > >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 data > > should be sent. >=20 > 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. >=20 [Stefan] No, this is not an error. Se other response. > Best, > -Ekr >=20 >=20 > _______________________________________________ > TLS mailing list > TLS@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/tls _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Tue Apr 18 14:11:47 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FVufp-0005H7-Nu; Tue, 18 Apr 2006 14:11:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FVufo-0005GZ-Sz; Tue, 18 Apr 2006 14:11:36 -0400 Received: from mail-eur.microsoft.com ([213.199.128.145]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FVufn-0006W4-JV; Tue, 18 Apr 2006 14:11:36 -0400 Received: from EUR-MSG-11.europe.corp.microsoft.com ([65.53.193.197]) by mail-eur.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 18 Apr 2006 19:11:35 +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 Subject: RE: [TLS] Re: Comments on draft-santesson-tls-ume-04/draft-santesson-tls-supp-00 Date: Tue, 18 Apr 2006 19:11:04 +0100 Message-ID: In-Reply-To: <861wvubvyu.fsf@raman.networkresonance.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [TLS] Re: Comments on draft-santesson-tls-ume-04/draft-santesson-tls-supp-00 Thread-Index: AcZjErdJSi0PQ+xGSJ+OXmLE2I2QWgAAHX9g From: "Stefan Santesson" To: "EKR" X-OriginalArrivalTime: 18 Apr 2006 18:11:35.0020 (UTC) FILETIME=[872F72C0:01C66313] X-Spam-Score: 0.0 (/) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 Cc: iesg@ietf.org, tls@ietf.org 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org Eric, On last issue, I will add that explanation to my change log. Stefan Santesson Program Manager, Standards Liaison Windows Security > -----Original Message----- > From: Eric Rescorla [mailto:ekr@raman.networkresonance.com] > Sent: den 18 april 2006 10:05 > To: Stefan Santesson > Cc: Russ Housley; iesg@ietf.org; tls@ietf.org > Subject: Re: [TLS] Re: Comments on draft-santesson-tls-ume-04/draft- > santesson-tls-supp-00 >=20 > "Stefan Santesson" writes: >=20 > >> Eric: > >> > >> >These drafts seem basically sound. Minor comments below. > >> > > >> >-tls-supp: > >> >You should state that only one SupplementalData field may > >> >be used per handshake. > >> > >> I agree. This was pointed out by the Gen-ART reviewer too. > >> > > > > [Stefan] I've put this on my change log. To be precise in words, should > > the text state that "The client and server MUST NOT send more than one > > supplementalData handshake message each."? >=20 > Yes, I think that's right. >=20 >=20 > >> This is being discussed. The reason that I would like to see it as > >> standards-track is that the structure supports more than just > >> Microsoft names. The Microsoft names are simply the first ones that > >> are supported. > >> > > [Stefan] A agree to the proposed path of the reason stated by Russ. I'm > > willing to tune down the mentioning of Microsoft as it isn't necessary > > for the syntax definitions of this document. >=20 > That doesn't really resolve my issue, because it still results in > incompletely specified semantics. >=20 >=20 > >> >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 data > >> should be sent. > >> > > [Stefan] I don't see much value in this direction as the server MUST be > > prepared for the case where the client chooses not to send any hint. It > > may have come to the conclusion that this is not the right server to > > send the hint it intended for some reason. Another reason may be that > > the user has declined sending his user name to this server in a user > > dialog box. > > > > I view sending of hints as completely voluntary at the discretion of the > > client. Even after extension exchange. >=20 > Then that that needs to be stated clearly in the specification. >=20 > -Ekr >=20 >=20 >=20 _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Tue Apr 18 14:24:54 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FVusd-0008SR-VJ; Tue, 18 Apr 2006 14:24:51 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FVusc-0008SJ-LS; Tue, 18 Apr 2006 14:24:50 -0400 Received: from raman.networkresonance.com ([198.144.196.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FVusb-0007E1-9q; Tue, 18 Apr 2006 14:24:50 -0400 Received: by raman.networkresonance.com (Postfix, from userid 1001) id DA41C1E8C1F; Tue, 18 Apr 2006 11:24:48 -0700 (PDT) To: "Stefan Santesson" Subject: Re: [TLS] Re: Comments ondraft-santesson-tls-ume-04/draft-santesson-tls-supp-00 References: From: Eric Rescorla Date: Tue, 18 Apr 2006 11:24:48 -0700 In-Reply-To: (Stefan Santesson's message of "Tue, 18 Apr 2006 19:07:11 +0100") Message-ID: <86wtdmagi7.fsf@raman.networkresonance.com> User-Agent: Gnus/5.1007 (Gnus v5.10.7) XEmacs/21.4.18 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Cc: iesg@ietf.org, tls@ietf.org X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: EKR List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org "Stefan Santesson" writes: >> >> Russ Housley wrote: >> > >-tls-ume: >> > >Why is this draft going to Proposed? ISTM that it's pretty >> > >hard to interpret without a bunch of MS-proprietary >> > >information. There's no need for it to go to Proposed, since >> > >both extensions and Supp-data allow code points to be >> > >issued via informational. >> > >> > This is being discussed. The reason that I would like to see it as >> > standards-track is that the structure supports more than just >> > Microsoft names. The Microsoft names are simply the first ones that >> > are supported. >> >> I'm sympathetic to this, but I'm also uncomfortable with having a PS >> that's not really implementable in part. That said, this is probably >> part of a higher level IETF/IESG policy discussion rather than >> a TLS one. >> > > [Stefan] What part is not implementable? If you are referring to the > fact that normalization of the user name part of the UPN hint is not > fully defined, that does not make this specification un-implementable. > > Anny client/server based system that currently is using TLS for user > authentication must have an understanding of how names they use to > access accounts are formed. This standard makes it possible for them to > send that username in that form. If we enforce specific character > normalization on the user name then they may not be able to use this > standard anymore as it may conflict with how they encode usernames. > > Many standards define fields that higher level protocols and apps can > use in multiple ways. That does not make those standards > un-implementable. It's just a limitation of scope. I'm not talking about the normalization issue, primarily. I'm talking about the fact that the UPN part of the specification is incompletely specified. See, for instance my comments about how the client knows the domain should get the UPN data. For that matter, the procedure for determining whether the UPN maps to any given certificate is unspecified. The first issue in particular makes it very unlikely that one could interoperably implement this feature in a reasonable kind of way. -Ekr _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Tue Apr 18 14:41:16 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FVv8R-00041U-Ru; Tue, 18 Apr 2006 14:41:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FVv8Q-00041D-VD; Tue, 18 Apr 2006 14:41:10 -0400 Received: from mail-eur1.microsoft.com ([213.199.128.139]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FVv8Q-00089y-Kv; Tue, 18 Apr 2006 14:41:10 -0400 Received: from EUR-MSG-11.europe.corp.microsoft.com ([65.53.193.197]) by mail-eur1.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 18 Apr 2006 19:41:09 +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 Subject: RE: [TLS] Re: Comments ondraft-santesson-tls-ume-04/draft-santesson-tls-supp-00 Date: Tue, 18 Apr 2006 19:40:53 +0100 Message-ID: In-Reply-To: <86wtdmagi7.fsf@raman.networkresonance.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [TLS] Re: Comments ondraft-santesson-tls-ume-04/draft-santesson-tls-supp-00 Thread-Index: AcZjFWWurllNEjq/TPyS6MseVC7DIAAAC4yw From: "Stefan Santesson" To: "EKR" X-OriginalArrivalTime: 18 Apr 2006 18:41:09.0810 (UTC) FILETIME=[A90AE920:01C66317] X-Spam-Score: 0.0 (/) X-Scan-Signature: cf3becbbd6d1a45acbe2ffd4ab88bdc2 Cc: iesg@ietf.org, tls@ietf.org 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org Eric, It seems that we have a misunderstanding (or disagreement?) on the scope of this document. It is not intended to specify the UPN of Active Directory or how user account names in Active Directory are obtained. It neither intends to specify how any server environment should map this hint to any account. The scope of this document is to specify a _generic_ protocol syntax for exchanging hints. In addition to this the document specifies one specific hint type that may be used to send over a domain hint or a user@domain hint. Other hint types may be defined in future standards. Any references to use in a Microsoft environment should only be viewed as implementation examples. I've said before that I'm willing to change the name (not using "UPN" at all as variable name), keeping the same syntax, if that helps clarifying this. As a natural follow up I would certainly consider writing an informational document specifying the exact encoding and matching rules for a Microsoft UPN. But that would be a separate effort and obviously Informational. Stefan Santesson Program Manager, Standards Liaison Windows Security > -----Original Message----- > From: Eric Rescorla [mailto:ekr@raman.networkresonance.com] > Sent: den 18 april 2006 11:25 > To: Stefan Santesson > Cc: Russ Housley; iesg@ietf.org; tls@ietf.org > Subject: Re: [TLS] Re: Comments ondraft-santesson-tls-ume-04/draft- > santesson-tls-supp-00 >=20 > "Stefan Santesson" writes: >=20 > >> > >> Russ Housley wrote: > >> > >-tls-ume: > >> > >Why is this draft going to Proposed? ISTM that it's pretty > >> > >hard to interpret without a bunch of MS-proprietary > >> > >information. There's no need for it to go to Proposed, since > >> > >both extensions and Supp-data allow code points to be > >> > >issued via informational. > >> > > >> > This is being discussed. The reason that I would like to see it as > >> > standards-track is that the structure supports more than just > >> > Microsoft names. The Microsoft names are simply the first ones that > >> > are supported. > >> > >> I'm sympathetic to this, but I'm also uncomfortable with having a PS > >> that's not really implementable in part. That said, this is probably > >> part of a higher level IETF/IESG policy discussion rather than > >> a TLS one. > >> > > > > [Stefan] What part is not implementable? If you are referring to the > > fact that normalization of the user name part of the UPN hint is not > > fully defined, that does not make this specification un-implementable. > > > > Anny client/server based system that currently is using TLS for user > > authentication must have an understanding of how names they use to > > access accounts are formed. This standard makes it possible for them to > > send that username in that form. If we enforce specific character > > normalization on the user name then they may not be able to use this > > standard anymore as it may conflict with how they encode usernames. > > > > Many standards define fields that higher level protocols and apps can > > use in multiple ways. That does not make those standards > > un-implementable. It's just a limitation of scope. >=20 > I'm not talking about the normalization issue, primarily. I'm talking > about the fact that the UPN part of the specification is incompletely > specified. See, for instance my comments about how the client knows > the domain should get the UPN data. For that matter, the procedure > for determining whether the UPN maps to any given certificate is > unspecified. The first issue in particular makes it very unlikely > that one could interoperably implement this feature in a reasonable > kind of way. >=20 > -Ekr _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Tue Apr 18 14:47:16 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FVvEJ-0005wJ-Av; Tue, 18 Apr 2006 14:47:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FVvEI-0005wA-0K; Tue, 18 Apr 2006 14:47:14 -0400 Received: from raman.networkresonance.com ([198.144.196.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FVvEH-0008Gm-Mu; Tue, 18 Apr 2006 14:47:13 -0400 Received: by raman.networkresonance.com (Postfix, from userid 1001) id 0501D1E8C1F; Tue, 18 Apr 2006 11:47:12 -0700 (PDT) To: "Stefan Santesson" Subject: Re: [TLS] Re: Comments ondraft-santesson-tls-ume-04/draft-santesson-tls-supp-00 References: From: Eric Rescorla Date: Tue, 18 Apr 2006 11:47:12 -0700 In-Reply-To: (Stefan Santesson's message of "Tue, 18 Apr 2006 19:40:53 +0100") Message-ID: <86r73uafgv.fsf@raman.networkresonance.com> User-Agent: Gnus/5.1007 (Gnus v5.10.7) XEmacs/21.4.18 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Cc: iesg@ietf.org, tls@ietf.org X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: EKR List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org "Stefan Santesson" writes: > Eric, > > It seems that we have a misunderstanding (or disagreement?) on the scope > of this document. > > It is not intended to specify the UPN of Active Directory or how user > account names in Active Directory are obtained. > > It neither intends to specify how any server environment should map this > hint to any account. > > The scope of this document is to specify a _generic_ protocol syntax for > exchanging hints. In addition to this the document specifies one > specific hint type that may be used to send over a domain hint or a > user@domain hint. > Other hint types may be defined in future standards. > > Any references to use in a Microsoft environment should only be viewed > as implementation examples. > > I've said before that I'm willing to change the name (not using "UPN" at > all as variable name), keeping the same syntax, if that helps clarifying > this. The problem is that without specifying the semantics, this document just creates an opaque hole that isn't really implementable in an interoperable way, for the reasons I indicated. -Ekr _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Tue Apr 18 14:53:37 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FVvKL-0007Ns-Il; Tue, 18 Apr 2006 14:53:29 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FVvKK-0007Nb-9v; Tue, 18 Apr 2006 14:53:28 -0400 Received: from mail-eur1.microsoft.com ([213.199.128.139]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FVvKK-0008Nx-0N; Tue, 18 Apr 2006 14:53:28 -0400 Received: from EUR-MSG-11.europe.corp.microsoft.com ([65.53.193.197]) by mail-eur1.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 18 Apr 2006 19:53:27 +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 Subject: RE: [TLS] Re: Comments ondraft-santesson-tls-ume-04/draft-santesson-tls-supp-00 Date: Tue, 18 Apr 2006 19:53:25 +0100 Message-ID: In-Reply-To: <86wtdmagi7.fsf@raman.networkresonance.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [TLS] Re: Comments ondraft-santesson-tls-ume-04/draft-santesson-tls-supp-00 Thread-Index: AcZjFWWurllNEjq/TPyS6MseVC7DIAAA7Q+Q From: "Stefan Santesson" To: "EKR" X-OriginalArrivalTime: 18 Apr 2006 18:53:27.0452 (UTC) FILETIME=[60B625C0:01C66319] X-Spam-Score: 0.0 (/) X-Scan-Signature: 25620135586de10c627e3628c432b04a Cc: iesg@ietf.org, tls@ietf.org 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org Eric, Just adding that I already have agreed to make changes to the introduction to clarify the scope. Stefan Santesson Program Manager, Standards Liaison Windows Security > -----Original Message----- > From: Eric Rescorla [mailto:ekr@raman.networkresonance.com] > Sent: den 18 april 2006 11:25 > To: Stefan Santesson > Cc: Russ Housley; iesg@ietf.org; tls@ietf.org > Subject: Re: [TLS] Re: Comments ondraft-santesson-tls-ume-04/draft- > santesson-tls-supp-00 >=20 > "Stefan Santesson" writes: >=20 > >> > >> Russ Housley wrote: > >> > >-tls-ume: > >> > >Why is this draft going to Proposed? ISTM that it's pretty > >> > >hard to interpret without a bunch of MS-proprietary > >> > >information. There's no need for it to go to Proposed, since > >> > >both extensions and Supp-data allow code points to be > >> > >issued via informational. > >> > > >> > This is being discussed. The reason that I would like to see it as > >> > standards-track is that the structure supports more than just > >> > Microsoft names. The Microsoft names are simply the first ones that > >> > are supported. > >> > >> I'm sympathetic to this, but I'm also uncomfortable with having a PS > >> that's not really implementable in part. That said, this is probably > >> part of a higher level IETF/IESG policy discussion rather than > >> a TLS one. > >> > > > > [Stefan] What part is not implementable? If you are referring to the > > fact that normalization of the user name part of the UPN hint is not > > fully defined, that does not make this specification un-implementable. > > > > Anny client/server based system that currently is using TLS for user > > authentication must have an understanding of how names they use to > > access accounts are formed. This standard makes it possible for them to > > send that username in that form. If we enforce specific character > > normalization on the user name then they may not be able to use this > > standard anymore as it may conflict with how they encode usernames. > > > > Many standards define fields that higher level protocols and apps can > > use in multiple ways. That does not make those standards > > un-implementable. It's just a limitation of scope. >=20 > I'm not talking about the normalization issue, primarily. I'm talking > about the fact that the UPN part of the specification is incompletely > specified. See, for instance my comments about how the client knows > the domain should get the UPN data. For that matter, the procedure > for determining whether the UPN maps to any given certificate is > unspecified. The first issue in particular makes it very unlikely > that one could interoperably implement this feature in a reasonable > kind of way. >=20 > -Ekr _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Tue Apr 18 19:24:54 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FVzYs-00066x-1J; Tue, 18 Apr 2006 19:24:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FVzYq-00066U-Oy for tls@ietf.org; Tue, 18 Apr 2006 19:24:44 -0400 Received: from woodstock.binhost.com ([144.202.243.4]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FVzYo-0005gJ-G0 for tls@ietf.org; Tue, 18 Apr 2006 19:24:44 -0400 Received: (qmail 29504 invoked by uid 0); 18 Apr 2006 23:24:32 -0000 Received: from unknown (HELO THINKPADR52.vigilsec.com) (71.246.201.196) by woodstock.binhost.com with SMTP; 18 Apr 2006 23:24:32 -0000 Message-Id: <7.0.0.16.2.20060418154653.05a4ddf8@vigilsec.com> X-Mailer: QUALCOMM Windows Eudora Version 7.0.0.16 Date: Tue, 18 Apr 2006 15:49:58 -0400 To: Eric Rescorla From: Russ Housley In-Reply-To: <20060417231559.1B82B222418@laser.networkresonance.com> References: <20060417231559.1B82B222418@laser.networkresonance.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.1 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org 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 data > > 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 TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Tue Apr 18 19:33:01 2006 Received: from [127.0.0.1] (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 [10.91.34.44] (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 ([213.199.128.139]) 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 ([65.53.193.197]) 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: In-Reply-To: <7.0.0.16.2.20060418154653.05a4ddf8@vigilsec.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Comments on draft-santesson-tls-ume-04/draft-santesson-tls-supp-00 Thread-Index: AcZjP0oOrzf6gkLXReaRGULPAmLD6wAAIvhQ From: "Stefan Santesson" To: "Russ Housley" , "Eric Rescorla" 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 alert. 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 draft-santesson-tls-ume-04/draft-santesson-tls- > supp-00 >=20 > Eric: >=20 > > > >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 data > > > 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. >=20 > 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? >=20 > Russ >=20 _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Thu Apr 20 16:24:53 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FWfha-00059R-SO; Thu, 20 Apr 2006 16:24:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FWfhZ-00059M-1x for tls@ietf.org; Thu, 20 Apr 2006 16:24:33 -0400 Received: from dyn50.sunlabs.com ([204.153.12.50] helo=mail-mta.sunlabs.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FWfhX-0004Ok-OI for tls@ietf.org; Thu, 20 Apr 2006 16:24:33 -0400 Received: from mail.sunlabs.com ([152.70.2.186]) by dps.sfvic.sunlabs.com (Sun Java System Messaging Server 6.1 HotFix 0.02 (built Aug 25 2004)) with ESMTP id <0IY1003ZTFCVXW00@dps.sfvic.sunlabs.com> for tls@ietf.org; Thu, 20 Apr 2006 13:24:31 -0700 (PDT) Received: from [129.146.73.44] by mail.sunlabs.com (Sun Java System Messaging Server 6.1 HotFix 0.02 (built Aug 25 2004)) with ESMTPSA id <0IY100JIIFCUP9F1@mail.sunlabs.com> for tls@ietf.org; Thu, 20 Apr 2006 13:24:30 -0700 (PDT) Date: Thu, 20 Apr 2006 13:24:34 -0700 From: Vipul Gupta In-reply-to: <1FAE0E59-8FA0-4691-B9CC-6D22B31D5F7F@sun.com> To: tls mailing list Message-id: <73CF5496-1BDF-4E22-B432-5266773C139E@sun.com> MIME-version: 1.0 X-Mailer: Apple Mail (2.749.3) Content-type: text/plain; charset=US-ASCII; format=flowed Content-transfer-encoding: 7BIT References: <1FAE0E59-8FA0-4691-B9CC-6D22B31D5F7F@sun.com> X-Spam-Score: 0.5 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Cc: Vipul Gupta Subject: [TLS] Re: ECC Interoperability Forum 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org A web-site listing publicly available TLS/ECC interoperability resources (e.g. clients/servers implementing the spec) can be accessed at: http://dev.experimentalstuff.com:8082/ vipul On Mar 28, 2006, at 5:16 PM, Vipul Gupta wrote: > > I'd like to announce the availability of a new > mailing list specifically targeted at implementors > of the "ECC Cipher Suites in TLS" specification. > Current participants include representatives from > Microsoft, OpenSSL, Redhat, and Sun. If you have > an implementation you'd like to test for > interoperability, please send me email. > > thanks, > > vipul > > -- > Vipul Gupta, Ph.D. > Sun Microsystems Laboratories > 16 Network Circle, MS UMPK16-160 > Menlo Park, CA 94025 (USA) > Ph: 650 786 7551 > Fax: 650 786 6013 > _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Fri Apr 28 08:48:49 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FZSOd-0005l1-40; Fri, 28 Apr 2006 08:48:31 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FZSOb-0005kw-6f for tls@ietf.org; Fri, 28 Apr 2006 08:48:29 -0400 Received: from moutng.kundenserver.de ([212.227.126.171]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FZSOZ-00085w-Oi for tls@ietf.org; Fri, 28 Apr 2006 08:48:29 -0400 Received: from [134.147.40.237] (helo=tau.invalid) by mrelayeu.kundenserver.de (node=mrelayeu9) with ESMTP (Nemesis), id 0ML2xA-1FZSOW2ycC-0000g5; Fri, 28 Apr 2006 14:48:25 +0200 Received: by tau.invalid (Postfix, from userid 1000) id 2F0591831D; Fri, 28 Apr 2006 14:48:24 +0200 (CEST) Date: Fri, 28 Apr 2006 14:48:24 +0200 From: Bodo Moeller To: tls@ietf.org Message-ID: <20060428124823.GA15494@iota.site> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.9i X-Provags-ID: kundenserver.de abuse@kundenserver.de login:2100a517a32aea841b51dac1f7c5a318 X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Cc: Subject: [TLS] New RFCs: TLS 1.1 (RFC4346) and TLS Extensions (RFC4366) 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org FYI, since the official announcements to this list apparently were sacrificied for the fight against spam -- RFC 4346, "The Transport Layer Security (TLS) Protocol Version 1.1", has become available a couple of days ago: http://www1.ietf.org/mail-archive/web/ietf-announce/current/msg02442.html http://www.rfc-editor.org/rfc/rfc4346.txt Also, RFC 4366, "Transport Layer Security (TLS) Extensions" (the successor of RFC 3546) is now available: http://www1.ietf.org/mail-archive/web/ietf-announce/current/msg02448.html http://www.rfc-editor.org/rfc/rfc4366.txt _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Fri Apr 28 08:53:15 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FZST9-0008Ez-HX; Fri, 28 Apr 2006 08:53:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FZST8-0008EQ-JW for tls@ietf.org; Fri, 28 Apr 2006 08:53:10 -0400 Received: from moutng.kundenserver.de ([212.227.126.188]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FZST7-0008Bg-6t for tls@ietf.org; Fri, 28 Apr 2006 08:53:10 -0400 Received: from [134.147.40.237] (helo=tau.invalid) by mrelayeu.kundenserver.de (node=mrelayeu2) with ESMTP (Nemesis), id 0MKwtQ-1FZST53PGO-0001oy; Fri, 28 Apr 2006 14:53:08 +0200 Received: by tau.invalid (Postfix, from userid 1000) id 306301831D; Fri, 28 Apr 2006 14:53:07 +0200 (CEST) Date: Fri, 28 Apr 2006 14:53:07 +0200 From: Bodo Moeller To: tls@ietf.org Subject: Re: [TLS] New RFCs: TLS 1.1 (RFC4346) and TLS Extensions (RFC4366) Message-ID: <20060428125307.GA15851@iota.site> References: <20060428124823.GA15494@iota.site> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060428124823.GA15494@iota.site> User-Agent: Mutt/1.5.9i X-Provags-ID: kundenserver.de abuse@kundenserver.de login:2100a517a32aea841b51dac1f7c5a318 X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org On Fri, Apr 28, 2006 at 02:48:24PM +0200, Bodo Moeller wrote: > RFC 4346, "The Transport Layer Security (TLS) Protocol Version 1.1", > has become available a couple of days ago: > > http://www1.ietf.org/mail-archive/web/ietf-announce/current/msg02442.html > http://www.rfc-editor.org/rfc/rfc4346.txt > Also, RFC 4366, "Transport Layer Security (TLS) Extensions" (the > successor of RFC 3546) is now available: > > http://www1.ietf.org/mail-archive/web/ietf-announce/current/msg02448.html > http://www.rfc-editor.org/rfc/rfc4366.txt Also, there's now RFC 4347 on DTLS: http://www1.ietf.org/mail-archive/web/ietf-announce/current/msg02443.html http://www.rfc-editor.org/rfc/rfc4347.txt _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls