Subject: [pkix] Certificate Encoding Questions

From: <[email-masked]>
Date: Thu, 5 Sep 2019 15:19:24 +0000

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.

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.

Please keep Ken Goldman on the cc list for responses, if possible.

Thanks,

Steve

---

From: Ryan Sleevi <[email-masked]>
Date: Thu, 5 Sep 2019 12:09:44 -0400

On Thu, Sep 5, 2019 at 11:19 AM <[email-masked]> wrote:

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

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

---

From: <[email-masked]>
Date: Thu, 5 Sep 2019 17:45:40 +0000

Ryan,

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?

Thanks,

Steve

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

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

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.

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)

---

From: Michael StJohns <[email-masked]>
Date: Thu, 5 Sep 2019 16:21:08 -0400

On 9/5/2019 12:09 PM, Ryan Sleevi wrote:
>
>
> On Thu, Sep 5, 2019 at 11:19 AM <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     1)The KeyUsage extension includes a BIT STRING. Is this encoded so
>     (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.
>
> 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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/pkix