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

Re: Certificate Requesting

At 11:14 PM 2/24/98 -0500, Theodore Y. Ts'o wrote:

>

>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.


This might be the 'best' way.  See below.


>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.


Consider the discussion we had last week in Boston with the CA vendors. 
Those on this list that were there, help me along, please.


There are two 'standard' IKE exchanges:


Trade DNs and then each looks up a cert for that DN from its CA (or local
cache) and uses that cert in the exchange.


<paraindent><param>left</param>This might have some interesting spoof/DOS
attacks if a system gives a DN that it knows the other side knows about
but it does not have the private key for?

</paraindent>

Trade full cert chains.  This will probably be more than 1400 bytes,
particularly for longish cert chains.


The challenge here is if the two systems have multiple certs and trust
multiple roots with some overlap, or live in a cross-certified PKI that
has a 'trusted third party' root.


After the exchange, one or both systems might not have established
authentication, becuase either the wrong cert and chain was sent, or the
cert chain ended at the root, and did not proceed along the cross-cert
link to the trusted third party root.  Thus there is a need to issue a
cert-req and tell the other party, 'give me a cert plus chain that goes
back to one of these DNs' (either a list of trusted roots, or your CA's
root plus the TTP's root).


When to do this is the question.  given performance issues, it might
almost be 'smart' to first do a DN exchange and if you don't have the
cert cached give a cert-req, or some such.


better minds than mine might see a clearer way through this fog of
operational implementations....




Robert Moskowitz

ICSA

Security Interest EMail: rgm-sec@htt-consult.com
Follow-Ups: References: