Re: [pkix] Support for delegate certificates

Phil Lello <phil@dunlop-lello.uk> Fri, 15 April 2016 06:11 UTC

Return-Path: <phil@dunlop-lello.uk>
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 0A97E12D885 for <pkix@ietfa.amsl.com>; Thu, 14 Apr 2016 23:11:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.589
X-Spam-Level:
X-Spam-Status: No, score=-2.589 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, T_FILL_THIS_FORM_SHORT=0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=dunlop-lello-uk.20150623.gappssmtp.com
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 dAaBZPP2a1WO for <pkix@ietfa.amsl.com>; Thu, 14 Apr 2016 23:11:41 -0700 (PDT)
Received: from mail-lf0-x22b.google.com (mail-lf0-x22b.google.com [IPv6:2a00:1450:4010:c07::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E7B1D12D65A for <pkix@ietf.org>; Thu, 14 Apr 2016 23:11:40 -0700 (PDT)
Received: by mail-lf0-x22b.google.com with SMTP id c126so133870878lfb.2 for <pkix@ietf.org>; Thu, 14 Apr 2016 23:11:40 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dunlop-lello-uk.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to; bh=qBBxYBFZ3wLnKy4Lwe7iv7FDHG4Zgu50bqpBc4sUKas=; b=TDy/GBp1mDq0YeQR4oF1CGnrqFoUtYaUjFx3IFaapFQ2b/0a9boc44M7KLA3NF885N JgXxTVWwAGOIpruwTQ2W9h867SSkyzDNfqlJi4vC+e6e/HDH2p6T7EiShM/t3GYvt5/l kQtBv+mF2hjFUwN/ON5+N6GDUruHWCa7ytxlT5INdHTdjDk0sWH+ijihgD8+tl4iAbbE lpyu73envbK0VsgBKQoijM3fUmejBspjW0/BOAPskYPSwW0HMdk42daBWlqkCxJYtzXq mH3Nf4nwPzBoMWsOgjKAhq8xO8SU01wEDXprvPwxs9EEiGkukoTQ2cLBPK7QWHK1UxbW vIow==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to; bh=qBBxYBFZ3wLnKy4Lwe7iv7FDHG4Zgu50bqpBc4sUKas=; b=BEjy25GLloeQeepuDFJikCsHDEW2hJwVxUox55cRx7yKF7j9PbnQVbbOqN+GJd2co3 MjJeV/x8tW0mARYIpNe1r9HzZVtfH77KcdR+BlltGMeyb8J239r4WCeA3yDWK0Mnpa6O /OX1XcwR6phz58lyfKVV8XJp7XwVoNYsc9y9yQtU6V9snlgrlyhmLoCc8nQQACPd4EXm O6DcjMCWxFjt8WLzmbUwgo8zDP/OYMxS2LeTqUgHYjR6yMTFJBOn19UJHx9npDaE9vLR poNFstCpwsC9DEay8s22IOt7v/cfwepCMRfp+p/90jQlLKSGHBFv3t2wR1MdGACCHt06 hkJQ==
X-Gm-Message-State: AOPr4FVdmKjiC9nhoIGksOVNJcmPhrISl2zJxQ5bHeHZU4r5fqZ+5bSxGCIQMUAEx1ZI3ajjOXty+hLvNuTyElbJ
MIME-Version: 1.0
X-Received: by 10.25.205.146 with SMTP id d140mr8716813lfg.109.1460700698966; Thu, 14 Apr 2016 23:11:38 -0700 (PDT)
Received: by 10.25.27.16 with HTTP; Thu, 14 Apr 2016 23:11:38 -0700 (PDT)
In-Reply-To: <CAK6vND9Epe=bSv-rwvBOGPLQovz1g7XZWssfKtm62-8zm-ZF1w@mail.gmail.com>
References: <CAPofZaE52_FJpfYOu_VcpDAyvNWdeymTE+fYZB0G3mYrbvikdA@mail.gmail.com> <CAK6vND9Epe=bSv-rwvBOGPLQovz1g7XZWssfKtm62-8zm-ZF1w@mail.gmail.com>
Date: Fri, 15 Apr 2016 07:11:38 +0100
Message-ID: <CAPofZaHzZ=mHD7uStyGi3n=n7e9bxrJss9PGLb=r4AZ88_uPZg@mail.gmail.com>
From: Phil Lello <phil@dunlop-lello.uk>
To: "<pkix@ietf.org>" <pkix@ietf.org>
Content-Type: multipart/alternative; boundary="001a114128ca491c9305307fe2d0"
Archived-At: <http://mailarchive.ietf.org/arch/msg/pkix/sUt2VI53eFd_rMO3szGZ1MQKDEY>
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: Fri, 15 Apr 2016 06:11:44 -0000

On Fri, Apr 15, 2016 at 4:04 AM, Peter Bowen <pzbowen@gmail.com> wrote:

> On Thu, Apr 14, 2016 at 12:16 PM, Phil Lello <phil@dunlop-lello.uk> wrote:
> > 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 to act as a CA for issuing
> > certificate to delegates. Examples include:
> >
> >   - *.example.com issues a certificate to project1.example.com (to
> reduce
> > number of admins trusted with wildcard cert)
> >   - *.example.com issues a certificate to server.altsvc.com (to support
> > HTTP's Alt-Svc)
> >   - *.example.com issues a certificate to J.Smith@example.com, who
> issues a
> > certificate to 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.
>
> This concept already exists today in the form of name constraints
> (https://tools.ietf.org/html/rfc5280#section-4.2.1.10).  Name
> constraints provide namespace (e.g. example.com) and only allow
> issuance to subtrees of that name.  They are defined to work with DNS
> names, email addresses, IP addresses, SRV names, and other name forms,
> so almost everything you propose could work.
>
> Have you looked at name constraints?
>

I don't think name constraints are suitable for the sub-domain use-case,
since I want to support generation of sub-domain certs from a CA-issued
certificate with "Certificate Basic Constraints" of "Is not a Certificate
Authority", which should reliably be checked and enforced in current
use-cases - as far as I'm aware, Name Constraints aren't correctly/widely
enforced (although I may be referring to old information), so there's a
significant risk of a name-constrained CA certificate from a public CA
chain being treated as a general-purpose CA certificate by older libraries.

Further, I explicity need cross-domain functionality for a protocol I'm
designing - I'm envisaging a cache for signed content that generates signed
content in some scenarios (for example, an optimised image,
upstream-unavailable message, or adding headers for virus-scan results on a
download). In this case, the client should want to know:

  - Where the original content came from (certificate signature)
  - Where the cache-generated content came from (delegated certificate
signature)
  - That the cache had permission to generate content (delegated
certificate issuer)

The cross-domain functionality may also be an appropriate mechanism for
HTTP's Alt-Svc (RFC7838), where Host and Alt-Used are on different domains.
RFC7838 gives an example of

     GET /thing HTTP/1.1
     Host: origin.example.com
     Alt-Used: alternate.example.net

RFC7838 s2.1 specifies

   For example, if the origin's host is "www.example.com" and an
   alternative is offered on "other.example.com" with the "h2" protocol,
   and the certificate offered is valid for "www.example.com", the
   client can use the alternative.

Phil