comment on SAML V2.0 X.500/LDAP Attribute Profile: non-string encoding

[Mark Wahl <Mark.Wahl@informed-control.com>]

Hello, Section 2.5 of "SAML V2.0 X.500/LDAP Attribute Profile"
Committee Draft 01, 19 December 2006, states that

"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."

This specification is ambiguous because of the term "encompassing".

Suppose there is a value of an attribute userCertificate;binary.
The bytes of this value are the bytes of the BER encoding of a
Certificate. The first byte of the value will be a byte that
encodes a SEQUENCE tag, since the outermost encoding of a
Certificate is a SEQUENCE.

I would have assumed, as this is how LDIF and other formats handle
base64 encoding of LDAP values, that the string encoding is the
base64 encoding of the attribute value.  If I receive such an encoded
value and undo the base64 encoding, the first byte of a certificate
will be its SEQUENCE tag.

However, the phrase "OCTET STRING-encoded LDAP attribute value"
might give people the idea that the base64 encoding is of an
OCTET STRING, e.g. after unwrapping a base64 encoding of a received
Attributevalue element, the first byte is a OCTET STRING tag, the
second byte is the length, and so on, and the byte of the SEQUENCE
tag might not be until the third, fourth or fifth byte into the
encoding.  This doesn't seem useful as it requires additional ASN.1
encode and decode step for no apparent purpose, and hinders
interoperability.

Could this be changed to remove the phrase "encompassing ASN.1 OCTET
STRING-encoded"?  DSMLv2 doesn't have this phrase, and I don't think
it's needed here.

Thanks in advance,

Mark Wahl
Informed Control Inc.