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: [thread on X.500/LDAP attribute values in SAML 2.0 profile]


As background, a thread among some of us on this topic.  I'll be posting
proposed resolution shortly.

 - RL "Bob"
--- Begin Message --- 


I'm not sure who cares about this issue, so I'll start with y'all since
I'm still poking at it.

As discussed in Toronto (according to the minutes), Prateek's language (I
assume it was his), now incorporated into section 9.3 of
profiles-draft-12, about attribute values, says that since in the LDAP
protocol an attribute value is always syntactically an octet string, that
these attribute values, when put into the content of SAML AttributeValue
elements, will always use the XML hexbinary primitive type.  This is
obviously simple, but has the drawback that even LDAP/X.500 attributes
whose values are just (UTF-8) strings would have their values encoded in
hexbinary.  This may not be a showstopper, but it's the sort of thing that
makes implementors either get it wrong (I mean, cmon, just send the
string) or will cause folks to redefine their LDAP attributes for use in
SAML (as we did with eduperson, more or less) so as to avoid the lossage.

I observe that DSML 2.0 defines attribute values with:

  <!-- **** DSML Value **** -->
    <xsd:simpleType name="DsmlValue">
      <xsd:union memberTypes="xsd:string xsd:base64Binary
       xsd:anyURI"/>
    </xsd:simpleType>

So a value can be a string, or base64Binary (which I suppose I would
suggest rather than hexBinary), or a URI.  DSML doesn't offer any guidance
(that I can see) about how or why an implementation would pick one of
these types to use in any particular situation.  Presumably the idea was
that strings could be sent as strings, and other stuff could be sent as
binary (and certs as URIs ...).

A lofty goal in this space would be for the semantics of attribute types
defined for LDAP/X.500 to be made available as XML schema so use of
attributes in XML could be fully schema-supported.  This is among the
goals of the XED work, http://www.xmled.info/, and many I-Ds:

draft-legg-xed-schema-02.txt
draft-legg-xed-glue-02.txt
draft-legg-xed-rxer-02.txt
draft-legg-xed-asd-02.txt
draft-legg-xed-protocols-02.txt
draft-legg-xed-roadmap-03.txt

by Steven Legg et al.  The RXER draft in particular covers encoding in XML
of ASN.1 objects (especially those used in X.500?), in such as a way as to
make the resulting values XML-Schema-compatible (or something like that).
This is vast and fine work, but is still work-in-progress, and it's not
clear whether the IETF has any interest in standardizing it (hmm, maybe
another OASIS TC ...).  It would be nice to leave wiggle room to permit
the encodings define by this work to be used easily in SAML at some later
date.

So at the moment I'm interested in seeing whether the DSML approach (minus
the URI thing) can be enhanced slightly to make clear when to use strings
and when not, in some fashion that wouldn't require several pages of text.
But I don't have time to go into it more right now, and I'm headed on a
two-day vacation shortly, so let me toss out these ideas for your
reaction.  Obviously this needs to be wound up quickly if it's to be
included in SAML 2.0.

 - RL "Bob"
--- End Message ---
--- Begin Message --- 

> I'm not sure who cares about this issue, so I'll start with 
> y'all since I'm still poking at it.

I'm about to start work on the attribute profiles, so good timing.

> I observe that DSML 2.0 defines attribute values with:
> 
>   <!-- **** DSML Value **** -->
>     <xsd:simpleType name="DsmlValue">
>       <xsd:union memberTypes="xsd:string xsd:base64Binary
>        xsd:anyURI"/>
>     </xsd:simpleType>

I think that's generally speaking a reasonable approach following the 80/20
or maybe 90/10 rule.

> by Steven Legg et al.  The RXER draft in particular covers encoding in XML
> of ASN.1 objects (especially those used in X.500?), in such as a way as to
> make the resulting values XML-Schema-compatible (or something like that).

I'm not sure schema-specified and "expressed in the way most palatable by
XML processors and attribute consumers" are the same goal, however.

