Re: Need your input on final issuesondraft-ietf-syslog-transport-tls

Just to be clear, lest it be buried in my suggested text, my objections to this
text are threefold.

a) the structure of the first sentence, which I think leads the reader astray; I
think the reference to certificate path needs taking out into a separate section
since the following paragraphs seem unrelated to it.

b) Technically, I think it the wrong direction to allow a common name to
override a subjectAltName, I believe the world is going the other way; and I am
unclear from this how much wildcarding is permitted in a locally configured name
(seems to be unconstrained ).

c) Terminology is inconsistent and at variance with that of RFC5280; I assume
that this cannot be implemented without a familiarity with RFC5280 and that its
terminology is thus the only one we should be using.

Tom Petch

----- Original Message -----
From: "tom.petch" <[email protected]>
To: "Chris Lonvick" <[email protected]>; <[email protected]>
Sent: Thursday, August 28, 2008 6:15 PM
Subject: Re: [Syslog] Need your input on final
issuesondraft-ietf-syslog-transport-tls


> 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

_______________________________________________
Syslog mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/syslog