Re: [saag] Proposal to Consolidate Algorithms Registries

Satoru Kanno <kanno.satoru@po.ntts.co.jp> Fri, 18 November 2011 01:30 UTC

Return-Path: <kanno.satoru@po.ntts.co.jp>
X-Original-To: saag@ietfa.amsl.com
Delivered-To: saag@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB97811E8097 for <saag@ietfa.amsl.com>; Thu, 17 Nov 2011 17:30:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.09
X-Spam-Level:
X-Spam-Status: No, score=-0.09 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NLlyghBlcqwq for <saag@ietfa.amsl.com>; Thu, 17 Nov 2011 17:30:42 -0800 (PST)
Received: from mail12.ics.ntts.co.jp (mail12.ics.ntts.co.jp [210.232.35.65]) by ietfa.amsl.com (Postfix) with ESMTP id 3D03411E8094 for <saag@ietf.org>; Thu, 17 Nov 2011 17:30:42 -0800 (PST)
Received: from sadoku34.silk.ntts.co.jp (sadoku34 [10.7.18.34]) by mail12.ics.ntts.co.jp (8.14.4/8.13.4/NTTSOFT) with ESMTP id pAI1UGxC024172; Fri, 18 Nov 2011 10:30:16 +0900 (JST)
Received: (from root@localhost) by sadoku34.silk.ntts.co.jp (8.13.8/NTTSOFT) id pAI1UGIQ011463; Fri, 18 Nov 2011 10:30:16 +0900 (JST)
Received: from ccmds32.silk.ntts.co.jp [10.107.0.32] by sadoku34.silk.ntts.co.jp with SMTP id LAA11462; Fri, 18 Nov 2011 10:30:15 +0900
Received: from mail147.silk.ntts.co.jp (ccmds32.silk.ntts.co.jp [127.0.0.1]) by ccmds32.silk.ntts.co.jp (8.14.3/8.14.3) with ESMTP id pAI1UFWv032469; Fri, 18 Nov 2011 10:30:15 +0900
Received: from mail147.silk.ntts.co.jp (localhost.localdomain [127.0.0.1]) by mail147.silk.ntts.co.jp (8.14.5/8.14.5/NTTSOFT) with ESMTP id pAI1U9AQ012751; Fri, 18 Nov 2011 10:30:09 +0900
Received: from ccmds32 (mail145.silk.ntts.co.jp [10.107.0.145]) by mail147.silk.ntts.co.jp (8.14.5/8.14.5/NTTSOFT) with SMTP id pAI1U9r5012748; Fri, 18 Nov 2011 10:30:09 +0900
Message-ID: <4EC5B50F.3040206@po.ntts.co.jp>
Date: Fri, 18 Nov 2011 10:29:51 +0900
From: Satoru Kanno <kanno.satoru@po.ntts.co.jp>
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:8.0) Gecko/20111105 Thunderbird/8.0
MIME-Version: 1.0
To: Simon Josefsson <simon@josefsson.org>
References: <CAMm+LwiFts406H=WNu5XCMOxTj0=9VK56Ti3aUxUqRthP-xEgA@mail.gmail.com> <CAK3OfOiVxTQG_i15Q6YCCtKbZHORq--iDFQ=poYeGF6AdaHAfQ@mail.gmail.com> <CAMm+LwioQiF167ewRJAZoeB180MSH6SPkyWcG1XgKNJ0wsj+NQ@mail.gmail.com> <87sjlo4je3.fsf@latte.josefsson.org> <4EC44D40.1000703@po.ntts.co.jp> <87vcqjm5nv.fsf@latte.josefsson.org>
In-Reply-To: <87vcqjm5nv.fsf@latte.josefsson.org>
Content-Type: text/plain; charset="ISO-2022-JP"
Content-Transfer-Encoding: 7bit
X-CC-Mail-RelayStamp: CC-Mail-V4.3-Client
X-CC-Mail-RelayStamp: CC-Mail-V4.3-Server
Cc: Phillip Hallam-Baker <hallam@gmail.com>, saag@ietf.org
Subject: Re: [saag] Proposal to Consolidate Algorithms Registries
X-BeenThere: saag@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Security Area Advisory Group <saag.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/saag>, <mailto:saag-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/saag>
List-Post: <mailto:saag@ietf.org>
List-Help: <mailto:saag-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/saag>, <mailto:saag-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 18 Nov 2011 01:30:43 -0000

(2011/11/17 18:58), Simon Josefsson wrote:
> Satoru Kanno<kanno.satoru@po.ntts.co.jp>  writes:
> 
>> Hi Simon and Phillip,
>>
>> (2011/11/16 16:27), Simon Josefsson wrote:
>>> Phillip Hallam-Baker<hallam@gmail.com>   writes:
>>>
>>>> There is no shortage of cryptographic algorithms. I can't see why TLS
>>>> should even spend the time considering Camellia if there was any doubt
>>>> about the ability to use it in IPSEC. The only algorithms I can ever see
>>>> being worth consideration at this point would be ones that are sufficiently
>>>> general purpose that they can be used in multiple protocols.
>>>>
>>>> What I am proposing instead is a low bar to making Camellia an option in
>>>> any IETF protocol. I believe this to be a Pareto improvement as follows:
>>>>
>>>> * The developers of Camellia can get their algorithm enabled as an option
>>>> in all IETF protocols in a single operation.
>>>
>>> The situation with Camellia has another angle to it: the patent
>>> statements about it only applies to specific protocols, and there are
>>> now statements for (at least) TLS and Kerberos.  If Camellia is to be
>>> considered for any other protocol, a new patent disclosure is required.
>>> So Camellia is not intended to be a general purpose cipher.
>>>
>>
>> Up to now, because we proposed adding the Camellia cipher to each
>> protocols, we filed the Camellia IPRs for the relevant WGs.
>>
>> If IETF changes the policy of addition of cipher algorithms to new
>> one, of course, NTT&  Mitsubishi intend to file for the revised
>> general-purpose IPR which permits to use Camellia cipher in any
>> protocols in IETF.
> 
> I do not believe the IETF has changed any policy in this area.  The
> essential policies are described in RFC 3979 [1].  You could file a
> general patent disclosure on Camellia instead of a specific disclosure
> for each and every draft.
> 
> Generally, you are at liberty to use any license you want for your
> patent, but the community is at liberty to ignore your work if the
> license is considered to "get in the way".
> 
> I for one would welcome a new general patent disclosures that says you
> permit use of Camellia for any purpose to everyone.
> 

Thanks, Simon.
We understand your useful opinion.
As soon as possible, We start to discuss with our intellectual property
center whether we will revise our present IPRs to a new general-purpose IPR.

Regards,


> /Simon
> 
> [1] https://www.ietf.org/rfc/rfc3979.txt
> 


-- 
Satoru Kanno

Security Business Unit
Mobile and Security Solution Business Group
NTT Software Corporation

e-mail: kanno.satoru@po.ntts.co.jp