Re: Last Call: draft-saintandre-tls-server-id-check (Representation and Verification of Domain-Based Application Service Identity in Certificates Used with Transport Layer Security) to Proposed Standa
--On Thursday, July 15, 2010 16:08 -0700 The IESG iesg-secret...@ietf.org wrote: The IESG has received a request from an individual submitter to consider the following document: - 'Representation and Verification of Domain-Based Application Service Identity in Certificates Used with Transport Layer Security 'draft-saintandre-tls-server-id-check-08.txt as a Proposed Standard Hi. These are sort of nits, but they do identify areas where the document is substantively incorrect and subject to misinterpretation: (1) In Section 4.4.1, the reference should be to the IDNA2008 discussion. The explanations are a little better vis-a-vis the DNS specs and it is a bad idea to reference an obsolete spec. (2) In Section 4.4.2, note that there are definitional and procedural problems if one tries to talk about a single rule for full domain names. It is possible, and has been the only option until very recently, for a fully-qualified IDN to contain both traditional and internationalized labels. IDNA2008 avoided a number of definitional problems by being defined strictly in terms of labels for just that reason. In particular, conversion of an all-ASCII label to an A-label is undefined and meaningless: such a label is not a U-label and hence cannot be converted. One needs to parse the string into labels, determine for each label whether it is traditional or internationalized, and then apply the appropriate rule. I'd recommend rewriting 4.4.1 and 4.4.2 in terms of labels, not FQDNs. (3) Note that anything that requires that an application program parse a FQDN that might be an IDN into labels should probably have a Security Considerations note about the risks if various dotoids leak into the relevant environment. best, john ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Historic Moment - Root zone of the Internet was just signed minutes ago!!!
On Fri, 16 Jul 2010, Tony Finch wrote:
unbound requires trust anchors in DS format which is somewhat more
convenient, though you still have to edit IANA's XML to convert it into
master file format.
You can also use DNSKEY statements in unbound:
~ grep trusted-keys /etc/unbound/unbound.conf
trusted-keys-file: /etc/pki/dnssec-keys/production/root.conf
~ cat /etc/pki/dnssec-keys/production/root.conf
trusted-keys {
. 257 3 8
AwEAAagAIKlVZrpC6Ia7gEzahOR+9W29euxhJhVVLOyQbSEW0O8gcCjFFVQUTf6v58fLjwBd0YI0EzrAcQqBGCzh/RStIoO8g0NfnfL2MTJRkxoXbfDaUeVPQuYEhg37NZWAJQ9VnMVDxP/VHL496M/QZxkjf5/Efucp2gaDX6RS6CXpoY68LsvPVjR0ZSwzz1apAzvN9dlzEheX7ICJBBtuA6G3LQpzW5hOA2hzCTMjJPJ8LbqF6dsV6DoBQzgul0sGIcGOYl7OyQdXfZ57relSQageu+ipAdTTJ25AsRTAoub8ONGcLmqrAmRLKBP1dfwhYB4N7knNnulqQxA+Uk1ihz0=;
// key id = 19036
};
Paul
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
Re: TSV-DIR review of draft-daboo-srv-caldav-05
Hi, Cyrus, On 7/16/2010 6:11 PM, Cyrus Daboo wrote: Hi Joe, --On July 16, 2010 2:55:42 PM -0700 Joe Touch to...@isi.edu wrote: 1) the document contains a section discussing the registration of caldev and caldevs (Sec 3); a corresponding section for carddev and carddevs should be added. As noted in the fourth paragraph of the introduction, the CardDAV service types have been defined in [I-D.ietf-vcarddav-carddav] currently in the RFC Editor queue. The information from section 11 of that draft should be repeated in summary in this one, e.g., in Sec. 3. Note that ietf-vcarddav-carddav does not request that the carddev/carddevs strings be added to the SRV registry. 2) the IANA recommendation that these four service names be added as aliases to http and https (correspondingly) does not seem correct. If these are indeed aliases, then this specification should recommend the use of either http or https (correspondingly) in the SRV records, without the need for new names. However, I believe the intent is that the caldev and/or carddev servers could exist on other ports than the typical web server; as such, they should be registered as service names (as per the existing SRV registry, e.g.), NOT as aliases in either the SRV registry (which has no such concept) or the IANA ports table. I.e., these new names should be registered as service names, not as aliases. This should be sufficient for the purposes of this document. In [I-D.ietf-vcarddav-carddav], after much debate with the IESG and the associated working group, the approach of registering the service types as aliases was agreed upon as a stop gap measure until the IANA SRV registry is setup. draft-daboo-srv-caldav follows that same approach. The SRV registry exists even in advance of IANA's management thereof. Further, aliases have no meaning in the SRV registry - they are meaningful only in the IANA ports registry, and only insofar as multiple strings are assigned the same port number. No such port number assignment is requested or appropriate here (they aren't needed for SRV records per se). One exception would be if you *also* intend that these strings serve as aliases to the well-known ports 80 and 443, respectively. However, this document does NOT define an alias for either of those ports. An alias would be an equivalent name which can be substituted without impact. Here, were you to use http or www instead of caldev or carddev, you should presumably not be using the /caldev or /carddev URI suffixes. I would be glad to discuss this further wiht the IESG or WG if needed. 3) The use of a required URI suffix (/carddev or /caldev) seems to be too fixed. draft-cheshire-dnsext-dns-sd (intended as standards track) indicates a way to embed this information in the a TXT record with the same DNS name as the SRV record; RFC 5507 represents the IAB (informational) position that most additional information should be included in new RR types (though it's unclear this could easily support URI suffixes). My concern is that this document does neither; it embeds this information in this document as a requirement, rather than presenting it as a configurable option with a default. I would prefer to see the latter (regardless of how), to indicate the URI suffix if not the 'default' as specified in this document. RFC5785 defines the .well-known URI - I think it is very clear that, given that CalDAV and CardDAV are in effect web-services, making use of .well-known is the right thing to do. There is no need for any additional data in the DNS. What is more, the .well-known approach is in fact useful in the absence of SRV - it can minimise the information users would have to enter. I don't see this approach as being too fixed - the whole point about .well-known is to fix things like this. This doc seeks to escape the fixed allocations of the static IANA ports table by using SRV records to locate resources dynamically. However, this doc also refers back to a different but equally fixed .well-known URI table without a similar SRV-like dynamic escape mechanism. This isn't a fix; this is creating a stop-gap, and having a dynamic SRV registry refer back to a fixed table undermines the whole point of SRV records AFAICT. Joe ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-saintandre-tls-server-id-check (Representation and Verification of Domain-Based Application Service Identity in Certificates Used with Transport Layer Security) to Proposed Stan
At 5:22 AM -0400 7/17/10, John C Klensin wrote: (1) In Section 4.4.1, the reference should be to the IDNA2008 discussion. The explanations are a little better vis-a-vis the DNS specs and it is a bad idea to reference an obsolete spec. +1. I accept blame on this one, since I was tasked on an earlier version to bring the IDNA discussion up to date. (2) In Section 4.4.2, note that there are definitional and procedural problems if one tries to talk about a single rule for full domain names. It is possible, and has been the only option until very recently, for a fully-qualified IDN to contain both traditional and internationalized labels. IDNA2008 avoided a number of definitional problems by being defined strictly in terms of labels for just that reason. In particular, conversion of an all-ASCII label to an A-label is undefined and meaningless: such a label is not a U-label and hence cannot be converted. One needs to parse the string into labels, determine for each label whether it is traditional or internationalized, and then apply the appropriate rule. I'd recommend rewriting 4.4.1 and 4.4.2 in terms of labels, not FQDNs. Here we (may) disagree. 4.4.2 is already in terms of labels: If the source domain of a reference identifier is an internationalized domain name, then an implementation MUST convert every label in the domain name to an A-label before checking the domain anme. Are you saying that the correct wording should elide If the source domain of a reference identifier is an internationalized domain name, then and just start at An implementation MUST? That would work for me. (3) Note that anything that requires that an application program parse a FQDN that might be an IDN into labels should probably have a Security Considerations note about the risks if various dotoids leak into the relevant environment. E, why should this document be forced to have such a warning when the IDNA2008 documents don't? --Paul Hoffman, Director --VPN Consortium ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Nomcom Enhancements: Improving the IETF leadership selection process
Folks, Nomcom has been an integral part of the IETF for nearly 20 years. A number of us have been developing a set of recommendations designed to adapt the Nomcom process to better match current realities of the IETF community. The draft has progressed far enough to call for public consideration. Some of the proposal's recommendations require no changes in formal rules. They can be adopted immediately, possibly by the current Nomcom, should it so choose. Others require a formal development and approval cycle. At: http://www.bbiw.net/recent.html#nomcom2010 there is a copy of the Full Proposal, and a Summary which primarily contains just the recommendations. The proposal's Abstract is: Every year the IETF's Nominating Committee (Nomcom) reviews and selects half of the IETF's leadership on the IESG, IAB and IAOC/Trust. In the 18 years since the inception of the Nomcom process, the Internet industry and the IETF have gone through many changes in funding, participation and focus, but not in the basic formation, structure or operation of Nomcom. This paper explores challenges that have emerged in the conduct of Nomcom activities, particularly due to changing IETF demographics. The paper reviews the nature, causes and consequences of these challenges, and proposes a number of specific changes. The changes provide better communication of Nomcom institutional memory, enhance Nomcom membership expertise, and produce stronger confidentiality and etiquette practices among Nomcom participants. Some changes require formal modification to Nomcom rules; others can be adopted immediately. Please feel free to discuss the proposal with any of the authors or folks listed in the Acknowledgments section, or on this list. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: TSV-DIR review of draft-daboo-srv-caldav-05
Hi Joe, --On July 17, 2010 8:19:13 AM -0700 Joe Touch to...@isi.edu wrote: As noted in the fourth paragraph of the introduction, the CardDAV service types have been defined in [I-D.ietf-vcarddav-carddav] currently in the RFC Editor queue. The information from section 11 of that draft should be repeated in summary in this one, e.g., in Sec. 3. Note that ietf-vcarddav-carddav does not request that the carddev/carddevs strings be added to the SRV registry. There is supposed to be an RFCEditor note covering the change. 2) the IANA recommendation that these four service names be added as aliases to http and https (correspondingly) does not seem correct. If these are indeed aliases, then this specification should recommend the use of either http or https (correspondingly) in the SRV records, without the need for new names. However, I believe the intent is that the caldev and/or carddev servers could exist on other ports than the typical web server; as such, they should be registered as service names (as per the existing SRV registry, e.g.), NOT as aliases in either the SRV registry (which has no such concept) or the IANA ports table. I.e., these new names should be registered as service names, not as aliases. This should be sufficient for the purposes of this document. In [I-D.ietf-vcarddav-carddav], after much debate with the IESG and the associated working group, the approach of registering the service types as aliases was agreed upon as a stop gap measure until the IANA SRV registry is setup. draft-daboo-srv-caldav follows that same approach. The SRV registry exists even in advance of IANA's management thereof. Further, aliases have no meaning in the SRV registry - they are meaningful only in the IANA ports registry, and only insofar as multiple strings are assigned the same port number. No such port number assignment is requested or appropriate here (they aren't needed for SRV records per se). One exception would be if you *also* intend that these strings serve as aliases to the well-known ports 80 and 443, respectively. However, this document does NOT define an alias for either of those ports. An alias would be an equivalent name which can be substituted without impact. Here, were you to use http or www instead of caldev or carddev, you should presumably not be using the /caldev or /carddev URI suffixes. I would be glad to discuss this further wiht the IESG or WG if needed. Well there have been plenty of discussions around this in the context of the CardDAV draft. This draft is following the process agreed upon for CardDAV. The goal here is to not delay drafts trying to use SRV whilst details of the IANA ports stuff is sorted out (and then debate on that has been going on for a while now). Once the new IANA procedure is in place it will subsume the definitions in CardDAV and this draft. 3) The use of a required URI suffix (/carddev or /caldev) seems to be too fixed. draft-cheshire-dnsext-dns-sd (intended as standards track) indicates a way to embed this information in the a TXT record with the same DNS name as the SRV record; RFC 5507 represents the IAB (informational) position that most additional information should be included in new RR types (though it's unclear this could easily support URI suffixes). My concern is that this document does neither; it embeds this information in this document as a requirement, rather than presenting it as a configurable option with a default. I would prefer to see the latter (regardless of how), to indicate the URI suffix if not the 'default' as specified in this document. RFC5785 defines the .well-known URI - I think it is very clear that, given that CalDAV and CardDAV are in effect web-services, making use of .well-known is the right thing to do. There is no need for any additional data in the DNS. What is more, the .well-known approach is in fact useful in the absence of SRV - it can minimise the information users would have to enter. I don't see this approach as being too fixed - the whole point about .well-known is to fix things like this. This doc seeks to escape the fixed allocations of the static IANA ports table by using SRV records to locate resources dynamically. However, this doc also refers back to a different but equally fixed .well-known URI table without a similar SRV-like dynamic escape mechanism. This isn't a fix; this is creating a stop-gap, and having a dynamic SRV registry refer back to a fixed table undermines the whole point of SRV records AFAICT. I don't understand this. SRV by itself (whilst dynamic in terms of host and port) is not sufficient for clients to reasonably do account bootstrapping as needed for CalDAV and CardDAV. A path is needed in addition to the host/port. This specification standardizes the path for CalDAV and CardDAV services. The whole basis of .well-know is that web clients want fixed paths for finding out things about web servers. This spec simply extends that to allow CalDAv and
Re: TSV-DIR review of draft-daboo-srv-caldav-05
On 17 jul 2010, at 21.00, Cyrus Daboo wrote: The whole basis of .well-know is that web clients want fixed paths for finding out things about web servers. This spec simply extends that to allow CalDAv and CardDAV clients to quickly find the paths to their relevant services. As I have said before as input to this last call, I think IESG should make a decision whether using such redirects in HTTP is a proper architecture solution to finding out how a service can be reached. I think personally it is not good design. I therefore ask IESG to make a specific decision on this topic, and not just say ok or not ok on the draft in question. Patrik PGP.sig Description: This is a digitally signed message part ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: TSV-DIR review of draft-daboo-srv-caldav-05
Hi, Cyrus, On 7/17/2010 12:00 PM, Cyrus Daboo wrote: ... The SRV registry exists even in advance of IANA's management thereof. Further, aliases have no meaning in the SRV registry - they are meaningful only in the IANA ports registry, and only insofar as multiple strings are assigned the same port number. No such port number assignment is requested or appropriate here (they aren't needed for SRV records per se). One exception would be if you *also* intend that these strings serve as aliases to the well-known ports 80 and 443, respectively. However, this document does NOT define an alias for either of those ports. An alias would be an equivalent name which can be substituted without impact. Here, were you to use http or www instead of caldev or carddev, you should presumably not be using the /caldev or /carddev URI suffixes. I would be glad to discuss this further wiht the IESG or WG if needed. Well there have been plenty of discussions around this in the context of the CardDAV draft. This draft is following the process agreed upon for CardDAV. The goal here is to not delay drafts trying to use SRV whilst details of the IANA ports stuff is sorted out (and then debate on that has been going on for a while now). Once the new IANA procedure is in place it will subsume the definitions in CardDAV and this draft. Until the new procedure in place, the current procedure - albeit unoffical - is to register with the SRV registry as a conventional SRV entry. The term alias has no relevance here, though. 3) The use of a required URI suffix (/carddev or /caldev) seems to be too fixed. draft-cheshire-dnsext-dns-sd (intended as standards track) indicates a way to embed this information in the a TXT record with the same DNS name as the SRV record; RFC 5507 represents the IAB (informational) position that most additional information should be included in new RR types (though it's unclear this could easily support URI suffixes). My concern is that this document does neither; it embeds this information in this document as a requirement, rather than presenting it as a configurable option with a default. I would prefer to see the latter (regardless of how), to indicate the URI suffix if not the 'default' as specified in this document. RFC5785 defines the .well-known URI - I think it is very clear that, given that CalDAV and CardDAV are in effect web-services, making use of .well-known is the right thing to do. There is no need for any additional data in the DNS. What is more, the .well-known approach is in fact useful in the absence of SRV - it can minimise the information users would have to enter. I don't see this approach as being too fixed - the whole point about .well-known is to fix things like this. This doc seeks to escape the fixed allocations of the static IANA ports table by using SRV records to locate resources dynamically. However, this doc also refers back to a different but equally fixed .well-known URI table without a similar SRV-like dynamic escape mechanism. This isn't a fix; this is creating a stop-gap, and having a dynamic SRV registry refer back to a fixed table undermines the whole point of SRV records AFAICT. I don't understand this. SRV by itself (whilst dynamic in terms of host and port) is not sufficient for clients to reasonably do account bootstrapping as needed for CalDAV and CardDAV. A path is needed in addition to the host/port. That's what I understood from the doc. The question is whether that path is fixed in some table somewhere - much like IANA ports - or whether the path is provided by a service - like SRV records are for port numbers. SRVs have extensions to do this - associated TXT records, as per Cheshire's draft. This specification standardizes the path for CalDAV and CardDAV services. The whole basis of .well-know is that web clients want fixed paths for finding out things about web servers. This spec simply extends that to allow CalDAv and CardDAV clients to quickly find the paths to their relevant services. The problem is the idea of a 'fixed' path. That's no more useful or appropriate than a fixed port number. Arguably ./well-known is just as dynamic as SRV in that the .well-known resources can use HTTP redirect to any arbitrary host/port/path combination. All we are doing is fixing the name of the .well-known via a registry - which seems to me exactly the same process as registering the SRV service types. I agree with Patrick here; redirects are NOT a solution to dynamic discovery of paths. The appropriate solution for a port discovered via SRV records is to use TXT records. Joe ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: TSV-DIR review of draft-daboo-srv-caldav-05
On 17 jul 2010, at 21.27, Joe Touch wrote: The appropriate solution for a port discovered via SRV records is to use TXT records. And, for the ones that have not followed the whole history of this last call, my view is that a new RR type is needed, and I propose a URI resource record that as RDATA have the full URI to the resource in question. Patrik PGP.sig Description: This is a digitally signed message part ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: TSV-DIR review of draft-daboo-srv-caldav-05
Patrick, Are you suggesting a new RR instead of the SRV or in addition to the SRV? The latter seems useful; the former begs the question of how many SRV variants we would want. Joe On 7/17/2010 12:33 PM, Patrik Fältström wrote: On 17 jul 2010, at 21.27, Joe Touch wrote: The appropriate solution for a port discovered via SRV records is to use TXT records. And, for the ones that have not followed the whole history of this last call, my view is that a new RR type is needed, and I propose a URI resource record that as RDATA have the full URI to the resource in question. Patrik ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Nomcom Enhancements: Improving the IETF leadership selection process
On 2010-07-18 03:48, Dave CROCKER wrote: ... At: http://www.bbiw.net/recent.html#nomcom2010 there is a copy of the Full Proposal, and a Summary which primarily contains just the recommendations. Um, we have this new system called Internet-Drafts, whereby proposals are issued by a certain cutoff date so that people have a chance to read them before a meeting. Did you consider using that system? Brian ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Nomcom Enhancements: Improving the IETF leadership selection process
Brian, it wasn't ready. Are you trying to say something beyond asking why it wasn't submitted as a draft? I don't understand the subtext. Scott ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Nomcom Enhancements: Improving the IETF leadership selection process
On 7/17/2010 1:49 PM, Brian E Carpenter wrote: http://www.bbiw.net/recent.html#nomcom2010 ... Um, we have this new system called Internet-Drafts, ... Brian, There is? Good to know. I'll try to use it for the next version.[*] And now that we've traded the requisite sarcasm... As Scott noted, I circulated it as soon as it was stable. For example, last night I got a review comment that greatly improved the clarity of the text for a recommendation. This proposal covers a difficult topic, with a problematic history. Deciding when to offer it for public discussion was its own challenge. Although the substantial list of contributors to the proposal embody deep IETF history, it is currently only an unofficial activity. It's not on any agendas, except some of our personal ones. The goal is hallway discussion. If you are pressed for time, please scan the Summary version. That's what it's there for. d/ [*] FYI, the I-D submission tool happens to currently enforce a hard limit at the number of authors, contrary to the RFC Editor's suggested limit. I'm told that the tool will get fixed eventually, but I thought it worth mentioning the added hassle of using the tool that you might not have known about. I discovered the limit in the usual fashion, for this document. -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-saintandre-tls-server-id-check (Representation and Verification of Domain-Based Application Service Identity in Certificates Used with Transport Layer Security) to Proposed Stand
--On Saturday, July 17, 2010 08:42 -0700 Paul Hoffman paul.hoff...@vpnc.org wrote: ... (2) In Section 4.4.2, note that there are definitional and procedural problems if one tries to talk about a single rule for full domain names. It is possible, and has been the only option until very recently, for a fully-qualified IDN to contain both traditional and internationalized labels. IDNA2008 avoided a number of definitional problems by being defined strictly in terms of labels for just that reason. In particular, conversion of an all-ASCII label to an A-label is undefined and meaningless: such a label is not a U-label and hence cannot be converted. One needs to parse the string into labels, determine for each label whether it is traditional or internationalized, and then apply the appropriate rule. I'd recommend rewriting 4.4.1 and 4.4.2 in terms of labels, not FQDNs. Here we (may) disagree. 4.4.2 is already in terms of labels: If the source domain of a reference identifier is an internationalized domain name, then an implementation MUST convertevery label in the domain name to an A-label before checking thedomain name. Are you saying that the correct wording should elide If the source domain of a reference identifier is an internationalized domain name, then and just start at An implementation MUST? That would work for me. That would probably be an improvement. But my problem was with every label and a sticky detail of IDNA2008: the only things that can be converted to A-labels are U-labels. One cannot convert an LDH label to an A-label, nor can one convert something that was already an A-label into an A-label. Those operations are just not defined. So I think this should be every internationalized label or (probably better) every non-traditional label or something to that effect. (3) Note that anything that requires that an application program parse a FQDN that might be an IDN into labels should probably have a Security Considerations note about the risks if various dotoids leak into the relevant environment. E, why should this document be forced to have such a warning when the IDNA2008 documents don't? The IDNA2008 base document sort of dodge the problem by dealing with labels, not FQDNs. If I recall, you have some beware of leaks language in Mapping, but I might be wrong. In any event, the reason it occurred to me as something that might be useful to say here is that the functions of this document would be, IMO, particularly sensitive to having someone want to store a name with the local label separator convention and that would be a problem. Possibly not more serious than other places, but still possibly worth mentioning. In any event, I consider the topic worth mentioning but definitely not a showstopper. john ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-saintandre-tls-server-id-check (Representation and Verification of Domain-Based Application Service Identity in Certificates Used with Transport Layer Security) to Proposed St
At 8:57 PM -0400 7/17/10, John C Klensin wrote: --On Saturday, July 17, 2010 08:42 -0700 Paul Hoffman paul.hoff...@vpnc.org wrote: ... (2) In Section 4.4.2, note that there are definitional and procedural problems if one tries to talk about a single rule for full domain names. It is possible, and has been the only option until very recently, for a fully-qualified IDN to contain both traditional and internationalized labels. IDNA2008 avoided a number of definitional problems by being defined strictly in terms of labels for just that reason. In particular, conversion of an all-ASCII label to an A-label is undefined and meaningless: such a label is not a U-label and hence cannot be converted. One needs to parse the string into labels, determine for each label whether it is traditional or internationalized, and then apply the appropriate rule. I'd recommend rewriting 4.4.1 and 4.4.2 in terms of labels, not FQDNs. Here we (may) disagree. 4.4.2 is already in terms of labels: If the source domain of a reference identifier is an internationalized domain name, then an implementation MUST convertevery label in the domain name to an A-label before checking thedomain name. Are you saying that the correct wording should elide If the source domain of a reference identifier is an internationalized domain name, then and just start at An implementation MUST? That would work for me. That would probably be an improvement. But my problem was with every label and a sticky detail of IDNA2008: the only things that can be converted to A-labels are U-labels. One cannot convert an LDH label to an A-label, nor can one convert something that was already an A-label into an A-label. Those operations are just not defined. So I think this should be every internationalized label or (probably better) every non-traditional label or something to that effect. Sounds good to me. Suggested edit for Paul and John to sing kumbaya: 4.4.2. Checking of Internationalized Domain Names The term internationalized domain name refers to a DNS domain name that conforms to the overall form of a domain name (dot-separated labels) but that can include Unicode code points outside the traditional US-ASCII range, as explained by and [IDNA2008]. An implementation MUST convert every non-traditional label in the domain name to an A-label before checking the domain name. (3) Note that anything that requires that an application program parse a FQDN that might be an IDN into labels should probably have a Security Considerations note about the risks if various dotoids leak into the relevant environment. E, why should this document be forced to have such a warning when the IDNA2008 documents don't? The IDNA2008 base document sort of dodge the problem by dealing with labels, not FQDNs. ... fully dodge... If I recall, you have some beware of leaks language in Mapping, but I might be wrong. We talk a bit about leaking into the app; this document is about certs and identities, and those identities don't necessarily come from the apps. In any event, the reason it occurred to me as something that might be useful to say here is that the functions of this document would be, IMO, particularly sensitive to having someone want to store a name with the local label separator convention and that would be a problem. Possibly not more serious than other places, but still possibly worth mentioning. But this would cause a false negative, not a false positive. It seems to me to be the same as many false negatives such as the app storing U+00B2 instead of U+0032. In any event, I consider the topic worth mentioning but definitely not a showstopper. Agree. --Paul Hoffman, Director --VPN Consortium ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-saintandre-tls-server-id-check (Representation and Verification of Domain-Based Application Service Identity in Certificates Used with Transport Layer Security) to Proposed St
--On Saturday, July 17, 2010 19:05 -0700 Paul Hoffman paul.hoff...@vpnc.org wrote: ... In any event, the reason it occurred to me as something that might be useful to say here is that the functions of this document would be, IMO, particularly sensitive to having someone want to store a name with the local label separator convention and that would be a problem. Possibly not more serious than other places, but still possibly worth mentioning. But this would cause a false negative, not a false positive. It seems to me to be the same as many false negatives such as the app storing U+00B2 instead of U+0032. Yes, absolutely. And, again, if we disagree, it is about whether the issue is worth mentioning, not whether avoiding mentioning it would be some sort of showstopper. I think it is marginally worth mentioning. You may think it marginally not worth the bits. But I can't imagine either of us losing a lot of sleep about either outcome. In any event, I consider the topic worth mentioning but definitely not a showstopper. Agree. Yes. See above. john ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-saintandre-tls-server-id-check (Representation and Verification of Domain-Based Application Service Identity in Certificates Used with Transport Layer Security) to Proposed Standa
On Thu, Jul 15, 2010 at 04:29:07PM -0700, Paul Hoffman wrote: At 4:08 PM -0700 7/15/10, The IESG wrote: The IESG has received a request from an individual submitter to consider the following document: - 'Representation and Verification of Domain-Based Application Service Identity in Certificates Used with Transport Layer Security ' draft-saintandre-tls-server-id-check-08.txt as a Proposed Standard The middle of Section 4.2 says: The client then orders the list in accordance with the following rules: Then, in 4.3, it checks each reference in this ordered list until it (hopefully) finds a match. Given that it is going to do an exhaustive search, what is the purpose of ordering? Not sure I'm following your question, but the purpose of ordering is to look for the subject identities in preference order (SRV/URI, before dNSName, before Common Name etc). Once a match is found, the search is aborted; an exhaustive search is only performed if the matched identity is the last one or there is no match. Section 4.3 has: It does so by seeking a match in preference order and aborting the search if any presented identifier matches one of its reference identifiers. The search fails if the client exhausts its list of reference identifiers without finding a match. -- Shumon Huque University of Pennsylvania. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
