Russ Housley <housley@xxxxxxxxxxxx> 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@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf