Re: [pkix] Support for delegate certificates
"Dr. Pala" <director@openca.org> Thu, 14 April 2016 19:53 UTC
Return-Path: <director@openca.org>
X-Original-To: pkix@ietfa.amsl.com
Delivered-To: pkix@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B1F1612E2E2 for <pkix@ietfa.amsl.com>; Thu, 14 Apr 2016 12:53:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.105
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kIS1ILOlGF8A for <pkix@ietfa.amsl.com>; Thu, 14 Apr 2016 12:53:29 -0700 (PDT)
Received: from mail.katezarealty.com (unknown [IPv6:2607:5501:1000:1ff::87c4]) by ietfa.amsl.com (Postfix) with ESMTP id E356F12E2E0 for <pkix@ietf.org>; Thu, 14 Apr 2016 12:53:28 -0700 (PDT)
Received: from iMassi.local (unknown [63.88.3.14]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.katezarealty.com (Postfix) with ESMTPSA id 5237137423E8 for <pkix@ietf.org>; Thu, 14 Apr 2016 15:53:28 -0400 (EDT)
To: pkix@ietf.org
References: <CAPofZaE52_FJpfYOu_VcpDAyvNWdeymTE+fYZB0G3mYrbvikdA@mail.gmail.com>
From: "Dr. Pala" <director@openca.org>
Organization: OpenCA Labs
Message-ID: <570FF537.9090004@openca.org>
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: <CAPofZaE52_FJpfYOu_VcpDAyvNWdeymTE+fYZB0G3mYrbvikdA@mail.gmail.com>
Content-Type: multipart/alternative; boundary="------------030807010509000403020606"
Archived-At: <http://mailarchive.ietf.org/arch/msg/pkix/hlh7kwtjQZTXwXzADJWFJoM4iYA>
Subject: Re: [pkix] Support for delegate certificates
X-BeenThere: pkix@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: PKIX Working Group <pkix.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/pkix>, <mailto:pkix-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/pkix/>
List-Post: <mailto:pkix@ietf.org>
List-Help: <mailto:pkix-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/pkix>, <mailto:pkix-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 14 Apr 2016 19:53:30 -0000
Well, 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(https://datatracker.ietf.org/doc/rfc3820/) * proxy certificates (https://datatracker.ietf.org/doc/rfc5755/) 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., example.com) can be extended. For example, valid URL would be: www.example.com, smtp.example.com, imap.example.com - 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: * http://cs.dartmouth.edu/~sws/pubs/pss10.pdf Cheers, Max 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 *.example.com <http://example.com> to > act as a CA for issuing certificate to delegates. Examples include: > > - *.example.com <http://example.com> issues a certificate to > project1.example.com <http://project1.example.com> (to reduce number > of admins trusted with wildcard cert) > - *.example.com <http://example.com> issues a certificate to > server.altsvc.com <http://server.altsvc.com> (to support HTTP's Alt-Svc) > - *.example.com <http://example.com> issues a certificate to > J.Smith@example.com <mailto:J.Smith@example.com>, who issues a > certificate to www.randompublisher.net <http://www.randompublisher.net> > > 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 > pkix@ietf.org > https://www.ietf.org/mailman/listinfo/pkix > > -- > Massimiliano Pala, PhD > Director at OpenCA Labs > twitter: @openca
- [pkix] Support for delegate certificates Phil Lello
- Re: [pkix] Support for delegate certificates Dr. Pala
- Re: [pkix] Support for delegate certificates Peter Bowen
- Re: [pkix] Support for delegate certificates Phil Lello