>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
