Encoding of AlgorithmIdentifier with NULL parameters

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

Encoding of AlgorithmIdentifier with NULL parameters

Thulasi Goriparthi
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.
Reply | Threaded
Open this post in threaded view
|

Re: 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 <[hidden email]> 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.

Reply | Threaded
Open this post in threaded view
|

Re: Encoding of AlgorithmIdentifier with NULL parameters

Viktor Dukhovni
In reply to this post by Thulasi Goriparthi
On Fri, Jan 29, 2021 at 12:37:18AM +0530, Thulasi Goriparthi 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.

Indeed it appears that the development branch differs in its output
format from the stable releases, in that the (05 00) NULL parameters
present in the tbsCertificate are missing from the signature block:

    $ OpenSSL_master/bin/openssl req \
        -config <(printf 'distinguished_name = dn\n[dn]\nprompt=yes\n') \
        -new -newkey rsa:1024 -keyout /dev/null \
        -x509 -subj / -days 30 -nodes 2>/dev/null |
        openssl asn1parse
        0:d=0  hl=4 l= 381 cons: SEQUENCE
        4:d=1  hl=3 l= 233 cons: SEQUENCE
        7:d=2  hl=2 l=  20 prim: INTEGER           :58EFB7C8A23DC6F6A16D9C30A9300C285B7E9287
       29:d=2  hl=2 l=  11 cons: SEQUENCE
       31:d=3  hl=2 l=   9 prim: OBJECT            :sha256WithRSAEncryption
       42:d=2  hl=2 l=   0 cons: SEQUENCE
       44:d=2  hl=2 l=  30 cons: SEQUENCE
       46:d=3  hl=2 l=  13 prim: UTCTIME           :210128221706Z
       61:d=3  hl=2 l=  13 prim: UTCTIME           :210227221706Z
       76:d=2  hl=2 l=   0 cons: SEQUENCE
       78:d=2  hl=3 l= 159 cons: SEQUENCE
       81:d=3  hl=2 l=  13 cons: SEQUENCE
       83:d=4  hl=2 l=   9 prim: OBJECT            :rsaEncryption
       94:d=4  hl=2 l=   0 prim: NULL
       96:d=3  hl=3 l= 141 prim: BIT STRING
      240:d=1  hl=2 l=  11 cons: SEQUENCE
      242:d=2  hl=2 l=   9 prim: OBJECT            :sha256WithRSAEncryption
      253:d=1  hl=3 l= 129 prim: BIT STRING

as compared with e.g. OpenSSL 1.1.1:

    $ OpenSSL_1_1_1/bin/openssl req \
        -config <(printf 'distinguished_name = dn\n[dn]\nprompt=yes\n')
        -new -newkey rsa:1024 -keyout /dev/null \
        -x509 -subj / -days 30 -nodes 2>/dev/null |
        openssl asn1parse
        0:d=0  hl=4 l= 385 cons: SEQUENCE
        4:d=1  hl=3 l= 235 cons: SEQUENCE
        7:d=2  hl=2 l=  20 prim: INTEGER           :72A1C904EDFE1C1F15DF51649A7A9F339A0982CD
       29:d=2  hl=2 l=  13 cons: SEQUENCE
       31:d=3  hl=2 l=   9 prim: OBJECT            :sha256WithRSAEncryption
       42:d=3  hl=2 l=   0 prim: NULL
       44:d=2  hl=2 l=   0 cons: SEQUENCE
       46:d=2  hl=2 l=  30 cons: SEQUENCE
       48:d=3  hl=2 l=  13 prim: UTCTIME           :210128222008Z
       63:d=3  hl=2 l=  13 prim: UTCTIME           :210227222008Z
       78:d=2  hl=2 l=   0 cons: SEQUENCE
       80:d=2  hl=3 l= 159 cons: SEQUENCE
       83:d=3  hl=2 l=  13 cons: SEQUENCE
       85:d=4  hl=2 l=   9 prim: OBJECT            :rsaEncryption
       96:d=4  hl=2 l=   0 prim: NULL
       98:d=3  hl=3 l= 141 prim: BIT STRING
      242:d=1  hl=2 l=  13 cons: SEQUENCE
      244:d=2  hl=2 l=   9 prim: OBJECT            :sha256WithRSAEncryption
      255:d=2  hl=2 l=   0 prim: NULL
      257:d=1  hl=3 l= 129 prim: BIT STRING

