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

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

I am certainly in favor of declaring the "encompasing ASN.1..." an  
error, if we can do that.

-Greg

On Jan 17, 2006, at 3:06 AM, RL 'Bob' Morgan wrote:

>
> 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"
>
>
> ---------------------------------------------------------------------
> To unsubscribe from this mail list, you must leave the OASIS TC that
> generates this mail.  You may a link to this group and all your TCs  
> in OASIS
> at:
> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php