>
> Few questions (I do not know enough about FIPS 186-3 or SP 800-57 etc
> to know the answer myself).
>
> When we have DSS signature in FIPS 186-3 format, I have understood
> that there is no indication about whether the signature is ECDSA or
> normal DSA, or what is the domain parameters for the ECDSA, and what
> is the hash function used when generating the signature.
>
> I.e. the signature just consist of some raw bits, and there is no
> other information around it and all that other information must be
> carried to the verifier over some other medium?
>
> Is this correct?
Yes, in both cases (DSA, ECDSA) the signature consists of two integers. RFC
3279 defines:
Dss-Sig-Value ::= SEQUENCE {
r INTEGER,
s INTEGER }
Ecdsa-Sig-Value ::= SEQUENCE {
r INTEGER,
s INTEGER }
And the bit length is typically comparable.
>
> If that is correct how does the PKIX solve this? I.e. when I have
> certificate signed by the some other certificate using DSA? If my
> reading of RFC5280 is correct there is this signatureAlgorithm ASN.1
> blob in front of the signature itself and that gives all that
> information (including the domain parameters and hash functions etc).
>
> Is my understanding correct?
>
Almost. The signature scheme and hash are specified in the signatureAlgorithm
identifier, e.g. id-dsa-with-sha256 and
ecdsa-with-SHA256. The parameters (DSA parameters and ECC domain parameters)
are stored in subjectPublicKey. But this is
specified in the certificate.
Note: for DSA is is admissible (according to RFC 3279) to omit the patrameters
and then the parameters of the CA key
apply, which are specified in the CA certificate. So it an be necessary to
parse the CA certificate as well to obtain
them.
> If so then I think we should use similar method in the IKEv2 too, and
> fix both ECDSA and normal DSA at the same time, i.e. create one new
> authentication method where the actual signature format that contains
> both the signatureAlgorithm and signatureValue (4.1.1.2 and 4.1.1.3
> from the RFC5280).
>
> This will fix the problem for all DSA methods (EC or normal) and
> allows using any hash function allowed by signers policy. It also
> allows responder to immediately know the domain parameters and hash
> function even when certificate of the public key was not delivered
> inband of the IKEv2.
>
That would work but would expand the auth payload by more than two or three
bytes. For instance the OID
ecdsa-with-SHA256 is 1.2.840.10045.4.3.2.
While this is still limited, for the new RSA-PSS scheme (see my response
regarding RSA below)
> If we define one new authentication method then we can also deprecate
> old DSA methods (DSS Digital Signature - 3, ECDSA with * on the P-*
> curve - 9-11), and recommend that new implementations will use this
> new method. Or we can still say that for SHA-1 DSS and SHA-2 with
> those curves still use the old methods.
>
Deprecation is the cleaner method but I fear that existing implementation will
not quickly adpat to the new rule, so
still allowing the old methods is more safe.
> This same method could also be used for RSA, but as this problem of
> not knowing hash-function / parameters do not exists in RSA there is
> no point of changing the current RSA method.
>
This may change. Since 2005, PKIX supports through RFC 4055 the signature
scheme RSASA-PSS which provides provable
security (in a certain mathematical model) and is generally considered the
better padding method as compared to the old
padding PKCS#1v1.5.
However, in RSASA-PSS, the encoding of the PKIX signature algorithm identifier
may be quite large as it has several
parameters:
RSASSA-PSS-params ::= SEQUENCE {
hashAlgorithm [0] HashAlgorithm DEFAULT sha1,
maskGenAlgorithm [1] MaskGenAlgorithm DEFAULT mgf1SHA1,
saltLength [2] INTEGER DEFAULT 20,
trailerField [3] TrailerField DEFAULT trailerFieldBC
}
--
Johannes
_______________________________________________
IPsec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ipsec
