[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: IKEV2: Issue #4 Revised Identity
At 11:07 PM -0800 2/10/03, Eric Rescorla wrote:
>In IKEv1 the authenticating party tells the client what its identity is
>and then the verifying party compares the ID payload to the
>certificate.
That is one interpretation; there are many others. As others have
said before on this thread, anyone who has gone to the bakeoffs knows
this.
> In your scheme the verifying party has to
>guess based on the certificate, which is a potential problem
>if the cert has ambiguous identity information.
There is no such thing as a certificate with ambiguous identifying
information. You inherently trust the certificate issuer to give the
right information.
> > But this is not what the WG chairs have proposed. There is no proposal
>> for clarifying the semantics in IKEv2 on the table. We are left with
>> the same nothing as in IKEv1. Why would an implementer go to IKEv2 if
>> the major user problems with IKEv1 are left the same?
>As far as I can tell, it is what they've proposed. Quoting from
>Ted's message:
>
> The choice between the working group, then is between using
> language taken from pki-profile-01 to make explicit when
> certificate payloads are sent, or choosing the
> revised-identity proposal. More comments about the tradeoffs
> inherent between these two choices are hereby requested.
So, let's ask the WG chairs then: is Eric's interpretation correct?
Is this also a WG last call on pki-profile-01? If not, then IKEv2
will be plagued with the same interop problems that IKEv1 has. If it
is a last call, the WG should be discussing the document, which has
gotten no traffic to date.
--Paul Hoffman, Director
--VPN Consortium