Re: Adding revised identities to IKEv2

[Tero Kivinen <kivinen@ssh.fi>]

Paul Hoffman / VPNC writes:
> >>        Certificate bundle                  2
> >>           A simple ASN.1 sequence of PKIX certificates. A bundle can have
> >>           end-entity certificates and/or certificates from a chain to a
> >>           root. The first certificate in the bundle is the sender's
> >>           preferred identity certificate, but beyond that there is no
> >>           meaning to the ordering.
> The reason I proposed two was that some gateways would only want the 
> certificate of the other party because they would do all the 
> additional validation themselves. If you just say "I want a cert 
> bundle", the other party will always need to send the whole chain.

True. Actually I think bundle should be defined not to include the
root, so in normal case bundle and single cert will be same.

Also I think the SGW will always be using the url version, as it can
find, load and cache all those certificates quite easily.

> Either format seems fine. Every time I propose wrapping ASN.1 objects 
> like PKIX certs in non-ASN.1 wrappers, I catch grief. Every time I 
> create a new ASN.1 structure, I catch grief.

I was just worried about creating new ASN.1 structure, and I think
creating non-ASN.1 wrapper is easier for most of the people (i.e if
the encoding is some standard ASN.1 encoding (pkcs7) then it is easier
to just give that whole stuff to certificate manager library, but if
you need to manually parse that ASN.1 before giving the certificates
to the certificate manager library then it is easier to use non ASN.1
encoding). 

> Probably disagree. If I have two certs for the same public key that 
> lead to different trust anchors, you wouldn't be able to tell which I 
> was proposing to you.

And what difference does it make? You are going to use the public key
to verify my signature and it really doesn't matter which certificate
you used.

> By using just the public key, you are forcing the receiving party to
> search all paths for certs that match the public key.

It needs to do the same thing anyway. It needs to find the path from
the certificate to the some trusted root, and it doesn't really matter
if it does that based on the public key instead of certificate.
-- 
kivinen@ssh.fi
SSH Communications Security                  http://www.ssh.fi/
SSH IPSEC Toolkit                            http://www.ssh.fi/ipsec/