Re: [pkix] Certificate Encoding Questions

<> Thu, 05 September 2019 17:45 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 816C01200E5 for <>; Thu, 5 Sep 2019 10:45:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.298
X-Spam-Status: No, score=-4.298 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id uH38QAQJ5Rai for <>; Thu, 5 Sep 2019 10:45:45 -0700 (PDT)
Received: from ( [IPv6:2a00:18f0:1e00:4::4]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 4A1AF1200D6 for <>; Thu, 5 Sep 2019 10:45:45 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;;; q=dns/txt; s=IFXMAIL; t=1567705545; x=1599241545; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=DUP6w+Nzkx9FjE6OeXHLdut/eXEFeZUB8+LW9e7pq2c=; b=J1XbzoN6+RsyWT+PQubqvn38cJWiYCBVGXnaurgYNVTYZITLL5yzmmqw sQrgJ6gdMu1QvZFQYug0be4L4nywoQScCDk8FyPL+bKDOVy98nO/VmiR+ Bq7l6oeSjpIx1bb8P92SCHv1F8dxQDREaQXf8WdoQbqGS01PoMsxDxjZw M=;
IronPort-SDR: VYhZ6n1obFy45056RWDeAj25Ha0naUibzhywLzsb9yFJby8ZA18grgmtCteaHHW2Yu/q3QI9ho IZ259ZUPfy8A==
X-SBRS: None
X-IronPort-AV: E=McAfee;i="6000,8403,9371"; a="11867060"
X-IronPort-AV: E=Sophos; i="5.64,470,1559512800"; d="scan'208,217"; a="11867060"
Received: from unknown (HELO ([]) by with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 05 Sep 2019 19:45:41 +0200
Received: from ( []) by (Postfix) with ESMTPS; Thu, 5 Sep 2019 19:45:41 +0200 (CEST)
Received: from ( by ( with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.1.1713.5; Thu, 5 Sep 2019 19:45:41 +0200
Received: from ( by ( with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.1.1713.5; Thu, 5 Sep 2019 19:45:41 +0200
Received: from ([fe80::e599:a749:53f5:64a1]) by ([fe80::e599:a749:53f5:64a1%17]) with mapi id 15.01.1713.008; Thu, 5 Sep 2019 19:45:40 +0200
From: <>
To: <>
CC: <>, <>
Thread-Topic: [pkix] Certificate Encoding Questions
Thread-Index: AdVj/No4WD0mhQIeRjm/+bbI1YgSBP//7W0A///G0cA=
Date: Thu, 5 Sep 2019 17:45:40 +0000
Message-ID: <>
References: <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: multipart/alternative; boundary="_000_f0ae2bd5921d40a68cbae00730a5b04einfineoncom_"
MIME-Version: 1.0
Archived-At: <>
Subject: Re: [pkix] Certificate Encoding Questions
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: PKIX Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 05 Sep 2019 17:45:48 -0000


Thanks for your quick response.

I just downloaded X.690 and also X.680 because that seems to be also necessary to answer my question 1). My conclusion is that the answer to question 1) is “Yes”. Right?



From: Ryan Sleevi <>
Sent: Thursday, September 5, 2019 12:10 PM
To: Hanna Steve (IFAM DSS SMD AMR) <>
Cc: IETF PKIX <>rg>;
Subject: Re: [pkix] Certificate Encoding Questions

On Thu, Sep 5, 2019 at 11:19 AM <<>> wrote:
I have a few simple questions about ASN.1 encoding for X.509 certificates. Can you help?

1)      The KeyUsage extension includes a BIT STRING. Is this encoded so that the most significant bit in the DER encoded value is bit 0 (digitalSignature)? After looking at a few certificates, that seems to be true but I want to verify.

X.690 addresses this, as that describes how DER encoding (and BER encoding) work on the wire.

In X.690 (08/15), the relevant clause will be (for the general BER encoding) and 11.2 for the further DER modifications.

2)      RFC 5754 says that when the algorithm OID in an AlgorithmIdentifier structure is sha256WithRSAEncryption, the parameters MUST be NULL. Would that NULL value encode to an additional 05 00 at the end of the SEQUENCE? Again, I observe this to be true but I want to verify it.
Yes. Omission would have been specified by "MUST be absent.".

This is perhaps more obvious in RFC 5912, which provides an explicit ASN.1 module that captures these encoding requirements (specifically, see Section 8, ASN.1 Module for RFC 4055)