Re: Support for delegate certificates

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?

Thanks,
Peter

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