> 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 clearances. 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. Ned _______________________________________________ Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf