Subject: Re: [Syslog] Need your input on finalissuesondraft-ietf-syslog-transport-tls

From: "Rainer Gerhards" <[email-masked]>
Date: Mon, 1 Sep 2008 17:20:38 +0200

I have been away, so my comments are late...

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of tom.petch
> Sent: Saturday, August 30, 2008 6:43 PM
> To: Chris Lonvick; [email-masked]
> Subject: Re: [Syslog] Need your input on finalissuesondraft-ietf-
> syslog-transport-tls
> 

[snip]

> 
> 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 ).

I agree with Tom. I think we should NOT MANDATE to check the common name
if a subject AltName is present. I always understood the previous text
so that common name would be a fallback if and only if no subjectAltName
was present.

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

---

From: "Rainer Gerhards" <[email-masked]>
Date: Mon, 1 Sep 2008 17:26:40 +0200

<inline>

> Behalf Of Joseph Salowey (jsalowey)
> Sent: Thursday, August 28, 2008 7:59 AM
> To: Martin Schütte; [email-masked]
> Subject: Re: [Syslog] Need your input on finalissueson draft-ietf-
> syslog-transport-tls
> 
> 
> 
> > 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.
> >
> > Looks good to me. Only one question:
> >
> > > === 1 ===
> > >     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
> >
> > Is this a MAY or a MUST?
> >
> [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.

Mhh... I'd say it should be a RECOMMENDED at most. Otherwise, we are back to the policy decision discussion we had earlier this year.

As a side-note, I find it quite counter-productive to allow this at all. IMHO "MAY" is even too strong. This opens up a can of worms, which leads to non-identification of the remote peer. So far, we had a very strong position that the peer's *identity* must be known but "our" instance can decide whether or not it accepts the peer's identity. With wildcards inside the certificate, that choice is partly moved over to the remote peer. If we make it a MUST, I already see users asking for a way to "turn off accepting wildcard certificates". So in my opinion this is a bad choice. Comparing to other protocols makes only sense if the share the same security concerns, and I think syslog's are quite unique (as has been stressed several times before by others on this list when it came to requesting support for anonymous peers;)).

Rauber

---

From: "Joseph Salowey (jsalowey)" <[email-masked]>
Date: Mon, 1 Sep 2008 20:57:19 -0700

So many of these issues existed with draft-13,  not that they aren't
valid, however I am worried we may start going around in circles with
this.   

> [mailto:[email-masked]] On Behalf Of tom.petch
> Sent: Saturday, August 30, 2008 9:43 AM
> To: Chris Lonvick (clonvick); [email-masked]
> Subject: Re: [Syslog] Need your input on 
> finalissuesondraft-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.
> 
[Joe] I agree that the first sentence is a bit awkward.  I don't think
the section needs to be split.  

"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:"

> 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 ).
> 
[Joe] SubjectAltName is no more or less valid of an identity than
Subject Name.  Common Name is only a portion of the Subject Name and it
may not be unique, however it is commonly assumed to be unique.   While
the use of SubjectAltName for host names is preferred, there are still
many deployments which rely upon the use of Common Name.  Given this I
really think implementations SHOULD support common name.   We can remove
the text about  matching more than one identity.  

"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."

Perhaps we should remove text on locally configured wildcard matching
since it is a matter of local implementation.

> 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.
> 
[Joe] I agree we should be in line with RFC 5280.  Which terminology do
you think is inconsistent? 

> 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
> 
> 
> > 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
> >
> >
> > > 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.
> > >
> > >     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

---

From: "Joseph Salowey (jsalowey)" <[email-masked]>
Date: Mon, 1 Sep 2008 21:09:48 -0700

> From: Rainer Gerhards [mailto:[email-masked]] 
> Sent: Monday, September 01, 2008 8:27 AM
> To: Joseph Salowey (jsalowey); Martin Schütte; [email-masked]
> Subject: RE: [Syslog] Need your input on finalissueson 
> that value.
> Mhh... I'd say it should be a RECOMMENDED at most. Otherwise, 
> we are back to the policy decision discussion we had earlier 
> this year.
> 
> As a side-note, I find it quite counter-productive to allow 
> this at all. IMHO "MAY" is even too strong. This opens up a 
> can of worms, which leads to non-identification of the remote 
> peer. So far, we had a very strong position that the peer's 
> *identity* must be known but "our" instance can decide 
> whether or not it accepts the peer's identity. With wildcards 
> inside the certificate, that choice is partly moved over to 
> the remote peer. If we make it a MUST, I already see users 
> asking for a way to "turn off accepting wildcard 
> certificates". So in my opinion this is a bad choice. 
> Comparing to other protocols makes only sense if the share 
> the same security concerns, and I think syslog's are quite 
> unique (as has been stressed several times before by others 
> on this list when it came to requesting support for anonymous 
> peers;)).
> 
[Joe] Today, there are CA's that issue certificates with wildcards in the hostname.  It would be good if Syslog implementations could be configured to work with these CA's.  It is not required that this support always be enabled.  Would the addition help:

