> ned+ietf@xxxxxxxxxxxxxxxxx wrote:
> > I completely disagree with this assessment. The points you mention are quite
> > specifically talking about Agreements, not certificates.
> Yes, this is obviously right, "Agreements" are not certificates. But I don't
> think it's clear that storing Agreements covers only "a fairly specific set of
> use cases."
Well, perhaps "specific set of use cases" was a bit strong, but OTOH I think
there are quite a few legitimate use cases that are pretty clearly allowed
under this license, such as the one Russ provided involving military
The question is whether or not the allowed use cases are sufficient to warrant
standardization. This is why I thought it would be interesting to see the
writeup - it might include statements of planned implementations and uses.
> Since Agreements include contracts and negotiable instruments, it
> seems that it could encompass most uses in e-commerce: for example an online
> store that requires buyers to use authorizations when making a purchase, and
> then stores the transaction details along with the authorization data.
> Sales transactions are a central use case for TLS, are they not?
For basic TLS, sure, it's a major use, if not the major use. For exchanging
additional authorization information, it's a lot less obvious. Again, the
applications I can envision wanting this extension for have nothing to do with
such agreements and nothing to do with e-commerce.
That said, I will also point point that from my perspective at least the real
issue I have with using this extension has more to do with how TLS is
implemented in real world applcations. This extension has to be implemented in
existing TLS libraries in order to be usable - if that's not going to happen
then the extension is useless to me. (Another reason the writeup might be
interesting to see.)
And even if this does get implemented there are still issues. I have a lot more
experience with nss than openssl, so maybe this doesn't apply to openssl, but
in complex server-side environemnts gettting at and using extension stuff in
nss is not exactly trivial. So given a choice between doing this exchange as
part of the application versus using this extension, the extension needs to
present some pretty compelling added value to be the preferred choice.
> If online
> sales using the authz extensions are not within the scope of term 3, I don't
> think it is at all clear from the IPR Statement, and the onus should be on
> RedPhone to clarify this. If they are, I think RedPhone's restrictions can
> hardly be said to apply only to corner cases.
I was quite careful not to make any such claim.
Ietf mailing list