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

Richard Barnes <rlb@ipv.sx> Sat, 25 January 2014 08:21 UTC

Return-Path: <rlb@ipv.sx>
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 E61E21A02C1 for <cfrg@ietfa.amsl.com>; Sat, 25 Jan 2014 00:21:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.977
X-Spam-Level:
X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] 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 h0qkrkknz3Dr for <cfrg@ietfa.amsl.com>; Sat, 25 Jan 2014 00:21:04 -0800 (PST)
Received: from mail-oa0-f52.google.com (mail-oa0-f52.google.com [209.85.219.52]) by ietfa.amsl.com (Postfix) with ESMTP id 3A3521A02B3 for <cfrg@irtf.org>; Sat, 25 Jan 2014 00:21:03 -0800 (PST)
Received: by mail-oa0-f52.google.com with SMTP id i4so4728176oah.25 for <cfrg@irtf.org>; Sat, 25 Jan 2014 00:21:02 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=HRf7Ow7LLiiNXEaozYYFEXvkuHH+w+loBDJlqOL55kY=; b=jYGGiBlC6BCIK4xGEfhI8DiEJ5+Kk119ZzOC6noLqUcfygEMz/AbmnIZWiVFdRgPoB yHRrnNIx/4cPdV5A3AMw2R04OnK4RL4PPiTWtZh6SZs1hvToRt4wC0x8lEbt9K6AqQYi Ylh4ohRp1w3tijHCBcm5zgY2o8iQpIkz3ZTOqXz/bEihjBlaNjn+plBUSHgmMBETVPx8 tR8bojWuShluw9YgaSG8g2X0ekMvPaiZ6PM5MBuLJk2QPen0QrsHva2HL9LWD3O9RaWL 5Yqwf16Hs4QP58OuDG8+f4XvLm1i2ssHc4i0vtjWddvqCsD0+skC2MWu2DkbkcWsBCbv mxaw==
X-Gm-Message-State: ALoCoQnRJgTECrr0mlL7laohIIVqnmA84FJ7Uiv9HEW0dqzifFc2PVlARhgrh+ymj5I7Dlca93jo
MIME-Version: 1.0
X-Received: by 10.182.84.132 with SMTP id z4mr113311oby.49.1390638062445; Sat, 25 Jan 2014 00:21:02 -0800 (PST)
Received: by 10.60.54.65 with HTTP; Sat, 25 Jan 2014 00:21:02 -0800 (PST)
In-Reply-To: <52E2F485.5040202@gmail.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> <52E2F485.5040202@gmail.com>
Date: Sat, 25 Jan 2014 09:21:02 +0100
Message-ID: <CAL02cgTNfG-+NLG1Rau1=hz=ZHH0=BYRAhrWngYm39vkgh4tow@mail.gmail.com>
From: Richard Barnes <rlb@ipv.sx>
To: Rene Struik <rstruik.ext@gmail.com>
Content-Type: multipart/alternative; boundary="089e0111c09ab93bbf04f0c727bb"
Cc: Sean Turner <turners@ieca.com>, David McGrew <mcgrew@cisco.com>, "cfrg@irtf.org" <cfrg@irtf.org>
Subject: Re: [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: Sat, 25 Jan 2014 08:21:08 -0000

+1 to an I-D

Key centric architecture sounds like something I would be interested in.  I
think I've got a rough idea of what Paul means based on his mail, but would
appreciate more detail on what he's thinking.


On Sat, Jan 25, 2014 at 12:17 AM, Rene Struik <rstruik.ext@gmail.com> wrote:

> 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
>
> _______________________________________________
> Cfrg mailing list
> Cfrg@irtf.org
> http://www.irtf.org/mailman/listinfo/cfrg
>