Re: [IPsec] #107: Sending certificate chains in IKEv2
>David Wierbowski writes: >> 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. > >This text looks good for me. And I think it is important to add this >to X.509 Certificate - Signature (4) case, even when we have some >generic text elsewhere saying same thing, as this is the most common >case people are using now. > >> 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. > >Agreed. > >I think in addition to that text we might want to add some generic >text to the final paragraph saying: > > Some of the certificate formats can only contain one certificate > (for example formats 4, 7, 11 and 12), and some can contain > multiple certificates (for example 1, 13). In case those formats > which contain one certificate are used and multiple certificates > are to be sent then each certificate are sent as separate > Certificate Payload. > I agree that text like this should be added. I suggest some minor editorial changes (change "In case those formats" to "When" and "are" to "is": Some of the certificate formats can only contain one certificate (for example formats 4, 7, 11 and 12), and some can contain multiple certificates (for example 1, 13). When formats which contain one certificate are used and multiple certificates are to be sent then each certificate is sent as separate Certificate Payload. In that past I've asked if the first certificate payload is encoded using type 13 does the first certificate in the bundle have to be the one used to create the signature and you've answered yes. Perhaps we should also clarify that here. I do not think we can make such a statement when type 1 is used. I know of at least one vendor that uses type 1. The signing cert is not the first certificate in their PKCS #7 data. > >Or add similar text than what is in the 3.7 Certificate Request >Payload which have following sentence at the end of first paragraph >"If multiple CAs are trusted and the certificate encoding does not >allow a list, then multiple Certificate Request payloads would need to >be transmitted." I prefer your previous wording. > >One more thing, do we want to explictly mention that it is very common >to mix multiple types of certificate payloads, i.e. send certificate >multiple payloads some having X.509 Certificate - Signature (4) format >and some having Certificate Revocation List (7) format. > I agree that we should state that mixing multiple types of certificate payloads is allowed. The examples are helpful, but I'm not sure we need to include them in the text. >Another combination could be Raw RSA Key (11) and X.509 Certificate - >Signature (4). In that case the Raw RSA Key (11) format is meant for >minimal implementations who have the raw RSA key of the other end >statically configured to their policy, and the X.509 Certificate - >Signature (4) format is meant for full implementations which can >process and validate certificates. > >Note also that not all certificates are there to form a chain, they >can also provide other things like CRLs or even multiple different >chains towards the different CAs (in case the private/public key use >has certificates from multiple CAs, and other end didn't indicate any >known CA), so the extra certificate payloads (after the first one used >to sign the AUTH payload) are there just to help validation of the >first certificate, not necessarely to form a chain. I agree that we should stste the extra certificate payloads are there to help validation of the first certificate, not necessarely to form a single chain. >-- >kivi...@iki.fi___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] #107: Sending certificate chains in IKEv2
All of which taken together indicates the Sec. 3.6 needs to be rewritten. It'll be hard enough to get interoperability with all these options, but certainly if much remains undocumented. We might even need to resort to defining what the mythical "minimal implementation" is allowed to do. Thanks, Yaron > -Original Message- > From: Tero Kivinen [mailto:kivi...@iki.fi] > Sent: Thursday, August 27, 2009 9:57 > To: David Wierbowski > Cc: ipsec@ietf.org; ipsec-boun...@ietf.org; Yaron Sheffer > Subject: Re: [IPsec] #107: Sending certificate chains in IKEv2 > > David Wierbowski writes: > > 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. > > This text looks good for me. And I think it is important to add this > to X.509 Certificate - Signature (4) case, even when we have some > generic text elsewhere saying same thing, as this is the most common > case people are using now. > > > 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. > > Agreed. > > I think in addition to that text we might want to add some generic > text to the final paragraph saying: > >Some of the certificate formats can only contain one certificate >(for example formats 4, 7, 11 and 12), and some can contain >multiple certificates (for example 1, 13). In case those formats >which contain one certificate are used and multiple certificates >are to be sent then each certificate are sent as separate >Certificate Payload. > > Or add similar text than what is in the 3.7 Certificate Request > Payload which have following sentence at the end of first paragraph > "If multiple CAs are trusted and the certificate encoding does not > allow a list, then multiple Certificate Request payloads would need to > be transmitted." > > One more thing, do we want to explictly mention that it is very common > to mix multiple types of certificate payloads, i.e. send certificate > multiple payloads some having X.509 Certificate - Signature (4) format > and some having Certificate Revocation List (7) format. > > Another combination could be Raw RSA Key (11) and X.509 Certificate - > Signature (4). In that case the Raw RSA Key (11) format is meant for > minimal implementations who have the raw RSA key of the other end > statically configured to their policy, and the X.509 Certificate - > Signature (4) format is meant for full implementations which can > process and validate certificates. > > Note also that not all certificates are there to form a chain, they > can also provide other things like CRLs or even multiple different > chains towards the different CAs (in case the private/public key use > has certificates from multiple CAs, and other end didn't indicate any > known CA), so the extra certificate payloads (after the first one used > to sign the AUTH payload) are there just to help validation of the > first certificate, not necessarely to form a chain. > -- > kivi...@iki.fi > > Scanned by Check Point Total Security Gateway. smime.p7s Description: S/MIME cryptographic signature ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] #107: Sending certificate chains in IKEv2
David Wierbowski writes: > 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. This text looks good for me. And I think it is important to add this to X.509 Certificate - Signature (4) case, even when we have some generic text elsewhere saying same thing, as this is the most common case people are using now. > 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. Agreed. I think in addition to that text we might want to add some generic text to the final paragraph saying: Some of the certificate formats can only contain one certificate (for example formats 4, 7, 11 and 12), and some can contain multiple certificates (for example 1, 13). In case those formats which contain one certificate are used and multiple certificates are to be sent then each certificate are sent as separate Certificate Payload. Or add similar text than what is in the 3.7 Certificate Request Payload which have following sentence at the end of first paragraph "If multiple CAs are trusted and the certificate encoding does not allow a list, then multiple Certificate Request payloads would need to be transmitted." One more thing, do we want to explictly mention that it is very common to mix multiple types of certificate payloads, i.e. send certificate multiple payloads some having X.509 Certificate - Signature (4) format and some having Certificate Revocation List (7) format. Another combination could be Raw RSA Key (11) and X.509 Certificate - Signature (4). In that case the Raw RSA Key (11) format is meant for minimal implementations who have the raw RSA key of the other end statically configured to their policy, and the X.509 Certificate - Signature (4) format is meant for full implementations which can process and validate certificates. Note also that not all certificates are there to form a chain, they can also provide other things like CRLs or even multiple different chains towards the different CAs (in case the private/public key use has certificates from multiple CAs, and other end didn't indicate any known CA), so the extra certificate payloads (after the first one used to sign the AUTH payload) are there just to help validation of the first certificate, not necessarely to form a chain. -- kivi...@iki.fi ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] #107: Sending certificate chains in IKEv2
Hi Yoav, This text (to be added for this specific encoding) duplicates the existing text at the end of this same section. Moreover, we keep saying "multiple certificates" without mentioning the semantics of these multiple certs, i.e. they should form a trust chain. Thanks, Yaron > -Original Message- > From: ipsec-boun...@ietf.org [mailto:ipsec-boun...@ietf.org] On Behalf Of > Yoav Nir > Sent: Wednesday, August 26, 2009 16:54 > To: Tero Kivinen > Cc: ipsec@ietf.org > Subject: Re: [IPsec] #107: Sending certificate chains in IKEv2 > > Good. So how about we close this issue by adding the last sentence > below: > >If > multiple certificates are sent, the first certificate MUST contain > the public key used to sign the AUTH payload. The other > certificates > may be sent in any order. Each certificate is encoded in a separate > CERT payload. > > Does this sound OK to everyone? > > On Aug 26, 2009, at 4:43 PM, Tero Kivinen wrote: > > > Martin Willi writes: > >> It is not even clear from the spec how to encode multiple > >> certificates > >> in a single cert payload with type 4 (just concatenate?). > > > > There is no way to encode more than one certificate with X.509 > > Certificate - Signature (#4) format in one certificate payload. > > -- > > kivi...@iki.fi > > ___ > > IPsec mailing list > > IPsec@ietf.org > > https://www.ietf.org/mailman/listinfo/ipsec > > > > Scanned by Check Point Total Security Gateway. > > > Email secured by Check Point > ___ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > > Scanned by Check Point Total Security Gateway. smime.p7s Description: S/MIME cryptographic signature ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] #107: Sending certificate chains in IKEv2
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
Sent by: To
ipsec-boun...@iet Yaron Sheffer
f.org
cc
"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
<><><>___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] #107: Sending certificate chains in IKEv2
We use multiple certificate payloads when using X.509 Certificate -
Signature (4) encoding.
I do not really see how this could be questioned. RFC 4306 clearly says
X.509 Certificate - Signature (4) encoding contains a single certificate as
pointed out below. The logical conclusion is that if you need to send
multiple certificates and choose to use X.509 Certificate - Signature (4)
encoding then you need multiple payloads.
On the other hand you can send one payload if you use Hash and URL of X.509
bundle encoding. If you do then the first certificate in the bundle must
contain the public key used to sign the AUTH payload.
I think the existing text is fine.
Dave Wierbowski
Yaron Sheffer
To
Sent by: "ipsec@ietf.org"
ipsec-boun...@iet cc
f.org
Subject
[IPsec] #107: Sending certificate
08/25/2009 05:23 chains in IKEv2
PM
Yoav says:
Section 3.6 ("Certificate Payload") describes sending certificates in the
IKE_AUTH exchange. The usual format for sending certificates is #4 (X.509
Certificate - Signature). Here's what it says:
{{{
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 the singular) The last paragraph says:
{{{
Implementations MUST be capable of being configured to send and
accept up to four X.509 certificates in support of authentication...
...If
multiple certificates are sent, the first certificate MUST contain
the public key used to sign the AUTH payload. The other certificates
may be sent in any order.
}}}
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)
Input from actual implementations (and bakeoffs) will be most valuable
here.
Thanks,
Yaron(See attached file: smime.p7s)
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
<><><>
smime.p7s
Description: Binary data
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
[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
Re: [IPsec] #107: Sending certificate chains in IKEv2
Good. So how about we close this issue by adding the last sentence below: If multiple certificates are sent, the first certificate MUST contain the public key used to sign the AUTH payload. The other certificates may be sent in any order. Each certificate is encoded in a separate CERT payload. Does this sound OK to everyone? On Aug 26, 2009, at 4:43 PM, Tero Kivinen wrote: > Martin Willi writes: >> It is not even clear from the spec how to encode multiple >> certificates >> in a single cert payload with type 4 (just concatenate?). > > There is no way to encode more than one certificate with X.509 > Certificate - Signature (#4) format in one certificate payload. > -- > kivi...@iki.fi > ___ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > > Scanned by Check Point Total Security Gateway. Email secured by Check Point ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] #107: Sending certificate chains in IKEv2
Martin Willi writes: > It is not even clear from the spec how to encode multiple certificates > in a single cert payload with type 4 (just concatenate?). There is no way to encode more than one certificate with X.509 Certificate - Signature (#4) format in one certificate payload. -- kivi...@iki.fi ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] #107: Sending certificate chains in IKEv2
Hi, > Input from actual implementations (and bakeoffs) will be most valuable > here. We and I think all vendors I have tested against use multiple certificate payloads (however, multi-level CA is a feature not tested with many participants). It is not even clear from the spec how to encode multiple certificates in a single cert payload with type 4 (just concatenate?). Regards Martin ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
[IPsec] #107: Sending certificate chains in IKEv2
Yoav says:
Section 3.6 ("Certificate Payload") describes sending certificates in the
IKE_AUTH exchange. The usual format for sending certificates is #4 (X.509
Certificate - Signature). Here's what it says:
{{{
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 the singular) The last paragraph says:
{{{
Implementations MUST be capable of being configured to send and
accept up to four X.509 certificates in support of authentication...
...If
multiple certificates are sent, the first certificate MUST contain
the public key used to sign the AUTH payload. The other certificates
may be sent in any order.
}}}
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)
Input from actual implementations (and bakeoffs) will be most valuable here.
Thanks,
Yaron
smime.p7s
Description: S/MIME cryptographic signature
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