If there isn't yet a Github issue for this, please open one.  It appears
that the code that is actually generating the signature is no longer
encoding explicit NULL parameters for the algorithms in question.

--
    Viktor.
Reply | Threaded
Open this post in threaded view
|

Re: Encoding of AlgorithmIdentifier with NULL parameters

OpenSSL - User mailing list
In reply to this post by Thulasi Goriparthi
Also note that the official ASN.1 declaration for
AlgorithmIdentifier (from X.509 (2012), section 7.2) marks
the parameters field as OPTIONAL, so parsers really should
accept its absence.


However if broken parsers are common (this thread
only found one such parser), maybe it would be
good practice to include the NULL value for compatibility.

AlgorithmIdentifier{ALGORITHM:SupportedAlgorithms} ::= SEQUENCE {
    algorithm ALGORITHM.&id({SupportedAlgorithms}),
    parameters ALGORITHM.&Type({SupportedAlgorithms}{@algorithm}) OPTIONAL,
... }

On 2021-01-28 20:07, Thulasi Goriparthi 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.
Enjoy

Jakob
-- 
Jakob Bohm, CIO, Partner, WiseMo A/S.  https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark.  Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded
Reply | Threaded
Open this post in threaded view
|

Re: Encoding of AlgorithmIdentifier with NULL parameters

Blumenthal, Uri - 0553 - MITLL

“OPTIONAL” means the parser must deal with complete absence, not only encoded as ASN.1 NULL.

 

Broken parsers should be fixed.

--

Regards,

Uri

 

There are two ways to design a system. One is to make is so simple there are obviously no deficiencies.

The other is to make it so complex there are no obvious deficiencies.

                                                                                                                                     -  C. A. R. Hoare

 

 

From: openssl-users-bounce <[hidden email]> on behalf of openssl-users <[hidden email]>
Organization: WiseMo A/S
Reply-To: Jakob Bohm <[hidden email]>
Date: Thursday, January 28, 2021 at 21:10
To: openssl-users <[hidden email]>
Subject: Re: Encoding of AlgorithmIdentifier with NULL parameters

 

Also note that the official ASN.1 declaration for
AlgorithmIdentifier (from X.509 (2012), section 7.2) marks
the parameters field as OPTIONAL, so parsers really should
accept its absence.

However if broken parsers are common (this thread
only found one such parser), maybe it would be
good practice to include the NULL value for compatibility.

AlgorithmIdentifier{ALGORITHM:SupportedAlgorithms} ::= SEQUENCE {
    algorithm ALGORITHM.&id({SupportedAlgorithms}),
    parameters ALGORITHM.&Type({SupportedAlgorithms}{@algorithm}) OPTIONAL,
... }


