RE: Adding revised identities to IKEv2

["Max Pritikin" <pritikin@cisco.com>]

From: owner-ipsec@lists.tislabs.com <>
> Subject: Re: Adding revised identities to IKEv2
>
>
> 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.

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.

	- max

>> 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/