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. 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 ). 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. 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
