[Opensst-developer] Re: SAML

[Alexandre D. <ad...@fo...>]

On Thu, 14 Aug 2003, Sebastien Stormacq - Senior Architect - Software Services Belux wrote:

> Hello,
> 
> Once again ... I think it migth be interresting to investigate the SAML 
> spec to replace / embrace the existing opensst message format
> 
> http://weblogs.java.net/pub/wlg/331
> 

SAML is  'mainly' of the exchange of  authentication and authorization
date in a XML format. SAML is only a part of Web Services security and
do  not provide 'directly'  a new  general format  for post-processing
message or signed messages. So I can't see where we can use it for the
message  format.   SAML  is a  friend  of  XACML.   SAML can  use  XML
Signature  /  XML  Encryption  standard  and  they  are  not  directly
connected.  

I tend to consider that  XML Signature / XML Encryption standard[3][4]
is a possible replacement for the current OpenSST message format. They
are implementation (one year ago  it wasn't the case) of XML Signature
/ XML Encryption  standard available and working quite  well.  For the
XML Security Library[1] done by Aleksey Sanin is an excellent piece of
software. They are  existing method and approch for  session key based
messages                                                              :
http://www.aleksey.com/xmlsec/api/xmlsec-encrypt-with-session-key.html. 

The main issue  is the complexity of the standard  itself, look at the
MUST/SHOULD keyword in the  standard. Sometimes (often?), the standard
is  not  fully  supported  by   lack  of  various  encryption  in  the
cryptography librairies[2] 

So building, a small message format using (a subset?) of XML Signature
/ XML Encryption seems quite possible. 

The main advantage of XML Sig/Enc  is that can be applied to arbitrary
digital  content. We  have also  to  dig the  Canonical and  Exclusive
Canonical  issue in  order  to provide  an  easy way,  they are  somes
libraries available doing that (for example, the example Gnome Libxml2
library). 

So we can imagine, an existing <OpenSSTdata part>/<OpenSSTheader part>
with  an enveloping signature  <Object><data id  part />  <header part
/></Object or a  detached signature (with an uri  reference inside the
document). 

For the encryption, we can  imagine an encryption on the whole element
(in  a first  version) of  OpenSSTdata part  (header to  ?  or another
encapsulated        header       part        ?).       <EncryptedData>
<CipherData><CipherValue>...<CipherValue>... 

The ordering is  easily solve by following the  ordering of decryption
and verification in the standard. (xmlenc-decrypt)

What do you think of that ? We have to define the data part (quite the
same as the current part ?) and the header part (is it needed?) ? 

Thanks,

Have a nice day,

adulau

[1] http://www.aleksey.com/xmlsec/
[2] http://www.aleksey.com/xmlsec/xmldsig.html 
[3] http://www.w3.org/TR/xmldsig-core/
[4] http://www.w3.org/TR/xmlenc-core/


-- 
-- 	  	     Alexandre Dulaunoy (adulau) -- http://www.foo.be/
-- 	   http://pgp.ael.be:11371/pks/lookup?op=get&search=0x44E6CBCD
-- 	   "Knowledge can create problems, it is not through ignorance
-- 				  that we can solve them" Isaac Asimov