Hi Folks,
The DISCUSSes and COMMENTs are here:
https://datatracker.ietf.org/idtracker/ballot/2334/
Joe, Pasi and Chris Newman have been having a discussion to come up with
modifications to address them. We want to bring these things to the WG to
make sure that implementors are comfortable with these changes. If you
have comments, please send them in. If you read these and agree with the
changes, please comment to the WG list as well so we know that we're
getting an adequate review.
=== 1 ===
We have a proposed change to Section 5.2, Subject Name Authorization,
which are the first three paragraphs of Chris Newman's DISCUSS.
Implementations MUST support specifying the authorized peers using
locally configured host names, MUST support certification path
validation [RFC5280] and matching the name with the certificate as
follows:
Implementations MUST support matching the locally configured 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.
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.
The '*' (ASCII 42) wildcard character is allowed in subjectAltName
values of type dNSName (and in Common Name, if used), 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 also MAY support wildcards in locally configured
names to match a range of values. Using wildcards makes it
possible to deploy trust-root-based authorization where all
credentials issued by a particular CA trust root are authorized.
Implementations MAY support matching a locally configured
IP address against a SubjectAltName of type ipAddress. 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 subjectAltName of
type iPAddress.
==== 2 ===
Joe also wrote for the fourth paragraph of Chris Newman's DISCUSS:
I think the last outstanding issue in the Discuss with using an IANA
registry for hash function names. I think we could use the registry for
RFC 4572. The allocation is tied to PKIX documents, which is probably OK.
The one question is whether someone would adopt a hash function that
become common convention for naming, but was not adopted by PKIX. I think
the risk is very low here. It would change the label in the draft from
"SHA1" to "sha-1".
The mechanism to generate a fingerprint is to take the hash of
the DER-encoded certificate using a cryptographically strong
algorithm and convert the result into colon separated,
hexadecimal bytes, each represented by 2 uppercase ASCII
characters. When a fingerprint value is displayed or configured
the fingerprint is prepended with an ASCII label identifying the
hash function followed by a colon. The ASCII label is take from
the IANA registry for Hash Function Textual
Names. Implementations MUST support SHA-1 as the hash algorithm
and use the ASCII label "sha-1" from the registry to identify the
SHA-1 algorithm. The length of a SHA-1 hash is 20 bytes and the
length of the corresponding fingerprint string is 64 characters.
An example certificate fingerprint is:
sha-1:E1:2D:53:2B:7C:6B:8A:29:A2:76:C8:64:36:0B:08:4B:7A:F1:9E:9D
=== 3 ===
We have already cleared Lars' DISCUSS on the system port.
=== 4 ===
I'd like to get a "me too" for Tim's COMMENT:
s/(as described in Sections 5.2 and 5.3)/(as described in Sections 5.3 and
5.4)/
=========
Please comment on these proposed changes.
Actually, please comment _NOW_ as these are the last things holding up the
three core IDs. :-)
Thanks,
Chris
_______________________________________________
Syslog mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/syslog
