Encoding of AlgorithmIdentifier with NULL parameters

[Russ Housley]

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mta.openssl.org/pipermail/openssl-users/attachments/20210128/2f9c8ad9/attachment-0001.html>