Re: [lamps] [EXTERNAL]Re: Re-charter text for LAMPS to work on Post-Quantum, and PQ problem statement

Mike:

I think that you should take your draft to the SECDISPATCH mail list and see if they want to put you on their agenda or go straight to a BoF.

Russ

> On Aug 27, 2019, at 3:28 PM, Mike Ounsworth <Mike.Ounsworth@entrustdatacard.com> wrote:
> 
> Thanks for the feedback Stephen,
> 
> I see your point that such a re-think / replacement of X.509 is well outside the scope of LAMPS.
> 
> 
> I believe that there are three categories of small modifications to existing X.509-based PKIs that will accomplish the goal (as outlined in my "Problem Statument" draft below)
> 
> The question I'm asking is which X.509 tweak solution(s) are worth pursuing? And how / where?
> 
> - - -
> Mike Ounsworth | Office: +1 (613) 270-2873
> 
> -----Original Message-----
> From: Stephen Farrell <stephen.farrell@cs.tcd.ie> 
> Sent: Saturday, August 24, 2019 7:02 AM
> To: Mike Ounsworth <Mike.Ounsworth@entrustdatacard.com>; spasm@ietf.org
> Subject: [EXTERNAL]Re: [lamps] Re-charter text for LAMPS to work on Post-Quantum, and PQ problem statement
> 
> 
> Sorry to be negative but...
> 
> On 24/08/2019 14:49, Mike Ounsworth wrote:
>> A) LAMPS re-charter so that post-quantum is guaranteed time on future agendas.
> 
> To me, that's close to the antithesis of what LAMPS was setup to do.
> 
> If current PKI is going to be challenged by quantum computers then IMO we ought re-think x.509-based PKI and not just consider all that an issue to tackle via algorithm agility and whatever other ad-hoc hacks we stumble upon.
> 
> x.509 is >30 years old as a container technology for public keys. Pretty much everyone hates it or just about puts up with it. IMO we ought not continue to use x.509 across such a classic/post-quantum boundary - if we get anywhere near wanting multiple keys bound to an identifier (and have >1 of those used for a single key establishment) then I can't see how the costs of re-using x.509 would be worthwhile compared to the costs of ditching x.509.
> 
> Such a re-think is definitely not a limited additional mechanism for PKIX or S/MIME.
> 
> S.
> _______________________________________________
> Spasm mailing list
> Spasm@ietf.org
> https://www.ietf.org/mailman/listinfo/spasm