So many of these issues existed with draft-13, not that they aren't valid, however I am worried we may start going around in circles with this.
> -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of tom.petch > Sent: Saturday, August 30, 2008 9:43 AM > To: Chris Lonvick (clonvick); [email protected] > Subject: Re: [Syslog] Need your input on > finalissuesondraft-ietf-syslog-transport-tls > > Just to be clear, lest it be buried in my suggested text, my > objections to this text are threefold. > > a) the structure of the first sentence, which I think leads > the reader astray; I think the reference to certificate path > needs taking out into a separate section since the following > paragraphs seem unrelated to it. > [Joe] I agree that the first sentence is a bit awkward. I don't think the section needs to be split. "Implementations MUST support certification path validation [RFC5280]. In addition they MUST support specifying the authorized peers using locally configured host names and matching the name against the certificate as follows:" > b) Technically, I think it the wrong direction to allow a > common name to override a subjectAltName, I believe the world > is going the other way; and I am unclear from this how much > wildcarding is permitted in a locally configured name (seems > to be unconstrained ). > [Joe] SubjectAltName is no more or less valid of an identity than Subject Name. Common Name is only a portion of the Subject Name and it may not be unique, however it is commonly assumed to be unique. While the use of SubjectAltName for host names is preferred, there are still many deployments which rely upon the use of Common Name. Given this I really think implementations SHOULD support common name. We can remove the text about matching more than one identity. "Implementations MUST support matching the locally configured name against a SubjectAltName field with a type of dNSName and SHOULD support checking the name against the Common Name portion of the Subject Distinguished Name." Perhaps we should remove text on locally configured wildcard matching since it is a matter of local implementation. > c) Terminology is inconsistent and at variance with that of > RFC5280; I assume that this cannot be implemented without a > familiarity with RFC5280 and that its terminology is thus the > only one we should be using. > [Joe] I agree we should be in line with RFC 5280. Which terminology do you think is inconsistent? > Tom Petch > > ----- Original Message ----- > From: "tom.petch" <[EMAIL PROTECTED]> > To: "Chris Lonvick" <[EMAIL PROTECTED]>; <[email protected]> > Sent: Thursday, August 28, 2008 6:15 PM > Subject: Re: [Syslog] Need your input on final > issuesondraft-ietf-syslog-transport-tls > > > > No, not ok; I find 1) unclear, poorly written, hard to > parse, prone to > > misinterpretation. > > > > "Implementations MUST a, MUST b and matching c as follows:" > > followed by chunky paragraphs most of which start "If a", with a > > sneaky > 'also' > > carrying overtones that the writer thinks it will not be > clear where > > the list > of > > what follows starts and ends:-( > > > > I think that 'a' (ie locally configured names) should be treated as > > one and anything else, which seems not much, removed to another > > section, eg > > > > > > Implementations MUST support locally configured host names > to specify > > authorised [yuk, are we authorising or > authenticating?]peers, matching > > the locally configured host name with the certificate as follows. > > > > A) Implementations MUST support matching the locally > configured name > against > > a subjectAltName extension of dNSName and SHOULD support > checking the > > name against the common name portion of the subject distinguished > > name. If more than one identity is present in the certificate, a > > match on any identity is acceptable. > > > > [I think this wrong; draft-hodges, which we are not referencing, > > deprecates > the > > use of common name, while we are saying if common name matches, and > > subjectAltName does not, then that is acceptable; I think not - I > > think that best practice is that if subjectAltName is > present, it must > > match] > > > > B) If the locally configured name is an internationalized > domain name, > > conforming implementations MUST convert it to the ASCII Compatible > > Encoding (ACE) format as specified in Section 7 of RFC 5280. > > > > C) The '*' (ASCII 42) wildcard character is allowed in > subjectAltName > > values of dNSName (and in common name, if used) but only as the > > left-most (least significant) DNS label in that value. > This wildcard > > matches any left-most DNS label in the server name. That is, the > > subject *.example.com matches the server names a.example.com and > > b.example.com, but does not match example.com or a.b.example.com. > > > > D) Implementations MAY support wildcards in locally > configured names > > to match a range of values. For example, using wildcards makes it > > possible to deploy trust-root-based authorization where all > > credentials issued by a particular CA trust root are authorized. > > > > {Q is the use of wildcard constrained here or can I say > local.*.ca ? > > dunno} > > > > E) Implementations MAY support matching a locally configured IP > > address against a subjectAltName extension of iPAddress. In this > > case, the locally configured IP address is converted to an octet > > string as specified in RFC 5280, Section 4.2.1.6 [RFC5280]. > A match > > occurs > if > > this octet string is equal to the value of a subjectAltName > extension > > of iPAddress. > > > > Tom Petch > > > > ----- Original Message ----- > > From: "Chris Lonvick" <[EMAIL PROTECTED]> > > To: <[email protected]> > > Sent: Thursday, August 28, 2008 12:43 AM > > Subject: [Syslog] Need your input on final issues > > ondraft-ietf-syslog-transport-tls > > > > > > > Hi Folks, > > > > > > The DISCUSSes and COMMENTs are here: > > > https://datatracker.ietf.org/idtracker/ballot/2334/ > > > > > > Joe, Pasi and Chris Newman have been having a discussion > to come up > > > with modifications to address them. We want to bring > these things > > > to the WG to make sure that implementors are comfortable > with these > > > changes. If you have comments, please send them in. If you read > > > these and agree with the changes, please comment to the > WG list as > > > well so we know that we're getting an adequate review. > > > > > > === 1 === > > > We have a proposed change to Section 5.2, Subject Name > > > Authorization, which are the first three paragraphs of > Chris Newman's DISCUSS. > > > > > > Implementations MUST support specifying the > authorized peers using > > > locally configured host names, MUST support certification path > > > validation [RFC5280] and matching the name with the > certificate as > > > follows: > > > > > > Implementations MUST support matching the locally > configured name > > > against a SubjectAltName field with a type of dNSName > and SHOULD > > > support checking the name against the Common Name > portion of the > > > Subject Distinguished Name. If more than one > identity is present > > > in the certificate, a match in any one of the set is > considered > > > acceptable. > > > > > > If the locally configured name is an > internationalized domain name, > > > conforming implementations MUST convert it to the > ASCII Compatible > > > Encoding (ACE) format as specified in Section 7 of RFC 5280. > > > > > > The '*' (ASCII 42) wildcard character is allowed in > subjectAltName > > > values of type dNSName (and in Common Name, if used), > and then only > > > as the left-most (least significant) DNS label in > that value. This > > > wildcard matches any left-most DNS label in the > server name. That > > > is, the subject *.example.com matches the server > names a.example.com > > > and b.example.com, but does not match example.com or > a.b.example.com. > > > > > > Implementations also MAY support wildcards in locally > configured > > > names to match a range of values. Using wildcards makes it > > > possible to deploy trust-root-based authorization where all > > > credentials issued by a particular CA trust root are > authorized. > > > > > > Implementations MAY support matching a locally configured > > > IP address against a SubjectAltName of type > ipAddress. In this > > > case, the locally configured IP address is converted > to an octet > > > string as specified in RFC 5280, Section 4.2.1.6. A > match occurs > > > if this octet string is equal to the value of > subjectAltName of > > > type iPAddress. > > > > > > ==== 2 === > > > > > > Joe also wrote for the fourth paragraph of Chris Newman's DISCUSS: > > > I think the last outstanding issue in the Discuss with > using an IANA > > > registry for hash function names. I think we could use > the registry > > > for RFC 4572. The allocation is tied to PKIX documents, > which is probably OK. > > > The one question is whether someone would adopt a hash > function that > > > become common convention for naming, but was not adopted > by PKIX. I > > > think the risk is very low here. It would change the label in the > > > draft from "SHA1" to "sha-1". > > > > > > The mechanism to generate a fingerprint is to take the hash of > > > the DER-encoded certificate using a cryptographically strong > > > algorithm and convert the result into colon separated, > > > hexadecimal bytes, each represented by 2 uppercase ASCII > > > characters. When a fingerprint value is displayed or > configured > > > the fingerprint is prepended with an ASCII label > identifying the > > > hash function followed by a colon. The ASCII label > is take from > > > the IANA registry for Hash Function Textual > > > Names. Implementations MUST support SHA-1 as the hash > algorithm > > > and use the ASCII label "sha-1" from the registry to > identify the > > > SHA-1 algorithm. The length of a SHA-1 hash is 20 > bytes and the > > > length of the corresponding fingerprint string is 64 > characters. > > > An example certificate fingerprint is: > > > > > > > sha-1:E1:2D:53:2B:7C:6B:8A:29:A2:76:C8:64:36:0B:08:4B:7A:F1:9E:9D > > > > > > === 3 === > > > > > > We have already cleared Lars' DISCUSS on the system port. > > > > > > === 4 === > > > > > > I'd like to get a "me too" for Tim's COMMENT: > > > s/(as described in Sections 5.2 and 5.3)/(as described in > Sections > > > 5.3 and 5.4)/ > > > > > > ========= > > > > > > > > > Please comment on these proposed changes. > > > > > > Actually, please comment _NOW_ as these are the last > things holding > > > up the three core IDs. :-) > > > > > > Thanks, > > > Chris > > > _______________________________________________ > > > Syslog mailing list > > > [email protected] > > > https://www.ietf.org/mailman/listinfo/syslog > > > > _______________________________________________ > > Syslog mailing list > > [email protected] > > https://www.ietf.org/mailman/listinfo/syslog > > _______________________________________________ > Syslog mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/syslog > _______________________________________________ Syslog mailing list [email protected] https://www.ietf.org/mailman/listinfo/syslog
