Re: Adding revised identities to IKEv2

[Paul Hoffman / VPNC <paul.hoffman@vpnc.org>]

At 10:22 PM +0200 11/12/02, Tero Kivinen wrote:
>The changes seems quite ok, but I think they are too complicated.

Quite possibly true.

>  >       PKIX certificate                    1
>>           A standalone PKIX certificate.
>>        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.
>
>Is there any need to have both? Isn't the PKIX certificate just
>certificate bundle with one entry?

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.

>  Also I don't think simple ASN.1
>sequence of PKIX certificate is good way to transmit bundles, better
>use something like 16-bit length of certificate, certificate date,
>16-bit length of certificate, certificate data.... (16-bits is enough
>as the maximum payload length is 16-bits).

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.

>  >       Hash-and-URL of PKIX certificate    3
>>           The first 20 octets are the SHA-1 hash of a certificate; the
>>           rest is a URL that resolves to the certificate. This is
>>           described in more detail below.
>>        URL to a PKIX certificate bundle    4
>>           This is described in more detail below.
>
>Same here, why both bundle and single certiicate.

Same as above.

>  Also I would thing
>instead of SHA-1 hash of the certificate it would be better to use
>SHA-1 hash of the public key as used already in the trustedroot
>payload. The other end doesn't really need a certificate it needs a
>public key and it needs it to be trusted somehow. If used hash of the
>public key, then the same method can be used to identify raw public
>keys (with minimal asn.1 code to encode the public key to same format
>used in pkix key identifier).

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. By using just the public key, you are forcing 
the receiving party to search all paths for certs that match the 
public key.

Having just said that, I admit that this is an edge case and that it 
isn't that onerous.

>Also there might be multiple certificates for the same public key (old
>certificate and new certificate) thus the url would return similar
>bundle of certificates as in first section in all cases (i.e the first
>certificate in the bundle would be the preferred identity
>certificate).

Good point.

>  >       PKIX keyIdentifier                  5
>>           Identifies a self-signed certificate that the receiver has
>>           already pre-loaded. Note that this is only useful when using
>>           self-signed certificates.
>
>This would be redundant and better to use the keyidentifier + url
>format above, but leave the url empty.

Good idea!

>  > For FullID types 3 and 4, the URL scheme must be "http", although it can
>>  be on any port number. The URL can be to a persistent repository, or it
>>  might be to the initiating machine (such as for a remote access client).
>
>There should propably be note, here saying that if the initiator is
>behind NAT then it cannot really use the url pointing to itself, as
>the connection from the responder will not get through to the
>initiator.

Yup.

>  > If a system that is using certificates knows that it cannot resolve URLs
>>  (for example, because it is not yet on the Internet), it SHOULD use
>>  FullID types 1 and 2 in its IDAccepted payload. If a system can resolve
>  > URLs, it SHOULD use type 3 and 4 unless it is sure that it does not have
>>  the certificate of the other side, such as if it has just recovered from
>>  a crash and its cache is empty. All systems should be able to handle
>>  certificate bundles because the other party might have multiple
>>  identities which have different certificates.
>
>With those modifications we would only have two different types of
>FullID types for certificates, use type 1 if not connected to network
>and type 2 if you are connected to network and can fetch urls.

Yes, if we make all the requests for bundles.

>One thing missing that was in the IKEv1 is the transfering of the
>CRLs, but when considering the size of them it is better to leave them
>out.

Exactly.

--Paul Hoffman, Director
--VPN Consortium