Re: [pkix] Redundant signature algorithm info in certs.

Erwann Abalea <> Tue, 24 May 2016 23:51 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id EF68F12D7FB for <>; Tue, 24 May 2016 16:51:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Status: No, score=-2.699 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 f4VeEFMo5jjt for <>; Tue, 24 May 2016 16:51:22 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4010:c07::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 214B012D5D3 for <>; Tue, 24 May 2016 16:51:22 -0700 (PDT)
Received: by with SMTP id e131so11956605lfb.0 for <>; Tue, 24 May 2016 16:51:22 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=GlnGuzCO9F0DJbB6pcfnajjX25QGYEpBoNEGwIo6Xjo=; b=hnIAL90HT4MhQrXpDjdMHLnFgoLmFRqgM3bS2ZQYIFyXUT5hSO88DcFJXKQSHeBRad XUZvOEMC63Sym85vnbctXxZUPqqewiMxEcAYM7S6JwNcw/cxxkQXpPpbh7bQIIxqME3L c76SZ9bYrbdFZQIoho0KwVwBhAWvQIhnVh1YC68Z88l1gs1ZusdE9VeJvlG1LpZA2Jq9 B5rXbwuPDGhRjaFhGX+XFch1iNkpdHaso9k7S/z3kezj4WzntmyMTdmz/c04ZA+h/6xL 9W0hQ+4UjKjqd/2GTnjv23y+tC3k8mMUmdMBk5uNy1BzTZduZVtJmWnkg/FiMWT3AyK3 wg+g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=GlnGuzCO9F0DJbB6pcfnajjX25QGYEpBoNEGwIo6Xjo=; b=ZJpuLPJwZyeIqmaMkyDAXsFdtUWTByzkYyCauJBLH4dF8aJzxckCx7xxo7fptkQvDx HhalhAh5NXeZbhnk/eam5YCEcgzonw6+PBrd34G7GXo/ZdQwuJkQXXKfdu1/70gZxHYW kWRMvTAMVhZnOnl3SbA1vAkbvWOH9BIwnDbWNMFsk5MDMGkzJdGWkOiJd6YmsW5KHgLd qyeT8URG7ZyLvf+hUXFWLHPl0p5CVEg86LZdelU+BnJWJ0B/NhyZgYNGOZwSUJuwtYBH ARAnOvLABSOpjvhXwwh9LL23BH6bbx0xV2wOdj+DyPs+grrAFQiM80cUXWJ6Y9rvV+oj 3jhA==
X-Gm-Message-State: ALyK8tJp5lzri9fwpppva8t+2PMWOzg5ufjQYsm1VkEbyNRVxNDuWiJDBOFhTekbS2WhIx6bev0iu+03dKzIIw==
MIME-Version: 1.0
X-Received: by with SMTP id b124mr133999lfb.99.1464133880207; Tue, 24 May 2016 16:51:20 -0700 (PDT)
Received: by with HTTP; Tue, 24 May 2016 16:51:20 -0700 (PDT)
In-Reply-To: <000701d1b5bd$267b0d60$73712820$>
References: <000701d1b5bd$267b0d60$73712820$>
Date: Wed, 25 May 2016 01:51:20 +0200
Message-ID: <>
From: Erwann Abalea <>
To: Erik Andersen <>
Content-Type: multipart/alternative; boundary=001a11403a26d5642e05339f3b29
Archived-At: <>
Cc: PKIX <>, Directory list <>
Subject: Re: [pkix] Redundant signature algorithm info in certs.
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: PKIX Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 24 May 2016 23:51:24 -0000


2016-05-24 15:06 GMT+02:00 Erik Andersen <>eu>:

> The question about apparently redundant signature algorithm information in
> public-key certificates, attribute certificates and CRLs has been raised
> before. It seems clear that by including the signature algorithm within the
> body of the cert, it is protected by the signature. But why does the
> algorithm then has to be part of the signature itself?

Probably because X.509 starts by defining what a signature is, defining a
SIGNED ASN.1 macro able to take a private key, a signature algorithm, and
some opaque "ToBeSigned" data, resulting in a complete structure that can
be passed to an equivalent hypothetical VERIFY macro? This macro doesn't
need to know that the signatureAlgorithm is or isn't included in this
ToBeSigned. From an API point of view, that doesn't sound illogical.
A Certificate is defined as a SIGNED{Something} since the 1993 edition, at
The order between "defining what is a Certificate" and "what is a digital
signature" has been reversed between 1993 and 1997 editions.

I am not suggesting to change current specifications. The question could be
> relevant for new  signed structures developed by other specifications.
PKCS#7/CMS hasn't followed this path. What is really protected in integrity
is either the sole content or a DER encoded version of the signed
attributes. The signature algorithm in itself isn't protected.