Re: [Opensst-developer] Proposed message format (outline :-)

[Tycho F. <ty...@fr...>]

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