Re: Using ECC Brainpool curves with ipsec

>>
>> 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.

> 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
> johannes.merkle@...
> www.secunet.com
>
> Scanned by Check Point Total Security Gateway.