> -----Original Message-----
> From: TLS [mailto:tls-boun...@ietf.org] On Behalf Of Henrick Hellström
> Sent: Sunday, September 25, 2016 4:35 PM
> To: David Benjamin <david...@chromium.org>; Adam Langley
> <a...@imperialviolet.org>
> Cc: tls@ietf.org
> Subject: Re: [TLS] BoringSSL's TLS test suite
>
> 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:
OPTIONAL and DEFAULT are not the same things. A DEFAULT value is omitted
but not an OPTIONAL value. A single field cannot be both OPTIONAL and
DEFAULT.
Jim
>
> 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
> -- ¶mPresence - 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,
> ¶mPresence 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 ¶mPresence ]
> [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.
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
