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

 


Help: OASIS Mailing Lists Help | MarkMail Help

saml-dev message

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


Subject: RE: [saml-dev] RE: [x500standard] Re: SAML V2.0 X.500/LDAP Attribute Profile


> The new LDAP profile "supersedes the erroneous profile in [SAML2Prof]",
> and states that asserting and relying party implementations conform to
> the profile if they are consistent with the normative text of section 2.
> But because the profile uses a mixture of RFC 2119 requirement levels
> and descriptive text, determining which text is normative is a
> challenge.

You can't put the word MUST everywhere, no spec does. That said, the
conformance clause had to be added to satisfy OASIS, and basically no
thought went into it at all. The intent of it is "follow the spec", which is
just silly; that's self-evident in this case.

> For example, the NameFormat MUST be urn:...:uri, but to construct
> attribute names, the URN oid namespace "is used", and the
> FriendlyName attribute "plays no role" in the comparison.  Although no
> reasonable person could argue with the intent of this text, experience
> says that it is better to have standards resistant to attack even from
> unreasonable people :-)

Well, my experience is that that's a hopeless goal because unreasonable
people have an agenda and don't let text (or reality) get in their way.
Lawyering is just something standards implementers have to deal with.

If something is actually unclear, errata can be written, but practically
speaking, we're out of public review here (people just had 60 days to
comment) and we just voted this to CS. It isn't coming back out again, at
least not with me as editor right now.

> Could the profile mark every normative requirement with a requirement
> level, e.g. "To construct attribute names, the URN oid namespace ...
> MUST be used", and "The FriendlyName attribute SHOULD NOT be sent and
> MUST play no role in the comparison"?

See above, but I disagree with you on that last point anyway.
 
> From a security perspective,
> every non-validated input accepted from another party is a
> vulnerability, so applications should not just accept FriendlyNames at
> face value and display them.

The FriendlyName is a helpful aid in debugging when OIDs are used, and we
intended to allow it. We never intended anybody would "accept" them in any
other way and that kind of issue is simply a general security guideline. A
sentence could easily be added to core or the security considerations doc as
errata to clarify that, I would think.
 
> From a usability perspective, displaying
> FriendlyNames in the sender's language inhibits i18n; instead relying
> applications should generate FriendlyNames in the receiver's language
> from the OID.

FriendlyName is not really for display. I don't think core says anything
like that.
 
> And from an efficiency perspective, EFX schema-based
> compression is impaired by both free text elements and redundant
> content.

I don't know that that is, and I'm not aware of any role it plays in SAML at
the moment. But it seems like that's a simple matter of just not using
FriendlyName in cases where it impacts deployment.
 
> A quick scan shows new informative sentences on Tagging options in 2.3
> and 2.3.1 and the Encoding attribute moved from <AttributeValue> to
> <Attribute>.  Does the change in location of Encoding completely address
> the problem of "well-formed but schema-invalid XML" in the original
> profile, or are other changes required?

Yes, it addresses that problem. That's why the profile was redone. The
tagging issue wasn't even known at the time. The only intended change was
just to move the attribute.

-- Scott




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