Re: Support for delegate certificates

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.
>
> I have a couple of scenarios in mind where it could be useful for the 
> 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 protected] <mailto:[email protected]>, who issues a 
> certificate to www.randompublisher.net <http://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
>
>
> _______________________________________________
> pkix mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/pkix
>
> -- 
> Massimiliano Pala, PhD
> Director at OpenCA Labs
> twitter: @openca

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