Subject: [pkix] specifying signature parameters in draft-ietf-pkix-ocspagility-08

From: "David A. Cooper" <[email-masked]>
Date: Tue, 15 Jun 2010 11:39:51 -0400

Stefan, Phillip,

I am working on incorporating draft-ietf-pkix-ocspagility-08 into the 
update to RFC 2560 and I have a question about the following sentence in 
the section describing the new preferred signature algorithm extension:

    sigIdentifier specifies the signature algorithm the client prefers,
    e.g. algorithm=ecdsa-with-sha256. Parameters are absent for most
    common signature algorithms.

This seems appropriate in the case of DSA, ECDSA, and GOST, since the 
parameters field is absent for all of these signature algorithms.

What about RSA PKCS #1 v1.5, where parameters field in a signature must 
be present with the value NULL.  Is the parameters field supposed to be 
absent in the case of RSA PKCS #1 v1.5?

What about RSASSA-PSS, where the signature algorithm OID is just 
id-RSASSA-PSS and the parameters field contains

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

Dave

P.S.  It appears to me that the ASN.1 module in Appendix A.1 requires 
the parameters field to be present for both RSA PKCS #1 v1.5 and 
RSASSA-PSS, based on the definitions of the signature algorithms in RFC 
5912.  Could someone let me know if I am interpreting the new ASN.1 
modules correctly?

---

From: Sean Turner <[email-masked]>
Date: Wed, 16 Jun 2010 10:43:30 -0400

> 5912.  Could someone let me know if I am interpreting the new ASN.1 

You are reading them correctly.

spt

---

From: "David A. Cooper" <[email-masked]>
Date: Wed, 16 Jun 2010 11:53:24 -0400

Thanks Sean.  So, if the ASN.1 for sigIdentifier then the requirements
for the parameters field are the same as for a signature, and
parameters must be present for RSA.

Taking another look at the ASN.1, I believe that the ASN.1 for
certIdentifier is incorrect;

certIdentifier specifies the subject public key algorithm identifier

the client prefers in the server's certificate used to validate the

OCSP response. e.g. algorithm=id-ecPublicKey and parameters=

secp256r1.

PreferredSignatureAlgorithm ::= SEQUENCE {

sigIdentifier  AlgorithmIdentifier{SIGNATURE-ALGORITHM, {...}},

certIdentifier AlgorithmIdentifier{SIGNATURE-ALGORITHM, {...}}

OPTIONAL  }

I would guess that PreferredSignatureAlgorithm should be defined as:

PreferredSignatureAlgorithm ::= SEQUENCE {

sigIdentifier  AlgorithmIdentifier{SIGNATURE-ALGORITHM, {...}},

certIdentifier AlgorithmIdentifier{PUBLIC-KEY, {...}}

OPTIONAL  }

with PUBLIC-KEY also being imported from AlgorithmInformation-2009.

There is also a typo in the definition of the extension syntax:

re-preferred-signature-algorithms EXTENSION ::= {

SYNTAX PreferredSignatureAlgorithm

IDENTIFIED BY id-pkix-ocsp-pref-sig-algs  }

It should be "SYNTAX PreferredSignatureAlgorithms"

Dave

On 06/16/2010 10:43 AM, Sean Turner wrote:

David A. Cooper wrote:

Stefan, Phillip,

Dave

spt
.

---

From: Sean Turner <[email-masked]>
Date: Wed, 16 Jun 2010 12:22:16 -0400

David A. Cooper wrote:
> for the parameters field are the same as for a signature, and parameters 
> must be present for RSA.
> 
> It should be "SYNTAX PreferredSignatureAlgorithm*_s_*"

I believe you are correct on all counts.

spt

---

From: "Jim Schaad" <[email-masked]>
Date: Fri, 18 Jun 2010 10:32:09 -0600

I am not sure that I agree this is the correct thing to be doing, or perhaps
just that I think that the field is defined incorrectly.

I believe that what should be appearing at that location is the parameters
as defined by the SMimeCapabilities field rather than as defined by the
actual signature.  This is how I would have programmed it up myself.  In
this case the parameters would have been absent for RSA-PSS.

Where the issue would be more problematic to use actual parameter rather
than the S/MIME caps is when you introduce things which are somewhat odd.
However using SMimeCaps also has an issue that would need to be looked at.

Consider asking for two signature algorithms, RSA-PSS w/ SHA-256 and RSA-PSS
w/ MD5-XOR.  If full parameters are required, then one ends up specifying
two different PreferredSignatureAlgorithm fields.  And one ends up
specifiying a number of values in the parameters that need to be ignored(?)
by the responder.

The saltLength would be set by the signer independent of the requested
algorithm.
The two different places where the hash algorithm would be present
(hashAlgorithm and maskGenAlgorithm for mgf1) would have parameters fields
that would be ignored by the signer and generated anew - or would be
incorrectly omitted by the requester.

On the other hand, if one uses SMIMECaps as currently defined, then the hash
algorithm cannot be specified.  For other locations where a sequence of
SMimeCaps are used the hash algorithms supported can be inferred by
specifying the signature algorithm RSA-PSS and then the two hash algorithms
SHA-256 and MD5-XOR in the single caps sequence.

jim

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Sean Turner
> Sent: Wednesday, June 16, 2010 10:22 AM
> To: David A. Cooper
> Cc: Stefan Santesson; Phillip Hallam-Baker; [email-masked]
> Subject: Re: [pkix] specifying signature parameters in draft-ietf-pkix-
> ocspagility-08
> 
> David A. Cooper wrote:
> _______________________________________________
> pkix mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/pkix