[pkix] Support for delegate certificates

Phil Lello <phil@dunlop-lello.uk> Thu, 14 April 2016 19:16 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 BDFB612DB2C for <pkix@ietfa.amsl.com>; Thu, 14 Apr 2016 12:16:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.598
X-Spam-Level:
X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AC_DIV_BONANZA=0.001, BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] 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 Ocx1rmvoLi_a for <pkix@ietfa.amsl.com>; Thu, 14 Apr 2016 12:16:53 -0700 (PDT)
Received: from mail-lf0-x230.google.com (mail-lf0-x230.google.com [IPv6:2a00:1450:4010:c07::230]) (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 ACE5F12DABF for <pkix@ietf.org>; Thu, 14 Apr 2016 12:16:52 -0700 (PDT)
Received: by mail-lf0-x230.google.com with SMTP id e190so120804506lfe.0 for <pkix@ietf.org>; Thu, 14 Apr 2016 12:16:52 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dunlop-lello-uk.20150623.gappssmtp.com; s=20150623; h=mime-version:date:message-id:subject:from:to; bh=PfAWtCH7c8KfKKHQ9Cc9TRC6WtsIjpMa1sEZM4kWP78=; b=0IkJ7Kt5Sz8hz67QjaSItZ2YUp0jAHzUimTC/GtqnMcUyLN8qR+x3LyK3kKqN7pP2g 4hmAW+7B+HCCWEZocIWKkOSC2Ewcadym6c1H1xgfm9Uu5npuTdESj1DtecXiYUmSzR34 UsQwztxvDwyfhOhCnanD5tC0V4EYzUFfQsvkSxp5MMy5Tb/Vcz2Llx+7lgFmGEbjROzw dUH4tETYu9rz7hhlKCdKo+gk4n8UHAtr0YmHC+i2c/PEdgRQnUTWtpfkWt2Xut9j2X8h ManXEqD28wHdWL21DIUGkJNqx/o+ivNCfbkvElHhRPxf6aOweGdwqIxmdbpi44mNk9j+ q8BQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to; bh=PfAWtCH7c8KfKKHQ9Cc9TRC6WtsIjpMa1sEZM4kWP78=; b=QI9msyl5HojRaomLd6rIcbCifYNLGzkK2kTzEhbdhtE++j6yiRLymIvH42OhtBjEFr O5kc6X2FBHKh1cFqdrZ+NSa5pLhZgKgCV3TPxAR2GdFNFD414ua8LyGX30Y2BxKU0XId 1CZlTpXaO6nctWm9aQIUbxrYpe1K7vrqip3ppyrQIDJueMVqFp2/p9UDtJTl04ob71dO ElHrnNVVi9KivccxbACb2M1E76SDx12uD7uwpxHkobRd0z0ZoawBDB/NCfb0j8JDOb+X Tgl2Po7hRWRVMjWqBrAUR7gn1RqdWfgbqAsc8qcK1baim/WR3m14xVrx+wsOVPNKLekg GWHA==
X-Gm-Message-State: AOPr4FWAOGn4+REYxLxx//aa1lqkVd7bEObn75Wii3pI1tpNS6dFvQsPbzp4L95K8uUqdLIH88OJabY06rQHBpWw
MIME-Version: 1.0
X-Received: by 10.25.165.140 with SMTP id o134mr7517538lfe.35.1460661410809; Thu, 14 Apr 2016 12:16:50 -0700 (PDT)
Received: by 10.25.27.16 with HTTP; Thu, 14 Apr 2016 12:16:50 -0700 (PDT)
Date: Thu, 14 Apr 2016 20:16:50 +0100
Message-ID: <CAPofZaE52_FJpfYOu_VcpDAyvNWdeymTE+fYZB0G3mYrbvikdA@mail.gmail.com>
From: Phil Lello <phil@dunlop-lello.uk>
To: pkix@ietf.org
Content-Type: multipart/alternative; boundary="001a11410a0e877012053076bc42"
Archived-At: <http://mailarchive.ietf.org/arch/msg/pkix/w66BLnD0JGAZ23HPrZSQmMFx6d0>
Subject: [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:16:56 -0000

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 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.

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