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
-- ¶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
[email protected]
https://www.ietf.org/mailman/listinfo/tls
