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] LDAP Attribute Profile (saml-profiles-saml2.0)



On Mon, 16 Jan 2006, Greg Whitehead wrote:

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

Hmm, I'm not sure where the "encompassing ASN.1 OCTET STRING-encoded LDAP 
attribute value" phrase came from (I don't think it was provided by Steven 
Legg, my invited expert on this stuff).  But I think the intent here was 
as Greg says, to enable the use of the values directly, with the string 
encodings as commonly used in LDAP, and to get the ASN.1 out of the way. 
Part of the discussion at the time, as I recall, was whether model was 
that the SAML-producing component would be, as Irving suggests, an LDAP 
client, thus handling values coming in as LDAP PDUs, or whether the re-use 
is more at design time, to avoid another round of naming and specifying 
the same old attributes.  I think the conclusion was the latter (hence the 
option for non-LDAP encodings, potentially).  Part of the problem is that 
LDAP's handling of the underlying X.500/ASN.1 concepts is shall we say not 
particularly clean.  The descriptions are much better in the new round of 
ldapbis drafts that will be RFCs shortly (in particular 
draft-ietf-ldapbis-syntaxes-11.txt) but there are still some conceptual 
difficulties, in particular with octet-string-valued attributes (you don't 
want to know about the debates regarding cert-handling).

So, I would say the point is not to burden a SAML attribute recipient with 
the ASN.1 OCTET STRING wrapping, since we are replacing that wrapping with 
xs:base64Binary.  Irving said his product does include the wrapper, so it 
may be that the TC will have to consider whether clarifying this can be 
done with an erratum or whether it means doing a whole new profile.

  - RL "Bob"



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