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 protected]
_______________________________________________
IPsec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ipsec