"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 SHOULD provide the ability to enable support for 
these types of wildcards within the host name in the certificate. "

---

From: <[email-masked]>
Date: Tue, 2 Sep 2008 09:17:27 +0300

Joseph Salowey wrote:

> [Joe] Today, there are CA's that issue certificates with wildcards
> in the hostname.  It would be good if Syslog implementations could
> be configured to work with these CA's.  It is not required that this
> support always be enabled.  Would the addition help:
> 
> a.b.example.com.  Implementations SHOULD provide the ability to
> enable support for these types of wildcards within the host name in
> the certificate. "

I think this needs to be "Implementations MUST support wildcards in
certificates as specified above, but MAY provide a configuration
option to disable them."

Best regards,
Pasi

---

From: "Rainer Gerhards" <[email-masked]>
Date: Tue, 2 Sep 2008 08:21:59 +0200

> Behalf Of [email-masked]
> Sent: Tuesday, September 02, 2008 8:17 AM
> To: [email-masked]; [email-masked]
> Subject: Re: [Syslog] Need your inputonfinalissueson
draft-ietf-syslog-
> transport-tls

So we require an application to support certificates to identify the
remote peer, go great length to prevent anonymous peers ... and then we
introduce anon peers by allowing wildcards inside the certificate?
Well... if that's really our intension, I'll no longer object it. I just
wonder why we don't simply allow plain anon peers as was suggested by
others and me several times...

Rainer

---

From: <[email-masked]>
Date: Tue, 2 Sep 2008 09:27:06 +0300

Rainer Gerhards wrote:

> remote peer, go great length to prevent anonymous peers ...  and
> then we introduce anon peers by allowing wildcards inside the
> certificate?  Well... if that's really our intension, I'll no longer
> object it. I just wonder why we don't simply allow plain anon peers
> as was suggested by others and me several times...

Wildcards in certificates aren't anonymous peers; they're a shorthand
for specifying that the subject of the certificate is the valid
"owner" of (large set of) multiple different names.

Plain anonymous peers are allowed by the specification, but the
text about them is in a different subsection than we're discussing
now.

Best regards,
Pasi

---

From: "tom.petch" <[email-masked]>
Date: Tue, 2 Sep 2008 15:20:19 +0200

----- Original Message -----
From: "Joseph Salowey (jsalowey)" <[email-masked]>
To: "tom.petch" <[email-masked]>; "Chris Lonvick (clonvick)"
<[email-masked]>; <[email-masked]>
Sent: Tuesday, September 02, 2008 5:57 AM
Subject: RE: [Syslog] Need your input on
finalissuesondraft-ietf-syslog-transport-tls

<tp>
Well I did raise some of them before without seeing a response:-)
</tp>

<tp>
yes, fixes it for me
</tp>

"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."

<tp>
I'll wait to see what others think
</tp>

<tp>

'type iPAddress' is an oxymoron and may raise hackles (does mine -  iPAddress is
of type OCTET STRING:-)  RFC5280 classifies it as a field, name form, component
but never type.

'type ipAddress' see above and in addition 'ipAddress' does not exist.

'subjectAltName' is an extension and is always referred to as such.

'SubjectAltName'  is a type, I think that 'subjectAltName' is meant.

'Common Name' is not used in RFC5280, rather 'common name', likewise 'subject
distinguished name' is preferred to 'Subject Distinguished Name'.

As I said, I regard familiarity with RFC5280 to be a prerequisite for this work,
and so expect (some) readers of this I-D to notice these differences, and think
the less of this I-D that they should exist.

Tom Petch
</tp>
> issuesondraft-ietf-syslog-transport-tls
<snip>

---

From: "Joseph Salowey (jsalowey)" <[email-masked]>
Date: Tue, 2 Sep 2008 22:10:11 -0700

