Re: [saag] draft-iab-crypto-alg-agility-00

Stephen Kent <kent@bbn.com> Mon, 07 April 2014 17:54 UTC

Return-Path: <kent@bbn.com>
X-Original-To: saag@ietfa.amsl.com
Delivered-To: saag@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 326D61A01AE for <saag@ietfa.amsl.com>; Mon, 7 Apr 2014 10:54:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.211
X-Spam-Level:
X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Rm2XKri4DAVI for <saag@ietfa.amsl.com>; Mon, 7 Apr 2014 10:54:43 -0700 (PDT)
Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by ietfa.amsl.com (Postfix) with ESMTP id 667381A0752 for <saag@ietf.org>; Mon, 7 Apr 2014 10:54:43 -0700 (PDT)
Received: from dommiel.bbn.com ([192.1.122.15]:42437 helo=comsec.home) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from <kent@bbn.com>) id 1WXDkj-000F4W-9Y for saag@ietf.org; Mon, 07 Apr 2014 13:54:37 -0400
Message-ID: <5342E65C.5070309@bbn.com>
Date: Mon, 07 Apr 2014 13:54:36 -0400
From: Stephen Kent <kent@bbn.com>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.4.0
MIME-Version: 1.0
To: saag@ietf.org
References: <5999195E-9073-4649-A224-BF71BA61CBAF@vigilsec.com> <CAG5KPzzqSQ++YpQcnYesecL0GQ0+J0ieMXBrNk6txMAC58xEQQ@mail.gmail.com> <2A0EFB9C05D0164E98F19BB0AF3708C7120A04EBD0@USMBX1.msg.corp.akamai.com> <6.2.5.6.2.20140406121529.0bd2d730@resistor.net> <2A0EFB9C05D0164E98F19BB0AF3708C7120A04EBD7@USMBX1.msg.corp.akamai.com> <CAG5KPzxihe+k0x0njC+BANacmrrQyfU5RAY_EYcMYW2rx8DZfw@mail.gmail.com> <2A0EFB9C05D0164E98F19BB0AF3708C7120A04ED14@USMBX1.msg.corp.akamai.com> <CAG5KPzzzmJhcPfs0cJuS3f8Lu_Rua9dj0XWaOZ0RQ0Mwyd+egw@mail.gmail.com>
In-Reply-To: <CAG5KPzzzmJhcPfs0cJuS3f8Lu_Rua9dj0XWaOZ0RQ0Mwyd+egw@mail.gmail.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/saag/9sHbAW5LxcCzVpM9xCglrJY6WbM
Subject: Re: [saag] draft-iab-crypto-alg-agility-00
X-BeenThere: saag@ietf.org
X-Mailman-Version: 2.1.15
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: Mon, 07 Apr 2014 17:54:48 -0000

Ben,

Sorry to jump on late on this, but as a co-author of an RFC that deals
with alg agility for the RPKI, I thought I might be able to contribute.

It's generally useful to have a MUST implement alg (or set, if there are 
multiple
algs needed) for any set of protocols (data formats, etc.) to help ensure
interoperability. Selecting the MUST implement is sometimes hard, but 
it's worth
the effort.

Then one needs to have a way for all clients, CA, and log servers (in 
the CT context)
to express which alg9s) are being used at any time, so that everyone 
else knows
what choices have been made, when choices are allowed, and to guide 
folks through the
transition process.

I suggest folks read RFC 6919 as an example of how that can be done, 
although
I'm not suggesting that CT needs to adopt as thorough a model as did the 
RPKI.

Steve