----- Original Message ----- From: "Joseph Salowey (jsalowey)" <[EMAIL PROTECTED]> To: "tom.petch" <[EMAIL PROTECTED]>; "Chris Lonvick (clonvick)" <[EMAIL PROTECTED]>; <[email protected]> Sent: Tuesday, September 02, 2008 5:57 AM Subject: RE: [Syslog] Need your input on finalissuesondraft-ietf-syslog-transport-tls
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. <tp> Well I did raise some of them before without seeing a response:-) </tp> > -----Original Message----- > From: [EMAIL PROTECTED] > 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:" <tp> yes, fixes it for me </tp> > 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. <tp> I'll wait to see what others think </tp> > 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? <tp> 'type iPAddress' is an oxymoron and may raise hackles (does mine - iPAddress is of type OCTET STRING:-) RFC5280 classifies it as a field, name form, component but never type. 'type ipAddress' see above and in addition 'ipAddress' does not exist. 'subjectAltName' is an extension and is always referred to as such. 'SubjectAltName' is a type, I think that 'subjectAltName' is meant. 'Common Name' is not used in RFC5280, rather 'common name', likewise 'subject distinguished name' is preferred to 'Subject Distinguished Name'. As I said, I regard familiarity with RFC5280 to be a prerequisite for this work, and so expect (some) readers of this I-D to notice these differences, and think the less of this I-D that they should exist. Tom Petch </tp> > > ----- 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 <snip> _______________________________________________ Syslog mailing list [email protected] https://www.ietf.org/mailman/listinfo/syslog
