The CR payload still

[Pekka Riikonen <priikone@iki.fi>]

: 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)).

The second issue that would be nice to consider and decide is the
expansion of usage of CERTREQ to allow the verification of whether a
cached cert is the correct or not by including eg. the hash of the cert in
CERTREQ.  This also relates to the earlier revised identity discussion on
the list.

	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