Time by time I receive questions about alternate signature algorithms. What is the difference between them and what benefits are in an alternate signature algorithms.

As per TechNet article:

For certificates based on RSA algorithms, PKCS #1 v2.1 specifies separate object identifiers for the hash algorithm and for the asymmetric algorithm. (In PKCS #1 v.1.5, only one object identifier is used to identify both the hash and asymmetric algorithms.) In addition, if you select the alternate signature format for certificates based on RSA algorithms, an enhanced cryptographic formula is used to create the signature.

Generally speaking, alternate signature algorithm (signature format) just allows to specify additional details about how signature is constructed.

PKCS#1 v1.5

Here is a classic algorithm identifier structure for PKCS#1 v1.5:

RSAES-AlgorithmIdentifier ::= AlgorithmIdentifier { {PKCS1Algorithms} }

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

Algorithm parameters are set to NULL, so signature actually looks as follows:

Here we see a sequence that is followed by an algorithm identifier (sha1RSA) and optional parameters are set to null.

PKCS#1 v2.1

With alternate signature algorithm, the structure become a bit more complicated:

OAEP-PSSDigestAlgorithms    ALGORITHM-IDENTIFIER ::= {
    { OID id-sha1       PARAMETERS NULL }|
    { OID id-sha224     PARAMETERS NULL }|
    { OID id-sha256     PARAMETERS NULL }|
    { OID id-sha384     PARAMETERS NULL }|
    { OID id-sha512     PARAMETERS NULL }|
    { OID id-sha512-224 PARAMETERS NULL }|
    { OID id-sha512-256 PARAMETERS NULL },
    ...  -- Allows for future expansion --
}

HashAlgorithm ::= AlgorithmIdentifier { {OAEP-PSSDigestAlgorithms} }
-- example hash algorithm for sha1:
-- HashAlgorithm ::= {
--     algorithm   id-sha1, 
--     parameters  SHA1Parameters : NULL
-- }

PKCS1MGFAlgorithms    ALGORITHM-IDENTIFIER ::= {
    { OID id-mgf1 PARAMETERS HashAlgorithm }, 
    ...  -- Allows for future expansion --
}

MaskGenAlgorithm ::= AlgorithmIdentifier { {PKCS1MGFAlgorithms} }


id-RSASSA-PSS    OBJECT IDENTIFIER ::= { pkcs-1 10 } -- 1.2.840.113549.1.1.10

RSAES-AlgorithmIdentifier ::= AlgorithmIdentifier { {PKCS1Algorithms} }

RSASSA-PSS-params ::= SEQUENCE {
    hashAlgorithm      [0] HashAlgorithm      DEFAULT sha1, 
    maskGenAlgorithm   [1] MaskGenAlgorithm   DEFAULT mgf1SHA1, 
    saltLength         [2] INTEGER            DEFAULT 20,
    trailerField       [3] TrailerField       DEFAULT trailerFieldBC
}

TrailerField ::= INTEGER { trailerFieldBC(1) }

rSASSA-PSS-Default-Identifier    RSASSA-AlgorithmIdentifier ::= {
    algorithm   id-RSASSA-PSS, 
    parameters  RSASSA-PSS-params : {
        hashAlgorithm       sha1, 
        maskGenAlgorithm    mgf1SHA1, 
        saltLength          20,
        trailerField        trailerFieldBC
    }
}
RSASSA-AlgorithmIdentifier ::= AlgorithmIdentifier { {PKCS1Algorithms} }

I just pointed the most notable parts of the ASN module which are necessary to construct alternate signature algorithm. You can see that RSASSA-AlgorithmIdentifier structure consist of:

• algorithm, which is id-RSASSA-PSS (1.2.840.113549.1.1.10) and it’s algorithm parameters:
• maskGenAlgorithm which is mgf1XXX, where XXX is hashing algorithm identifier.
• saltLength which is 32 bytes by default.
• trailerField which is a number and is used for compatibility purposes and is set to one (1).

In the ASN viewer we can see something like this:

I just labeled ASN.1 viewer nodes with a corresponding objects in the ASN module. In a given example, RSASSA-PSA algorithm uses sha256 hashing algorithm. TrailerField is absent, because it is implicitly set to 1 (other values are not defined in the current profile).

To be or not to be?

While all this is very interesting and entertaining, main question is: should I use PKCS#1 v2.1 signature formats and when? The answer is…there is no definite answer. Normally, I would suggest to avoid alternate signature format usage until it is required by a particular product even though it is very flexible. Most applications do not utilize these features and just propagate v1.5 signature to a v2.1 format and you don’t get any benefits from here. Common v1.5 standard is widely supported and there is no any security risk with it unless you are not using weak algorithms (lower than SHA1).

HTH