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