Re: [pkix] Certificate Encoding Questions

[Michael StJohns <[e-mail]>]

On 9/5/2019 12:09 PM, Ryan Sleevi wrote:
>
>
> On Thu, Sep 5, 2019 at 11:19 AM <[e-mail] 
> <mailto:[e-mail]>> 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/pkix