> 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.
> >
> [Joe] I agree we should be in line with RFC 5280.  Which 
> terminology do you think is inconsistent?
> 
> <tp>
> 
> 'type iPAddress' is an oxymoron and may raise hackles (does 
> mine -  iPAddress is of type OCTET STRING:-)  RFC5280 
> classifies it as a field, name form, component but never type.
> 
> 'Common Name' is not used in RFC5280, rather 'common name', 
> likewise 'subject distinguished name' is preferred to 
> 'Subject Distinguished Name'.
> 
> As I said, I regard familiarity with RFC5280 to be a 
> prerequisite for this work, and so expect (some) readers of 
> this I-D to notice these differences, and think the less of 
> this I-D that they should exist.
> 
[Joe] OK, thanks.  Here is a revision of the text.  It probably still
needs some work, but hopefully it is in the right direction. 

certificate as follows:

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. 

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 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.

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."

---

From: Chris Lonvick <[email-masked]>
Date: Wed, 3 Sep 2008 13:25:03 -0700 (PDT)

Hi Rainer,

> others and me several times...

We have the following for unathenticated sessions:
Section 5.3 for Unauthenticated Transport Sender
Sectoin 5.4 for  Unauthenticated Transport Receiver
Section 5.5 for  Unauthenticated Transport Receiver and Sender

These sections are where we allow for anonymous peers but still use tls as 
the transport.

Thanks,
Chris

---

From: "David Harrington" <[email-masked]>
Date: Wed, 3 Sep 2008 16:37:52 -0400

Hi, 

(speaking as a technical contributor)

> Encoding (ACE) format as specified in Section 7 of RFC 5280.

Do we need to be clear about when (i.e. for what usages) this
translation needs to be done? Is this necessary before string
comparisons, for example?

> in certificates as specified above, but MAY provide a configuration 

shouldn't we make the ability to disable wildcards a MUST-implement,
so we can be sure the strong-security option will be available if an
operator wants to disable them for security reasons? That would seem
to be consistent with BCP61.

David Harrington
[email-masked]
[email-masked]
[email-masked]

---

From: Chris Lonvick <[email-masked]>
Date: Wed, 3 Sep 2008 13:43:50 -0700 (PDT)

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

---

From: Chris Lonvick <[email-masked]>
Date: Wed, 3 Sep 2008 13:48:35 -0700 (PDT)

Hi,

We seem to be having a great time discussing issue 1 (below).  I think Joe 
is on top of it and we need some feedback to make sure.

I'm going to declare issues 2, 3, and 4 (below) to be resolved.  I know 
people have read them and have not sent in any negative comments or 
proposed revisions so I'm going to assume that everyone is OK with them.

Thanks,
Chris

On Wed, 27 Aug 2008, Chris Lonvick wrote:

> 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
>    validation [RFC5280] and matching the name with the certificate as
>    follows:
>
>    Implementations MUST support matching the locally configured name
>    Subject Distinguished Name.  If more than one identity is present
>    in the certificate, a match in any one of the set is considered
>    acceptable.
>
>    The '*' (ASCII 42) wildcard character is allowed in subjectAltName
>    Implementations also MAY support wildcards in locally configured
>    IP address against a SubjectAltName of type ipAddress.  In this
>    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 ===
>
> 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".
>
>    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
>    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.
> s/(as described in Sections 5.2 and 5.3)/(as described in Sections 5.3 and
> 5.4)/
>
> =========
>
>
> Actually, please comment _NOW_ as these are the last things holding up the
> three core IDs.  :-)
>
> Thanks,
> Chris

---

From: "Joseph Salowey (jsalowey)" <[email-masked]>
Date: Wed, 3 Sep 2008 17:36:07 -0700

> [mailto:[email-masked]] On Behalf Of David Harrington
> Sent: Wednesday, September 03, 2008 1:38 PM
> To: 'syslog'
> Subject: Re: [Syslog] Need your 
> inputonfinalissuesondraft-ietf-syslog-transport-tls
> 
> Hi, 
> 
[Joe] Yes, I think this section is missing some context: 
"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."

> > label in that value.  This wildcard matches any left-most 
> DNS label in 
> > the server name.  That is, the subject *.example.com matches the 
> shouldn't we make the ability to disable wildcards a 
> MUST-implement, so we can be sure the strong-security option 
> will be available if an operator wants to disable them for 
> security reasons? That would seem to be consistent with BCP61.
> 
[Joe] In many cases this policy is left up to the CA as to whether to
issue certificates of this type or not, however it has been pointed out
on the list that there is a concern that the syslog administrator may
not control the CA and may have some different policies than the CA.  In
this case a control would be necessary.  I'd be ok with changing this to
a MUST (or a SHOULD).

---

From: "[email-masked]" <[email-masked]>
Date: Thu, 4 Sep 2008 13:10:35 +0300

> comparisons, for example?

Could perhaps add "before comparing it with the certificate"?

> > The '*' (ASCII 42) wildcard character is allowed in the dNSName of

Hmm... IMHO wildcards in certificates are compatible with strong
security -- they're just convenient shorthand for multiple names.
Disabling wildcards basically makes sense if the operator doesn't
trust the CA to issue certificates properly (and IMHO in this case,
you have worse problems), so I don't think anything stronger than
MAY is needed here.

Best regards,
Pasi

---

From: <[email-masked]>
Date: Thu, 4 Sep 2008 13:12:33 +0300

Looks good, but the text about wildcards in locally configured
names was lost.

Best regards,
Pasi

> [mailto:[email-masked]] On Behalf Of ext Chris Lonvick
> Sent: 03 September, 2008 23:44
> To: Joseph Salowey (jsalowey)
> Cc: syslog
> Subject: [Syslog] revised 5.2 text : please comment was: RE: 
> Need your input on finalissuesondraft-ietf-syslog-transport-tls
> 
> Hi,
>

---

From: "tom.petch" <[email-masked]>
Date: Thu, 4 Sep 2008 18:17:14 +0200

Joe

Yes, this fixes my comments about the terminology.

In case anyone else wonders, 'certification path validation' may read oddly but
it is what RFC5280 uses.

Tom Petch

----- Original Message -----
From: "Joseph Salowey (jsalowey)" <[email-masked]>
To: "tom.petch" <[email-masked]>; "Chris Lonvick (clonvick)"
<[email-masked]>; "syslog" <[email-masked]>
Sent: Wednesday, September 03, 2008 7:10 AM
Subject: RE: [Syslog] Need your input on
finalissuesondraft-ietf-syslog-transport-tls

---

From: "Joseph Salowey (jsalowey)" <[email-masked]>
Date: Fri, 5 Sep 2008 15:10:52 -0700

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. 

        4.2.1.6.  A match occurs if this octet string is equal to the
value

Cheers,

Joe

> From: Chris Lonvick (clonvick) 
> Sent: Wednesday, September 03, 2008 1:44 PM
> Cc: tom.petch; syslog
> Subject: revised 5.2 text : please comment was: RE: [Syslog] 
> 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.
> 
> ===

---

From: <[email-masked]>
Date: Tue, 9 Sep 2008 12:40:35 +0300

Switching the order of the 1st (wildcards) and 2nd (subjectaltname)
bullets would IMHO make the flow more logical. Otherwise, looks good.

Best regards,
Pasi

> [mailto:[email-masked]] On Behalf Of ext Joseph 
> Salowey (jsalowey)
> Sent: 06 September, 2008 01:11
> To: Chris Lonvick (clonvick)
> Cc: syslog
> Subject: Re: [Syslog] revised 5.2 text : please comment was: 
> RE: Need yourinput on finalissuesondraft-ietf-syslog-transport-tls
>

---

From: Chris Lonvick <[email-masked]>
Date: Tue, 9 Sep 2008 06:57:58 -0700 (PDT)

Hi Pasi,

> bullets would IMHO make the flow more logical. Otherwise, looks good.

I see your point but that would create a forward reference.  The second 
bullet (subjectAltName) contains the line, "Locally configured 
names MAY contain the wildcard character to...".  I'm thinking that the 
wildcard character should be defined before that.

It could be swapped with a reference such as the following placed into the 
subjectAltName bullet, "Locally configured names MAY contain the wildcard 
character (see next bullet) to...".

What does everyone think about this?

Thanks,
Chris

---

From: <[email-masked]>
Date: Tue, 9 Sep 2008 17:30:39 +0300

Perhaps the text should be split to three bullets, describing the
normal case first, and special cases (wildcards in cert, wildcards
in local name) next?

Like these (just rearranging the text, not changing the words):

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 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.

Best regards,
Pasi

