xacml — archive
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
— [Date Index]
| [Thread Index]
| [Month Index]
| [List Home]
[xacml] x500Name-match and rfc822Name-match specifications
rfc822Name-match xs:boolean xs:rfc822Name xs:rfc822Name
An rfc822 name consists of a <local-part> followed
by "@" followed by <domain>. The <local-part> is
case-sensitive, while the <domain> (which is usually a DNS host
name) is not case-sensitive.*
The first argument points to or specifies a particular complete
rfc822Name. The second argument is a complete or partial
rfc822Name used to select appropriate values in the first
argument as follows.
In order to match a particular mailbox in the first argument,
the second argument must specify the complete mail address to
be matched. For example, if the second argument is
"[email protected]", this matches a value in the first argument
of "[email protected]" and "[email protected]", but not
"[email protected]" or "[email protected]".
In order to match any mail address at a particular host in the
first argument, the second argument must specify that host name
(usually a DNS name). For example, if the second argument is
"sun.com", this matches a value in the first argument of
"[email protected]" or "[email protected]", but not
"[email protected]".
In order to match any mail address in a particular domain in
the first argument, the second argument must specify the
desired domain name with a leading ".". For example, if the
second argument is ".east.sun.com", this matches a value in the
first argument of "[email protected]" and
"[email protected]" but not "[email protected]".
* According to IETF RFC822 and its successor specifications
(RFC2821), case is significant in the <local-part>. Many
mail systems, as well as the IETF PKIX specification, treat
the <local-part> as case-insensitive. This is considered an
error by mail-system designers and is not encouraged. For
this reason, rfc822Name-match treats <local-part> as case
sensitive. x500Name-match
xs:boolean xs:x500Name
xs:x500Name
The string representation of an x500Name is specified in IETF
RFC 2253 "Lightweight Directory Access Protocol (v3): UTF-8
String Representation of Distinguished Names Names".*
IETF RFC 3280 "Internet
X.509 Public
Key Infrastructure
Certificate and Certificate Revocation List (CRL)
Profile",
Section 4.2.1.4 "Issuer" contains rules for matching x500Name
values.
The first argument contains a complete x500Name value. The
second argument contains a partial or complete x500Name value
used to select appropriate values in the first argument as
follows.
First, normalize the two arguments according to the RFC2253
syntax and according to the "subset of the name comparison
functionality" listed in IETF PKIX RFC3280, Section 4.1.2.4
"Issuer".
Next, if any Relative Distinguished Name contains multiple
attributeTypeAndValue pairs, re-order the AttributeValuePairs
in that Relative Distinguished Name in ascending order when
compared as octet strings (described in ITU-T Rec. X.690 (1997
E) Section 11.6, "Set-of components").
Finally, x500name-match returns true if all Relative
Distinguished Names in the second argument are equal, using
byte-by-byte integer-equal, to a trailing subset of the
Relative Distinguished Names in the first argument.
* An earlier RFC, RFC 1779 "A String Representation of
Distinguished Names", is less restrictive, so xacml:x500Name
uses the syntax in RFC 2253 for better interoperability.
** ITU-T Rec. X.520 contains rules for matching X500 names, but
these are very complex and require knowledge of the syntax of
various AttributeTypes. IETF RFC 3280 contains simplified
matching rules that the XACML x500Name-match function uses.
--
Anne H. Anderson
Email: [email protected]
Sun Microsystems Laboratories 1 Network Drive,UBUR02-311
Tel: 781/442-0928
Burlington, MA 01803-0902 USA
Fax: 781/442-1692
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
— [Date Index]
| [Thread Index]
| [Month Index]
| [List Home]