Subject: Re: [IPsec] Last Call: <draft-kivinen-ipsecme-signature-auth-06.txt> (Signature Authentication in IKEv2) to Proposed Standard

From: Tero Kivinen <[email-masked]>
Date: Tue, 7 Oct 2014 17:24:03 +0300

Johannes Merkle writes:
> thanks for updating the document. However, I'm not sure the first
> issue is solved. 

Sorry this has taken so long, having the IEEE, IETF, Vacation and
RFC5996bis to taken care of before getting back to this draft. 

> Tero Kivinen wrote on 20.07.2014 21:02:
> > Changed to:
> > 
> > 	With RSASSA-PSS, the algorithm object identifier must always
> > 	be id-RSASSA-PSS, and the hash function and padding parameters
> > 	are conveyed in the parameters (which are not optional in this
> > 	case). See <xref target="RFC4055"/> for more information.
> > 
> > In the RSASSA-PSS the parameters are required, but they can be empty,
> > so they are not optional in this case.
> > 
> 
> Really? Section 3.1 of RFC 4055 states
>    When RSASSA-PSS is used in an AlgorithmIdentifier, the parameters
>    MUST employ the RSASSA-PSS-params syntax.  The parameters may be
>    either absent or present when used as subject public key information.
> 
> My understanding of this is that the parameters can indeed be absent
> not just empty.

After reading RFCs 3447, 4055 and 5912, I think that is not true. 

> IMHO the semantic is different: If the parameters are empty (empty
> sequence in RSASSA-PSS-param), the default values apply, and
> according to Section 3.3, case 3, of RFC 4055, the parameters in a
> signature MUST be validated against the (default) parameters
> specified in SPKI. However, if the parameters are absent, then,
> according to Section 3.3, case 2, of RFC 4055, no parameter
> validation is needed in a signature validation, i.e. a signature may
> use any parameters.
> 
> Maybe, I misinterpret the spec here?

RFC 3447 says:

----------------------------------------------------------------------
Appendix C. ASN.1 module
...
-- When id-RSASSA-PSS is used in an AlgorithmIdentifier the
-- parameters MUST be present and MUST be RSASSA-PSS-params.
--
id-RSASSA-PSS    OBJECT IDENTIFIER ::= { pkcs-1 10 }
...
--
-- AlgorithmIdentifier.parameters for id-RSASSA-PSS.
-- Note that the tags in this Sequence are explicit.
--
RSASSA-PSS-params ::= SEQUENCE {
    hashAlgorithm      [0] HashAlgorithm      DEFAULT sha1,
    maskGenAlgorithm   [1] MaskGenAlgorithm   DEFAULT mgf1SHA1,
    saltLength         [2] INTEGER            DEFAULT 20,
    trailerField       [3] TrailerField       DEFAULT trailerFieldBC
}
...
--
-- Identifier for default RSASSA-PSS algorithm identifier
-- The DER Encoding of this is in hexadecimal:
-- (0x)30 0D
--        06 09
--           2A 86 48 86 F7 0D 01 01 0A
--        30 00
-- Notice that the DER encoding of default values is "empty".
----------------------------------------------------------------------

RFC4055 says:
----------------------------------------------------------------------
3.  RSASSA-PSS Signature Algorithm
...
					... CAs that use the RSASSA-PSS
   algorithm for signing certificates or CRLs MUST include RSASSA-PSS-
   params in the signatureAlgorithm parameters in the TBSCertificate or
   TBSCertList structures.
...
3.1.  RSASSA-PSS Public Keys
...
   The parameters MUST be present when used in the algorithm identifier
   associated with a signature value.
----------------------------------------------------------------------

I.e. the next sentence after your quoted section says that for
signatures the parameters MUST be present. They can be absent or
present when talking about subject public key information, but not for
signature. The ASN.1 is not very clear on this as it says only:

----------------------------------------------------------------------
6.  ASN.1 Module
...
      -- When id-RSASSA-PSS is used in an AlgorithmIdentifier, and the
      -- parameters field is present, it MUST be RSASSA-PSS-params.

      id-RSASSA-PSS  OBJECT IDENTIFIER  ::=  { pkcs-1 10 }
...
      -- AlgorithmIdentifier parameters for id-RSASSA-PSS.
      -- Note that the tags in this Sequence are explicit.

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

RFC5912 is more clear about this in ASN.1:
----------------------------------------------------------------------
8.  ASN.1 Module for RFC 4055
   -- =============================
   --    Algorithm Objects
   -- =============================

   --
   -- Public key object for PSS signatures
   --

   pk-rsaSSA-PSS PUBLIC-KEY ::= {
       IDENTIFIER id-RSASSA-PSS
       KEY RSAPublicKey
       PARAMS TYPE RSASSA-PSS-params ARE optional
        -- Private key format not in this module --
       CERT-KEY-USAGE { nonRepudiation, digitalSignature,
                            keyCertSign, cRLSign }
   }

   --
   --  Signature algorithm definition for PSS signatures
   --

   sa-rsaSSA-PSS SIGNATURE-ALGORITHM ::= {
       IDENTIFIER id-RSASSA-PSS
       PARAMS TYPE RSASSA-PSS-params ARE required
       HASHES { mda-sha1 | mda-sha224 | mda-sha256 | mda-sha384
                    | mda-sha512 }
       PUBLIC-KEYS { pk-rsa | pk-rsaSSA-PSS }
       SMIME-CAPS { IDENTIFIED BY id-RSASSA-PSS }
   }
...
   -- When id-RSASSA-PSS is used in an AlgorithmIdentifier, and the
   -- parameters field is present, it MUST be RSASSA-PSS-params.

   id-RSASSA-PSS  OBJECT IDENTIFIER  ::=  { pkcs-1 10 }
...
   -- AlgorithmIdentifier parameters for id-RSASSA-PSS.
   -- Note that the tags in this Sequence are explicit.
   -- Note: The hash algorithm in hashAlgorithm and in
   -- maskGenAlgorithm should be the same.

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

I.e you can clearly see that in the public key object for PSS
signatures the RSASSA-PSS-params are optional, but for the signature
algorithm definition for PSS signatures the RSASSA-PSS-params are
required. The actual content of the sequence can be empty, but the
sequence MUST be there.

So the current text saying that the params are not optional in this
case is correct. The A.4.1 has example of empty parameters, where
there is the id-RSASSA-PSS object identifier and empty sequence after
that. Note, that the hex for that matches the hex in RFC3447...
-- 
[email-masked]

---

From: Johannes Merkle <[email-masked]>
Date: Tue, 7 Oct 2014 17:46:16 +0200

> required. The actual content of the sequence can be empty, but the

I agree with that.

> that. Note, that the hex for that matches the hex in RFC3447...

I was mistaken in thinking that the SubjectPublicKey Identifier is used, but, of course, it is the signatureAlgoithm
Identifier. So I was completely wrong here.
Issue closed.

-- 
Johannes