I added information on locally configured names with wildcards,
clarified the ACE conversion is for comparison, and change the ordering
of the bullets. I think this text should be pretty close now.
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.
o The '*' (ASCII 42) wildcard character is allowed in the dNSName
of
the subjectAltName extension (and in common name, if used to
store
the host name), and then only as the left-most (least
significant)
DNS label in that value. This wildcard matches any left-most
DNS
label in the server name. That is, the subject *.example.com
matches the server names a.example.com and b.example.com, but
does
not match example.com or a.b.example.com. Implementations MUST
support wildcards in certificates as specified above, but MAY
provide a configuration option to disable them.
o Implementations MUST support matching the locally configured
host
name against a dNSName in the subjectAltName extension field and
SHOULD support checking the name against the common name portion
of
the subject distinguished name. Locally configured names MAY
contain
the wildcard character to match a range of values. The types of
wildcards supported MAY be more flexible than what is allowed in
certificate subjects to make it possible to support various
policies
for different environments. For example, a policy could allow
for a
trust-root-based authorization where all credentials issued by a
particular CA trust root are authorized.
o If the locally configured name is an internationalized domain
name, conforming implementations MUST convert it to the ASCII
Compatible Encoding (ACE) format for performing comparisons as
specified in Section 7 of RFC 5280.
o Implementations MAY support matching a locally configured IP
address against an iPAddress stored in the subjectAltName
extension. In this case, the locally configured IP address is
converted to an octet string as specified in RFC 5280, Section
4.2.1.6. A match occurs if this octet string is equal to the
value
of iPAddress in the subjectAltName extension.
Cheers,
Joe
> -----Original Message-----
> From: Chris Lonvick (clonvick)
> Sent: Wednesday, September 03, 2008 1:44 PM
> To: Joseph Salowey (jsalowey)
> Cc: tom.petch; syslog
> Subject: revised 5.2 text : please comment was: RE: [Syslog]
> Need your input on finalissuesondraft-ietf-syslog-transport-tls
>
> Hi,
>
> I'm going to take a stab at word smithing. I think there's
> still some ambiguity in the section that Joe just proposed
> and we may be able to resolve by putting in bullets. Please
> look at this and give feedback.
>
> ===
> 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.
> o Implementations MUST support matching the locally
> configured host
> name against a dNSName in the subjectAltName
> extension field and
> SHOULD support checking the name against the common
> name portion of
> the subject distinguished name.
> o Implementations MAY support matching a locally configured IP
> address against an iPAddress stored in the subjectAltName
> extension. In this case, the locally configured IP address is
> converted to an octet string as specified in RFC 5280, Section
> 4.2.1.6. A match occurs if this octet string is
> equal to the value
> of iPAddress in the subjectAltName extension.
> o The '*' (ASCII 42) wildcard character is allowed in
> the dNSName of
> the subjectAltName extension (and in common name, if
> used to store
> the host name), and then only as the left-most (least
> significant)
> DNS label in that value. This wildcard matches any
> left-most DNS
> label in the server name. That is, the subject *.example.com
> matches the server names a.example.com and
> b.example.com, but does
> not match example.com or a.b.example.com. Implementations MUST
> support wildcards in certificates as specified above, but MAY
> provide a configuration option to disable them.
> o If the locally configured name is an internationalized domain
> name, conforming implementations MUST convert it to the ASCII
> Compatible Encoding (ACE) format as specified in
> Section 7 of RFC
> 5280.
>
> ===
>
> Does this work for anyone? :-)
>
> Thanks,
> Chris
>
_______________________________________________
Syslog mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/syslog
