PSS parameter encoding undefined in SignatureAlgorithms

[HansBusch]

The specification doesn't say anything about the layout of the SignatureAlgorithms type. The parameter value is defined as Base64 encoded.

The DTT expects the signature algorithm. Not sure where this requirement is stated and how the parameter should be encoded.
From a readability point of view the parameter should be encoded as textual OID. Not sure why the parameter must be base64 encoded.

[HansBusch]

Assigned to Maria, may be she can shed some light on this.

[MariaYa0091]

Hello @HansBusch,

If I understand correctly you are talking about parameters field from here:

For PSS sha-256 etc., are defined through parameters (specifically hashAlgorithm).

It is based on the following:

• https://datatracker.ietf.org/doc/html/rfc4055#section-3.1
• https://datatracker.ietf.org/doc/html/rfc8017#appendix-A.2.3

This is DTT expectations:

DTT decode parameters field as Base64DERencodedASN1Value with standard tools. and then check hashAlgorithm parameter based on PSS specification.

[HansBusch]

Thanks for the explanation. I don't think that it makes sense to provide such detailed information and especially not cryptic base64 encoded.

Either we change the field signature to xs:string and allow a set of IDs or we should drop it completely.

[MariaYa0091]

There could be other parameters (the list is algorithm specific) and for certificate generation this field is transferred as is from capabilities. So it is not a list of possible parameters it is exact parameters to be used for the request. If several hashAlgorithm values supported, there will be several entries.

[HansBusch]

Looks like this feature needs clarification in the specification. As the approach chosen by the DTT is both lengthy and very cryptic I propose to investigate alternatives:

1. Explicitly state in the security specification that PSS OID shall be provided without Parameters.
2. Change Parameter to xs:string and allow clear-text parameters instead of base64 encoding. Require hash function only, ignore MGF, salt length etc.
3. Add property HashAlgorithms pointing to list of IANA defined names and require for PSS single entry supporting all listed hashes.
4. Add attribute HashAlgorithms to AlgorithmIdentifier including IANA defined names.
   For IANA registry see https://www.iana.org/assignments/named-information#hash-alg

Solution 1 is the most simplistic but lacks information.
Solution 2 needs textual clarification and has backward compatibility issues.
Solution 3 and 4 are similar regarding complexity and information. Solution 3 may help in other circumstances.

[AxelKeskikangas]

The parameter field is trying to capture the content from https://datatracker.ietf.org/doc/html/rfc8017#appendix-A.2.3 the parameters are the following:
RSASSA-PSS-params ::= SEQUENCE {
hashAlgorithm [0] HashAlgorithm DEFAULT sha1,
maskGenAlgorithm [1] MaskGenAlgorithm DEFAULT mgf1SHA1,
saltLength [2] INTEGER DEFAULT 20,
trailerField [3] TrailerField DEFAULT trailerFieldBC
}

I don't think 1) works since RSA-PSS can be used with various hash functions, usually matching the key length of the RSA signing algorithm but that is implicitly transmitted.

My guess is that the original specification expected more algorithms to follow the same pattern, but with an unknown parameter set, then BASE64 encoding the ASN1 data is one of the few ways to actually be compatible. Fortunately we have steered clear of this kind of configurability on the algorithm side lately since everyone realized it is a mess.

Options 2 where we only care about the hashAlgorithm I feel somewhat uncertain about, in theory it is still allowed by the standard (and the Onvif spec historically) to change all parameters beyond the hashAlgorithm. I have no idea if anyone in the Onvif ecosystem is actually doing it but thats an other thing (trying to figure out what all corners of Axis is doing here is not too easy...).

For options 3&4, the gain is that we get rid of the BASE64 encode of ASN1 variables making it more humanly readable on the wire/in the call, but any cryptographic library worth its salt should be able to decode the whole thing when received. We also introduce an inconsistency in the spec, if I want to specify both hashAlgorithm & maskGenerationAlgorithm, is it sufficient to include only the maskGenerationAlgorithm in the param structure? or should I double specify hashAlgorithm in both?

tldr: Its ugly but why change away from the RFC spec?

[HansBusch]

Please do not get me wrong: it was not my intention to change the certificates itself. There we definitely need the DER encoded parameters.

I'm solely concerned about obscure capabilities. According to RFC 8017 the salt length should be chosen to match the hash size. What remains are the MGF and the Hash. IANA currently only standardises three variants related to a draft IETF spec. MGF1 exists since PKCS#1 and has never been amended. As the lifetime of RSA is nearing its end changes are very unlikely.

To simplify things I propose to add a note to section 5.8.2 Keystore Capabilities that listing RSASSA-PSS OID without parameters requires support for MGF1 and hashes listed in the security baseline. Additional variants may be signalled using the base64 encoded DER parameter.

[kieran242]

@AxelKeskikangas thank you for your detailed response and @MariaYa0091. @HansBusch this may need further discussion at Prague.

[HansBusch]

For further discussion use PR #837