Encoding of AlgorithmIdentifier with NULL parameters

[Richard Levitte]

This was a good find, thank you all.

It's clearly a bug.  Fix on GitHub, in PR #14030
(https://github.com/openssl/openssl/pull/14030)

Cheers,
Richard

On Thu, 28 Jan 2021 21:04:17 +0100,
Russ Housley wrote:
> 
> [1  <text/plain; us-ascii (quoted-printable)>]
> [2  <text/html; us-ascii (quoted-printable)>]
> RFC 4055 says:
> 
>    The object identifier used to identify the PKCS #1 version 1.5
>    signature algorithm with SHA-224 is:
> 
>       sha224WithRSAEncryption  OBJECT IDENTIFIER  ::=  { pkcs-1 14 }
> 
>    The object identifier used to identify the PKCS #1 version 1.5
>    signature algorithm with SHA-256 is:
> 
>       sha256WithRSAEncryption  OBJECT IDENTIFIER  ::=  { pkcs-1 11 }
> 
>    The object identifier used to identify the PKCS #1 version 1.5
>    signature algorithm with SHA-384 is:
> 
>       sha384WithRSAEncryption  OBJECT IDENTIFIER  ::=  { pkcs-1 12 }
> 
>    The object identifier used to identify the PKCS #1 version 1.5
>    signature algorithm with SHA-512 is:
> 
>       sha512WithRSAEncryption  OBJECT IDENTIFIER  ::=  { pkcs-1 13 }
> 
>    When any of these four object identifiers appears within an
>    AlgorithmIdentifier, the parameters MUST be NULL.  Implementations
>    MUST accept the parameters being absent as well as present.
> 
> So, when generating the certificate, the NULL ought to be there.
> 
> Also, when validating, the code should be forgiving about it not being there.
> 
> Russ
> 
>     On Jan 28, 2021, at 2:07 PM, Thulasi Goriparthi <thulasi.goriparthi at gmail.com> wrote:
>    
>     I am trying to provide a test certificate generated by openssl-3.0.0-alpha10 to a third party
>     certificate parser/manager. This software expects AlgorithmIdentifier to either have
>     parameters or to have null encoded (05 00) parameters which seems to be missing in the
>     certificate.
>    
>     Certificate generated by openssl-3.0.0-alpha10
>    
>         0:d=0  hl=4 l=1030 cons: SEQUENCE          
>         4:d=1  hl=4 l= 752 cons: SEQUENCE          
>         8:d=2  hl=2 l=   3 cons: cont [ 0 ]        
>        10:d=3  hl=2 l=   1 prim: INTEGER           :02
>        13:d=2  hl=2 l=   1 prim: INTEGER           :01
>        16:d=2  hl=2 l=  11 cons: SEQUENCE          
>        18:d=3  hl=2 l=   9 prim: OBJECT            :sha256WithRSAEncryption
>        29:d=2  hl=3 l= 143 cons: SEQUENCE          
>        32:d=3  hl=2 l=  11 cons: SET               
>        34:d=4  hl=2 l=   9 cons: SEQUENCE          
>        36:d=5  hl=2 l=   3 prim: OBJECT            :countryName
>    
>     Certificate generated by openssl-1.1.1g
>    
>         0:d=0  hl=4 l= 988 cons: SEQUENCE          
>         4:d=1  hl=4 l= 708 cons: SEQUENCE          
>         8:d=2  hl=2 l=   3 cons: cont [ 0 ]        
>        10:d=3  hl=2 l=   1 prim: INTEGER           :02
>        13:d=2  hl=2 l=   1 prim: INTEGER           :01
>        16:d=2  hl=2 l=  13 cons: SEQUENCE          
>        18:d=3  hl=2 l=   9 prim: OBJECT            :sha256WithRSAEncryption
>        29:d=3  hl=2 l=   0 prim: NULL              
>        31:d=2  hl=3 l= 143 cons: SEQUENCE          
>        34:d=3  hl=2 l=  11 cons: SET               
>        36:d=4  hl=2 l=   9 cons: SEQUENCE          
>        38:d=5  hl=2 l=   3 prim: OBJECT            :countryName
>    
>     From https://tools.ietf.org/html/rfc5280#section-4.1.1.2, It isn't clear if NULL parameters
>     can be completely omitted or if it should still have NULL encoding.
>    
>     Is this a too stringent check in the third-party s/w or a miss in openss-3.0.0-alpha10?
>    
>     Thanks,
>     Thulasi.
> 
> 
-- 
Richard Levitte         levitte at openssl.org
OpenSSL Project         http://www.openssl.org/~levitte/