Subject: [Syslog] Need your input on final issues on draft-ietf-syslog-transport-tls

From: Chris Lonvick <[email-masked]>
Date: Wed, 27 Aug 2008 15:43:21 -0700 (PDT)

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-masked]
https://www.ietf.org/mailman/listinfo/syslog

---

From: Martin Schütte <[email-masked]>
Date: Thu, 28 Aug 2008 07:04:17 +0200

>     as the left-most (least significant) DNS label in that value.  This

Is this a MAY or a MUST?

-- 
Martin

---

From: "Joseph Salowey (jsalowey)" <[email-masked]>
Date: Wed, 27 Aug 2008 22:58:44 -0700

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Martin Schütte
> Sent: Wednesday, August 27, 2008 10:04 PM
> To: [email-masked]
> Subject: Re: [Syslog] Need your input on final issueson 
> draft-ietf-syslog-transport-tls
> 
> Chris Lonvick schrieb:
> > 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.
> 
[Joe] I think it is a MUST or RECOMMENDED.  Other applications allow wildcards to appear in certificates so it might be surprising for deployers if it is not supported in Syslog TLS.

---

From: "tom.petch" <[email-masked]>
Date: Thu, 28 Aug 2008 18:15:48 +0200

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-masked]>
To: <[email-masked]>
Sent: Thursday, August 28, 2008 12:43 AM
Subject: [Syslog] Need your input on final issues
ondraft-ietf-syslog-transport-tls

---

From: "David Harrington" <[email-masked]>
Date: Sat, 30 Aug 2008 09:58:17 -0400

Hi,

I am a little concerned by text that specifies mandatory or optional
features without using the RFC2119 keywords. I would prefer tighter
text that uses the RFC2119 keywords, throughout the document.

Text like "is allowed" does not give clear enough directions to
implementers of receivers versus senders; we need to be clear what
"conservative what you send" means.

dbh

> Sent: Thursday, August 28, 2008 1:04 AM
> To: [email-masked]
> agree with the

---

From: "tom.petch" <[email-masked]>
Date: Sat, 30 Aug 2008 18:43:00 +0200

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-masked]>
To: "Chris Lonvick" <[email-masked]>; <[email-masked]>
Sent: Thursday, August 28, 2008 6:15 PM
Subject: Re: [Syslog] Need your input on final
issuesondraft-ietf-syslog-transport-tls