[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [TLS] Document Action: 'TLS Elliptic Curve Cipher Suites with SHA-256/384 and AES Galois Counter Mode' to Informational RFC



If there is any uncertainty, the the proper course of action is to
disclose the possibility (because its relevant), and then contact the
patent holder. Infringing the patent because you "can't be certain",
doesn't exempt one from the criminal penalties of intentional
infringement, nor the civil penalties of unintentional infringement.
Otherwise, everyone would simply claim that they "weren't certain", and
just ignore patents altogether. Instead, one's obligation is to get
certainty, or get permission.  "Uncertainty" is a frivolous assertion
that also doesn't exempt one from the law or from following RFC3979.

If one wants to dispute a specific patent claim, that's your
business--there are procedures for doing that--I encourage that.  
However, deceiving the internet community into unwitting and unwilling
patent infringement is not a proper (or lawful) method of fighting
patents. But I don't think the authors or IETF managers intend to
secretly fight patents through failure to disclose these patents to the
internet community.  I don't think object of the present
misrepresentation is to get the internet community to unwittingly
infringe, and subsequently be forced to help fight the Certicom patents.

In the TLS-Authz case, at least, the author (Housley) was working
directly for the patent holder.  I don't think Housley intended to (by
the misreprentation of TLS-Authz patent status)  fight the patent by
secretly imposing the burden of disputing the TLS-Authz patent on the
internet community.

Failure to disclose the patents prevents the internet community from
looking for and finding non-infringing alternatives.  Non-infringing
alternatives is by far the cheapest method of fighting patents.  
RFC3979 requires disclosure and requires that a discussion of
non-patented alternatives take place. A submarine-patented standard
obtained through deception is the very worst scenario--except for the
patent holder--who can make a _LOT_ of money on a patented STANDARD that
they own and that everyone else is forced to use or committed to using.


		--Dean

On Fri, 27 Jun 2008, Dan Harkins wrote:

> 
>   Dean,
> 
> On Fri, June 27, 2008 10:02 am, Dean Anderson wrote:
> > On Fri, 27 Jun 2008, Russ Housley wrote:
> >
> >> >Indeed, it appears to be the case that I was correct on the principle
> >> >issue:  That the general public is not licenced to use these patents on
> >> >implementing this draft.
> >>
> >> Right.  This is the reason the document is a candidate for the
> >> standards track.
> >
> > So, you (Russ--chair of IETF) knew of the patent encumbrances, but
> > failed to report those facts in an IETF 'IPR' (patent) disclosure?  And
> > the WG failed to discuss non-patent alternatives in the working group as
> > required by RFC3979?  This seems to be almost the same issues as with
> > TLS-Authz.  It is too bad that Sam Hartman is no longer on the IESG,
> > this time.
> 
>   I think you are _assuming_ that there are patent encumbrances.
> Certicom has patents in ECC but it is not clear that any of them
> necessarily apply to this draft. Maybe they do; maybe they don't. But
> given that uncertainty there isn't a whole lot to "disclose". Keep in
> mind it's hard to prove a negative ("no patents are infringed....") so
> the most innocent of I-Ds could, maybe, possibly infringe on some weird
> patent somewhere.
> 
>   Certicom would, of course, love to license all sorts of things to you
> whether you need them or not. They would like everyone to believe that
> _any_ use of elliptic curves requires licensing from them but that is
> just FUD.
> 
>   regards,
> 
>   Dan.
> 
> 
> 

-- 
Av8 Internet   Prepared to pay a premium for better service?
www.av8.net         faster, more reliable, better service
617 344 9000   


_______________________________________________
TLS mailing list
TLS@xxxxxxxx
https://www.ietf.org/mailman/listinfo/tls