Re: [pkix] Support for delegate certificates

"Dr. Pala" <> Thu, 14 April 2016 19:53 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id B1F1612E2E2 for <>; Thu, 14 Apr 2016 12:53:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.105
X-Spam-Status: No, score=-0.105 tagged_above=-999 required=5 tests=[AC_DIV_BONANZA=0.001, BAYES_00=-1.9, HK_NAME_DR=1, HTML_MESSAGE=0.001, RDNS_NONE=0.793] autolearn=no autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id kIS1ILOlGF8A for <>; Thu, 14 Apr 2016 12:53:29 -0700 (PDT)
Received: from (unknown [IPv6:2607:5501:1000:1ff::87c4]) by (Postfix) with ESMTP id E356F12E2E0 for <>; Thu, 14 Apr 2016 12:53:28 -0700 (PDT)
Received: from iMassi.local (unknown []) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPSA id 5237137423E8 for <>; Thu, 14 Apr 2016 15:53:28 -0400 (EDT)
References: <>
From: "Dr. Pala" <>
Organization: OpenCA Labs
Message-ID: <>
Date: Thu, 14 Apr 2016 15:53:27 -0400
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.7.2
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: multipart/alternative; boundary="------------030807010509000403020606"
Archived-At: <>
Subject: Re: [pkix] Support for delegate certificates
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: PKIX Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 14 Apr 2016 19:53:30 -0000


we do have two possible solutions for that that would also apply to the 
case for delegating the use of EV certs in CDN (see the lurk bof @ ietf95):

  * attribute certificates(
  * proxy certificates (

both of them have very good practical usages. I would say that the 
easiest would be the use of Proxy Certificates since it does not require 
an additional authority. The way I would enforce the check it would be 
that only the base URL from the EE certificate (e.g., can 
be extended. For example, valid URL would be:,, - non valid names would be anything 
that does not match /\.example\.com$/.

For Apache (since it uses OpenSSL) you might be able to set the trust by 
using an ENV variable to enable validation of proxy certificates - the 
problem remains the browsers which do not support that out of the box 
(details in the paper linked below).

Actually, I did manage (some time ago) to have a client certificate to 
be trusted on Firefox by installing the certificate and set it trusted 
via a simple extension (it seems that the trust flags take precedence - 
deails in the paper linked below).

Take a look at Proxy Certificates - that is probably what you would 
end-up using (added benefit is that you can have short-lived 
certificates that use a different key-pair than the original one).

Check out this paper we published some (looooong) time ago:



On 4/14/16 3:16 PM, Phil Lello wrote:
> Hi all,
> Not sure if this has already been discussed (I couldn't find it), or 
> indeed if this is the most appropriate list, but I have a variation on 
> certificate chains I'd like considered.
> I have a couple of scenarios in mind where it could be useful for the 
> holder of a certificate, say for * <> to 
> act as a CA for issuing certificate to delegates. Examples include:
>   - * <> issues a certificate to 
> <> (to reduce number 
> of admins trusted with wildcard cert)
>   - * <> issues a certificate to 
> <> (to support HTTP's Alt-Svc)
>   - * <> issues a certificate to 
> <>, who issues a 
> certificate to <>
> The basic principle is that the certificate (as vetted by a public CA) 
> identifies the party responsible for the signed content, but allows 
> generation of certificates for alternate distribution points (or 
> individuals who can do so).
> This would require explicit changes for libraries supporting protocols 
> such as TLS (assuming the chain verification isn't hopelessly broken) 
> to provide a notification to the client to identify who's behalf the 
> certificate was issued on.
> I'd like to avoid adding any extra metadata to the delegating 
> certificate, as that would seem to serve no techincal purpose, and 
> simply be an excuse for a public CA to charge more.
> Does this sound feasible/desirable? The TLS use-case should probably 
> define extra handshake options to guide the server on selecting an 
> appropriate cert/logging a useful error.
> Best wishes,
> Phil Lello
> _______________________________________________
> pkix mailing list
> -- 
> Massimiliano Pala, PhD
> Director at OpenCA Labs
> twitter: @openca