Dan Harkins writes: > Well FIPS 186-3 specifically refers to SP 800-57 for "information about > the selection of the appropriate (L,N) pair in accordance with a desired > security strength for a given time period for the generation of digital > signatures." And SP 800-57 says that, for example, to produce a > signature valid "beyond 2030" it requires a minimum of 128 bits of > strength (table 4) and that when performing digital signatures of 128 > bits of security the valid hash functions are SHA-256, SHA-384, and > SHA-512. You want to restrict such signatures to SHA-256 so it's > not really meeting the requirements of FIPS 186-3.
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? 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? 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. 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. 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 would also make it so that we could use any public key method the PKIX decideds to define in the future without any changes to the IKEv2 document. > If only this protocol was designed better.... True, we can only blame ourselves. This same problem was already there for IKEv1, but nobody noticed that we should fix this when we were defining IKEv2. -- [email protected] _______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
