Re: [Cfrg] considering new topics for CFRG

Stephen Farrell <stephen.farrell@cs.tcd.ie> Wed, 08 January 2014 11:09 UTC

Return-Path: <stephen.farrell@cs.tcd.ie>
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 75CEF1AE339 for <cfrg@ietfa.amsl.com>; Wed, 8 Jan 2014 03:09:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.438
X-Spam-Level:
X-Spam-Status: No, score=-2.438 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.538] 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 TXJleFpyPIoy for <cfrg@ietfa.amsl.com>; Wed, 8 Jan 2014 03:09:55 -0800 (PST)
Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id A96B51AE2F0 for <cfrg@irtf.org>; Wed, 8 Jan 2014 03:09:54 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 52F94BE49; Wed, 8 Jan 2014 11:09:45 +0000 (GMT)
Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MyPZJsehD-+2; Wed, 8 Jan 2014 11:09:45 +0000 (GMT)
Received: from [134.226.36.180] (stephen-think.dsg.cs.tcd.ie [134.226.36.180]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 2AC28BE3F; Wed, 8 Jan 2014 11:09:45 +0000 (GMT)
Message-ID: <52CD31F9.4030302@cs.tcd.ie>
Date: Wed, 08 Jan 2014 11:09:45 +0000
From: Stephen Farrell <stephen.farrell@cs.tcd.ie>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0
MIME-Version: 1.0
To: "Max Pritikin (pritikin)" <pritikin@cisco.com>
References: <52C755AA.70200@cisco.com> <CEED2882.2B867%paul@marvell.com> <52C9F739.1020301@cisco.com> <7BAC95F5A7E67643AAFB2C31BEE662D018B7D6E094@SC-VEXCH2.marvell.com> <52CB30B4.9090206@cs.tcd.ie> <91BE5B4B-AE45-4C05-A423-EDF744A54766@cisco.com>
In-Reply-To: <91BE5B4B-AE45-4C05-A423-EDF744A54766@cisco.com>
X-Enigmail-Version: 1.6
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
Cc: Sean Turner <turners@ieca.com>, "David McGrew (mcgrew)" <mcgrew@cisco.com>, "cfrg@irtf.org" <cfrg@irtf.org>
Subject: Re: [Cfrg] 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: Wed, 08 Jan 2014 11:09:57 -0000

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'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)
> http://tools.ietf.org/html/draft-pritikin-comp-x509-00 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.)

S.

> 
> Thanks,
> 
> - max
> 
> 
> 
> On Jan 6, 2014, at 3:39 PM, Stephen Farrell
> <stephen.farrell@cs.tcd.ie> 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] https://www.ietf.org/mailman/listinfo/therightkey [2]
>> http://tools.ietf.org/wg/wpkops/ [3]
>> https://www.ietf.org/mailman/listinfo/pkix [4]
>> https://www.ietf.org/mailman/listinfo/saag
>> 
>> 
>> 
>> _______________________________________________ Cfrg mailing list 
>> Cfrg@irtf.org http://www.irtf.org/mailman/listinfo/cfrg
>