ietf
[Top] [All Lists]

Re: Fourth Last Call: draft-housley-tls-authz-extns

2009-01-16 05:14:38
Russ Housley <housley(_at_)vigilsec(_dot_)com> writes:

Simon:

For the people who want this draft published (and perhaps have a pending
implementation), would you please humour me by offering some usage
scenarios, other than debugging or toys, which would meet security
review and which are not covered by the four points which the
patent-holder notes as potentially encumbered?

I'll offer one based on attribute certificates (see RFC 3281).  If the
attribute certificate policy does not use a critical certificate
policy identifier that is within an arc registered to RedPhone
Security (e.g. iso.org.dod.internet.private.enterprise.23106), then
the most straightforward deployments would not encounter problems with
this IPR Statement.  RFC 3281 specifies ways to carry access
identities, group memberships, roles, and clearances in attribute
certificates.  As long as these are not coupled to signed agreements
such as contracts, as is their normal use, then I cannot see problems
with this IPR statement.

What's the point of a certificate if you don't ultimately couple it with
a contract?  Identities, group memberships, roles, and clearances are
all attributes defined by non-technical, real-world agreements, often
documented in the form of a contract.

I can think of many that are not tied to contracts, especially in the
manner described in the paragraph numbered 2 in the IPR statement.
The authorization data needs to be used to "locate" the agreement.
I've worked with many identification and authorization systems, and
this is not a traditional aspect of any of them.

I can't think of any realistic complete scenario using RFC 3281, can you
describe it?  All attribute certificate system I've worked with uses
identities that ultimately can be chained back to a legal entity, which
will be bound to certain conditions through agreements.  The
authorization data can thus be used to "locate" this agreement.

Generally, I don't think we should standardize protocols that are known
to be encumbered by patents for some applications.

I've forwarded the patent disclaimer 1026 to the FSF/SFLC for review by
lawyers.  I would have felt more comfortable if the patent disclaimer
only contained its first paragraph.  Right now, it feels like it is
saying one (good) thing in the first paragraph.  The next paragraphs
appears to take away most of the substance by limiting the scope, and
using terms that are likely intended to be narrowly scoped but can be
read more broadly.

/Simon
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf