Picking up on the comment about trust anchors, probably the closest you get in current RFC is for COPS in RFC4261
Tom Petch ----- Original Message ----- From: <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> Cc: <[email protected]> Sent: Monday, August 18, 2008 8:28 PM Subject: Re: [Syslog] DISCUSS and COMMENT: draft-ietf-syslog-transport-tls > 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-name s.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 _______________________________________________ Syslog mailing list [email protected] https://www.ietf.org/mailman/listinfo/syslog
