[IPsec] #119: Which certificate types can be mixed in one exchange?

[Tero Kivinen <kivinen at iki.fi>]

Yaron Sheffer writes:
> Should be added to Sec. 3.6, probably as a new subsection.
> 
> One Hash & URL (H&U) bundle only. Or...
> 
> One Raw RSA key, or...
> 
> One or more cert payloads of either type 4 or H&U (type 12)
> 
> Can have one or more CRLs and/or OCSP content (RFC
> 4806<http://tools.ietf.org/html/rfc4806>) added to any of the above,
> except for Raw RSA. 

I think the answer to question which types can be mixed in one
exchange is: Any.

As recipient should be able to ignore the formats it does not support
easily, and if that results to case where recipient does not have
enough information to validate the certificate then the authentication
cannot succeed. The sender should include certificates in the format
that they were requested by certificate request payload, but if it
cannot, then it might as well include the certificate in some other
format, just in case that will help the recipient. If that does not
help the recipient, then those two peers cannot authenticate each
other.

I do not see any problem when some implementation which needs to
present certificate for peer, which didn't send any certificate
request payload, decides to send same certiface using format 11 and 4
and also provides intermediate certificates for the X.509 certificate
as hash and url of X.509 certificates and even includes CRL in format
7 if all that can be fit to the packet without causing fragmentation
(i.e. if all that fits to packet less than 1280 bytes, then there is
no reason not to include all that helpful information if that was
readily available).

Then if the initiator was very limited IPsec garage door remote
controller implementation which required public key as raw rsa key
(format 11), it can take it from there, and ignore rest, and if it
happened to be real VPN client using preper CA, it can then verify the
certificates and CRLs etc.

Limiting the number of certificate types which can be mixed in one
exchange will limit the scenarios we can use with IPsec. I.e. if we
limit there can be only one type then we need to add more
configuration to the recipient, i.e. it needs to know from somewhere
that this incoming connection is now from this limited IPsec garage
door remote controller so only raw RSA key is presented, and if it is
this VPN client (laptop) then it need to give certificates etc.

I do not think this really affects interoperability as we already have
fixed list of mandatory to implement methods, this mostly affect how
much configuration each implementation needs to fill in, compared to
using more optimistic approach that fill in everything we have and
hope the other end has enough data to finish the authentication (if we
really gave everything we had, and that was not enough for the other
end, then we clearly cannot communicate regardless what format we
would have used).
-- 
kivinen at iki.fi