Re: [Cfrg] considering new topics for CFRG

Paul Lambert <> Fri, 24 January 2014 22:38 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 39EDB1A01E5 for <>; Fri, 24 Jan 2014 14:38:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.567
X-Spam-Status: No, score=-1.567 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, SPF_PASS=-0.001] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id JlDWxPF5jL6p for <>; Fri, 24 Jan 2014 14:38:39 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 2D9A21A01E0 for <>; Fri, 24 Jan 2014 14:38:39 -0800 (PST)
Received: from pps.filterd ( []) by (8.14.5/8.14.5) with SMTP id s0OMcT3n017690; Fri, 24 Jan 2014 14:38:33 -0800
Received: from ([]) by with ESMTP id 1hknvx1fr7-1 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Fri, 24 Jan 2014 14:38:33 -0800
Received: from ([]) by ([]) with mapi; Fri, 24 Jan 2014 14:38:32 -0800
From: Paul Lambert <>
To: David McGrew <>
Date: Fri, 24 Jan 2014 14:38:31 -0800
Thread-Topic: [Cfrg] considering new topics for CFRG
Thread-Index: Ac8ZAKACihJpX5muQuOG1mnMwP0+PwASXYMw
Message-ID: <>
References: <> <> <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
acceptlanguage: en-US
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.11.87, 1.0.14, 0.0.0000 definitions=2014-01-24_05:2014-01-24, 2014-01-24, 1970-01-01 signatures=0
X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 suspectscore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1305240000 definitions=main-1401240156
Cc: Sean Turner <>, "" <>
Subject: Re: [Cfrg] considering new topics for CFRG
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Crypto Forum Research Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 24 Jan 2014 22:38:41 -0000


]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
 - 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
 - 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 

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.


]On 01/23/2014 01:37 PM, Paul Lambert wrote:
]> Hi Kevin,
]> On 1/22/14, 9:29 AM, "Igoe, Kevin M." <> 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
]> 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
]>> later.
]>> 	4) Utter silence on the mailing list.
]>> As to #4, the Germans have a saying "Keine Antwort ist auch eine
]>> (no is answer is also an answer).
]>>> -----Original Message-----
]>>> From: Cfrg [] On Behalf Of
]>>> Sent: Friday, January 10, 2014 12:10 PM
]>>> To: Paul Lambert
]>>> Cc: Sean Turner; David McGrew;
]>>> 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
]>>>   > 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
]> .