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

Anders Rundgren <> Thu, 20 July 2017 19:56 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 69956131B8D for <>; Thu, 20 Jul 2017 12:56:35 -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 rdGU0Lm-1CSf for <>; Thu, 20 Jul 2017 12:56:25 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:400c:c0c::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id E8A67131B80 for <>; Thu, 20 Jul 2017 12:56:24 -0700 (PDT)
Received: by with SMTP id 33so18288534wrz.4 for <>; Thu, 20 Jul 2017 12:56:24 -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=6NnWhYRYS66pxmRSfdpj7eekC7ZMtH2dN0Pk3wlzC4Q=; b=F9a1ljDpjkj94XW+XQE15pppbusgmgH7Oxgn2NQyhZcSSsxGu4RNgpbKbY9Kh4AdfY BP5xjHK2lopGpSC8U1kCRARXIzajIZIGjh/vElF7dHzVuw9WDULED2tDh53Dn5YNjzcd OWe9c3zUTA7pigpR6MfJ2nVl56VV2qTwjVUwDgOfmC17399FJ01jGGcVMfMqi5bNNTUu B1DevVJ7s2aQU4XneKqkl8fBwqfR1QSotFepYEun55C8tjtIXJfsakxnIUs3ni/SqNHH wcaaVPMB6Jv93Vvh+KVKcsVb0HziYyZGUMVwKrELOc7lQv+bOgHJsEaoDsh99Hp0o3ne /MtA==
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=6NnWhYRYS66pxmRSfdpj7eekC7ZMtH2dN0Pk3wlzC4Q=; b=VGdKWMsxSY0pCADSKhD/b+9RgknfvqsKefl6iwXn46O8HpBy4Esjq7+tG/n32ffM5W wqGGnSWNyGM2gfy5N2xRl3CSbpR2lwgd+RLqZLEMoOBsKHK0dTgNQuwOQ6NcAZMUvOQX fHSE61m6wxRHCphLFgd8Yi51syKx/vaiLmCcmABdm1nczfICUy7S5332CsU6kqEb7j0Z nZN63sv48x0UreNgqD1P0ILVFcDwGUxBJLkEZ6GsEBTv3GtZhn5cKLtVBtPvZ2dCWXy9 m/seYZGrqtxbze1pIXrU2Xdr2ALqAKaR2Q3lJjqW4FlnXkXC1LIp8jCdDpOKvoGY+G45 MbBA==
X-Gm-Message-State: AIVw111RLVsReKp4d4jFD9ISlt9H2en7ovH/drTJobuv1m9LZKhCN/wR LvZtj+MxDAUF69j7
X-Received: by with SMTP id 75mr7063024wrl.99.1500580583250; Thu, 20 Jul 2017 12:56:23 -0700 (PDT)
Received: from [] ( []) by with ESMTPSA id b23sm722467wrd.40.2017. (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 20 Jul 2017 12:56:22 -0700 (PDT)
To: "Dr. Pala" <>, PKIX <>
References: <> <> <> <> <>
From: Anders Rundgren <>
Message-ID: <>
Date: Thu, 20 Jul 2017 21:56:20 +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 19:56:35 -0000

On 2017-07-20 18:39, Dr. Pala wrote:
> Thanks Anders,
> DISCLAIMER: I just want to clarify that this discussion is not part of what I proposed as work on revocation.
> This said, I would say that if your attempt to provide a decentralized system for payments would benefit from the work around revocation and / or discoverability, I would be interested to read about the use-cases there.

Hi Max,
The system I'm working with is fairly unconventional and maybe not in your taste.  If you take a peek at the link I provided (and associated documents), you will find a "Pseudo CA" issuing short-lived certificate-like objects expressed in JSON.
Why "Pseudo CA"?  Because a true X.509 solution would not meet the decentralization objectives.  Since the payment messages were based on JSON and use the definitions in the certificate-like objects, it seemed logical to use JSON everywhere it was possible.

IoT is an entirely different animal than payments (although some IoT devices can be payers as well).

PKI for user auth was severely wounded by the [not so] smart card industry.  The final kill was made by Google who removed on-line provisioning from Chrome. Not even the inventor of the Web, Sir Berners-Lee could save it:


> Thanks,
> Max
> On 7/20/17 5:53 PM, Anders Rundgren wrote:
>> 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 :-|
> -- 
> Best Regards,
> Massimiliano Pala, Ph.D.
> OpenCA Labs Director
> OpenCA Logo