>>
>> Hmm... so the EC domain parameters can be seen from the certificate? I
>> wonder why did the RFC4753 then made separate allocations for each EC
>> group?
>
> The particular curve can be determined from the subjectPublicKeyInfo.
> Section 4.1 of RFC 5639 gives the ASN.1 encodings to name the brainpool
> curves.
Actually, this is not strictly correct:
ANSI X9.62 defies three ways to specify the curve (domain parameters) in a
certificate (extracted from RFC 5480):
ECParameters ::= CHOICE {
namedCurve OBJECT IDENTIFIER
implicitCurve NULL
specifiedCurve SpecifiedECDomain
}
implicitCurve means that "the parameters are explicitly defined elsewhere".
So we can safely assume that the parameters are available to a pier receiving
the certificate of the other one.
By the way: While RFC 5480 prohibits the use of implicitCurve and
specifiedCurve, there are certainly still many
implementations of RFC 3279 out there which allowed all three methods.
>
> I'm not so sure it makes sense to define a new hash algorithm per curve
> though. I would suggest just using the negotiated hash function. That is
> going to be used for key derivation and will influence the level of security
> that the exchange affords. That is, if you define SHA-384 to use with
> brainpoolP384r1 but the two sides end up using SHA-1 for key derivation
> then I'm not sure what using SHA-384 for authentication is buying you.
Others have already pointed out that the PRF does not need to be a hash
function. But even if it had to, the
requirements are different. For a digital signature, you need a hash function
to be collision resistant, while for PRF
you need good mixing properties and, in some circumstances, one-wayness. The
requirements for a PRF are much easier to
achieve, e.g. even MD5 is still considered one-way and has good mixing
properties, while collisions have been found.
>
> [snip]
>>
>> I think the way forward is to take this WG and as whether WG would be
>> willing to recharter and add new items to its charter:
>>
>> 1) Add Brainpool curves to the IKEv2 IANA registry (this can also be
>> done as individual draft, and does not need to be WG item, but if
>> we are doing the rest in WG then I think this should also be WG
>> item too).
I am not sure. If the rest is not specific for the Brainpool curves (e.g.
defining a generic ECDSA auth method) it is
not so clear that both efforts should be bundled.
>> 2) Define a way to use Brainpool curves in ECDSA (and perhaps ECGDSA)
>> in the IKEv2. This may require new standard track RFC defining new
>> generic ECDSA method, and might also need solutions how hash
>> function is selected for each group.
According to the policy of the IANA registry for ath methods, standard track is
not required but only IETF consensus,
i.e. an informational WG document would suffice.
> If we're gonna recharter, maybe we should just work on an IKEv3 because
> the problems in IKEv2 are becoming apparent. This "new authentication mode"
> suggestion, or the need for a "generic ECDSA" algorithm are just hacks that
> should not be necessary for a properly defined protocol. In addition, the
I do not agree. The generic definition of the ECDSA auth method is analogous to
the auth methods defined for RSA and DSA
keys, and thus, is rather the proper (canonical) way to define it than a hack.
Of course, the fact than there are already 3 specific auth methods for ECDSA
(which are not canonically defined) makes
specification of a generic ECDSA method more cumbersome.
> issues with the incorrect definition of representation of the result of an
> ECDH (it's the x-coordinate, not the concatenation of the x- and
> y-coordinates) that's lead to interoperability issues, and the inability to
> handle point compression all lead one to the conclusion that this stuff
> should all be fixed once and for all and fixed cleanly.
>
> Dan.
>
>
Johannes
_______________________________________________
IPsec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ipsec
