Re: [TLS] Last Call: draft-ietf-tls-extractor (Keying Material Exporters for Transport Layer Security (TLS)) to Proposed Standard

[Dean Anderson <dean at av8.com>]

I think you misunderstand how patents work or what the license says.

The licence is available for the case "when used with either ...". It is
not the case that a patent only applies to specific RFCs.  RFC's aren't
mentioned in patents. Patent claims covering tls-extractor very likely*
apply to any use of extractor, not just those uses that also use other
Certicom technology in other RFCs.  I think you are assuming that
because Certicom offers a license for a certain situation (or maybe 'use
configuration' is a better phrase), that different use configurations
then won't need a license, but that isn't usually* the case. Those other
'use configurations' that infringe a claim still require a license.

Note also the Certicom license isn't available for use by Certificate
Authorities.

But note also that identifying the specific claims is not the best
approach for developing non-infringing technology. One starts with prior
art which cannot be patented. So the question to ask yourself is:

  "How difficult would it be to start from unpatentable prior art, and
  produce something that does what is needed, but differently from how
  Certicom et al did it?"

Except for some very fundamental technology, the answer is almost always
"Easy". The alternative is to pay license fees, create more income for
patented standards, and encourage even more patenting of standards.  
So, please, just say "no", and oppose this document.

                --Dean

[* Can't say for certain because Certicom has been unhelpful with
specific claims, and the bulk of patents is large--I've read some, but
not all.]




On Tue, 21 Jul 2009, Nikos Mavrogiannopoulos wrote:

> I'd propose to add this text to the standard:
> This protocol MUST NOT be used with RFC4492, RFC5289 and
> draft-rescorla-tls-suiteb.
> 
> That way the certicom's patents are not applicable.
> 
> On Mon, Jul 20, 2009 at 11:24 PM, Dan Harkins<dharkins at lounge.org> wrote:
> >
> >  Certicom's IPR statement dated 13 October 2008 lists some patents
> > that "may be necessary and essential to implementations of..." the
> > TLS extractor draft "when used with either: " RFC4492, RFC5289
> > or draft-rescorla-tls-suiteb. Check it out:
> >
> > http://www.certicom.com/images/pdfs/certicom%20-ipr-contribution-to-ietfsept08.pdf
> >
> >  Don't use it with RFC4492, RFC5289 or draft-rescorla-tls-suiteb and
> > then the IPR statement does not apply. If it's possible to use the TLS
> > extractor draft in a way that the IPR statement doesn't apply then I
> > don't think you can say "the TLS Extractor draft is patent-encumbered".
> >
> >  I support free software* and I have no problem with this draft being
> > advanced as a Proposed Standard.
> >
> >  regards,
> >
> >  Dan.
> >
> > * http://www.lounge.org/siv_for_openssl.tgz is a free version of RFC5297
> >  for OpenSSL, and check out the "authsae" project on Source Forge.
> >
> > On Mon, July 20, 2009 12:15 pm, Dean Anderson wrote:
> >> I am against this standard because of its patent encumbrances and
> >> non-free licencing terms.  The working group did not get any clear
> >> answers on what particular patents this draft may infringe, but a patent
> >> holder (Certicom) did assert an IPR disclosure (1004) listing many
> >> patents.  We have no alternative but to accept the Certicom disclosure
> >> statements as meaning that the TLS Extractor draft is patent-encumbered
> >> without a universal, free defensive license.
> >>
> >> The statement by https://datatrackerietf.org/ipr/1004/ referring to
> >> http://www.certicom.com/images/pdfs/certicom%20-ipr-contribution-to-ietfsept08.pdf
> >> which states:
> >>
> >>   "Certicom will, upon request, provide a nonexclusive, royalty free
> >> patent license, to manufacturers to permit end users (including both
> >> client and server sides), to use the patents in schedule A when
> >> implementing any of these protocols, including those requiring third
> >> party certificates provided the certificate is obtained from a licensed
> >> Certificate Authority (CA). This license does not cover the issuing of
> >> certificates by a Certification Authority (CA)."
> >>
> >> That is not a free license, since Certicom must respond to the "request"
> >> before any license is granted. After the IETF finally approves the
> >> necessary standards, Certicom is free to stop approving the requests.
> >>
> >> I ask others who support free software to join me in opposing this
> >> document by sending a message stating opposition to the IETF at IETF.ORG
> >> mailing list.  IETF participation is open to the public, and anyone may
> >> voice their view on IETF standards.  It is also substantive to oppose a
> >> document because of its patent status, and in fact, any topic that is
> >> considered during or related to the IETF process is substantive.
> >>
> >>               --Dean
> >>
> >>
> >> On Mon, 20 Jul 2009, The IESG wrote:
> >>
> >>> The IESG has received a request from the Transport Layer Security WG
> >>> (tls) to consider the following document:
> >>>
> >>> - 'Keying Material Exporters for Transport Layer Security (TLS) '
> >>>    <draft-ietf-tls-extractor-06.txt> as a Proposed Standard
> >>>
> >>> The IESG plans to make a decision in the next few weeks, and solicits
> >>> final comments on this action.  Please send substantive comments to the
> >>> ietf at ietf.org mailing lists by 2009-08-10. Exceptionally,
> >>> comments may be sent to iesg at ietf.org instead. In either case, please
> >>> retain the beginning of the Subject line to allow automated sorting.
> >>>
> >>> The file can be obtained via
> >>> http://www.ietf.org/internet-drafts/draft-ietf-tls-extractor-06.txt
> >>>
> >>>
> >>> IESG discussion can be tracked via
> >>> https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=16821&rfc_flag=0
> >>>
> >>> _______________________________________________
> >>> TLS mailing list
> >>> TLS at ietf.org
> >>> https://www.ietf.org/mailman/listinfo/tls
> >>>
> >>>
> >>
> >> --
> >> 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 at ietf.org
> >> https://www.ietf.org/mailman/listinfo/tls
> >>
> >
> >
> > _______________________________________________
> > TLS mailing list
> > TLS at ietf.org
> > https://www.ietf.org/mailman/listinfo/tls
> >
> 
> 

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