No, not ok; I find 1) unclear, poorly written, hard to parse, prone to
misinterpretation.
"Implementations MUST a, MUST b and matching c as follows:"
followed by chunky paragraphs most of which start "If a", with a sneaky 'also'
carrying overtones that the writer thinks it will not be clear where the list of
what follows starts and ends:-(
I think that 'a' (ie locally configured names) should be treated as one and
anything else, which seems not much, removed to another section, eg
Implementations MUST support locally configured host names to specify
authorised [yuk, are we authorising or authenticating?]peers, matching the
locally configured host name with the certificate as follows.
A) Implementations MUST support matching the locally configured name against
a subjectAltName extension 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 on any identity is acceptable.
[I think this wrong; draft-hodges, which we are not referencing, deprecates the
use of common name, while we are saying if common name matches, and
subjectAltName does not, then that is acceptable; I think not - I think that
best practice is that if subjectAltName is present, it must match]
B) 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.
C) The '*' (ASCII 42) wildcard character is allowed in subjectAltName
values of dNSName (and in common name, if used) but 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.
D) Implementations MAY support wildcards in locally configured
names to match a range of values. For example, using wildcards makes it
possible to deploy trust-root-based authorization where all credentials issued
by a particular CA trust root are authorized.
{Q is the use of wildcard constrained here or can I say local.*.ca ? dunno}
E) Implementations MAY support matching a locally configured
IP address against a subjectAltName extension of 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 [RFC5280]. A match occurs if
this octet string is equal to the value of a subjectAltName extension of
iPAddress.
Tom Petch
----- Original Message -----
From: "Chris Lonvick" <[EMAIL PROTECTED]>
To: <[email protected]>
Sent: Thursday, August 28, 2008 12:43 AM
Subject: [Syslog] Need your input on final issues
ondraft-ietf-syslog-transport-tls
> 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
_______________________________________________
Syslog mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/syslog
