On Jul 24, 2012, at 1:15 PM, David McGrew (mcgrew) wrote: > 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.
It is the latter, and that's exactly why having the output of a design team would be useful. > "Supports other protocols than IKEv2" is another desirable property. Not for this work, no. Maybe that would be appropriate for CFRG or SAAG, but not the IPsecME WG. > 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. There are already specifications from those WGs. > To > avoid parallel and potentially divergent solutions for other protocols, it > makes sense to consider extensions to ECDSA and its certificate format. Of course. >> - 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). Others might disagree. For example, NIST seems to be of multiple minds when they are choosing strengths. > 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. One thing that the design team needs to consider is the amount of flexibility. Note that the proposal says "allows flexibility", not "forces maximal flexibility". >> - 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. Good suggestion, yes. >> 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. If you have other concrete proposals, that would be grand. There has been enough disagreement in the thread this last week where it is likely that there are multiple ways to do things. --Paul Hoffman _______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
