Re: [TLS] BoringSSL's TLS test suite

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

On 2016-09-25 23:55, David Benjamin wrote:
> I believe we are also correct per spec. My interpretation of these
> documents is that the general AlgorithmIdentifier structure may or may
> not include parameters. However, whether a given parameter value or
> omitting parameters altogether is legal is a question for the particular
> algorithm. It's not overriding but plugging into the general framework.

THe ITU-T X.690 standard for DER might require some close reading to 
interpret, and this is obviously a topic for debate. I would presume 
that the use of "default" in lower caps in section 11.5, refers to both 
the DEFAULT and the OPTIONAL keyword:

   11.5	Set and sequence components with default value
   The encoding of a set value or sequence value shall not include an
   encoding for any component value which is equal to its default value.

After all, this is the only interpretation that is consistent with the 
description in section 12.5 of DER as unambiguous.

Since NULL is always empty, it should be omitted when OPTIONAL, given 
the above interpretation. But is it optional? The 1988 syntax did not 
feature information objects and classes, hence the use of the ANY keyword.

Luckily the ASN.1 modules were updated in RFC 5912 to modern ASN.1 
syntax. There you have these declarations:

--  SIGNATURE-ALGORITHM
--
--  Describes the basic properties of a signature algorithm
--
--  &id - contains the OID identifying the signature algorithm
--  &Value - contains a type definition for the value structure of
--              the signature; if absent, implies that no ASN.1
--              encoding is performed on the value
--  &Params - if present, contains the type for the algorithm
--               parameters; if absent, implies no parameters
--  &paramPresence - parameter presence requirement
--  &HashSet - The set of hash algorithms used with this
--                  signature algorithm
--  &PublicKeySet - the set of public key algorithms for this
--                  signature algorithm
--  &smimeCaps - contains the object describing how the S/MIME
--              capabilities are presented.
--
--  Example:
--  sig-RSA-PSS SIGNATURE-ALGORITHM ::= {
--     IDENTIFIER id-RSASSA-PSS
--     PARAMS TYPE RSASSA-PSS-params ARE required
--     HASHES { mda-sha1 | mda-md5, ... }
--     PUBLIC-KEYS { pk-rsa | pk-rsa-pss }
-- }


SIGNATURE-ALGORITHM ::= CLASS {
     &id             OBJECT IDENTIFIER UNIQUE,
     &Value          OPTIONAL,
     &Params         OPTIONAL,
     &paramPresence  ParamOptions DEFAULT absent,
     &HashSet        DIGEST-ALGORITHM OPTIONAL,
     &PublicKeySet   PUBLIC-KEY OPTIONAL,
     &smimeCaps      SMIME-CAPS OPTIONAL
} WITH SYNTAX {
     IDENTIFIER &id
     [VALUE &Value]
     [PARAMS [TYPE &Params] ARE &paramPresence ]
     [HASHES &HashSet]
     [PUBLIC-KEYS &PublicKeySet]

AlgorithmIdentifier{ALGORITHM-TYPE, ALGORITHM-TYPE:AlgorithmSet} ::=
         SEQUENCE {
             algorithm   ALGORITHM-TYPE.&id({AlgorithmSet}),
             parameters  ALGORITHM-TYPE.
                    &Params({AlgorithmSet}{@algorithm}) OPTIONAL
         }

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

Hence, the correct encoding is for NULL to be absent.