Hi Yaron, On 7/24/12 12:08 PM, "Yaron Sheffer" <[email protected]> wrote:
>Hi, >recent discussion on the list has indicated that there is some interest >in better supporting ECDSA certificates in IKEv2, and that the existing >solutions are not very extensible. The discussion was very useful in >outlining the existing issues and pointing to some possible ways forward. > >Paul and I would like to propose setting up a design team with the goal >of proposing a long-term solution to this problem. Some of the >attributes of a reasonable solution include: > >- Supports currently used and proposed ECDSA certificates. Has there been a formal proposal for new ECDSA certificates? Or do you mean the informal idea of using different elliptic curve parameters inside ECDSA? The latter suggestion is something that needs to be reviewed, and if it goes forward, would need to be well specified. (Thanks to Dan Brown for offering to help with this analysis.) "Supports other protocols than IKEv2" is another desirable property. If there is interest in ECDSA with other curves in IKEv2, then it is likely that there will be interest in other protocols such as TLS and SMIME. To avoid parallel and potentially divergent solutions for other protocols, it makes sense to consider extensions to ECDSA and its certificate format. >- Allows flexibility in defining EC domain parameters. >- Allows flexibility in associating hash functions with EC groups. I do not think that flexibility in hash/curve pairs is desirable (though it might be acceptable if there is well written guidance on which pairs to use). If the number of signature parameters is significantly larger than 256, as suggested below, then there are enough numbers to go around that we can assign every hash/curve pair that we care about its own number. >- Is not limited to 256 values >- ECDH is out of scope. >- Non-certificate authentication using raw public keys is out of scope, >unless it is trivially supported by the proposal. Another requirement: the solution should work with certificate chains, without requiring that all certificates in the chain have the exact same signature algorithm and parameters. > >The solution should be an extension to IKEv2, Why should this be a requirement? It is something of a layer violation to require the protocol to provide the information about how to process the signatures in the certificates that it carries. >and should not break the >protocol. Some of the ideas in >http://www.ietf.org/mail-archive/web/ipsec/current/msg07828.html can be >used as a starting point. > >Please respond to us privately or to the list, indicating if you would >like to participate in the design team, or if you only support the >effort and would be willing to review the ensuing I-D. I would like to participate. David > >Thanks, > Yaron > >_______________________________________________ >IPsec mailing list >[email protected] >https://www.ietf.org/mailman/listinfo/ipsec _______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
