Chris Newman wrote: > > Discuss: > This document does not discuss how to support IDN in domain names > for identity checking as required by BCP 18. I recommend copying > or referencing: > draft-hodges-server-ident-check-00 > for text on that topic.
Supporting IDNs in certificates and their verification is already extensively discussed in RFC 5280, Section 7. Do you think something important is missing from there? > The current text related to wildcards could create interopreability > problems. It is not clear if wildcards are permitted in the middle > of domain names and what their meaning would be in that context. > I also believe system operators who spend the money to purchase a > wildcard certificate (which some CAs charge extra to produce) would > be extremely unhappy if they could not use their purchase with syslog > software. For interoperability and least astonishment purposes, > shouldn't wildcard matching be mandatory-to-implement? (It's fine > if it can be disabled by policy or is off-by-default). This is a tricky question, but with two different parts. The current text says implementations MAY support wildcards in the *locally* configured name (the "reference identity" in draft-hodges-server-ident-check terminology). This "MAY" was intentional, I think -- this is mostly a local implementation detail, since the other end doesn't know wildcards are being used. Some implementations might support simple wildcards, others regular expressions, etc. The text doesn't say anything about wildcards in certificates, though. It probably needs to, and whatever is said needs to be mandatory-to-implement. Do you have suggestion what that text should say? (I've understood that e.g. none of the most common web browsers do exactly what RFC 2818 says, and no two of them behave identically.) > The current text does not discuss how to compare IP addresses in an > interoperable fashion. I recommend referencing or copying text from: > draft-hodges-server-ident-check-00 I think RFC 5280 specifies all the necessary certificate processing for IP addresses. > Question: did the WG consider creating (or reusing) an IANA registry > for hash function ASCII names? In the event fingerprints algorithms > other than "SHA1" become useful in the future it would be helpful > to have such a registry for interoperability. Hmm... I took a look at the IANA pages, and found an existing registry, created in RFC 4572, that might work: http://www.iana.org/assignments/hash-function-text-names/hash-function-text-names.xhtml > Comment: > I find it to be bad design that every time we bind TLS to a > particular protocol we have to duplicate lots of text about server > identity checks, domain name matching, etc. Often these texts vary > slightly in ways that are unimportant to the underlying problem but > will cause operator/administrator consternation for no technical > benefit. > > This particular instantiation has some very good text about > certificate handling that probably belongs in all the other > instances of this problem, so I would strongly encourage the authors > to contribute to > draft-hodges-server-ident-check I agree that having such a document would be a very good idea. > One thing that could be added to the certificate handling text to > improve it further is a requirement to support importing new trust > anchors and/or removing or disabling any built-in trust anchors. This would probably belong in draft-hodges-server-ident-check; I don't recall seeing this kind of text in any other protocol using TLS. Best regards, Pasi _______________________________________________ Syslog mailing list [email protected] https://www.ietf.org/mailman/listinfo/syslog
