Re: Support for delegate certificates

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

> On Thu, Apr 14, 2016 at 12:16 PM, Phil Lello <[email protected]> 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 [email protected], 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

_______________________________________________
pkix mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/pkix