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

[Russ Housley <[e-mail]>]

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 mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/ietf