OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

xacml message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: RE: [xacml] IP Address comparisons


Actually this behavior is specified in RFC 2818 (Section 3.1), which although it is Informational, is widely cited, including in Standards Track RFCs. (Although RFC 2818 dates from May 2000, it has never been updated or obsoleted.)

 

However if you look at the Errata for 2818 (http://www.rfc-editor.org/errata_search.php?rfc=2818) it turns out that there is controversy over the very issue I mentioned.

 

Also note that RFC 2818 allows constructs like f*.com to match foo.com, but not bar.com. This syntax is not currently permitted by XACML.

 

Finally to save people time, RFC 2818 says: “Matching is performed using the matching rules specified by [RFC2459]. I looked at that and it does not cover wildcards. (Actually it explicitly excludes wildcards in subjectAltName and does not discuss their use anywhere else. I suspect that the authors of 2459 knew or believed that “*” was not legal in the subject field, which must contain distinguished name(s) per some X.509 spec. This is a minor conflict with 2818, which seems to imply that either subject and subjectAltName can contain wildcards.)

 

Hal

 

 

From: Bill Parducci [mailto:bill@parducci.net]
Sent: Tuesday, October 01, 2013 11:26 AM
To: Hal Lockhart
Cc: Danny Thorpe; xacml@lists.oasis-open.org
Subject: Re: [xacml] IP Address comparisons

 

On Oct 1, 2013, at 7:51 AM, Hal Lockhart <hal.lockhart@oracle.com> wrote:



It is less clear to me whether *.mail.example.com matches mail.example.com. I believe the answer is no.

 

Anecdotally, SSL certificates support wildcard matches. A "*" cert for xacml.org matches "www.xacml.org" and "xacml.org", but it will NOT match "foo.www.xacml.org". The wildcard _expression_ only supports a single subdomain level (and the root for which it is generated).

 

I suggest that we consider following this model for the sake of consistency (even though from a regex perspective it is kinda nutty).

 

b



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]