> So at the moment I'm interested in seeing whether the DSML approach (minus
> the URI thing) can be enhanced slightly to make clear when to use strings
> and when not, in some fashion that wouldn't require several pages of text.

I can try and come up with something suitable vague, I guess.

-- Scott
--- End Message ---
--- Begin Message --- 

I think this language sucks, but it's all I could do on short notice. We can
play with it in last call. Since I don't know much about LDAP syntaxes, I
can't say for sure how wiggly "easily be expressed" really is.

-- Scott

"The canonical representation for X.500/LDAP attribute syntaxes is an octet
string. However, to simplify the job of the attribute consumer, any
X.500/LDAP attribute syntax that can easily be expressed in string form
SHOULD be passed as a string, with no additional whitespace. In such cases,
the xsi:type XML attribute MUST be set to xsd:string.

Examples of such attribute syntaxes are those with string, numeric, or
date/time values. Date/time values MUST be expressed in UTC form.

Any attribute value (particularly those without a reasonable string form,
such as binary data) MAY be passed by base64-encoding the octet string and
specifying an xsi:type XML attribute of xsd:base64Binary. The  xsi:type XML
attribute MUST be present in such cases.

As additional standards in the expression of X.500/LDAP attribute syntaxes
in XML form develop, this profile may evolve to incorporate such
approaches."
--- End Message ---
--- Begin Message --- 

RL 'Bob' Morgan wrote:
 > I'm not sure who cares about this issue, so I'll start with y'all since
 > I'm still poking at it.

I've done a little bit of research on it too. mucho thanks for putting this all 
together, and especially for the refs to the xed stuff.

fwiw, IMHO, your msg should simply be sent to the sstc list, as should my 
forthcoming response(s) to Scott's responses.


 > As discussed in Toronto (according to the minutes), Prateek's language (I
 > assume it was his), now incorporated into section 9.3 of
 > profiles-draft-12, about attribute values, says that since in the LDAP
 > protocol an attribute value is always syntactically an octet string,

given careful reading of RFCs 2251 and 2252, that assertion..

   "an (LDAP) attribute value is always syntactically an octet string"

..is only sorta correct.


 > that
 > these attribute values, when put into the content of SAML AttributeValue
 > elements, will always use the XML hexbinary primitive type.  This is
 > obviously simple, but has the drawback that even LDAP/X.500 attributes
 > whose values are just (UTF-8) strings would have their values encoded in
 > hexbinary.

agreed that this is likely a lose.

 > This may not be a showstopper, but it's the sort of thing that
 > makes implementors either get it wrong (I mean, cmon, just send the
 > string) or will cause folks to redefine their LDAP attributes for use in
 > SAML (as we did with eduperson, more or less) so as to avoid the lossage.

hm, AFAICT that should be "..potential for lossage."

AFAICT, "hexbinary" should work just fine in the XML/SOAP/HTTP world. It 
appears from reading of RFC2045 and such that base64 was invented for the 
(edge) cases where (SMTP) data was handled, and perhaps translated into local 
charset form and then back to ASCII, by arcane systems whose native string 
encoding scheme was not ASCII (read: EBCDIC-based systems) and in which 
conveyance context record lengths were sometimes fixed (can you say "RECL=80"?)

Anyway, hexbinary would yield shorter encoded stings than base64binary, and 
there likely isn't any great difference in xlation performance. If anything I'd 
think it'd be faster.

But, there's perhaps some edge case I'm not seeing here that'd make 
base64binary work "better" overall?  eg shipping SOAP msgs over SMTP?  (how 
many folks are gonna do that?)


 > I observe that DSML 2.0 defines attribute values with:
 >
 >   <!-- **** DSML Value **** -->
 >     <xsd:simpleType name="DsmlValue">
 >       <xsd:union memberTypes="xsd:string xsd:base64Binary
 >        xsd:anyURI"/>
 >     </xsd:simpleType>
 >
 > So a value can be a string, or base64Binary (which I suppose I would
 > suggest rather than hexBinary), or a URI.  DSML doesn't offer any guidance
 > (that I can see) about how or why an implementation would pick one of
 > these types to use in any particular situation.  Presumably the idea was
 > that strings could be sent as strings, and other stuff could be sent as
 > binary (and certs as URIs ...).

