Re: [pkix] Support for delegate certificates

Peter Bowen <pzbowen@gmail.com> Fri, 15 April 2016 03:04 UTC

Return-Path: <pzbowen@gmail.com>
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 A003612D110 for <pkix@ietfa.amsl.com>; Thu, 14 Apr 2016 20:04:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.99
X-Spam-Level:
X-Spam-Status: No, score=-1.99 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001, 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=gmail.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 ObCsguEX7YU9 for <pkix@ietfa.amsl.com>; Thu, 14 Apr 2016 20:04:53 -0700 (PDT)
Received: from mail-pa0-x229.google.com (mail-pa0-x229.google.com [IPv6:2607:f8b0:400e:c03::229]) (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 EC35D12D6AF for <pkix@ietf.org>; Thu, 14 Apr 2016 20:04:52 -0700 (PDT)
Received: by mail-pa0-x229.google.com with SMTP id fs9so32000022pac.2 for <pkix@ietf.org>; Thu, 14 Apr 2016 20:04:52 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=gW6yVu/5Cv6gwUHgClO01dPEckWmelKp0XnsU1O98lg=; b=WGkz4IPruwlgY3yqBiZzcJIg81jPyal4ZElF3d3D9xJoEIpRfzvMI/37vTobB5Q7XT piRe5/2qWbzfh0YilePclxCCAH7xXNhklMnYiP+Hz1z8vWS4WhJfJkrp3leU2V1RB6KH x9P+qKem8M0m3lGoLYHxFKfaLeugjuVLgIWWbNp2pFYPPaIS+oIYiFkpk23Yt6eAcfkz MRWKV137c3M6/3sPzP4tdIn9POmqf0M0MTD65A9aIkJ4N2+PpzabislyIRfDIqivqM/u o6UbVZQmLjHNCDUMPIY1FJHEHTcb8dAnArxH2eK7FmssT8/avs++f/9ra3qy4SSZC7HE BKRw==
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:cc; bh=gW6yVu/5Cv6gwUHgClO01dPEckWmelKp0XnsU1O98lg=; b=mNixxRo66O+RcpsNPrZgCiZeyR6BqPhKflKogvYic+BX2YFBtsvab6YUdbACkzfJDy /1HRylAWxj/vf8myDV6lrlfFmxQUuPjUrrbDUqXih+vFkuTR4axNHAC9MHxcifQHGlkC C3WONH9vK9+m9UKlGFEKtYhMuxcUB/0x7qIoDZupopfQgcyMFcG2fW06zhomIVsPYrNC u9mVmZ56cy6Qx5AAFnblB0vfATQekLpf+2OjrZIrfcGEZsw+ftUzGcmCfRFRHMijAQZm ipxfqKLbUHc1L+L4TVUl8V5XeI4ZZsegOChJOG3u3dQ8MQq5gyElxWls/sOoOSXYw4KX 6n6w==
X-Gm-Message-State: AOPr4FWYsMe3q4J45d7TWOdqYZhXiAl5D8DWrAgj8Jhod9N92wdkb8PX56ARQG9MubzpQG6cwIjvKuH9na12Uw==
MIME-Version: 1.0
X-Received: by 10.66.160.201 with SMTP id xm9mr25996336pab.68.1460689492502; Thu, 14 Apr 2016 20:04:52 -0700 (PDT)
Received: by 10.66.74.39 with HTTP; Thu, 14 Apr 2016 20:04:52 -0700 (PDT)
In-Reply-To: <CAPofZaE52_FJpfYOu_VcpDAyvNWdeymTE+fYZB0G3mYrbvikdA@mail.gmail.com>
References: <CAPofZaE52_FJpfYOu_VcpDAyvNWdeymTE+fYZB0G3mYrbvikdA@mail.gmail.com>
Date: Thu, 14 Apr 2016 20:04:52 -0700
Message-ID: <CAK6vND9Epe=bSv-rwvBOGPLQovz1g7XZWssfKtm62-8zm-ZF1w@mail.gmail.com>
From: Peter Bowen <pzbowen@gmail.com>
To: Phil Lello <phil@dunlop-lello.uk>
Content-Type: text/plain; charset=UTF-8
Archived-At: <http://mailarchive.ietf.org/arch/msg/pkix/DJm01gK7FAoqGcnShKkUEPIlIAI>
Cc: "<pkix@ietf.org>" <pkix@ietf.org>
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 03:04:54 -0000

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?

Thanks,
Peter