I too support making these last final clarifications and move this specification along.
John > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf > Of Rainer Gerhards > Sent: Thursday, June 05, 2008 1:26 AM > To: Joseph Salowey (jsalowey) > Cc: syslog > Subject: Re: [Syslog] Subject Name verification policy > > 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 _______________________________________________ Syslog mailing list [email protected] https://www.ietf.org/mailman/listinfo/syslog
