[Cfrg] 'key centric' architecture (was: Re: considering new topics for CFRG)

Rene Struik <rstruik.ext@gmail.com> Fri, 24 January 2014 23:17 UTC

Return-Path: <rstruik.ext@gmail.com>
X-Original-To: cfrg@ietfa.amsl.com
Delivered-To: cfrg@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 399731A0215 for <cfrg@ietfa.amsl.com>; Fri, 24 Jan 2014 15:17:38 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] 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 LdNZI6XUYhR1 for <cfrg@ietfa.amsl.com>; Fri, 24 Jan 2014 15:17:34 -0800 (PST)
Received: from mail-ig0-x232.google.com (mail-ig0-x232.google.com [IPv6:2607:f8b0:4001:c05::232]) by ietfa.amsl.com (Postfix) with ESMTP id D0C7A1A01F0 for <cfrg@irtf.org>; Fri, 24 Jan 2014 15:17:34 -0800 (PST)
Received: by mail-ig0-f178.google.com with SMTP id uq10so3880501igb.5 for <cfrg@irtf.org>; Fri, 24 Jan 2014 15:17:33 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=Tyc4n81HLeD902IVGKVPCF0bcs8hUvy37tTu2WrKRj4=; b=pNDQ824vFju+wEfcuXTY4KRJcJgjSFE4bIMdsH4hpNVoV9rZt1KhqedRTWCDekTyA5 AppfmKX9FosqW4KRqMkZRYT2RLvcTSjga6a3Q00YjpkhOVkaDIrWWfaESab1sDutsjQc MSDHPL6CVNf94j5tdzydDbxsMbshVZZbJllP+hC0MPE2hpzK7cTKcGecjSzkRV8qDNlC 94Pp9Yn4c7YXtX98I23jyDwkKhLzlljpKxDBHbiFwznigu5V0SEaBl/fdswBBXw6id0d D6H7Ai28lUs6NCnDQvC6bFpG4oqXfMHlpIRjS7sziupQoA9NJRbgaJgRKKWI9c81mqAK 7DVw==
X-Received: by 10.50.78.229 with SMTP id e5mr6832271igx.49.1390605453443; Fri, 24 Jan 2014 15:17:33 -0800 (PST)
Received: from [192.168.1.101] (CPE0013100e2c51-CM001cea35caa6.cpe.net.cable.rogers.com. [99.230.254.17]) by mx.google.com with ESMTPSA id ac3sm14952434igd.4.2014.01.24.15.17.30 for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 24 Jan 2014 15:17:32 -0800 (PST)
Message-ID: <52E2F485.5040202@gmail.com>
Date: Fri, 24 Jan 2014 18:17:25 -0500
From: Rene Struik <rstruik.ext@gmail.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0
MIME-Version: 1.0
To: Paul Lambert <paul@marvell.com>, David McGrew <mcgrew@cisco.com>
References: <CEF1A5BF.2BBC6%paul@marvell.com> <20140110171000.15EB92280EA@palinka.tinho.net> <3C4AAD4B5304AB44A6BA85173B4675CABA9C8FFD@MSMR-GH1-UEA03.corp.nsa.gov> <CF068ACA.2D33A%paul@marvell.com> <52E25DD0.9020703@cisco.com> <7BAC95F5A7E67643AAFB2C31BEE662D018B80AF535@SC-VEXCH2.marvell.com>
In-Reply-To: <7BAC95F5A7E67643AAFB2C31BEE662D018B80AF535@SC-VEXCH2.marvell.com>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Cc: Sean Turner <turners@ieca.com>, "cfrg@irtf.org" <cfrg@irtf.org>
Subject: [Cfrg] 'key centric' architecture (was: Re: considering new topics for CFRG)
X-BeenThere: cfrg@irtf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Crypto Forum Research Group <cfrg.irtf.org>
List-Unsubscribe: <http://www.irtf.org/mailman/options/cfrg>, <mailto:cfrg-request@irtf.org?subject=unsubscribe>
List-Archive: <http://www.irtf.org/mail-archive/web/cfrg/>
List-Post: <mailto:cfrg@irtf.org>
List-Help: <mailto:cfrg-request@irtf.org?subject=help>
List-Subscribe: <http://www.irtf.org/mailman/listinfo/cfrg>, <mailto:cfrg-request@irtf.org?subject=subscribe>
X-List-Received-Date: Fri, 24 Jan 2014 23:17:38 -0000

Hi Paul:

It may help to write a short I-D where you introduce the topic of 'key 
centric' architecture, so that people who are unfamiliar with the topic 
area have context and a potential problem statement to work from 
(researchers like problem statements...). This also makes it easier to 
add to this than going over past emails sent to mailing lists.

I can imagine this would fit with saag or cfrg, depending on details.

It would be great to see you in Toronto in July.

Best regards, Rene

