[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]