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

Re: The CR payload still



On Wed, 26 Feb 2003, Pekka Riikonen wrote:

: : explicit specifications about when the CERT and CERTREQ packets much
: : be sent and how they should be handled, the addition of crypto suites,
: :
: I would still raise the issue of CR payload usage I mentioned a while
: back.  The ability for initiator to request 'any' cert from responder
: (regardless of the CA) would be in my opinion important to have.  The way
: specs seems to suggest implementation to work is that CERT is not sent if
: CERTREQ is not sent, if CERTREQ was sent but no such CA was found CERT is
: still not sent.  This means that you must know the CA before hand or you
: must have the cert cached for the exchange to ever succeed (since you
: won't have the public key to verify the AUTH).  Now, maybe in ideal world
: everyone always know who everyone else trusts or everybody trusts always
: the same CAs but I think in real world this won't be the case.
:
: The way in IKEv1 this was done was to unofficially agree between vendors
: (eg. in every bakeoff for past several years I've attended to) that empty
: CR payload means kind of "any" request.  IKEv2 does not allow this, but
: pki-profile provides a loophole for it anyway.  What I am suggesting is
: that empty CR payloads would be allowed in IKEv2 (explicitly), or by some
: other mechanism (eg. ANY cert encoding (but I don't like this very much)).
:
Ted, to your call for people to write the text for their ideas, I shall
reply to my own email with the text for this CERTREQ. :)

It says,

   Empty (zero length) CA names MUST NOT be generated and SHOULD be
   ignorred.

should be removed and later to say something like this,

   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.  If so the processor SHOULD send its local
   certificate or certificate chain 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).

or something like that...

	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