Re: [Cfrg] considering new topics for CFRG

Paul Lambert <> Wed, 08 January 2014 17:38 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id DACC21AE3E3 for <>; Wed, 8 Jan 2014 09:38:40 -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 4uyJvD4LMB_T for <>; Wed, 8 Jan 2014 09:38:39 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id C07051ADFF8 for <>; Wed, 8 Jan 2014 09:38:38 -0800 (PST)
Received: from pps.filterd ( []) by (8.14.5/8.14.5) with SMTP id s08HcO8s012953; Wed, 8 Jan 2014 09:38:24 -0800
Received: from ([]) by with ESMTP id 1h919r9n3d-1 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 08 Jan 2014 09:38:24 -0800
Received: from ([]) by ([]) with mapi; Wed, 8 Jan 2014 09:38:23 -0800
From: Paul Lambert <>
To: Stephen Farrell <>, "Max Pritikin (pritikin)" <>, Sean Turner <>
Date: Wed, 08 Jan 2014 09:38:21 -0800
Thread-Topic: [Cfrg] considering new topics for CFRG
Thread-Index: Ac8MmG1Oqiw3aPneS3iapTEwUXyBUg==
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="Windows-1252"
Content-Transfer-Encoding: quoted-printable
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-08_07:2014-01-07, 2014-01-08, 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-1401080091
Cc: "David McGrew (mcgrew)" <>, "" <>
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: Wed, 08 Jan 2014 17:38:41 -0000

On 1/8/14, 3:09 AM, "Stephen Farrell" <> wrote:

>Hi Max,
>On 01/08/2014 02:31 AM, Max Pritikin (pritikin) wrote:
>> With the advent of DICE (DTLS in Constrained Environments), and
>> similar attempts to discuss optimizations, it would seem that any
>> discussion of "next generation" PKI discussions should include
>> discussion on how to optimize the X.509 certificate/chain format.
>> That appears to be missing in this conversation so far.
>True. OTOH, DICE is definitely predicated on DTLS so any
>discussion on cert formats for that would fit into the TLS
>WG discussion on 1.3. I've not however seen that listed on
>any 1.3 wish-list so far so it seems unlikely to me at
>least that DICE will push things along here.
>> I agree that any replacement for our current PKI is going to run into
>> the same complexities. So, rather than assume they don't exist, would
>> it be reasonable to look at how to optimize the existing work?

I think it could be much simpler.  If you start with just
keys and key hashes as identity, then you do not need CAs
or other naming authorities.

Of course Š as you then assign attributes to keys (that might include
names) and support delegation complexity arises, but you still
maintain a simple model for simple devices.

Note - assigning 'names to key¹s versus 'keys to names' are
two very different architectures.  It is not easy
to tweak 509 to be key centric.

So .. This thread may imply to different paths of work.

On CFRG work.

A key centric architecture would benefit from CFRG
recommendations for:
 1) recommendations for ³suitable" EC curves
   and associated methods
   (e.g. Brainpool or Ed25519)
 2 recommendations for how to use the same public
   key for signatures and key establishment
   (current architectures are complicated by this split)
 3) a canonical definition of public key representation
    for identification (e.g. Key hash) that provides
   - indépendance of representation to underlying
     Public key or hashing algorithms
   - considerations and options
     for human and machine readability and reliability
   - mutability of ID to support anonymity of visible
     Id binding to key
   - extensibility of cipher suites
   - optional opacity of cipher suite support
   - variable length of identification to support
     short forms that might be ambiguous when not viewed in context

Hummm Š maybe only the first two are CFRG items.

>I'm not sure. I think that might run the risk of inheriting
>all the warts (e.g. policy mapping, the N-R bit) without
>providing much incentive to change. When we were working on
>RFC3280bis (which became 5280) we did try to do as much of
>that as we could, but very few simplifications turned out
>to be possible. It is fair to say though that a lot of the
>real practical problems had not really bitten folks at
>that stage though, so I guess its possible that the same
>exercise done now might pay off.
>> Some off the cuff examples to frame what I mean: - Define a specific
>> lightweight trust anchor format (yes, we can all use X.509 certs. But
>> what about a canonical smaller format?) - Optimized version of the
>> X.509 cert itself: Perhaps a compressed format similar to the (old,
>> abandoned and incomplete)

There are completely different trust anchor models from X.509 and we
Should work to make a better distributed model for name spaces and
Trust delegation. Improvements are required in the:
 - semantics of the signatures, attributes and delegation
 - clear definition of useable constraints for extensible attributes
 - redefinition of name spaces to be anchored by keys
 - etc.

>> draft for
>> compressed certs? Perhaps a v4 format that is restructured to provide
>> easier/quicker parsing Or if a non-ASN1 format is truly preferred
>> then such a format could be defined that is can carry the same
>> semantics as the existing PKI (namely, if the problem is ASN1 then we
>> can fix that without also re-inventing all the rest)  Approaching the
>> questions from this angle leads me to ask what _exactly_ the concerns
>> with the current PKI are. Is it the ASN1, the CA infrastructure, the
>> certificate chains, the cruft in each individual certificate, or?
>Personally, I think the main problems with X.509 PKI to date
>have been around (the need for, and absence of widely supported
>standard for) enrollment and (particularly name) constraints
>when there are many CAs. Dealing with ASN.1 is a PITA, but a
>well-known one, so that'd be low down on my list anyway. I
>know you've spent a lot of effort trying to help with the
>enrollment problem with EST and I do hope that works out,
>but we don't know yet.
>Again though, I don't think thrashing out the pros and cons
>of X.509 on this list is a good plan. Better would be for a
>bunch of really-interested parties to go into a huddle and
>come up with a worked out proposal. (But if a bunch of
>semi-interested parties ask for a new list to talk about
>this, I've no problem helping that happen, though wouldn't
>be very hopeful of a useful outcome.)

Let me know Š I am interested and have some ideas on directions and
perhaps some code.


>> Thanks,
>> - max
>> On Jan 6, 2014, at 3: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 for 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.
>>>> 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.
>>> 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).
>>> 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.
>>> And there's the saag list [4] which is for general security topics
>>> if none of the above fit.
>>> 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 problem, 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;-). One could argue
>>> that that's why of all the "large DB of public keys" approaches,
>>> only CT seems to be left standing.
>>> One other thing - listing the problems with the current PKI is not
>>> likely to be a useful place to start. 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;-)
>>> 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.
>>> S.
>>> PS: For any of [1]-[4] please check the archives before diving in,
>>> or ask someone who might be familiar, which could include me.
>>> [1] [2]
>>> [3]
>>> [4]
>>> _______________________________________________ Cfrg mailing list