Re: [TLS] BoringSSL's TLS test suite

[Henrick Hellström <[e-mail]>]

On 2016-09-26 01:29, Jim Schaad wrote:
> The ASN.1 module in RFC 5280 does not say anything about if the field is
> optional for any specific algorithm.  The ASN.1 for algorithm identifier is
>
> AlgorithmIdentifier  ::=  SEQUENCE  {
>         algorithm               OBJECT IDENTIFIER,
>         parameters              ANY DEFINED BY algorithm OPTIONAL
>
> This very explicitly says that the value (and hence presence) of the
> parameters fields is strictly defined by the algorithm identifier.  The
> algorithm identifiers for RSA with the SHA2 algorithms explicitly say they
> are required.
>
>
> RFC 5912 shows that this is required with the way it defines the same
> information
>
>   sa-sha256WithRSAEncryption SIGNATURE-ALGORITHM ::= {
>        IDENTIFIER sha256WithRSAEncryption
>        PARAMS TYPE NULL ARE required
>        HASHES { mda-sha256 }
>        PUBLIC-KEYS { pk-rsa }
>        SMIME-CAPS { IDENTIFIED BY sha256WithRSAEncryption }
>    }
>
> You can see that the parameters are required and not optional.

Thanks, you are absolutely correct about this, and this crucial for 
getting PKCS #1 v1.5 signatures right (since the algorithm identifier 
encoding is part of the data to be signed), but at the same time, NULL 
should be absent from the RSA public key:

    pk-rsa PUBLIC-KEY ::= {
     IDENTIFIER rsaEncryption
     KEY RSAPublicKey
     PARAMS TYPE NULL ARE absent
     -- Private key format not in this module --
     CERT-KEY-USAGE {digitalSignature, nonRepudiation,
     keyEncipherment, dataEncipherment, keyCertSign, cRLSign}
    }

and this is definitely not common practice.