Re: [security-services] LDAP Attribute Profile (saml-profiles-saml2.0)

[Greg Whitehead <greg.whitehead@hp.com>]

I'm willing to believe that the intention was to include the ASN.1  
octet string wrapper, but I won't say that I'm not disappointed.  
Perhaps I'm missing the value that it adds (none that I can see).

I assume that, following LDAP, the basic encoding rules (BER) would  
be used for the octet string wrapper. e.g.
	05 <len> <bytes>

Of course, <len> is a variable byte encoding (<128 fits in one byte).

We definitely need an errata item for this.

Another nit, which probably deserves a separate thread, is that the  
LDAP attribute profile sets a bad design precedent in my opinion.  
Namely, it is impossible to know that the LDAP attribute profile has  
been used without first knowing about the LDAP attribute profile. Let  
me explain with an example:

> <saml:Attribute
> xmlns:x500="urn:oasis:names:tc:SAML:2.0:profiles:attribute:X500"
> NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri"
> Name="urn:oid:0.9.2342.19200300.100.1.60" FriendlyName="jpegPhoto">
> <saml:AttributeValue xsi:type="xs:base64Binary"
> x500:Encoding="LDAP">...</saml:AttributeValue>
> </saml:Attribute>

1) The NameFormat is urn:oasis:names:tc:SAML:2.0:attrname-format:uri,  
which is a generic format that could be used in any profile. This in  
itself is not a problem, but it means that the AttributeValue  
encoding has to be self-describing.

2) The ONLY clue we have that the AttributeValue is encoded using the  
X500/LDAP profile is an attribute in the profile namespace  
(x500:Encoding). Unless we know to look for that attribute, or we  
search for all attributes that we don't understand and throw up our  
hands if any are found, there is NO way to know what crazy encoding  
rules have been applied to the AttributeValue (such as ASN.1 octet  
string wrappers).

This strikes me as a very poor design pattern. It would be much  
better to have a well known Format/Encoding attribute on  
AttributeValue that unambiguously instructs the receiver on how to  
process the value.

-Greg

On Jan 13, 2006, at 9:30 AM, Scott Cantor wrote:

>> The way I read it, you *do* include the ASN.1 wrapper.
>> Strictly compliant LDAP servers don't store arbitrary binary
>> data in attributes (though some servers let you get away with
>> it). My reading of the text is that you're supposed to take
>> the attribute blob you got from LDAP, which is the JPEG
>> *with* an ASN.1 wrapper, and base64 the whole thing.
>>
>> If that's not what the profile author intended (or even if it
>> is) we probably need an erratum to clarify.
>
> My perspective is LDAP-ignorant, so assuming that at least some other
> implementers share that ignorance, we definitely need to clarify it.
>
> The actual text was worked over by a colleague that Bob Morgan  
> contacted
> that does have the necessary expertise, so I would tend to trust the
> interpretation of anybody that shares it.
>
> -- Scott
>