Yaron Sheffer writes:
> There was very limited discussion of this issue, which I see as the
> main reason why Sec. 3.6 is underspecified. If my proposal below is
> too restrictive we can expand it somewhat but still keep the number
> of possible combinations at a level where testing (and
> interoperability) is possible.

I think the list is too restrictive.

For example we definately want to allow sending both Raw RSA key, and
same key using some certificate format. This would be the one that can
be used bootstrap environments for using Raw RSA keys in the beginning
(and each host will have list of allowed rsa keys (or hashes of
them)), and then later each site can be updated to include proper
certificate from some CA too, and they can still talk to the old non
updated hosts using Raw RSA keys, and to new updated hosts using
certificates.

This means the PKI does not need to be taken in to use as atomic
operation, but it can be rolled in to use slowly one host at time.

I agree there is no point of having multiple Raw RSA keys, i.e. we
could limit the number of those to one (or zero). I do not think we
can make too much other restrictions without making existing
implementations non-conforming.

I can also see uses for multiple hash and url bundles, in case the
responder has for example certificate signed by 2 different CAs and
initiator didn't specify which of them should be used, so responder
can send hash and url bundles for both of them.

> David also asked whether we'd want to fold RFC 4806 (OCSP extensions
> to IKEv2) into -bis. My personal opinion is No, despite the fact
> that it is a Proposed Standard. 

I agree on that.

> Subject: [IPsec] #119: Which certificate types can be mixed in one exchange?
> 
> 
> 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. 
-- 
kivi...@iki.fi
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Reply via email to