Re: [pkix] Considerations about the need to resume PKIX work

Anders Rundgren <> Thu, 20 July 2017 15:53 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id A871B131838 for <>; Thu, 20 Jul 2017 08:53:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id lxT1BF8_P0zh for <>; Thu, 20 Jul 2017 08:53:34 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:400c:c0c::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 4E974131C73 for <>; Thu, 20 Jul 2017 08:53:31 -0700 (PDT)
Received: by with SMTP id k71so19066675wrc.2 for <>; Thu, 20 Jul 2017 08:53:31 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=5w1Wevp+V4p7mZgqSYNloQI249U2GKnrn+gKvs+EhRc=; b=s7PcTvu8dpiWgC70Ka1GC7b6w4DaWSbGI9NfPrqLy3FMybGGTkrn+1Os3dJrk0hJhi /64CaQiy7trA/v7CygZYOLZ/1XK0FYN+ilFDDLsxYDANzMQfWOgfFwV3iOUp4zL7eQPV eJINafFWvYhlP6cuIYyuu/N0QCPEEViVlF0m+RS8npuqk7eYh5p5d+bIoy5agbsUR76r 03E1bzB6Yiv6Q1ivZxMURFA1ArxCBmfTngktDuketDbFUNCyY5nEesEM/UfB4B+kU3eJ Bsj7EYk2wURHMcNiYTc4VOwgnOXxMrLe0FE25C6UuEKcd1EzpZNNLQU5io2oMIHUFgeX xnmw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=5w1Wevp+V4p7mZgqSYNloQI249U2GKnrn+gKvs+EhRc=; b=mqTZlLtJJw6jN2+tF+vjxUr8JqBVYSUcAehAePoZgdD/+P3n4kkOj59ozPCTRLJ+bt MyFSX4PB1yN2B64sPqcut5g5IU+Jo25s5EZn8ByM/msY6WmAocYtVe3F+NSF0zyZbrb/ fU33xDV6Rvhg1rPNOILpLDwcS92cw9NUvDqdyKSh9AMvKSmm9sCHU3HjMVQzTSo33wqQ JFk8MUqPjBUBtwTvtqRd+4VTPtY10zUa2R4N7Qiyqc/1RxHTtOW2NBdBJEPc3WuwHugP 92oFYsrcSY2blskAyxQ+qC1zwvlVf7Z+abUvdf6tfhQmNnCZ+B+wXrM+l1IgQISzltbv 587A==
X-Gm-Message-State: AIVw111Iv5KEhLDM7Rx+07eLWurKa8J/WtA0KX3jGDShNQAsmzzxzNaf nKDrTFhaOTjeq/uW
X-Received: by with SMTP id k7mr3737816wrd.232.1500566009501; Thu, 20 Jul 2017 08:53:29 -0700 (PDT)
Received: from [] ( []) by with ESMTPSA id v203sm2801002wmd.2.2017. (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 20 Jul 2017 08:53:28 -0700 (PDT)
To: "Dr. Pala" <>, PKIX <>
References: <> <> <>
From: Anders Rundgren <>
Message-ID: <>
Date: Thu, 20 Jul 2017 17:53:26 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: <>
Subject: Re: [pkix] Considerations about the need to resume PKIX work
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: PKIX Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 20 Jul 2017 15:53:41 -0000

On 2017-07-20 14:24, Dr. Pala wrote:
> Hi Anders,

Hi Max,

> Maybe, this time we might have a way in. I would be willing to work on it (even outside IETF, if there is no interest) and provide implementations in LibPKI. Easy and Secure "Provisioning / Enrollment" protocols are at the core for many ecosystems (e.g., IoT, WIFI, etc.). For the TEEP - I do not think they are going to address this particular issue/issues for what I have seen at the BoF.
> Let's talk about this - can you send me pointers you might think are useful to start from ?

Oh, there are virtually TONs of possible and potentially useful crypto-related projects out there.

I have over the years provided plenty of pointers in PKIX to such with quite limited feedback.
The crux is getting anything implemented as well as getting some kind of funding.

There are more subtle hurdles as well.  If you are not world-renowned cryptographer or
working for a well-known (US) technology provider nobody will even read your papers.

I do currently not work with IoT or WiFi authentication so I may be a less useful partner.

I'm rather trying to create a scheme for challenging CENTRALIZED payment schemes
like Android and Apple Pay through a DECENTRALIZED trust infrastructure.
It is so full of crypto that hardly any bank-tech folks get it :-|


> Cheers,
> Max
> On 7/20/17 2:15 PM, Anders Rundgren wrote:
>> Max,
>> If we stick to the problem with outdated crypto algorithms, the only reasonable solution is updating keys (and software...) when needed.  The latter is worked on in the IETF TEEP WG.
>> Regarding the state of PKI, none of the PKIX enrollment protocols support MFA or key attestations.  In fact, the entire PKIX WG were *against* such ideas (when raised by me) when EST was on the "drawing board". FIDO alliance products (of course) have this as a core facility.
>> Anders
> -- 
> Best Regards,
> Massimiliano Pala, Ph.D.
> OpenCA Labs Director
> OpenCA Logo
> _______________________________________________
> pkix mailing list