smime.p7s (7K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Encoding of AlgorithmIdentifier with NULL parameters

OpenSSL - User mailing list
If only one or a few parsers are broken, they need to be fixed.

If many broken parsers have proliferated due to generators
semi-violating DER by not omitting the empty field, that has become the
new reality that generators must deal with.

PKIX arbitrarily limiting serial numbers to 159 bits has created a
similar unfortunate reality.

On 2021-01-29 03:19, Blumenthal, Uri - 0553 - MITLL wrote:

> “OPTIONAL” means the parser _must_ deal with complete absence, not only
> encoded as ASN.1 NULL.
>
> Broken parsers should be fixed.
>
> --
>
> Regards,
>
> Uri
>
> //
>
> /There are two ways to design a system. One is to make is so simple
> there are obviously no deficiencies./
>
> /The other is to make it so complex there are no obvious deficiencies./
>
> /                  
>                                                                                                                     -  C. A. R. Hoare/
>
> *From: *openssl-users-bounce <[hidden email]> on
> behalf of openssl-users <[hidden email]>
> *Organization: *WiseMo A/S
> *Reply-To: *Jakob Bohm <[hidden email]>
> *Date: *Thursday, January 28, 2021 at 21:10
> *To: *openssl-users <[hidden email]>
> *Subject: *Re: Encoding of AlgorithmIdentifier with NULL parameters
>
> Also note that the official ASN.1 declaration for
> AlgorithmIdentifier (from X.509 (2012), section 7.2) marks
> the parameters field as OPTIONAL, so parsers really should
> accept its absence.
>
> However if broken parsers are common (this thread
> only found one such parser), maybe it would be
> good practice to include the NULL value for compatibility.
>
> AlgorithmIdentifier{ALGORITHM:SupportedAlgorithms} ::= SEQUENCE {
>      algorithm ALGORITHM.&id({SupportedAlgorithms}),
>      parameters ALGORITHM.&Type({SupportedAlgorithms}{@algorithm}) OPTIONAL,
> ... }
>



Enjoy

Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S.  https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark.  Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded
Reply | Threaded
Open this post in threaded view
|

Re: Encoding of AlgorithmIdentifier with NULL parameters

tincanteksup
"Reality" ought not be defined this way.

On 29/01/2021 02:38, Jakob Bohm via openssl-users wrote:

> If only one or a few parsers are broken, they need to be fixed.
>
> If many broken parsers have proliferated due to generators
> semi-violating DER by not omitting the empty field, that has become the
> new reality that generators must deal with.
>
> PKIX arbitrarily limiting serial numbers to 159 bits has created a
> similar unfortunate reality.
>
> On 2021-01-29 03:19, Blumenthal, Uri - 0553 - MITLL wrote:
>> “OPTIONAL” means the parser _must_ deal with complete absence, not
>> only encoded as ASN.1 NULL.
>>
>> Broken parsers should be fixed.
>>
>> --
>>
>> Regards,
>>
>> Uri
>>
>> //
>>
>> /There are two ways to design a system. One is to make is so simple
>> there are obviously no deficiencies./
>>
>> /The other is to make it so complex there are no obvious deficiencies./
>>
>> /
>>                                                                                                                     -  
>> C. A. R. Hoare/
>>
>> *From: *openssl-users-bounce <[hidden email]> on
>> behalf of openssl-users <[hidden email]>
>> *Organization: *WiseMo A/S
>> *Reply-To: *Jakob Bohm <[hidden email]>
>> *Date: *Thursday, January 28, 2021 at 21:10
>> *To: *openssl-users <[hidden email]>
>> *Subject: *Re: Encoding of AlgorithmIdentifier with NULL parameters
>>
>> Also note that the official ASN.1 declaration for
>> AlgorithmIdentifier (from X.509 (2012), section 7.2) marks
>> the parameters field as OPTIONAL, so parsers really should
>> accept its absence.
>>
>> However if broken parsers are common (this thread
>> only found one such parser), maybe it would be
>> good practice to include the NULL value for compatibility.
>>
>> AlgorithmIdentifier{ALGORITHM:SupportedAlgorithms} ::= SEQUENCE {
>>      algorithm ALGORITHM.&id({SupportedAlgorithms}),
>>      parameters ALGORITHM.&Type({SupportedAlgorithms}{@algorithm})
>> OPTIONAL,
>> ... }
>>
>
>
>
> Enjoy
>
> Jakob
Reply | Threaded
Open this post in threaded view
|

Re: Encoding of AlgorithmIdentifier with NULL parameters

Richard Levitte - VMS Whacker-2
In reply to this post by Russ Housley
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 <[hidden email]> 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         [hidden email]
OpenSSL Project         http://www.openssl.org/~levitte/