On Jul 19, 2012, at 1:43 PM, Johannes Merkle wrote: >> >> How about standardizing just one more authentication method? >> >> Call it "public key signature" or some such, and make the signing algorithm >> depend on the public key in the CERT payload. >> >> If it's RSA, go by bit strength: >> - <=1024 - SHA-1 with RSA >> - 1024<x<=2048 - SHA2-256 with RSA >> - 2048<x<=4096 - SHA2-384 with RSA >> - >4096 - SHA2-512 with RSA >> >> DSA - always SHA-1 >> >> ECDSA will be defined by curve. The three NIST curves that everyone uses >> already have hashes associated with them. Any new curve would have to >> specify the signature algorithm in the same document. >> > > Adding new methods giving more flexibility seems a good approach but, > unfortunately, your proposal would not offer the > flexibility you aim at: > > The Subject Public Key Algorithm OID typically used in certs are defined in > RFC 3279 and these do not specify the > signature algorithm. For RSA, the RSAPublicKey OID allows both > RSASSA-PKCS1-v1_5 and RSASSA-PSS (currently, only an > authentication method for the former is specified but the latter is > definitely to be used in the future). For > RSASSA-PSS, more specific public key types are specified in RFC 4055 but use > of the old key identifiers is still > permitted and very common. In case of ECC keys, the identifier id-ecPublicKey > does also not specify the signature > algorithm. > > Thus, unless you want to enforce usage of the id-RSASSA-PSS OID from RFC 4055 > for (future) RSASA-PSS keys and restrict > ECC keys to ECDSA (thus, not allowing the future use any other EC-based > signature algorithm apart from ECDSA), any new > authentication method should at least specify the signature algorithm (e.g. > RSASSA-PKCS1-v1_5, RSASSA-PSS, ECDSA). As > Tero suggested, the specification of the domain parameters and hash function > could possibly be required using the 3 > bytes of reserved data in the authentication payload immediately after the > auth method.
As Tero said, the signature algorithms can be specified in the 3 reserved bytes, but support for such things should be indicated in the Notify payload. Yoav > It appears to me that an enhanced flexibility is also needed for the existing > RSASSA-PKCS1-v1_5 method as soon as other > hash functions than SH-1 are to be used. RFC 5996 is not very convincing in > its description how this can be accomplished: > > --- begin extract --- > Implementations can use the > certificates received from a given peer as a hint for selecting a > mutually understood hash function for the AUTH payload signature. > > Note, however, that the hash algorithm used in the AUTH payload > signature doesn't have to be the same as any hash algorithm(s) > used in the certificate(s). > --- end extract --- > > So implementations are supposed to use the hash algo used by the CA (!) as an > indication on what the peer uses, although > this does not need to be reliable? This seems to me as a lack of proper > specification. > > Johannes > > >> Since the same certificate can be used with both the old authentication >> method and the new, we'd have to signal support in a Notify, and that Notify >> could have bits for indicating support for other signature algorithms such >> as those that go with SHA3. >> >> Wouldn't this make adding future curves and other signature variants easier? >> >> Yoav >> >> > > -- > > Mit freundlichen Grüßen, > Johannes Merkle > -- > Dr. Johannes Merkle > Principal > Biometrie & Hoheitliche Dokumente > secunet Security Networks AG > Mergenthaler Allee 77 > 65760 Eschborn > Germany > Telefon +49 201 54 54-3091 > Telefax +49 201 54 54-1325 > Mobil +49 175 2224439 > [email protected] > www.secunet.com > > Scanned by Check Point Total Security Gateway. _______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