On 1/24/2014 5:38 PM, Paul Lambert wrote:
> David,
>
>
> ]Hi Kevin and Paul,
> ]
> ]I think the key-centric stuff is interesting and worthwhile, but to some
> ]extent it is outside the scope of CFRG.
> Perhaps yes since it's not just number theory.  However I'm not sure
> where else any discussion would belong in the IETF.  I also just noticed my
> response to Dan's last question on this topic is still dormant
> in my drafts box, so I will dump one more note to this list ...
> Advice on any forum to discuss non-X.509 public key architectures
> would be appreciated.
>
> ] Can I ask that the CFRG
> ]presentation on this topic cover the crypto mechanisms and protocols
> ]that are relevant for a key-centric architecture, rather than focus on
> ]the public-key authentication architecture itself?
>
> ???
> Protocols should be defined by the use cases and architecture.
>
> The grab-bag of mechanisms is still an interesting list, but
> Might be confusing when taken out-of-context from the use
> Case analysis and overall architecture.  I've already been
> asking related questions to the list.  Mechanism specific
> topics related to a 'key centric' architecture might
> include:
>   - public key algorithms and alternative algorithms
>     (like Edwards curves)
>   - public key algorithm representation, identification and enumeration
>     (partial proposal previously posted to list on naming
>     ... no response)
>   - definition of cipher suites in to facilitate
>     the clear semantics of public key usage in combination
>     with the other necessary cryptographic mechanisms.
>     Public keys and associated hashes, kdfs, encryption
>     Are handled in various ways in Internet protocols.
>     If the semantics of a public key is to be well defined, it
>     needs to be clearly associated with a set of appropriate
>     algorithms.
>   - privacy and anonymity mechanisms related to encodings
>     of key and key identifiers
>   - definition and of suitable crypto
>     mechanisms/standards for generation of key identifiers
>   - definition of suitable encoding mechanism for binary
>     identifiers and keys (human readable)
>   - clear definition and enumeration of crypto mechanisms
>     suitable for particular public key types
>     (e.g. earlier discussion of encrypting and signing
>     with the same public key)
>   - cryptographic protocols using public keys to
>     support various types of authentication and
>     the bootstrapping of 'key centric' identities.
>     The protocols need to be tuned to the use case
>     requirements.
>
> On protocols ... is the discussion of set theoretic
> protocol semantics (like RT) a viable topic area for this group?
> Or ... is this group limited to number theoretic discussions?
>
> ]]Not trying to discourage work in this area, just trying to make sure
> ]that agenda time covers algorithms and protocols first.
>
> First - when you say agenda, is it the yet to be scheduled
> invited F2F presentation (likely would have been July)
> or the agenda of this mailing list?
>
> Algorithms would never be the first thing I'd present.
> So, your limitations are very discouraging.  I was at first
> enthusiastic that there was any interest in my proposed
> set of architectural concepts. Now, rather than being able to
> present a coherent set of ideas, you are telling me to
> focus on the 'math/crypto'.  The architectural concepts
> need to defined before the math.   I'd be happy to have
> review of material prior to a f2f presentation and
> adjustments could be made at that point.
>
> I will just move my work to non-IETF forums if
> contributions are discouraged or if they are not able
> to make any impact. The impact of a 'research' group
> is questionable by definition and I fear I am wasting
> my time participating on this mailing list.
>   
>
> Paul
>
> ]
> ]David
> ]
> ]On 01/23/2014 01:37 PM, Paul Lambert wrote:
> ]> Hi Kevin,
> ]>
> ]> On 1/22/14, 9:29 AM, "Igoe, Kevin M." <kmigoe@nsa.gov> wrote:
> ]>
> ]>> If we were to put "key centric" on the CFRG agenda for IETF-89, do we
> ]>> have a speaker willing to give a presentation?
> ]> Thank you for your interest in the topic. I would be very willing and
> ]> interested in presenting on Œkey centric¹, however for the first time
> ]> in many years the IETF is occurring the same week as the Wi-Fi
> ]> Alliance Š so I¹m not available that week.
> ]>
> ]>> If this is too short of a
> ]>> deadline to meet, we can always have a presentation at a later
> ]meeting?
> ]> Yes.  That would work well.
> ]>
> ]> Paul
> ]>
> ]>> Three options:
> ]>> 	1) discuss at nest meeting
> ]>> 	2) discuss in the near future but not at the next meeting
> ]>> 	3) no support for a presentation in the near future. Maybe
> ]sometime
> ]>> later.
> ]>> 	4) Utter silence on the mailing list.
> ]>>
> ]>> As to #4, the Germans have a saying "Keine Antwort ist auch eine
> ]Antwort"
> ]>> (no is answer is also an answer).
> ]>>
> ]>>> -----Original Message-----
> ]>>> From: Cfrg [mailto:cfrg-bounces@irtf.org] On Behalf Of dan@geer.org
> ]>>> Sent: Friday, January 10, 2014 12:10 PM
> ]>>> To: Paul Lambert
> ]>>> Cc: Sean Turner; David McGrew; cfrg@irtf.org
> ]>>> Subject: Re: [Cfrg] considering new topics for CFRG
> ]>>>
> ]>>>
> ]>>>   > A useful mechanism, but it would be better to start with
> ]>>> reexamining and  > redefining our usage of public keys.
> ]>>> Specifically - I'm an advocate of  > keys as the primary
> ]identifiers.  A "key centric"
> ]>>> approach is a dual model
> ]>>>   > to Kohnfelder/X.509   The SDSI/SPKI work did progress work in
> ]this
> ]>>>   > direction, but failed for a variety of reasons.
> ]>>>
> ]>>> Key-centric versus name-centric identity is The Question, is it not?
> ]>>>
> ]>>> I rather doubt that the Administration's push for the NSTIC is
> ]>>> likely to settle in on key-centricity, but might you elaborate on
> ]>>> your preference for it?  I'm sympathetic to it on the grounds that
> ]>>> it directly enables multi-personna and, thus, data segmentation.
> ]>>>
> ]>>> If I'm being obtuse, feel free to say so.
> ]>>>
> ]>>> --dan
> ]>>>
> ]>>> _______________________________________________
> ]>>> Cfrg mailing list
> ]>>> Cfrg@irtf.org
> ]>>> http://www.irtf.org/mailman/listinfo/cfrg
> ]> .
> ]>
>
> _______________________________________________
> Cfrg mailing list
> Cfrg@irtf.org
> http://www.irtf.org/mailman/listinfo/cfrg


-- 
email: rstruik.ext@gmail.com | Skype: rstruik
cell: +1 (647) 867-5658 | US: +1 (415) 690-7363