Subject: [IPsec] #107: Sending certificate chains in IKEv2

From: Yaron Sheffer <[email-masked]>
Date: Wed, 26 Aug 2009 00:23:01 +0300

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

---

From: Martin Willi <[email-masked]>
Date: Wed, 26 Aug 2009 09:17:56 +0200

Hi,

> Input from actual implementations (and bakeoffs) will be most valuable

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

---

From: Tero Kivinen <[email-masked]>
Date: Wed, 26 Aug 2009 16:43:23 +0300

> 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. 
-- 
[email-masked]

---

From: Yoav Nir <[email-masked]>
Date: Wed, 26 Aug 2009 16:53:54 +0300

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:

> _______________________________________________
> IPsec mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ipsec
>
> Scanned by Check Point Total Security Gateway.

Email secured by Check Point

---

From: Tero Kivinen <[email-masked]>
Date: Wed, 26 Aug 2009 16:42:29 +0300

> 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. 
-- 
[email-masked]

---

From: David Wierbowski <[email-masked]>
Date: Wed, 26 Aug 2009 09:49:59 -0400

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                                                 
             <yaronf@checkpoin                                             
             t.com>                                                     To 
             Sent by:                  "[email-masked]" <[email-masked]>   
             ipsec-bounces@iet                                          cc 
             f.org                                                         
                                                                   Subject 
                                       [IPsec] #107: Sending certificate   
             08/25/2009 05:23          chains in IKEv2                     
             PM                                                            

Yoav says:

{{{

{{{

Input from actual implementations (and bakeoffs) will be most valuable
here.

Thanks,
            Yaron(See attached file: smime.p7s)
_______________________________________________
IPsec mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ipsec

---

From: David Wierbowski <[email-masked]>
Date: Wed, 26 Aug 2009 11:10:36 -0400

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                                                  
             <[email-masked]>                                              
             Sent by:                                                   To 
             ipsec-bounces@iet         Yaron Sheffer                       
             f.org                     <[email-masked]>             
                                                                        cc 
                                       "[email-masked]" <[email-masked]>   
             08/26/2009 09:42                                      Subject 
             AM                        [IPsec]  #107: Sending certificate  
                                       chains in IKEv2

---

From: Yaron Sheffer <[email-masked]>
Date: Wed, 26 Aug 2009 17:14:05 +0300

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: [email-masked] [mailto:[email-masked]] On Behalf Of
> Yoav Nir
> Sent: Wednesday, August 26, 2009 16:54
> To: Tero Kivinen
> Cc: [email-masked]
> Subject: Re: [IPsec] #107: Sending certificate chains in IKEv2
>

---

From: Tero Kivinen <[email-masked]>
Date: Thu, 27 Aug 2009 09:57:25 +0300

>       first of which holds the public key used to validate the sender's

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. 

> Certificate - Signature.encoding.  MUST terminology really is not needed in

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. 
-- 
[email-masked]

---

From: Yaron Sheffer <[email-masked]>
Date: Thu, 27 Aug 2009 11:35:34 +0300

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

> From: Tero Kivinen [mailto:[email-masked]]
> Sent: Thursday, August 27, 2009 9:57
> To: David Wierbowski
> Cc: [email-masked]; [email-masked]; Yaron Sheffer

---

From: David Wierbowski <[email-masked]>
Date: Thu, 27 Aug 2009 09:08:59 -0400

>   are to be sent then each certificate are sent as separate

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.

>allow a list, then multiple Certificate Request payloads would need to

I prefer your previous wording.

>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.

>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.