RE: Adding revised identities to IKEv2

[Russ Housley <housley@vigilsec.com>]

>Max Pritikin writes:
> > Your previous statement,
> > >>> The other end doesn't really need a certificate it needs a public key
> > and it needs it to be trusted somehow.
> >               ^^^^^^^
> > is the difference. The particular certificate matters because the 'somehow'
> > is to use the binding and identifying information in the certificate to
> > determine the appropriate policy.

>Tero Kivinen wrote:
>Certificate is not the only way the public key can be trusted. For
>example you could preconfigure the public key to the system (i.e the
>sgw have database of all public keys and what they are authorized to
>do with those keys). Or it might be internally use pgp-keys, dns
>record or ...

Tero, I agree.  I will limit my comments to the X.509 case.  Self-signed 
certificates are one way to establish trust anchors.  This approach is the 
one that is talked about the most because the major browser vendors use 
it.  RFC 3280 defines the minimum requirements for a trust anchor.  It says:

       The trust anchor information includes:

          (1)  the trusted issuer name,

          (2)  the trusted public key algorithm,

          (3)  the trusted public key, and

          (4)  optionally, the trusted public key parameters associated
          with the public key.

This information can be installed in any secure manner.

Russ