Subject: [pkix] Support for delegate certificates

From: Phil Lello <[email-masked]>
Date: Thu, 14 Apr 2016 20:16:50 +0100

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 [email-masked], 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

---

From: "Dr. Pala" <[email-masked]>
Date: Thu, 14 Apr 2016 15:53:27 -0400

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.
>
> 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 
> [email-masked] <mailto:[email-masked]>, who issues a 
> certificate to www.randompublisher.net <http://www.randompublisher.net>
>
> 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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/pkix
>
> -- 
> Massimiliano Pala, PhD
> Director at OpenCA Labs
> twitter: @openca

---

From: Peter Bowen <[email-masked]>
Date: Thu, 14 Apr 2016 20:04:52 -0700

On Thu, Apr 14, 2016 at 12:16 PM, Phil Lello <[email-masked]> wrote:
> 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
> generation of certificates for alternate distribution points (or individuals
> who can do so).
>

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

---

From: Phil Lello <[email-masked]>
Date: Fri, 15 Apr 2016 07:11:38 +0100

On Fri, Apr 15, 2016 at 4:04 AM, Peter Bowen <[email-masked]> wrote:

> indeed
> holder
> such

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