If ya dig thru RFC2251 & 2252, one can conclude that in most cases one'd simply 
take LDAP attr values that're based entirely on Directory Strings (which 
indicate's they're UTF-8 encoded) -- one has to unwrap them from their ASN.1 
OCTET STRING wrapper first -- and then stuff that directly into the SAML 
XML-based element at hand, and ship it.

For LDAP attr values that have more complex internal structure with 
non-Directory String(-based) components, or are simply arbitary (binary) blobs 
(eg "Certificate"), one'd then need to use some form of encoding (eg hexbinary) 
  of the entire LDAP attr value (probably easiest to just encode the entire 
ASN.1 OCTET STRING-wrapped blob), and stuff that into the SAML XML-based 
element at hand.

I've hacked up a build on Scott's suggested language that I'll send out.

HTH,

JeffH
--- End Message ---
--- Begin Message --- 

Scott Cantor wrote:
 > I think this language sucks, but it's all I could do on short notice. We can
 > play with it in last call. Since I don't know much about LDAP syntaxes, I
 > can't say for sure how wiggly "easily be expressed" really is.

I think this is in the correct direction based on my research on this topic, so 
thanks for hacking it up. I have the following builds on the proposed text. no 
time right now to include elaborate rationale, altho it is all in the LDAP 
RFCs, but it is somewhat confusing at first glance (eg very roughly speaking 
there are several layers of "string"s in the LDAP world that are built on each 
orther and/or wrap each other).

HTH,

JeffH

 > "The canonical representation for X.500/LDAP attribute syntaxes is an octet
 > string. However, to simplify the job of the attribute consumer, any
 > X.500/LDAP attribute syntax that can easily be expressed in string form
 > SHOULD be passed as a string, with no additional whitespace. In such cases,
 > the xsi:type XML attribute MUST be set to xsd:string.

The canonical on-the-wire encoding of X.500/LDAP attribute values, as conveyed 
via the LDAP protocol [RFC2251], is as ASN.1 OCTET STRINGs. However, X.500/LDAP 
attribute values are not necessarily stored in LDAP servers in the same form as 
they are transferred in LDAP protocol, and they also may have arbitarily 
complex internal structure, as described by their corresponding attribute 
syntaxes [RFC2252].

Thus, in order to simplify the job of SAML attribute consumers,
X.500/LDAP attributes whose LDAP attribute syntax is that of Directory String 
               (OID: 1.3.6.1.4.1.1466.115.121.1.15), or is constructed from a 
collection of subparts of syntax Directory String, SHOULD be passed in SAML as 
XML string values, with no additional whitespace. In such cases, the
xsi:type XML attribute MUST be set to xsd:string.


 > Examples of such attribute syntaxes are those with string, numeric, or
 > date/time values. Date/time values MUST be expressed in UTC form.

[the above para is covered, it seems to me, by the language in the above two 
suggested paragraphs. ie string, numeric, or date/time values in the LDAP world 
are typically based sytactically on Directory String. so I'd delete that para.]


 > Any attribute value (particularly those without a reasonable string form,
 > such as binary data) MAY be passed by base64-encoding the octet string and
 > specifying an xsi:type XML attribute of xsd:base64Binary. The  xsi:type XML
 > attribute MUST be present in such cases.

LDAP Attribute values whose LDAP syntax is either not based entirely on 
Directory String, and/or are not explicitly noted as a "human readable string" 
(e.g. "Certificate") [RFC2252] SHOULD be conveyed in SAML by base64-encoding 
[RFC2045] the encompassing ASN.1 OCTET STRING-encoded LDAP attribute value and 
specifying an xsi:type XML attribute of xsd:base64Binary.

 > As additional standards in the expression of X.500/LDAP attribute syntaxes
 > in XML form develop, this profile may evolve to incorporate such
 > approaches."

[no suggested builds on this para]


---
end
--- End Message ---

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