IETF Logo Mail Archive

Re: [pkix] DER encoding in RFC 3161

David Chadwick <D.W.Chadwick@kent.ac.uk> Wed, 05 August 2020 05:50 UTC

Return-Path: <D.W.Chadwick@kent.ac.uk>
X-Original-To: pkix@ietfa.amsl.com
Delivered-To: pkix@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B2EAB3A0C48 for <pkix@ietfa.amsl.com>; Tue, 4 Aug 2020 22:50:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.848
X-Spam-Level:
X-Spam-Status: No, score=-2.848 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.949, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 IQHt5kkJ5569 for <pkix@ietfa.amsl.com>; Tue, 4 Aug 2020 22:50:54 -0700 (PDT)
Received: from mx0.kent.ac.uk (mx0.kent.ac.uk [129.12.21.32]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 00E453A0C46 for <pkix@ietf.org>; Tue, 4 Aug 2020 22:50:53 -0700 (PDT)
Received: from mx6.kent.ac.uk ([129.12.21.37]) by mx0.kent.ac.uk with esmtps (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94) (envelope-from <D.W.Chadwick@kent.ac.uk>) id 1k3CKC-000Vef-6R for pkix@ietf.org; Wed, 05 Aug 2020 06:50:52 +0100
Received: from 222.236.93.209.dyn.plus.net ([209.93.236.222] helo=AdminisatorsMBP.lan) by mx6.kent.ac.uk with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.92.3) (envelope-from <D.W.Chadwick@kent.ac.uk>) id 1k3CKA-00034k-AX for pkix@ietf.org; Wed, 05 Aug 2020 06:50:52 +0100
To: pkix@ietf.org
References: <PS1PR03MB48921EE23E93434559DF1ECE9D730@PS1PR03MB4892.apcprd03.prod.outlook.com> <CAMm+LwhdgfkbwXrfX8yiK3UDJRGOGzMJ2mXuyKqZWTdGbBE6gQ@mail.gmail.com>
From: David Chadwick <D.W.Chadwick@kent.ac.uk>
Organization: University of Kent
Message-ID: <2587f56c-1159-9933-e4e4-4e97082bb8da@kent.ac.uk>
Date: Wed, 05 Aug 2020 06:49:47 +0100
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:68.0) Gecko/20100101 Thunderbird/68.11.0
MIME-Version: 1.0
In-Reply-To: <CAMm+LwhdgfkbwXrfX8yiK3UDJRGOGzMJ2mXuyKqZWTdGbBE6gQ@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Content-Language: en-GB
X-Kent-Spam-Score: -1.0
X-Kent-Spam-Bar: -
X-Kent-Spam-Report: No, tests=ALL_TRUSTED=-1, NICE_REPLY_A=-0.001, TVD_RCVD_IP=0.001
Archived-At: <https://mailarchive.ietf.org/arch/msg/pkix/_mTwDLkdH26QztKA3CIWB94HAw4>
Subject: Re: [pkix] DER encoding in RFC 3161
X-BeenThere: pkix@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: PKIX Working Group <pkix.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/pkix>, <mailto:pkix-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/pkix/>
List-Post: <mailto:pkix@ietf.org>
List-Help: <mailto:pkix-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/pkix>, <mailto:pkix-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 05 Aug 2020 05:50:56 -0000

On 29/07/2020 22:10, Phillip Hallam-Baker wrote:
> I have been doing X.509v3 for 30 years now. I have yet to hear a good 
> answer to the question of why DER encoding is needed in PKIX.
>
> It is a requirement of X.509 but not one that makes the slightest 
> sense in these days when you can store a billion certs on one disk 
> drive and X.500 directory has fewer active users than Edison 
> phonographs. Certificates are moved from point A to point B as an 
> opaque binary blob which is encoded by the signer at signing time and 
> only at signing time. This notion of signing the abstract data rather 
> than the binary bits keeps coming up but I have yet to see anyone work 
> out how to do it reliably, let alone add value by doing so.
>
> A digital signature is over a string of bits. The road to madness is 
> paved by canonicalization schemes.

And it is infectious. In the W3C CCG group the canonicalisation issue 
was raised again this week, only this time it is about canonicalising 
the JSON encoding of a public key. I have said it is not needed, but I 
am not convinced that many?anyone? are/is listening.

Kind regards

David

>
>
> It is sufficiently possible that there are ASN.1 parsers there that 
> insist on strict DER with definite length encoding throughout that 
> changing PKIX to allow BER encoding would now be a breaking change. 
> And the same argument can be made for cases where BER encoding is 
> indicated.
>
> So at this point, the best thing we can do is to just accept that the 
> spec is going to be ugly and not try to fix it.
>
>
>
> On Tue, Jul 28, 2020 at 3:58 AM Koichi Sugimoto 
> <koichi.sugimoto=40globalsign.com@dmarc.ietf.org 
> <mailto:40globalsign.com@dmarc.ietf.org>> wrote:
>
>     Hello PKIX members,
>
>     RFC 3161 specifies “The eContent SHALL be the DER-encoded value of
>     TSTInfo.” in “2.4.2. Response Format”
>
>     Why RFC 3161 does not require DER-encoded value for full
>     time-stamp token (CMS data)?
>
>     On the other hand, following protocol encoding seems to require
>     all DER-encoded for entire time-stamp message.
>
>     3..1. Time-Stamp Protocol Using E-mail
>
>     3.2. File Based Protocol
>
>     3.3. Socket Based Protocol
>
>     3.4. Time-Stamp Protocol via HTTP
>
>     This seems time-stamp token requires DER-encoded indirectly.
>
>     Regards,
>
>     Koichi Sugimoto.
>
>     _______________________________________________
>     pkix mailing list
>     pkix@ietf.org <mailto:pkix@ietf.org>
>     https://www.ietf.org/mailman/listinfo/pkix
>
>
> _______________________________________________
> pkix mailing list
> pkix@ietf.org
> https://www.ietf.org/mailman/listinfo/pkix

v2.23.0 | Report a Bug | By Email