Subject: Re: [Cfrg] Hash substitution in PSS

From: Peter Gutmann <[email-masked]>
Date: Tue, 30 Apr 2013 16:43:50 +0000

Dan Brown <[email-masked]> writes:

>[DB] RFC 5756 says "When the id-RSASSA-PSS object identifier
>   appears in the TBSCertificate subjectPublicKeyInfo algorithm field of
>   EE certificates, then the parameters field MAY include the RSASSA-
>   PSS-params structure."
>
>RFC 4055 says "RSASSA-PSS-params  ::=  SEQUENCE  {
>         hashAlgorithm      [0] HashAlgorithm DEFAULT
>                                   sha1Identifier,
>         maskGenAlgorithm   [1] MaskGenAlgorithm DEFAULT
>                                   mgf1SHA1Identifier,
>         saltLength         [2] INTEGER DEFAULT 20,
>         trailerField       [3] INTEGER DEFAULT 1  }"

I think the problem is with RFC 4055, it should have either made the entire
sequence optional if all-defaults are used or otherwise constrained it so that
at least one element must be present (making it non-optional).  At the moment
the sequence (via its ASN.1 definition) is non-optional but every parameter is
optional.  OTOH the text then makes it optional, except when it's not.  It's a
bit of a mess (uh, sorry Jim :-), I can see implementers arguing over whose
interpretation is correct...

Peter.

---

From: Russ Housley <[email-masked]>
Date: Tue, 30 Apr 2013 13:11:40 -0400

> interpretation is correct...

This is aligned with PKCS#1.  Yes, it would be ideal for the whole thing to be NULL if all of the values are DEFAULT, but that is not the way PKCS#1 did it.

Russ

---

From: Dan Brown <[email-masked]>
Date: Tue, 30 Apr 2013 17:38:58 +0000

This part of the thread has diverged from crypto.  It should probably go on the PKIX mailing list instead.  It mainly concerns interpreting ASN.1, not whether particular actions have security benefits.  For now, I respond below, just trying to establish what PKIX says about PSS hash algorithm identification in certificates (and then CFRG can discuss its merits).

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Peter Gutmann
> optional.  OTOH the text then makes it optional, except when it's not.
> It's a bit of a mess (uh, sorry Jim :-), I can see implementers arguing over
> whose interpretation is correct...
> 
[DB] RFC 3280 says "   An algorithm identifier is defined by the following ASN.1 structure:

   AlgorithmIdentifier  ::=  SEQUENCE  {
        algorithm               OBJECT IDENTIFIER,
        parameters              ANY DEFINED BY algorithm OPTIONAL  }"

and "   SubjectPublicKeyInfo  ::=  SEQUENCE  {
        algorithm            AlgorithmIdentifier,
        subjectPublicKey     BIT STRING  }"

so, the optionality of the parameters for the algorithm associated with a key inside a cert is also present in the ASN.1 definition, not just the text.  The text in 5756 simply says that parameters remain optional.

DEFAULT does not mean OPTIONAL in meaning, only in encoding.  So, when RSASSA-PSS-params is included in AlgorithmIdentifier and BER or DER encoded as a sequence of no elements, then the abstract value should be taken as the default values.  In fact, if I understand ASN.1 correctly, DER requires omission of DEFAULT elements (when the abstract value has the default elements).  Yes, it does seem weird, changes in tag and length octets only could have a such drastic change in value (this might be argument for avoiding DEFAULT ...).

RFC 4055 says "   3.  The key is identified by the id-RSASSA-PSS signature algorithm
       identifier and the parameters are present.  In this case all
       parameters in the signature structure algorithm identifier MUST
       match the parameters in the key structure algorithm identifier
       except the saltLength field.  The saltLength field in the
       signature parameters MUST be greater or equal to that in the key
       parameters field."

This requires checking consistency between the RSA-PSS cert and the RSA-PSS signature (independently of whether DEFAULT elements are encoded or not.)

I do not see much of a problem in this at all (let alone a preclusion of hash-checking).  Yes, it is still optional both in the text and the ASN.1.  

Perhaps things could be a little clearer:  The relevant portions of other RFCs could have been quoted, so that the final RFC contained all necessary ASN.1 to be able to parse things.  The ASN.1 field optionality may not be a clear enough mechanism for optionality of certain algorithm steps (like item 3 above from RFC 4055), maybe an additional flag ASN.1 field like requireParameterChecking could have inserted somewhere.

I agree that implementers could argue over this, especially if they miss out parts of the specifications (which is easy to do, and thus the clarifications I suggested), or they have already deployed this, or they don't see the need, etc.

---------------------------------------------------------------------
This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful.

---

From: Russ Housley <[email-masked]>
Date: Tue, 30 Apr 2013 14:06:16 -0400

>> This is aligned with PKCS#1.  Yes, it would be ideal for the whole
>> thing to be NULL if all of the values are DEFAULT, but that is not the
>> way PKCS#1 did it.
>> 
> [DB] Why would that be ideal?  NULL parameters usually mean the equivalent of absent parameters, not DEFAULT parameters.
> 
> This does raise an orthogonal issue: what about historial implementations that do not support OPTIONAL parameters (in AlgorithmIdentifier).  (((Chances are such an implementation would also not support DEFAULT parameters?))).  Some RFCs specify that NULL-valued parameters have the same meaning as absent parameters.   To address such implementations, RFC 4055 could be modified to take the same approach, with an erratum.  (Also, NULL-value parameter do not count as present for the purposes of the actions to be taken, etc.)
> 
> But maybe 4055 does not need to grandfather to such implementations, since it is all about some kind of newfangled RSA-PSS that grandpa never heard of and would never bother with anyway, being happy with good old PKCS#1v1.5.

I did not intend to pick the scab off the absent vs NULL discussion.  My point was that a shorthand for four default values would have been desirable, but it is way too late.

Russ

---

From: "Manger, James H" <[email-masked]>
Date: Wed, 1 May 2013 10:44:31 +1000

> I did not intend to pick the scab off the absent vs NULL discussion.
> My point was that a shorthand for four default values would have been
> desirable, but it is way too late.

Surely a shorthand for RSASSA-PSS-params that use the 4 default values is precisely what the use of DEFAULT in its ASN.1 definition provides.

The DER-encoding of RSSASA-PSS-params that use SHA-1, MGF1 with SHA-1, a 20-byte salt, and the 0xBC trailer byte is:

  30 00

Those 2 bytes are just as short as the DER-encoding of NULL (05 00).

--
James Manger