Re: [IPsec] #119: Which certificate types can be mixed in one exchange?

Tero Kivinen <> Wed, 25 November 2009 12:23 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id E65EA3A69F5 for <>; Wed, 25 Nov 2009 04:23:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.576
X-Spam-Status: No, score=-2.576 tagged_above=-999 required=5 tests=[AWL=0.023, BAYES_00=-2.599]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id LfYMrAApARYL for <>; Wed, 25 Nov 2009 04:23:28 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id B2DE83A68C8 for <>; Wed, 25 Nov 2009 04:23:27 -0800 (PST)
Received: from (localhost []) by (8.14.3/8.14.3) with ESMTP id nAPCNGZU015228 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 25 Nov 2009 14:23:16 +0200 (EET)
Received: (from kivinen@localhost) by (8.14.3/8.12.11) id nAPCNGNv014167; Wed, 25 Nov 2009 14:23:16 +0200 (EET)
X-Authentication-Warning: kivinen set sender to using -f
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <>
Date: Wed, 25 Nov 2009 14:23:16 +0200
From: Tero Kivinen <>
To: Yaron Sheffer <>
In-Reply-To: <>
References: <> <>
X-Mailer: VM 7.19 under Emacs 21.4.1
X-Edit-Time: 14 min
X-Total-Time: 20 min
Cc: IPsecme WG <>
Subject: Re: [IPsec] #119: Which certificate types can be mixed in one exchange?
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Discussion of IPsec protocols <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 25 Nov 2009 12:23:29 -0000

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

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<>;) added to any of the above,
> except for Raw RSA.