> From: ext Chris Lonvick [mailto:[email-masked]] 
> Sent: 09 September, 2008 16:58
> To: Eronen Pasi (Nokia-NRC/Helsinki)
> Cc: [email-masked]; [email-masked]
> Subject: RE: [Syslog] revised 5.2 text : please comment was:

---

From: "tom.petch" <[email-masked]>
Date: Wed, 10 Sep 2008 15:02:55 +0200

Yeees, I think so but ...

Have we just introduced 'certificate subjects' where previously we have used
'subject names' eg as in the heading of this section? I assume that both refer
to the same concept, in which case I would prefer 'than that which is allowed in
subject names'.

Tom Petch

----- Original Message -----
From: <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>
Sent: Tuesday, September 09, 2008 4:30 PM
Subject: Re: [Syslog] revised 5.2 text : please comment was: RE: Needyourinput
on finalissuesondraft-ietf-syslog-transport-tls

---

From: "Joseph Salowey (jsalowey)" <[email-masked]>
Date: Mon, 15 Sep 2008 15:44:07 -0700

Here is the text I will put in the revised draft for this section:

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 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 Locally configured names MAY contain the wildcard character to match a
range of values.  The types of wildcards supported MAY be more flexible
than that which is allowed in subject names 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.

Thanks,

Joe
> Sent: Wednesday, September 10, 2008 6:03 AM
> To: [email-masked]; Chris Lonvick (clonvick)
> Cc: [email-masked]
> RE:Needyourinput on finalissuesondraft-ietf-syslog-transport-tls
> 
> Have we just introduced 'certificate subjects' where 
> previously we have used 'subject names' eg as in the heading 
> of this section? I assume that both refer to the same 
> concept, in which case I would prefer 'than that which is 
> allowed in subject names'.
> 
> Tom Petch
> 
> 
> RE: Needyourinput on finalissuesondraft-ietf-syslog-transport-tls
> 
> 
> >
> > normal case first, and special cases (wildcards in cert, 
> wildcards in 
> > local name) next?
> >
> > > > Switching the order of the 1st (wildcards) and 2nd 
> > > > (subjectaltname) bullets would IMHO make the flow more logical. 
> > > > Otherwise,
> > > looks good.
> > > >
> > >
> > > bullet (subjectAltName) contains the line, "Locally 
> configured names 
> > > MAY contain the wildcard character to...".  I'm thinking that the 
> > > It could be swapped with a reference such as the following placed 
> > > into the subjectAltName bullet, "Locally configured names MAY 
> > > contain the wildcard character (see next bullet) to...".
> > >
> > > >> [mailto:[email-masked]] On Behalf Of ext 
> Joseph Salowey 
> > > >> (jsalowey)
> > > >> RE: Need yourinput on 
> > > >> clarified the ACE conversion is for comparison, and change the 
> > > >> ordering of the bullets. I think this text should be 
> pretty close 
> > > >> now.
> > > >>
> > > >>     In addition they MUST support specifying the 
> authorized peers 
> > > >> using
> > > >>       o The '*' (ASCII 42) wildcard character is 
> allowed in the 
> > > >> dNSName of
> > > >>         SHOULD support checking the name against the 
> common name 
> > > >> portion of
> > > >>         certificate subjects to make it possible to support 
> > > >> various policies
> > > >>> Need your input on 
> > > >>> 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.
> > > >>>
> > > >>> ===
> > > >>>         name against a dNSName in the subjectAltName 
> extension 
> > > >>> field and
> > > >>>         SHOULD support checking the name against the 
> common name 
> > > >>> portion of
> > > >>>         4.2.1.6.  A match occurs if this octet string 
> is equal 
> > > >>> to the value
> > > >>>       o The '*' (ASCII 42) wildcard character is 
> allowed in the 
> > > >>> dNSName of
> > > >>>         Compatible Encoding (ACE) format as specified 
> in Section 
> > > >>> 7 of RFC
> > > >>>         5280.
> > > >>>
> > > >>> ===
> > > >>>

---

From: "Rainer Gerhards" <[email-masked]>
Date: Tue, 16 Sep 2008 10:57:24 +0200

Fine with me.

Rainer

> Sent: Tuesday, September 16, 2008 12:44 AM
> To: tom.petch; [email-masked]; Chris Lonvick (clonvick)
> Cc: [email-masked]
> Subject: Re: [Syslog] revised 5.2 text : please comment
> was:RE:Needyourinput on finalissuesondraft-ietf-syslog-transport-tls
> 
> In
> name
host
> a
> Section
string
host
of
extension