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.
There are two parts to your message. I'll try to respond to both.
EXAMPLE
Clearance may be the easiest one. For simplicity, let's assume that
the client are server already have X.509 identity
certificates. Assume the server is operated by the military, and it
includes some information that its wants to share with the public,
perhaps recruiting data, and information that is available to anyone
that has a clearance. This latter information is released to any
client that presents a valid attribute certificate that is bound to
the X.509 identity certificate used in client authentication and
issued by any of the military branches that demonstrates that the
client holds a clearance.
THE IPR STATEMENT
I think it was appropriate for RedPhone to provide insight into their
patent application. I'm not a lawyer, but the IPR statement is
telling the community the ways that this protocol (and It seems to
me, any authorization protocol that can has data that can "locate"
agreements) might infringe on the patent application. The major
point being that the protocol itself is not be focus of the patent application.
Russ
_______________________________________________
Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf