[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Latest ipsec-pki-req-04.txt
At 06:28 AM 12/16/99 +0200, Tero Kivinen wrote:
The pictures in the IKE documents are ONLY EXAMPLES.
They are? I didn't see anywhere in the document that says that or even
hints that. Sorry if I'm being dense, but maybe this should be clearer in
the new RFC.
> >6.3 Content of Certificate payloads
> >"If a responding device is not offering a certificate that will chain to
> >the certificate authority named in the Certificate Request payload, the
> >Certificate payload offered in response to a Certificate Request
> >payload MUST specify a certificate encoding of type NONE."
> >
> >This is completely new behavior. And not very flexible.
>
> Disagree. Agree.
I haven't seen that kind of description before. Is somebody really
doing that?
I have been told that by at least one shipping vendor; there may be others.
Usually the device has only 1 or 2 certificates for itself.
I don't think that's necessarily true. One example is that a remote access
user might have many more than that. But even gateways might have ten or
more, such as one for each corporate business partner.
If it
doesn't know how to build the chain from its certificates to the CA
the other end provided, why not send those 1 or 2 certificates to the
other end and see if he can make the chain.
Because this could turn into an message that is >50K bytes. Very long UDP
messages are inherently dangerous, yes?
There is also INVALID-CERT-AUTHORITY and CERTIFICATE-UNAVAILABLE
notifications that can be used.
But you use those when you cannot set up an SA. What if a party sent three
cert requests with three different roots, of which you only have one
matching. I don't think you should send back two CERTIFICATE-UNAVAILABLE
failure notices and a cert; I think you send two NONE cert payloads and a
real cert. The other option is to only send certs that do match, and if
there are none, you obviously would want to send an error notification.
> Your problem is real, but it is not common (one might say "extremely rare
> except for Entrust customers"). I think what is proposed here is OK
> *except* for the case of cross-certification, and that if we want to deal
> with that problem, we need a solution specific to cross-certs.
No, I think sending information you have to the other end to see if he
can make sense of it, is the best way to do it. It will allow two
parties to communicate if either one of parties have extra information
that allows him to build the completele path.
I still disagree, but am open to this if many folks want to do it. Again,
be aware that this means that a request for a root that you don't have
might cause the responder to dump a large number of packets on you.
--Paul Hoffman, Director
--VPN Consortium