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

Re: The CR payload still




: At 11:07 AM -0800 3/5/03, Brian Korver wrote:
: >Except for the case of opportunistic IPsec, I don't see the point
: >of telling your peer "I don't care".
:
: There are other meanings than "I don't care". We need to be able to
: say "send me a cert of type other than 4", namely types 11, 12, and
: 13. Currently, we can't specify that.
:
If the IKEv2 document doesn't want to specify other usage for CERTREQ then
surely it is possible to write additional specifications for those other
types.

In fact, for an empty CERTREQ case whould there be any harm in saying:

   If empty CERTREQ payload is received the sender indicates that it does
   not require any specific certificate or certificate chain, but it may
   accept any certificate.  The Cert Encoding field indicates the type of
   certificate encoding sender is expecting.  If so the processor SHOULD
   send its local certificate or certificate chain of correct type it is
   going to use in the negotiation.  The sender of this payload will later
   decide whether it will trust the certificate (by perhaps prompting
   first a human operator).

By including multiple CERTREQs in exchange would allow request of multiple
different kind of certs and public keys.

	Pekka
___________________________________________________________________________
 Pekka Riikonen                    | Email: priikone@iki.fi
 SSH Communications Security Corp. | http://iki.fi/priikone/
 Tel. +358 (0)40 580 6673          | Snellmanninkatu 34 A 15, 70100 Kuopio
 PGP KeyID A924ED4F: http://iki.fi/~priikone/pubkey.asc