Hi Joe, excellent suggestions. I concur to both.
It may also be useful (but not vital) to include a note that transport-tls is a secure, but not a 100% reliable protocol (because tcp without an app-layer ack is unreliable). Lots of folks have the misconception that just because tcp is used it is reliable. For that, one needs to implement rfc 3195. But, again, this is not a important enough point to hold publishing. Rainer > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On > Behalf Of Joseph Salowey (jsalowey) > Sent: Thursday, June 05, 2008 8:19 AM > To: syslog > Subject: [Syslog] Subject Name verification policy > > From the discussion on the list it seems that the largest issue is with > section 5.1 > > It seems that there is rough consensus to demote IP address matching in > certificates to a SHOULD or MAY. My preference would be to demote it > down to a may and just include it as an example of other things that > could be done, such as matching against the distinguished name as > Martin > suggested. > > "Implementations MAY also support authorization based on matching > configured names to other identity attributes. For example, the > authorization of a device Serial Number against the SerialNumber > portion > of the Subject Distinguished Name, IP address against a SubjectAltName > of type ipAddress, or an identity against a subject distinguished name. > Implementations MAY support other checks such as restrictions on the > depth of a certificate chain. " > > As far as hostname matching Tom brought up RFC4642 which has a slightly > different set of rules for matching host names (in particular it is > more > restrictive with wildcards). Text that is more in line with what 4642 > has might look like the following: > > " 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. If more than one host > name identity is present in the certificate a match in any one of the > set is considered acceptable. Matching is case-insensitive. > 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. For example, *.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. > > I'll work on clarifying some of the other sections and try to have > another revision by the end of the week. > > Cheers, > > Joe > _______________________________________________ > Syslog mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/syslog _______________________________________________ Syslog mailing list [email protected] https://www.ietf.org/mailman/listinfo/syslog
