Hi David,
please see my responses below.
Thanks,
Yaron
On 24.7.2012 23:15, 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. (Thanks to Dan
Brown for offering to help with this analysis.)
Sorry about the sloppy language. I meant the latter: the use of
certificates based on different EC domain parameters.
But I'm certainly not suggesting that we should define the certificate,
or that we should extend the ECDSA algorithm. The scope is very strictly
limited to IKEv2 use of ECDSA certs specified elsewhere.
"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.
I strongly disagree on this point. The is a short-term effort to solve a
problem related to IKEv2. I'm not advocating diverging from TLS on
purpose. But I'm not out to solve a problem for all of the IETF protocols.
- 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.
I'll be happy to see such guidance coming from CFRG. I doubt that we
have the relevant expertise in ipsecme to formulate or review this
"pairing". If we have "enough numbers to go around" we can have all the
useful pairs and there will also be some silly pairs, and it's not
reasonable to try to outlaw the silly ones in advance.
- 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.
I'm not disagreeing but I think that in the context of IKEv2 (and other
protocols), the only thing that touches the protocol is the end-entity
certificate. So we don't care about the rest of the chain.
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.
The existing protocol indicates how to generate the AUTH payload based
on the public key that's provided by the certificate. So it's not about
"processing the signatures in the certs", it's about "using the cert to
sign other stuff".
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
