[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Certificate Requesting

Well, here's the problem.  The identity payload (and the optional
certificate) don't get sent until the very end of the IKE exchanges.  So
unless there is some other "out of band" way (*) for the implementation
to know what the identity of its communication partner, by the time it
receives the identity payload and discovers that a certificate hadn't
been sent, it's too late for the implementation to do anything than
abort the entire IKE exchange and try again, this time with a CERT-REQ
earlier in the protocol.

(*) Deductions based on the (unsecure) IP address of communications
partner, looking at the previous failed IKE exchanges, psychic
abilities, etc.

Alternatively, you could always send a CERT-REQ payload, even before you
discover whether or not you really needed the payload, but that doesn't
seem awfully clean either.  I believe this is what was driving the
implementations to do the CERT-REQ that late in the game.

So the question is, what do we do?  Doug very nicely outlined our
possible choices of how to make the specification unambiguous.  There
are tradeoffs with either choice; implementation complexity, versus
problems in knowing whether or not you need to put a CERT-REQ earlier in
the exchange.  However we decide, either alternative is better than not
making a decision at all, so we need to settle this issue and then move
on.


							- Ted
Follow-Ups: References: