Re: [pkix] Certificate Encoding Questions

Michael StJohns <msj@nthpermutation.com> Thu, 05 September 2019 20:21 UTC

Return-Path: <msj@nthpermutation.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 BD6EF120868 for <pkix@ietfa.amsl.com>; Thu, 5 Sep 2019 13:21:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.896
X-Spam-Level:
X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=nthpermutation-com.20150623.gappssmtp.com
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 lEXQBLXgJyzg for <pkix@ietfa.amsl.com>; Thu, 5 Sep 2019 13:21:12 -0700 (PDT)
Received: from mail-qk1-x741.google.com (mail-qk1-x741.google.com [IPv6:2607:f8b0:4864:20::741]) (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 D662B1207FF for <pkix@ietf.org>; Thu, 5 Sep 2019 13:21:11 -0700 (PDT)
Received: by mail-qk1-x741.google.com with SMTP id f13so3459021qkm.9 for <pkix@ietf.org>; Thu, 05 Sep 2019 13:21:11 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nthpermutation-com.20150623.gappssmtp.com; s=20150623; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language; bh=p+GoVmNDYVTPNcPudNE2AhCp3ld7kHGiKFnT3fsCULI=; b=gRbzeGcKesCXMdoXPbTGTExF0HySzHWf0JMBiKPprNfkhBCgSKeuY8iIdxm07PDfVv krkggqcwjulKZZggEiF5x5JJ2zrmS09+HuGjz4ZgTjtn4CH03Y5pA3JDzOvbV5nLAfwP eJLxFAu9YMM+3srL64EcnPnSl7Gf2mxMGZlBXfOGEcs/D7mapikyBqNuTVXgQKwmb6me 9/J6Cjd00DxsKGOBAASzTHnV3WQ8RSTuOpgpvrxMcRGFi75N8fjCX4mLeENN4KToOSM+ 2ipssv5OYB3woqAHf/XpDkfdsdq9I2gBHnX/iuWnjT+jVwPYI3PmppKV4ttFSx9O5H0D Lp4Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language; bh=p+GoVmNDYVTPNcPudNE2AhCp3ld7kHGiKFnT3fsCULI=; b=dHKN2z8L9AF12YbLJ/Vq6wDuh5I1MfuW4dJqLVB75dvux6LHgeBl0jWx77/Z8/FImd fuAwh8y3+pWAPCvgXb4kh+8liqxdxvLkXDGekm/22TOs7hC5UBQB13IrW/hl93tjkfo3 t0bnvllZ9Cd2NMwgGYYm/MUKGq9oEPhbaVo696DXLQcuZNCQ9XfMH7tB4QsC57oYGVpg RHsKefZ5aOP7vnxgS0def8dzQxtgTCiozwA0leJI5o2fEo0t3CRkh/vGppZiPP8D5tlR T0yeaP81IycXD/qqzIOiionbHxPjUqQslAdJXFEpIpHVPuUArOLE90KmzFWUDPWlhI8r 83dg==
X-Gm-Message-State: APjAAAWVIzng5c068nj0ceMZePqbbwjTr+dDuamyTXGaD4E/euusgceD ozYDb0bsMth9ggjVV1QH/hNISPx0qks=
X-Google-Smtp-Source: APXvYqxpKZkCQTc/65g29VKIehYLqGTBRuMGw0p6DfM7W10wLW2Ct1kuryDJCrZ3nIURPKyFbiEW7g==
X-Received: by 2002:a37:883:: with SMTP id 125mr4927939qki.478.1567714870566; Thu, 05 Sep 2019 13:21:10 -0700 (PDT)
Received: from ?IPv6:2601:152:4400:437c:ed88:5732:4488:cfe8? ([2601:152:4400:437c:ed88:5732:4488:cfe8]) by smtp.gmail.com with ESMTPSA id h10sm1895949qtk.18.2019.09.05.13.21.09 for <pkix@ietf.org> (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 05 Sep 2019 13:21:10 -0700 (PDT)
To: pkix@ietf.org
References: <5eec7483c95247cb8968752588ff09f2@infineon.com> <CAErg=HE2YOc5jFK0km7eoTHMkykxzFTXBY0swkdbQD8JJ-5JKQ@mail.gmail.com>
From: Michael StJohns <msj@nthpermutation.com>
Message-ID: <0ec81bda-d7a8-63db-457a-ea8f6be255e5@nthpermutation.com>
Date: Thu, 5 Sep 2019 16:21:08 -0400
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0
MIME-Version: 1.0
In-Reply-To: <CAErg=HE2YOc5jFK0km7eoTHMkykxzFTXBY0swkdbQD8JJ-5JKQ@mail.gmail.com>
Content-Type: multipart/alternative; boundary="------------5C9A3C96DA6C8E4E75855C62"
Content-Language: en-US
Archived-At: <https://mailarchive.ietf.org/arch/msg/pkix/VqOXavxItgZhBK26bw9WI-7BWoQ>
Subject: Re: [pkix] Certificate Encoding Questions
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: Thu, 05 Sep 2019 20:21:14 -0000

On 9/5/2019 12:09 PM, Ryan Sleevi wrote:
>
>
> On Thu, Sep 5, 2019 at 11:19 AM <Steve.Hanna@infineon.com 
> <mailto:Steve.Hanna@infineon.com>> 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 8.6.2.1 (for the general 
> BER encoding) and 11.2 for the further DER modifications.

The left most bit of the left most byte is bit 0 in a BitString. That's 
Bit 1 of byte 0.  (Bits are numbered in the bytes from 1-8).    So 
{digitalSignature} would be encoded  03 02 07 80



>     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)

This is one of those things where it depends on the actual algorithm.   
AlgorithmIdentifier is defined as

>   AlgorithmIdentifier  ::=  SEQUENCE  {
>          algorithm               OBJECT IDENTIFIER,
>          parameters              ANY DEFINED BY algorithm OPTIONAL  }
which says first look at the algorithm field before trying to parse 
parameters.    In this case, the actual controlling document is RFC8017 
not RFC5912 and that defines the parameter field as NULL rather than 
omitting it which probably would have been a smarter definition.   From 
an implementation POV, I'd be surprised if anyone actually tries to 
parse the parameters field, but you're safer setting it to NULL  { 05 00 }.

Mike



>
> _______________________________________________
> pkix mailing list
> pkix@ietf.org
> https://www.ietf.org/mailman/listinfo/pkix