Domain-validated name-constrained CA certificates?
Matt McCutchen
message
recaps the substance of the existing discussion.]
It would be great if a Mozilla-recognized CA would be willing to give
me, as the registrant of mattmccutchen.net, an intermediate CA
certificate with a critical name constraint limiting it to
mattmccutchen.net. That would give me unlimited flexibility to issue
certificates for subdomains without bothering the CA. Such a
certificate would be an alternative to a wildcard certificate that
removes some limitations without fundamentally changing the security
model.
What are the technical obstacles that stand in the way of issuing such
certificates? I am aware of two:
#1. Bug 394919: NSS accepts the subject common name as an SSL server
name but does not constrain it. In bug 554442, I requested a hack so
that CAs could start using critical name constraints without NSS
versions lacking the fix for bug 394919 becoming vulnerable, but
Nelson
Bolyard decided that wasn't necessary.
#2. The tooltip of the Firefox SSL badge (a.k.a. "Larry" site identity
button) shows the Organization field of the lowest CA certificate,
i.e.,
the immediate signer of the server certificate. The registrant could
put a misleading value in this field. For example:
"Some Mozilla-recognized CA"
\_ "Matt's CA" (name constraint: mattmccutchen.net)
\_ "your evil twin"
\_ foo.mattmccutchen.net
+------------------------------+ +-----------------------------+
| [icon] foo.mattmccutchen.net | ---> | Verified by: your evil twin |
+------------------------------+ +-----------------------------+
Setting a maximum path length of 0 on the registrant's certificate
would
prevent this outcome, but it's a disappointing solution. Should
Firefox
show the organization name of the root CA instead, since it is
ultimately responsible for all validation paths that end at its trust
bit?
--
Matt
Jean-Marc Desperrier
> [...]
> It would be great if a Mozilla-recognized CA would be willing to give
> me, as the registrant of mattmccutchen.net, an intermediate CA
> certificate with a critical name constraint limiting it to
> mattmccutchen.net.
I don't believe this taking a hammer to crack a nut approach will have
much success. Especially since there's also the fact the CA would not be
able to constraint the *usage* you give to your certs.
> #2. The tooltip of the Firefox SSL badge (a.k.a. "Larry" site identity
> button) shows the Organization field of the lowest CA certificate,
> [...] The registrant could
> put a misleading value in this field. [...] Should Firefox
> show the organization name of the root CA instead, since it is
> ultimately responsible for all validation paths that end at its trust
> bit?
We are to something much more interesting here. I'm not sure it's really
a great practice to have only one level that's taken into account there.
But then only the root might be a bit too much in the other side. So,
maybe something better is needed but it's not easy to decide what.
Matt McCutchen
> On 04/04/2010 08:32, Matt McCutchen wrote:
> > [...]
> > It would be great if a Mozilla-recognized CA would be willing to give
> > me, as the registrant of mattmccutchen.net, an intermediate CA
> > certificate with a critical name constraint limiting it to
> > mattmccutchen.net.
>
> I don't believe this taking a hammer to crack a nut approach will have
> much success.
A name-constrained intermediate certificate could be quite convenient
for the large organizations that are presently demanding their users
to trust private CAs for the whole Web (see bug 501697). Users with
new enough NSS would see the sites just work; other users could trust
the intermediate certificate as if it were a root.
> Especially since there's also the fact the CA would not be
> able to constraint the *usage* you give to your certs.
An extended key usage of "TLS Web Server Authentication" on the
intermediate CA would constrain all sub-certificates, no?
--
Matt
Jean-Marc Desperrier
> An extended key usage of "TLS Web Server Authentication" on the
> intermediate CA would constrain all sub-certificates, no?
You are here talking about a proprietary Microsoft extension of the X509
security model.
Jean-Marc Desperrier
> A name-constrained intermediate certificate could be quite convenient
> for the large organizations that are presently demanding their users
> to trust private CAs for the whole Web (see bug 501697).
Ah ! The direction of restricting people who currently use sub-CA for
their purpose to make it more secure will certainly be much more
successful than presenting it as allowing many more people to have their
own sub-CA.
Rob Stradling
Mozilla has its own proprietary certificate extension (Netscape Cert Type)
that (IINM) can be used to achieve the same outcome (by setting the "SSL CA"
bit).
http://www.mozilla.org/projects/security/pki/nss/tech-notes/tn3.html has some
old notes from Nelson.
AFAIK, this extension is still supported by NSS, but having said that I
wouldn't be surprised if Nelson replies to this message with words to the
effect of "that extension is deprecated, so please don't use it any more!"
Rob Stradling
Senior Research & Development Scientist
C·O·M·O·D·O - Creating Trust Online
Office Tel: +44.(0)1274.730505
Office Fax: +44.(0)1274.730909
www.comodo.com
Comodo CA Limited, Registered in England No. 04058690
Registered Office:
3rd Floor, 26 Office Village, Exchange Quay,
Trafford Road, Salford, Manchester M5 3EQ
This e-mail and any files transmitted with it are confidential and intended
solely for the use of the individual or entity to whom they are addressed.
If you have received this email in error please notify the sender by replying
to the e-mail containing this attachment. Replies to this email may be
monitored by Comodo for operational or business reasons. Whilst every
endeavour is taken to ensure that e-mails are free from viruses, no liability
can be accepted and the recipient is requested to use their own virus checking
software.
Matt McCutchen
No, I'm talking about the "Extended Key Usage" extension defined in
RFC
5280 section 4.2.1.12.
--
Matt
Matt McCutchen
> Ah ! The direction of restricting people who currently use sub-CA for
> their purpose to make it more secure will certainly be much more
> successful than presenting it as allowing many more people to have their
> own sub-CA.
But I do want to allow many more people to have their own sub-CAs,
unless there is an actual technical reason why it is a bad idea, in
which case I am hoping you will tell me. The only issues I am aware
of are the two from my original message.
--
Matt
Eddy Nigg
> On Apr 6, 5:58 am, Jean-Marc Desperrier<jmd...@gmail.com> wrote:
>
>> Ah ! The direction of restricting people who currently use sub-CA for
>> their purpose to make it more secure will certainly be much more
>> successful than presenting it as allowing many more people to have their
>> own sub-CA.
>>
> But I do want to allow many more people to have their own sub-CAs,
> unless there is an actual technical reason why it is a bad idea, in
> which case I am hoping you will tell me.
>
Yes, for example do all potential client software enforce
name-constraining? How are the keys secured? Are the sub CAs going to
be audited (including site visit) as the root CA? How are the validation
requirements enforce? And a couple of more such questions...
If NSS would enforce name-constraining it will not automatically mean
that CAs would from then on happily issue intermediate CA certificates
to whomever asking. It however would allow to limit certain roots to
their specific field of activity if certain concerns exist or in case it
would make sense to do so. It's interesting mainly for CA roots, much
less for CAs issuing intermediate CAs to third parties.
--
Regards
Signer: Eddy Nigg, StartCom Ltd.
XMPP: star...@startcom.org
Blog: http://blog.startcom.org/
Twitter: http://twitter.com/eddy_nigg
Matt McCutchen
> On 04/07/2010 05:01 AM, Matt McCutchen:
> > unless there is an actual technical reason why it is a bad idea, in
> > which case I am hoping you will tell me.
>
> Yes, for example do all potential client software enforce
> name-constraining?
No. But since the name constraint extension is critical, client
software that does not support name constraints is required to reject
the intermediate certificate, which is safe. If client software
accepts the certificate but does not properly enforce the name
constraints (e.g., NSS bug 394919), that is the client software's
vulnerability.
CAs could start doing as I propose today. NSS users would be
vulnerable and, strictly speaking, it would be their own fault. Users
of client software that does not support name constraints (MSIE?)
would be completely unaffected since their software would reject all
the new sub-CAs.
> How are the keys secured? Are the sub CAs going to
> be audited (including site visit) as the root CA? How are the validation
> requirements enforce? And a couple of more such questions...
This is not an issue. The name constraint makes it impossible for a
domain registrant to issue a certificate that validates for a server
name outside that domain. Hence, anything bad I do with my
intermediate certificate could only hurt me as registrant of
mattmccutchen.net.
--
Matt
Kurt Seifried
> domain registrant to issue a certificate that validates for a server
> name outside that domain. Hence, anything bad I do with my
> intermediate certificate could only hurt me as registrant of
> mattmccutchen.net.
What about "www.paypal.com[NULL].yourcompany.com"? I assume that would
be allowed by the name constraint with respect to fixed software, but
still hit some older software that has the NULL certificate bug. I'm
also curious what about "www.paypal.com[lots of spaces or underscores
or something like that].yourcompany.com"?
> --
> Matt
-Kurt
Jean-Marc Desperrier
I repeat, you *are* talking about a proprietary Microsoft extension,
which is to take into account the EKU inside path validation.
The EKU as defined in section 4.2.1.12 of RFC 5280 only applies to the
certificate that contains it, it has no effect on certification paths
that include that certificate.
Matt McCutchen
Ah, you are right. Bummer! We do need a way to limit the
intermediate certificate to SSL server usage, otherwise it will be
difficult to anticipate and close off all the possibilities for abuse
with other EKUs. I will raise this with the PKIX working group. The
Microsoft behavior makes complete sense to me, so maybe it could just
be adopted by the standard.
--
Matt
Matt McCutchen
> What about "www.paypal.com[NULL].yourcompany.com"? I assume that would
> be allowed by the name constraint with respect to fixed software, but
> still hit some older software that has the NULL certificate bug.
I think "www.paypal.com[NULL].yourcompany.com" would match the name
constraint, but it isn't important, since modern software will not
allow that to match a requested hostname of "www.paypal.com". If some
people are still using software that is vulnerable, that's their
fault; we can't let them tie our hands indefinitely.
> I'm
> also curious what about "www.paypal.com[lotsof spaces or underscores
> or something like that].yourcompany.com"?
Spaces are not a problem because Firefox will not parse a URL where
the hostname contains a space. Barring spaces, this is the same
concern raised in the Problematic Practices for wildcard certificates,
except that the name constraints allow multiple labels (i.e., dots):
https://wiki.mozilla.org/CA:Problematic_Practices#Wildcard_DV_SSL_certificates
Personally I'm not worried about this weak attempt to fool the user.
It will be pretty obvious when the Larry button shows
"yourcompany.com" (browser.identity.ssl_domain_display = 1) or the
whole "www.paypal.com______.yourcompany.com" (2).
--
Matt