Hi Martin Thanks for looking at this.
> -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Martin Schütte > Sent: Thursday, June 05, 2008 4:00 AM > To: syslog > Subject: Re: [Syslog] Subject Name verification policy > > Joseph Salowey (jsalowey) schrieb: > > " o Host-name-based authorization where the host name of the > > authorized peer is compared against the subject fields in the > > certificate. For the purpose of interoperability, implementations > > MUST support matching the host name against a SubjectAltName field > > with a type of dNSName and SHOULD support checking hostname against > > the Common Name portion of the Subject Distinguished Name. > > So that means one has to do DNS lookup for name matching? > [Joe] Correct DNS lookups should not be done when matching. > What happened to the requirement from draft 12: > > For subject name verification, client implementations MUST support > > configuring, for each transport receiver, the name to be matched > > against the certificate. > > IMHO that is a useful requirement because it allows the user > to configure the hostname by IP and still match against a > dNSName in the certificate. > This easily allows DNS-independent syslog configurations > without having iPAddresses in the certificates and having to > match against them. > [Joe] I think I see your point, how about modifying the text such that host name is replaced by "configured name" as below: "o Host-name-based authorization where a configured name of the authorized peer is compared against the subject fields in the certificate. For the purpose of interoperability, implementations MUST support matching the 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. Matching is case-insensitive." Does this help? > > Implementations also MAY support wildcards to match a range > of values. > > A "*" wildcard character MAY be used as the left-most name > component > > in the certificate. > > So this only applies to wildcards in the certificate? > [Joe] I actually meant to remove the reference to wildcards in the certificate. > If a configured name is used for matching, should that be > allowed to contain wildcards as well? (I hope not because > that would make the whole name matching useless.) > [Joe] New text "Implementations also MAY support wildcards to match a range of values. For example, a "*" wildcard character MAY be used as the left-most name component. In this case *.example.com would match a.example.com, foo.example.com, etc., but would not match example.com. Using a wildcard for the entire host name makes it possible to deploy trust-root-based authorization where all credentials issued by a particular CA trust root are authorized." > > We should also include a discussion on using configured > names instead > > of names derived from DNS for matching. > > See above. > My current implementation uses only the hostname and an > optional configured subject name for matching. That way I > avoid DNS for certificate matching and I consider that a feature. > [Joe] Good. I agree. > -- > Martin > _______________________________________________ > Syslog mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/syslog > _______________________________________________ Syslog mailing list [email protected] https://www.ietf.org/mailman/listinfo/syslog
