Yaron Sheffer writes: > What this doesn't say is how we send this chain of certificates. Is it > multiple separate CERT payloads (in that case it should say so) or is it a > single CERT payload (and then we should also say so)
If you use format that can only store one certificate (for example X.509 Certificate - Signature (#4), or Hash and URL of X.509 certificate (#12)) then you send multiple Certificate Payloads each having one certificate in, and the first certificate payload you send contains the certificate you use to sign the AUTH payload. If you use format that can store multiple certificates (PKCS #7 wrapped X.509 certificate (#1) or Hash and URL of X.509 bundle (#13)) then the first certificate inside the first Certificate Payload is the one used to sign the AUTH payload. This thing is same as it was in IKEv1, i.e. sending multiple Certificate payloads, each having one certificate using X.509 Certificate - Signature (#4) was the most common configuration implementations supported. Note, that it is also valid to send mixed set of certificate payloads, i.e. send first few Certificate Payloads using X.509 Certificate - Signature (#4) format and then send couple of Certificate Payloads using Certificate Revocation List (CRL) (#7) format, to provide the CRLs for those certificates. I already had some comments to this at 2008-07-29, where I requested change to the "X.509 Certificate - Signature" description, so it would be clear that it can also be used in validation of the chain not only when validating AUTH payload http://www.ietf.org/mail-archive/web/ipsec/current/msg02953.html, actually Yoav Nir's version has even better text http://www.ietf.org/mail-archive/web/ipsec/current/msg04326.html (and disagree with Paul's comment that this text would add new MUST, as that requirement has always been there as there is no way to encode multiple certificates to one X.509 Certificate - Signature (#4) format, thus if you want to use that format you must have sent multiple certificates earlier too (note that the MUST was only "with this encoding")). On the other hand as this thing with multiple CERT payloads is not only restricted to that format, so some generic text to section 3.6 is needed anyways. There is also my previous email about this #107 ticket, which includes some more comments to the issue: http://www.ietf.org/mail-archive/web/ipsec/current/msg04327.html. -- kivi...@iki.fi _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
