|
From: Tycho F. <ty...@fr...> - 2002-06-25 06:51:07
|
On Tue, 2002-06-25 at 07:46, "Stormacq, S=E9bastien" wrote: > Hello, >=20 > Just a few remarks. > In a general, I do prefer refer to XML data as elements rather than attri= butes. > I use the follwoing convention : data are encoded as element and metadata= (data that describes the=20 > data are encoded as attributes) >=20 > I know that the attribute vs element debate is a long one in the XML comm= unity and I don't expect to=20 > reach a settlement here ... > However, I do propose an alternate syntax here under... then I will join = the decision taken by the=20 > majority of us :-) > I'd like to have a decision very quickly in order for me to continue the = proto development ... >=20 > > <opensst=20 > > version=3D"1" >=20 > missing a > here :-) >=20 >=20 > >=20 > >=20 > > <encryption > > type=3D"type description" > > keyid=3D"key id necessary for decryption" > > symmetric_key=3D"base64'd symmetric key encrypted to keyid" > > /> >=20 > here is an exemple of element encoding rather than attribute >=20 > <encryption> > <type>type description</type> > <keyid>key id necessary for decryption</keyid> > <symmetric_key>base64'd symmetric key encrypted to keyid</symmetric_k= ey> > </encryption> >=20 >=20 > Could you explain the symetric_key ? Is this the private (secret) key th= at is exchanged in each=20 > message ? ok . You encrypt a message with a (one-use-only) session key - every opensst message can stand on its own which is necessary for offline use of signed transactions. This (symmetric) key is then encrypted/garbled etc so that only the "right" user (with identifier "keyid") can decrypt the symmetric_key and get to the original message. > Is it not safer to exchange it once and keep it in memory somewhere on bo= th the client and server side ? no. Every message needs another key. >=20 > Shouldn't we also refer to the ascii-encoding process that was used to la= y down the cipher data ?=20 > (BASE64, UUENCODE, ...) Yes, this could be by definition base64 (a good reason to use attributes is to specify encoding details :-) >=20 > may be an element (attribute) <ascii-encoding>base64</ascii-encoding> wou= ld do the trick. seems a bit long for what it is supposed to do. <data encoding=3D"base64">blablablablabla</data> ? > > <envelope > > destination=3D"url where the thing should be sent to" > > > > >=20 > > <data> > > <tid=20 > > server=3D"<server_tid>"=20 > > client=3D"<client_tid>" > > /> >=20 > what does tid means ? > Here I would also suggest a element encoding rather than attributes transaction id. No problem with element encoding here (we might add some other things as well. >=20 > > <timestamp>....</timestamp> > > <datatype> > > web-form | > > authentication-message | > > key-enrollment | > > key-revocation | > > </datatype> > > ... data goes here ... > > </data> > > <signature=20 > > type=3D"X509 DN-RSA-SHA1"=20 > > id=3D"cn=3DMyName,o=3Dopensst,c=3DLU"=20 > > signature_time=3D"<timestamp"=20 > > signature=3D"behHf53132345"> > > /> >=20 > element rather than attributes for the signature ? > Same remark about the ascii encoding schema used. >=20 > > </envelope> > > </opensst> > >=20 > > You can have multiple signatures on one document, and multiple > > encryption. > > You can have multiple envelopes in one opensst transaction, each with > > other signatures. However, it is NOT possible to have multiple > > envelopes with different encryption profiles. Is this a problem ? >=20 >=20 > OK for me but how to you use "multiple enryption" as stated 4 lines above= ? multiple encryption =3D the data is encrypted with a random (one-time-use) symmetric message key. The message key is encrypted with the keyid of the recipient of the message. Multiple recipients mean multiple copies of this second encryption process. >=20 > > Putting the <encryption> tags within <envelope> does not really help > > because then we have a problem with which data must be encrypted and > > which not (eg. the encryption info cannot be encrypted or we won't be > > able to salvage it !). One solution is to have an extra layer in the > > hierarchy : > > <opensst> > > <envelope> > > <encryption /> > > <encryption /> > > <envelope-content> > > <data>...</data> > > <signature>...</signature> > > <signature>...</signature> > > </envelope-content> > > </envelope> > > </opensst> > >=20 > > what do you think ? >=20 > If multiple encryptions is the way to go, I think this is the most elegan= t way to express it. > However, I wonder the real usage that can be done of this feature. I bet= than 99% of the=20 > implementations won't use it. > Should we really care ? I don't know. Tycho |