--Apple-Mail=_B6401857-FE32-45EF-A393-65E1C90F6FC1
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
charset=us-ascii
Hi Alia,
Just a remark on your comment about section 3.1: I think the current =
requirement of associating a single secondary identity per connection =
does make sense if we want to keep traceability over I2RS secure =
transports.=20
You need to associate secondary identities with primary ones in a secure =
way to guarantee such traceability, and the mechanisms for this I can =
imagine using current transports (such as a certificate extension or =
alternate identity, or additional information in secure tokens) are =
associated with connection handshake, and therefore re-association is =
complicated to implement without restarting the connection. Note I say =
complicated, not impossible, but I cannot see the advantage in the =
additional complexity, especially when experience shows that additional =
complexity becoming source of security flaws...
Be goode,
On 11 Jun 2015, at 22:11 , Alia Atlas <[email protected]> wrote:
> <no-hat>
>=20
> Sue,
>=20
> Thanks for writing this draft. I think it is useful to clearly =
articulate the outside-of-I2RS behavior and protocols that are needed =
for the mutual authentication. I do have a couple comments on the =
draft.
>=20
>=20
> In Sec 3.1, it says "Each Identity will be linked to one secondary =
identity for the period of a connection." I would have assumed that the =
client could arbitrarily change its' secondary identity. This is to =
support the broker case where a client may be passing along requests =
from multiple applications. Since the secondary identity is just passed =
along and stored for traceability, I don't think that allowing it to =
change would cause significant complications. What do others think?
>=20
>=20
> In the I2RS architecture, there are 3 different types of transaction =
behavior desired for processing a message. In Sec 4, there's an =
assumption that "fail-on-error" with the associated roll-back is the =
only mode. Thus, I think that Section 4 needs a bit of massaging.
>=20
>=20
> Thanks,
>=20
> Alia
> _______________________________________________
> i2rs mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/i2rs
--
"Esta vez no fallaremos, Doctor Infierno"
Dr Diego R. Lopez
Telefonica I+D
http://people.tid.es/diego.lopez/
e-mail: [email protected]
Tel: +34 913 129 041
Mobile: +34 682 051 091
----------------------------------
--Apple-Mail=_B6401857-FE32-45EF-A393-65E1C90F6FC1
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
charset=us-ascii
<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html =
charset=3Dus-ascii"></head><body style=3D"word-wrap: break-word; =
-webkit-nbsp-mode: space; -webkit-line-break: after-white-space;">Hi =
Alia,<div><br></div><div>Just a remark on your comment about section =
3.1: I think the current requirement of associating a single secondary =
identity per connection does make sense if we want to keep traceability =
over I2RS secure transports. </div><div><br></div><div>You need to =
associate secondary identities with primary ones in a secure way to =
guarantee such traceability, and the mechanisms for this I can imagine =
using current transports (such as a certificate extension or alternate =
identity, or additional information in secure tokens) are associated =
with connection handshake, and therefore re-association is complicated =
to implement without restarting the connection. Note I say complicated, =
not impossible, but I cannot see the advantage in the additional =
complexity, especially when experience shows that additional complexity =
becoming source of security flaws...</div><div><br></div><div>Be =
goode,</div><div><br><div><div>On 11 Jun 2015, at 22:11 , Alia Atlas =
<<a href=3D"mailto:[email protected]";>[email protected]</a>> =
wrote:</div><br class=3D"Apple-interchange-newline"><blockquote =
type=3D"cite"><meta http-equiv=3D"Content-Type" content=3D"text/html; =
charset=3Dutf-8"><div dir=3D"ltr"><no-hat><br><br>Sue,<br><br>Thanks=
for writing this draft. I think it is useful to clearly =
articulate the outside-of-I2RS behavior and protocols that are needed =
for the mutual authentication. I do have a couple comments on the =
draft.<br><br><br>In Sec 3.1, it says "Each Identity will be linked to =
one secondary identity for the period of a connection." I would =
have assumed that the client could arbitrarily change its' secondary =
identity. This is to support the broker case where a client may be =
passing along requests from multiple applications. Since the =
secondary identity is just passed along and stored for traceability, I =
don't think that allowing it to change would cause significant =
complications. What do others think?<br><br><br>In the I2RS =
architecture, there are 3 different types of transaction behavior =
desired for processing a message. In Sec 4, there's an assumption that =
"fail-on-error" with the associated roll-back is the only mode. =
Thus, I think that Section 4 needs a bit of =
massaging.<br><br><br>Thanks,<br><br>Alia</div>
_______________________________________________<br>i2rs mailing =
list<br><a =
href=3D"mailto:[email protected]";>[email protected]</a><br>https://www.ietf.org/ma=
ilman/listinfo/i2rs<br></blockquote></div><br><div =
apple-content-edited=3D"true">
<div style=3D"color: rgb(0, 0, 0); letter-spacing: normal; orphans: =
auto; text-align: start; text-indent: 0px; text-transform: none; =
white-space: normal; widows: auto; word-spacing: 0px; =
-webkit-text-stroke-width: 0px; word-wrap: break-word; =
-webkit-nbsp-mode: space; -webkit-line-break: =
after-white-space;">--<br>"Esta vez no fallaremos, Doctor =
Infierno"<br><br>Dr Diego R. Lopez<br>Telefonica I+D<br><a =
href=3D"http://people.tid.es/diego.lopez/";>http://people.tid.es/diego.lope=
z/</a><br><br>e-mail: [email protected]<br>Tel: =
+34 913 129 041<br>Mobile: +34 682 051 =
091<br>----------------------------------</div>
</div>
<br></div></body></html>=
--Apple-Mail=_B6401857-FE32-45EF-A393-65E1C90F6FC1--
________________________________
Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario, puede
contener información privilegiada o confidencial y es para uso exclusivo de la
persona o entidad de destino. Si no es usted. el destinatario indicado, queda
notificado de que la lectura, utilización, divulgación y/o copia sin
autorización puede estar prohibida en virtud de la legislación vigente. Si ha
recibido este mensaje por error, le rogamos que nos lo comunique inmediatamente
por esta misma vía y proceda a su destrucción.
The information contained in this transmission is privileged and confidential
information intended only for the use of the individual or entity named above.
If the reader of this message is not the intended recipient, you are hereby
notified that any dissemination, distribution or copying of this communication
is strictly prohibited. If you have received this transmission in error, do not
read it. Please immediately reply to the sender that you have received this
communication in error and then delete it.
Esta mensagem e seus anexos se dirigem exclusivamente ao seu destinatário, pode
conter informação privilegiada ou confidencial e é para uso exclusivo da pessoa
ou entidade de destino. Se não é vossa senhoria o destinatário indicado, fica
notificado de que a leitura, utilização, divulgação e/ou cópia sem autorização
pode estar proibida em virtude da legislação vigente. Se recebeu esta mensagem
por erro, rogamos-lhe que nos o comunique imediatamente por esta mesma via e
proceda a sua destruição
_______________________________________________
i2rs mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/i2rs
