Hi Yaron I would like to participate.
A few comments on the proposed "charter": - Flexibility in associating hash functions should not a unlimited. There is no reason to allow a 521-bit EC group with MD4 as the hash function, or even with SHA2-256 as the hash function. I'm perfectly happy to limit that curve to SHA2-512 and SHA3-512. - I don't think "ECDSA" as opposed to "ECGDSA" or "DSA" or "RSA" should be an authentication method. It seems much more intuitive to me to expand that to "certificate authentication" or "public key signatures". The user gets a certificate by some method, installs it on their IKE endpoint, and then proceeds to use it. The public key in the certificate is suitable for verifying one or more kinds of signature, so it does influence the content of the AUTH payloads, but whatever kind of certificate you use, the method IMO should be the same. Since we're taking the public key from a SPKI structure in a certificate anyway (or from Tero's OOB draft that uses the same SPKI structure), the type of signature possible is already determined. Or if there is more than one possibility (as in ECDSA and ECGDSA) this can be signaled in the same way as the hash algorithm. Yoav On Jul 24, 2012, at 7:08 PM, Yaron Sheffer 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. > - Allows flexibility in defining EC domain parameters. > - Allows flexibility in associating hash functions with EC groups. > - 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. > > The solution should be an extension to IKEv2, 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. > > Thanks, > Yaron _______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
