I agree with Tero that Yoav's proposed text adds clarity and effectively it does not add a new MUST; however, to address Paul's concern can we just change the words "MUST be" to the word "are" or lower case "should be?" For example:
o X.509 Certificate - Signature (4) contains a DER encoded X.509
certificate whose public key is used to validate the sender's AUTH
payload. Note that with this encoding if a chain of certificates
needs to be sent, multiple CERT payloads are used, only the
first of which holds the public key used to validate the sender's
AUTH payload.
As Tero points out, this is the only way to send a chain this using X.509
Certificate - Signature.encoding. MUST terminology really is not needed in
my opinion.
Dave Wierbowski
Tero Kivinen
<kivi...@iki.fi>
Sent by: To
ipsec-boun...@iet Yaron Sheffer
f.org <yar...@checkpoint.com>
cc
"ipsec@ietf.org" <ipsec@ietf.org>
08/26/2009 09:42 Subject
AM [IPsec] #107: Sending certificate
chains in IKEv2
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
<<inline: graycol.gif>>
<<inline: pic15247.gif>>
<<inline: ecblank.gif>>
_______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
