Re: [Cfrg] considering new topics for CFRG

Paul Lambert <> Tue, 07 January 2014 21:05 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 461D41AE089 for <>; Tue, 7 Jan 2014 13:05:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: 0.883
X-Spam-Status: No, score=0.883 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, MIME_CHARSET_FARAWAY=2.45, SPF_PASS=-0.001] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id LGcZvPv46DTh for <>; Tue, 7 Jan 2014 13:05:57 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 572201AE1BD for <>; Tue, 7 Jan 2014 13:05:55 -0800 (PST)
Received: from pps.filterd ( []) by (8.14.5/8.14.5) with SMTP id s07L5YJu031031; Tue, 7 Jan 2014 13:05:34 -0800
Received: from ([]) by with ESMTP id 1h6q2mmh1f-11 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 07 Jan 2014 13:05:33 -0800
Received: from ([]) by ([::1]) with mapi; Tue, 7 Jan 2014 13:05:33 -0800
From: Paul Lambert <>
To: Stephen Farrell <>, David McGrew <>
Date: Tue, 07 Jan 2014 13:05:31 -0800
Thread-Topic: [Cfrg] considering new topics for CFRG
Thread-Index: Ac8L7DPlSNyDTq1RSV6NQ9KNvyIusg==
Message-ID: <>
References: <> <> <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
user-agent: Microsoft-MacOutlook/
acceptlanguage: en-US
Content-Type: text/plain; charset="euc-kr"
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-07_07:2014-01-07, 2014-01-07, 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-1401070132
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: Tue, 07 Jan 2014 21:05:59 -0000

On 1/6/14, 2:39 PM, "Stephen Farrell" <> wrote:

>On 01/06/2014 08:32 PM, Paul Lambert wrote:
>>> > This is an intriguing thought, but probably something out of scope
>>> > CFRG.   (Seems more like a PKNG thing if I understand you right.)
>> There was an IETF PKNG that died with no visible results.
>That was an IRTF RG. IMO it never had a cadre of researchers
>nor a sufficient set of IETF participants who were interested
>in a nextgen thing.
Yes - no visible results.
Note - I’m biased against even using the ‘I’ infrastructure terminology.
This was used to reflect the need for coordination required for CAs and
the original ideas of X.500

>> This is an area where the IETF seems either too unfocused or mired
>> in existing PKI to make progress.  Hence it's on my wish list ...
>> Let me know if you have any suggestion for other viable forums in IETF
>> for such a topic.
>We have a list where we discussed certificate transparency but
>which has a broader remit. [1] That's discussing whether or
>not to start a new CT WG in the IETF at the moment.
Excellent work.  Currently a bandaid to X.509 PKI.  The Merkle tree
mechanism do have broader applicability but are just one mechanism that
could be part of a new framework.
A tree/log based approach is useful for validating the time sequence
relationship of events. It can help with making claims based on time
ordering (perhaps for names).

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.

>There's the wpkops WG for operational issues related to the
>web PKI. [2] They could do with help in terms of cycles to do
>already-identified work (not hugely interesting for a
>security/crypto researcher though probably).
Old PKI … not a good venue.
>The PKIX list [3] is still open, and would be a good place to
>talk about any X.509-related PKI stuff. Not so good for non
>X.509 based PKI though maybe unless for an approach that's
>very much evolutionary and starts from X.509.
Yes. Wrong forum.
>And there's the saag list [4] which is for general security
>topics if none of the above fit.
Yes - but not useable for sustained conversations.
>So stuff is happening and there are places to discuss and
>propose stuff. And Sean and I would be quite happy to try
>help PKI nextgen stuff progress in the IETF should there
>be credible proposals.
>However, current PKI is not an easy thing to displace, no
>matter how much you dislike parts or all of it. The main
>reasons IMO are that replacements are likely to suffer a lot
>of the same (or equivalent) complexity since its a complex
Maybe ...

>and that any credible replacement will take at least
>a few years to work out and them 5-10 to get deployed which
>seems to be beyond the horizon for researchers (speaking as
>one who chases funding;-).
Perhaps … but it depends on the market and application.
IPv6 … 20-30 years.
X.509 in TLS in browsers … 5-10 years
New applications … instantly

>One could argue that that's why
>of all the "large DB of public keys" approaches, only CT
>seems to be left standing.
For fixing DNS names used in TLS

>One other thing - listing the problems with the current PKI
>is not likely to be a useful place to start.
Yes. It’s been done.

>We know those,
>and any credible approach would start with a fairly well
>worked out proposal, including consideration of that 5-10
>year overlap period. Its not easy;-)
Please note that I was not suggesting that we replace
X.509 directly in TLS and DNS:
>   - A public key based ¹trust¹ architecture to
>     determine ³who can do what² (not based on X.509 or PGP)

This is a broader applications than just
a DNS name. New features would accelerate adoption in new markets.


>Having said all that though, CT is I think a good proof of
>concept that the large-DB-of-public-keys thing could be
>a runner, and we have learned a lot about the wrinkles in
>X.509 based PKI over the years so there is hope maybe.
>PS: For any of [1]-[4] please check the archives before
>diving in, or ask someone who might be familiar, which
>could include me.
… You did not list SDSI/SPKI archives or PGP