[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
Follow-Ups: References: