[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