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

Re: The CR payload still



On 3/4/03 7:28 PM, "Charlie_Kaufman@notesdev.ibm.com"
<Charlie_Kaufman@notesdev.ibm.com> wrote:
> I think I'm hearing variations on the following proposal:
> 
> An empty CERTREQ payload is requesting any certificate or certificate chain
> the other side has without giving any hints as to what certificates are
> preferred.
> 
> A missing CERTREQ payload is requesting that the other side not bother
> sending any certificates.
> 
> When would an IKE implementation want to express the second request? I had
> assumed that if CERTREQ was missing that the other side should send
> whatever certificate it has, so an empty CERTREQ would just be a less
> efficient encoding of the same request. I get the impression from this
> discussion that IKEv1 had the two versions of the request as above. Were
> they both used?
> 
> If someone has a use for requesting no certificates, I think this is a fine
> way to encode it. But I'm reluctant to add a feature unless someone thinks
> they need it.
> 
>         --Charlie
> 
> Opinions expressed may not even be mine by the time you read them, and
> certainly don't reflect those of any other entity (legal or otherwise).

Carlie,

As you point out, no CERTREQ means "don't bother to send any CERTs",
but the question remains as to what an empty CERTREQ means.  ISAKMP
states that an empty CERTREQ means "send any CERTs you want, I don't
care".

Except for the case of opportunistic IPsec, I don't see the point
of telling your peer "I don't care".  Therefore, I agree that an empty
CERTREQ should be prohibited in IKEv2, especially because it creates an
interoperability rat hole.

- brian
briank@briank.com