IETF Logo Mail Archive

Re: [pkix] DER encoding in RFC 3161

Phillip Hallam-Baker <phill@hallambaker.com> Wed, 29 July 2020 21:11 UTC

Return-Path: <hallam@gmail.com>
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 BA23B3A115D for <pkix@ietfa.amsl.com>; Wed, 29 Jul 2020 14:11:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.915
X-Spam-Level:
X-Spam-Status: No, score=-1.915 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.001, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 fzQHXqVFfTqC for <pkix@ietfa.amsl.com>; Wed, 29 Jul 2020 14:10:58 -0700 (PDT)
Received: from mail-oo1-f52.google.com (mail-oo1-f52.google.com [209.85.161.52]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EA1403A0FDB for <pkix@ietf.org>; Wed, 29 Jul 2020 14:10:34 -0700 (PDT)
Received: by mail-oo1-f52.google.com with SMTP id k4so420707ooa.9 for <pkix@ietf.org>; Wed, 29 Jul 2020 14:10:34 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=3ce04IweFGExkdNgIUZ9p8Gl9vwFmro1hL9WS4IIX3I=; b=puMzCKe5npFuvfDEBAFHLw01ZvwVIz6hwtdKs97Zb6gWuGfBbWTGb5kTsoGf7VeTXI b1cyq2xvI9r4U0tAPTDePjm92gzsksr+YAM/P5j1nRmfP82OFzuNmxQ2Jvxdg+pp/Jvw fJKsNjc9g/3B5w5RQraEyYvEPk7tef225A5eqQECu7oLkW8LTBDXNv49qb95bKh8B45N b/83mY9pW08z0fte+GQuljkzhNfvNlDXaDK0EHdLOmT/24uElbRUL6uPLUFeaDaG/EBm PYiHXRNkRSb3Qcriw8+uwm7pgOGQDa+GjeAvYk06oM6lrekfqGs2C7AW1xkUJ6MEg42F 9VQg==
X-Gm-Message-State: AOAM532NGjnDEsXZhMK9IWD5Gm8RreoNKzUxVObTJe8hOr584LZugY9o HYZav8AD9GrW+NtmwNjFRZYsF1ETJ7ynkAWKEv52jV6B
X-Google-Smtp-Source: ABdhPJzGx4h5rQ+JLQGd+llgMnrZ/xmEAdveMv+QVW8t/z4Cp3rwObgc5XWc9v7/V68K7IxLNN2zEDHNU7s8NLEpeTE=
X-Received: by 2002:a4a:a80d:: with SMTP id o13mr130316oom.12.1596057034036; Wed, 29 Jul 2020 14:10:34 -0700 (PDT)
MIME-Version: 1.0
References: <PS1PR03MB48921EE23E93434559DF1ECE9D730@PS1PR03MB4892.apcprd03.prod.outlook.com>
In-Reply-To: <PS1PR03MB48921EE23E93434559DF1ECE9D730@PS1PR03MB4892.apcprd03.prod.outlook.com>
From: Phillip Hallam-Baker <phill@hallambaker.com>
Date: Wed, 29 Jul 2020 17:10:22 -0400
Message-ID: <CAMm+LwhdgfkbwXrfX8yiK3UDJRGOGzMJ2mXuyKqZWTdGbBE6gQ@mail.gmail.com>
To: Koichi Sugimoto <koichi.sugimoto=40globalsign.com@dmarc.ietf.org>
Cc: "pkix@ietf.org" <pkix@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000008e1bad05ab9afc07"
Archived-At: <https://mailarchive.ietf.org/arch/msg/pkix/ntYo0tqzG6O7qoCMIti2qGNHtwo>
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, 29 Jul 2020 21:11:07 -0000

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.


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> 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
> https://www.ietf.org/mailman/listinfo/pkix
>

v2.23.0 | Report a Bug | By Email