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


Help: OASIS Mailing Lists Help | MarkMail Help

security-services message

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

Subject: RE: [security-services] proposed new text for X.500/LDAP attributeprofile

On Mon, 9 Aug 2004, Philpott, Robert wrote:

> > 8.2.2 SAML Attribute Naming
> >
> > The NameFormat XML attribute in <AttributeDesignator> and <Attribute>
> > elements MUST be urn:oasis:names:tc:SAML:2.0:attrname-format:uri.
> >
> > To construct attribute names, the URN oid namespace described in
> [RFC3061]
> [RSP] Should we put a MUST right here?

Well, my attitude is that you don't use MUST in the basic description of
whatever it is you're doing, you only use it at particular points where
you're constraining implementations among many otherwise reasonable
choices.  RFC 2119 says:

   Imperatives of the type defined in this memo must be used with care
   and sparingly.  In particular, they MUST only be used where it is
   actually required for interoperation or to limit behavior which has
   potential for causing harm (e.g., limiting retransmisssions)  For
   example, they must not be used to try to impose a particular method
   on implementors where the method is not required for

but obviously we toss around these keywords with great abandon.  Oh well.

> > attribute value.  Only one value of this attribute is defined at this
> > time: LDAP.  This specifies the use of the LDAP-specific encoding for
> this
> > X.500 attribute value, as described in section 8.2.5.
> [RSP] The encoding is really UTF-8, not "LDAP".  Perhaps we should
> create SAML identifiers such as
> "urn:oasis:names:tc:SAML:2.0:attr-encoding:LDAP-UTF8" to indicate it is
> UTF-8 as used in LDAP directories.

Actually "LDAP-specific encoding" is the precise term used in the revised
LDAP specifications, see draft-ietf-ldapbis-syntaxes-08.txt (it would be
nice to refer to this text, but unfortunately they're still drafts, even
though they're pretty much done).  It happens to be that LDAP syntaxes
generally specify that their output is UTF-8 strings, but it isn't
necessary.  There is unfortunately a funky kind of relationship between
the ASN.1 syntax definitions of the most commonly used attributes and
their LDAP syntax definitions.  The revised LDAP specs try to harmonize
these, and to present the LDAP syntaxes as just "encodings" of what are
the same underlying info objects.  There are rough edges to this, but it's
the only way to resolve various difficult specification issues with LDAP
and X.500.

> > 8.2.4 <AttributeDesignator> Comparison
> >
> > Two <AttributeDesignator> elements are equal if and only if their Name
> > attribute values are equal in the sense of [RFC3061]. The FriendlyName
> > attribute plays no role in the comparison.
> [RSP] It may be obvious, but the NameFormat values must also match,
> right?

Within this profile the NameFormat is always uri, so yes, it's obvious ...

> > For all other LDAP syntaxes, the attribute value is encoded, as the
> > content of the <AttributeValue> element, by base64-encoding [RFC2045]
> the
> > encompassing ASN.1 OCTET STRING-encoded LDAP attribute value. The
> xsi:type
> > XML attribute MUST be set to xsd:base64Binary.  The Encoding XML
> attribute
> > is provided, with a value of "LDAP".
> [RSP] Hmmm... I think, again, I'd prefer a different value for the
> Encoding attribute that identifies the encoding as base64Binary in this
> case, not "LDAP".

The fact that it's base64binary is in the xsd.  What we're specifying here
is how to handle the LDAP-specific encoding that is in the definition of
the attribute (for those that have them).

 - RL "Bob"

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