Does the CA approval process consider intermediate certs?
Stephen Schultze
a few of the requesting entity's policies.
Root CAs can grant intermediate CA certs to third parties unknown to
Mozilla or the original auditor.
Is there any requirement in the auditing process for root CAs to
define a policy for granting intermediate certs?
Is there any requirement that root CAs publicly disclose intermediate
certs in order to maintain Mozilla default root CA status?
Eddy Nigg
> The current root CA approval process requires an audit which looks at
> a few of the requesting entity's policies.
>
> Root CAs can grant intermediate CA certs to third parties unknown to
> Mozilla or the original auditor.
>
> Is there any requirement in the auditing process for root CAs to
> define a policy for granting intermediate certs?
>
This has been raised previously, see
https://wiki.mozilla.org/CA:Problematic_Practices#Allowing_external_entities_to_operate_unconstrained_subordinate_CAs
To all of my knowledge the WebTrust criteria has such a requirement.
> Is there any requirement that root CAs publicly disclose intermediate
> certs in order to maintain Mozilla default root CA status?
>
That's much desired, I'm not aware that there is an explicit
requirement. IIRC there was a CA which couldn't/wouldn't disclose them.
But the disclosed their CA policies and practice statements regarding
the issuance of such intermediate CAs.
--
Regards
Signer: Eddy Nigg, StartCom Ltd.
XMPP: star...@startcom.org
Blog: http://blog.startcom.org/
Twitter: http://twitter.com/eddy_nigg
Stephen Schultze
> On 02/23/2010 03:17 AM, Stephen Schultze:
> > define a policy for granting intermediate certs?
>
>
> To all of my knowledge the WebTrust criteria has such a requirement.
That doesn't appear to be the case:
http://www.google.com/search?q=site%3Awww.webtrust.org+subordinate
Perhaps it has been raised previously but not addressed.
> > Is there any requirement that root CAs publicly disclose intermediate
> > certs in order to maintain Mozilla default root CA status?
>
> That's much desired, I'm not aware that there is an explicit
> requirement. IIRC there was a CA which couldn't/wouldn't disclose them.
> But the disclosed their CA policies and practice statements regarding
> the issuance of such intermediate CAs.
I think that they should be listed on this page or the CAs should be
revoked:
http://www.mozilla.org/projects/security/certs/
What do you think?
Kathleen Wilson
future) externally operated sub-CA's, we request and verify the
information listed here:
https://wiki.mozilla.org/CA:SubordinateCA_checklist
Usually the CA provides the information about each externally-operated
sub-CA publicly. However, there is a small number of CAs who deem the
names of their externally-operated sub-CAs to be sensitive information.
Those CAs have provided the information requested in
CA:SubordinateCA_checklist, but have held back the names of their
sub-CAs from public disclosure.
If you have concern about a particular root certificate authority,
please see https://wiki.mozilla.org/CA:Root_Change_Process
Kathleen
Stephen Schultze
> When CAs request inclusion of a root that has (or may have in the
> future) externally operated sub-CA's, we request and verify the
> information listed here:https://wiki.mozilla.org/CA:SubordinateCA_checklist
Where is the output of process documented (can you give me a link to
an example?), and what page do I go to in order to see the list of
subordinate CAs for a given root?
> Usually the CA provides the information about each externally-operated
> sub-CA publicly. However, there is a small number of CAs who deem the
> names of their externally-operated sub-CAs to be sensitive information.
> Those CAs have provided the information requested in
> CA:SubordinateCA_checklist, but have held back the names of their
> sub-CAs from public disclosure.
What is an example of a legitimate reason that this would be
"sensitive information" that overrides the security benefit of the
subordinate CA being known? Why would Mozilla think that it would
benefit users to allow CAs to secretly delegate full root authority to
arbitrary third parties?
Where do I get the items listed in SubordinateCA_checklist for the
following Entrust certificate?
Certificate:
Data:
Version: 3 (0x2)
Serial Number: 1116185248 (0x4287a2a0)
Signature Algorithm: sha1WithRSAEncryption
Issuer: C=US, O=Entrust.net, OU=www.entrust.net/CPS incorp. by
ref. (limits liab.), OU=(c) 1999 Entrust.net Limited, CN=Entrust.net
Secure Server Certification Authority
Validity
Not Before: May 11 14:03:22 2007 GMT
Not After : Mar 1 05:00:00 2012 GMT
Subject: C=CN, O=CNNIC SSL, CN=CNNIC SSL
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
RSA Public Key: (2048 bit)
Modulus (2048 bit):
00:98:bf:ee:a3:0e:36:67:68:75:1a:8a:6f:94:0c:
64:cf:17:69:02:d7:cb:6e:84:8d:39:c1:6e:52:fe:
58:2d:72:3c:65:f1:4c:5c:98:4a:3a:c9:28:1d:e2:
50:a3:f5:22:78:fd:77:29:8d:7d:0a:83:d0:5d:29:
fd:a5:a1:e9:10:a5:1d:bf:cd:a0:0c:11:db:38:c8:
7f:cc:6b:4a:d5:4e:79:40:a2:7a:e0:f3:e6:5e:d3:
54:a6:7f:6a:49:56:fd:47:08:cc:89:a3:f5:28:d1:
ce:2c:73:27:44:1d:77:b2:f4:49:6d:75:5a:0c:d4:
77:f2:04:a8:71:f2:d8:31:ea:de:a2:42:de:a5:27:
7e:45:8b:9a:63:e5:13:b4:14:27:87:20:eb:69:05:
c1:9d:af:ce:71:db:f6:d9:70:18:43:dd:da:29:38:
88:00:81:50:bf:17:d7:bc:78:05:5f:ff:0d:e3:a5:
d7:3e:f9:0e:90:cc:2e:39:94:4e:2f:ef:c2:6b:1c:
ff:52:a8:f4:49:70:ad:f9:23:17:82:fb:5d:8f:e1:
6d:0f:cd:fe:a9:a1:30:c9:fc:38:18:88:c1:b4:c8:
d7:8a:11:4b:ff:1e:89:4a:93:7b:42:f4:2b:0a:c2:
f9:8a:3d:e8:70:53:05:13:9b:01:95:a0:57:f5:f4:
67:19
Exponent: 65537 (0x10001)
X509v3 extensions:
X509v3 Key Usage: critical
Certificate Sign, CRL Sign
X509v3 Basic Constraints: critical
CA:TRUE, pathlen:0
Authority Information Access:
OCSP - URI:http://ocsp.entrust.net
X509v3 CRL Distribution Points:
URI:http://crl.entrust.net/server1.crl
X509v3 Certificate Policies:
Policy: 2.5.29.32.0
X509v3 Extended Key Usage:
TLS Web Server Authentication, TLS Web Client
Authentication
X509v3 Authority Key Identifier:
keyid:F0:17:62:13:55:3D:B3:FF:0A:00:6B:FB:
50:84:97:F3:ED:62:D0:1A
X509v3 Subject Key Identifier:
4B:D5:E1:51:16:A2:A7:ED:A3:A5:C7:E0:FF:B1:87:18:0E:C0:E3:D5
1.2.840.113533.7.65.0:
0
..V7.1....
Signature Algorithm: sha1WithRSAEncryption
44:f1:67:75:61:20:a1:39:52:aa:fe:79:a8:97:8b:d2:d4:11:
65:89:ac:9e:74:90:62:4d:6f:44:7d:ec:82:b5:f3:ef:09:bf:
66:46:3a:53:db:e9:38:3f:6c:bd:c4:94:85:38:1e:d9:f4:5b:
2f:72:33:30:a9:45:9d:7f:da:83:31:6a:a6:e1:05:dd:77:19:
73:b4:3b:59:e8:f6:62:4a:f6:77:1f:e9:97:89:66:bf:98:22:
cb:98:58:68:4c:49:41:fd:76:18:e1:aa:a0:fe:c9:b1:59:a5:
49:cc:77:1b:70:fd:04:0f:93:de:0b:14:22:16:98:1b:1d:e4:
55:8a
-----BEGIN CERTIFICATE-----
MIIEFzCCA4CgAwIBAgIEQoeioDANBgkqhkiG9w0BAQUFADCBwzELMAkGA1UEBhMC
VVMxFDASBgNVBAoTC0VudHJ1c3QubmV0MTswOQYDVQQLEzJ3d3cuZW50cnVzdC5u
ZXQvQ1BTIGluY29ycC4gYnkgcmVmLiAobGltaXRzIGxpYWIuKTElMCMGA1UECxMc
KGMpIDE5OTkgRW50cnVzdC5uZXQgTGltaXRlZDE6MDgGA1UEAxMxRW50cnVzdC5u
ZXQgU2VjdXJlIFNlcnZlciBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw0wNzA1
MTExNDAzMjJaFw0xMjAzMDEwNTAwMDBaMDUxCzAJBgNVBAYTAkNOMRIwEAYDVQQK
EwlDTk5JQyBTU0wxEjAQBgNVBAMTCUNOTklDIFNTTDCCASIwDQYJKoZIhvcNAQEB
BQADggEPADCCAQoCggEBAJi/7qMONmdodRqKb5QMZM8XaQLXy26EjTnBblL+WC1y
PGXxTFyYSjrJKB3iUKP1Inj9dymNfQqD0F0p/aWh6RClHb/NoAwR2zjIf8xrStVO
eUCieuDz5l7TVKZ/aklW/UcIzImj9SjRzixzJ0Qdd7L0SW11WgzUd/IEqHHy2DHq
3qJC3qUnfkWLmmPlE7QUJ4cg62kFwZ2vznHb9tlwGEPd2ik4iACBUL8X17x4BV//
DeOl1z75DpDMLjmUTi/vwmsc/1Ko9ElwrfkjF4L7XY/hbQ/N/qmhMMn8OBiIwbTI
14oRS/8eiUqTe0L0KwrC+Yo96HBTBRObAZWgV/X0ZxkCAwEAAaOCAR8wggEbMA4G
A1UdDwEB/wQEAwIBBjASBgNVHRMBAf8ECDAGAQH/AgEAMDMGCCsGAQUFBwEBBCcw
JTAjBggrBgEFBQcwAYYXaHR0cDovL29jc3AuZW50cnVzdC5uZXQwMwYDVR0fBCww
KjAooCagJIYiaHR0cDovL2NybC5lbnRydXN0Lm5ldC9zZXJ2ZXIxLmNybDARBgNV
HSAECjAIMAYGBFUdIAAwHQYDVR0lBBYwFAYIKwYBBQUHAwEGCCsGAQUFBwMCMB8G
A1UdIwQYMBaAFPAXYhNVPbP/CgBr+1CEl/PtYtAaMB0GA1UdDgQWBBRL1eFRFqKn
7aOlx+D/sYcYDsDj1TAZBgkqhkiG9n0HQQAEDDAKGwRWNy4xAwIAgTANBgkqhkiG
9w0BAQUFAAOBgQBE8Wd1YSChOVKq/nmol4vS1BFliayedJBiTW9EfeyCtfPvCb9m
RjpT2+k4P2y9xJSFOB7Z9FsvcjMwqUWdf9qDMWqm4QXddxlztDtZ6PZiSvZ3H+mX
iWa/mCLLmFhoTElB/XYY4aqg/smxWaVJzHcbcP0ED5PeCxQiFpgbHeRVig==
-----END CERTIFICATE-----
Kathleen Wilson
> an example?),
It's added to the bug of the root inclusion request. I started creating
the subCA review documents in 2009, so it's a relatively new process,
meaning that roots that were approved before then would not have this
specific type of documentation about the sub-CAs.
For an example see https://bugzilla.mozilla.org/show_bug.cgi?id=438825
Attachment called "Completed subCA Review Document".
> and what page do I go to in order to see the list of
> subordinate CAs for a given root?
There's currently no easy way (that I know of) to get a list of all of
the roots who have externally-operated sub-CAs, and what those sub-CAs are.
> What is an example of a legitimate reason that this would be
> "sensitive information" that overrides the security benefit of the
> subordinate CA being known? Why would Mozilla think that it would
> benefit users to allow CAs to secretly delegate full root authority to
> arbitrary third parties?
If Mozilla accepts and includes the �abc� root, then we have to assume
that we also accept any of their future sub-CAs and their sub-CAs.
Therefore, the selection criteria for their sub-CAs and their sub-CAs
will be a critical decision factor in the initial root inclusion. We ask
CAs who issue or may issue externally operated sub-CAs to point us to
the parts of the CP that clearly explain who can apply to operate a
sub-CA (at any level), the selection/approval process for sub-CAs and
their sub-CAs, the verification procedures applied to sub-CAs and their
sub-CAs, what restrictions (legal and technical) are placed on all
sub-CAs (eg constraints to issuing certs within certain domains).
> Where do I get the items listed in SubordinateCA_checklist for the
> following Entrust certificate?
The root in your question was approved before CA:SubordinateCA_checklist
was created. Back then the process for reviewing the sub-CAs didn't
include the same level of documentation. We don't usually go back and
retroactively apply root inclusion process changes to roots. The
exception being that we have started to require regularly updated audit
documents for all included root certificate authorities.
A complete list of all of the included root certificate authorities and
their corresponding audits can be found via the "List of all included
root certificates" link on http://www.mozilla.org/projects/security/certs/.
Mozilla has regular communication with the CA owning the root
certificate in your question. There is no indication that this CA has
not followed their documented and audited procedures for approving and
issuing sub-CAs. There is no indication that this CA is not following
the Mozilla CA Certificate Policy.
Stephen Schultze
On Feb 23, 3:48 pm, Kathleen Wilson <kathleen95...@yahoo.com> wrote:
> If Mozilla accepts and includes the abc root, then we have to assume
> that we also accept any of their future sub-CAs and their sub-CAs.
> Therefore, the selection criteria for their sub-CAs and their sub-CAs
> will be a critical decision factor in the initial root inclusion. We ask
> CAs who issue or may issue externally operated sub-CAs to point us to
> the parts of the CP that clearly explain who can apply to operate a
> sub-CA (at any level), the selection/approval process for sub-CAs and
> their sub-CAs, the verification procedures applied to sub-CAs and their
> sub-CAs, what restrictions (legal and technical) are placed on all
> sub-CAs (eg constraints to issuing certs within certain domains).
I see, but these requirements did not exist at the time of approval of
the Entrust cert in question? I ask because I can't find any
reference to these policies in their CP. They have a Subordinate CA
cert profile, but no explanation of the policy around subordinate CAs.
Did these requirements exist at the time of the approval of the
Entrust EV cert?
> > Where do I get the items listed in SubordinateCA_checklist for the
> > following Entrust certificate?
>
> The root in your question was approved before CA:SubordinateCA_checklist
> was created. Back then the process for reviewing the sub-CAs didn't
> include the same level of documentation. We don't usually go back and
> retroactively apply root inclusion process changes to roots. The
> exception being that we have started to require regularly updated audit
> documents for all included root certificate authorities.
>
> A complete list of all of the included root certificate authorities and
> their corresponding audits can be found via the "List of all included
> root certificates" link onhttp://www.mozilla.org/projects/security/certs/.
That page lists the high level auditor assertions rather than any
detailed audit report, correct? Do you receive the contents of the
full reports or do you rely on the attestation document alone?
> Mozilla has regular communication with the CA owning the root
> certificate in your question. There is no indication that this CA has
> not followed their documented and audited procedures for approving and
> issuing sub-CAs. There is no indication that this CA is not following
> the Mozilla CA Certificate Policy.
What are their documented and audited procedures for approving and
issuing sub-CAs? Can you point me to such a document?
David E. Ross
When dealing with OpenPGP keys, public disclosure is vital for
establishing trust. As part of that public disclosure, the source code
of applications implementing the OpenPGP specification (RFC 4880) is
generally available for inspection. The Web of Trust involves complete
identification of the owner of a key to prove not only that he controls
the private part of the key but also to prove that he is indeed the
person he asserts to be.
I think that public disclosure is equally important for establishing
trust in X.509 root certificates (roots) and the certificate authorities
(CAs) that own them. Such disclosure should include audit reports, the
CP, and the CPS.
Where a root from a CA signs an intermediate certificate used by an
external CA to then sign subsidiary intermediate certificates or
subscriber certificates, that situation needs to be disclosed. That
disclosure should include documentation of what requirements are imposed
by the CA owning the root upon the operations of external CAs. Further,
the PUBLIC audit report for the CA owning the root must somehow indicate
how and when the operations of the external CAs have been reviewed for
compliance with those documented requirements.
With appropriate advance notice, I think all this should be imposed
retroactively on CAs whose roots are already in Mozilla's NSS database.
After all, the control exerted by root CAs over their external CAs is
an ongoing point of concern when reviewing new requests for installing
root certificates. I think fairness requires that Mozilla impose on the
CAs of already-installed roots the same scrutiny that Mozilla imposes on
new CAs. If Mozilla can retroactively impose an audit requirement on
the CAs of already-installed roots, I don't see why this cannot be done.
--
David E. Ross
<http://www.rossde.com/>.
Anyone who thinks government owns a monopoly on inefficient, obstructive
bureaucracy has obviously never worked for a large corporation. � 1997
Eddy Nigg
Just would like to voice my support for everything you said here. Very
much agreed!
Jean-Marc Desperrier
> It's added to the bug of the root inclusion request. I started creating
> the subCA review documents in 2009, so it's a relatively new process,
> meaning that roots that were approved before then would not have this
> specific type of documentation about the sub-CAs.
>
> For an example see https://bugzilla.mozilla.org/show_bug.cgi?id=438825
> Attachment called "Completed subCA Review Document".
Kathleen, first thank you for starting this very useful process.
This being said :
- I believe that having this information disseminated in many root
inclusion request bugs is not a good choice.
I think there should be a companion page to
https://wiki.mozilla.org/CA:SubordinateCA_checklist that list the
currect published external sub-CA list for all root CA inside Mozilla.
- I believe there should be a rule that explicitly says external sub-CA
can not themselves have external sub-CA. Maybe it's already there.
- I believe we need a rule that described how the O and OU fields of the
intermediate CA certificate MUST reflect the change of affiliation, so
that it can be identified by an automated process
Jean-Marc Desperrier
> I think there should be a companion page to
> https://wiki.mozilla.org/CA:SubordinateCA_checklist that list the
> currect published external sub-CA list for all root CA inside Mozilla.
Forgot two points :
- having this in a separate page from the bug helps making it more
self-understanding that it must be keep up-to-date, and is *not* a
one-off operation
- the name of externally-operated sub-CAs is, by essence, a public
information (or do they *not* include that inside the certificate ??)
We have seen some proof that some CA operators have bots that crawls the
web to get the certificates of existing SSL sites.
Stephen Schultze
but I thought I'd summarize my understanding so people can correct me
if I'm wrong. To start, I think that the new CA Subordinate Checklist
is a good thing (and it looks like a lot of work). Here is my
understanding of the current status:
- Third-party subordinate CAs can sign certs for any domain -- name
constraints or other constraints are not implemented in NSS
- The audit documents that are typically publicly posted (Web of
Trust, etc.) are very high level assertions rather than full reports
(and they don't typically mention Subordinate CAs at all)
- The new Subordinate CA disclosure requirements apply only to new
roots, meaning that existing roots granted up until December 2008 were
not subject to the requirements and therefore don't have any
documentation on subordinate CAs.
- Any disclosed Subordinate CAs are listed in documents attached to
the root CA request, but are not listed in any centralized human-
readable or machine-readable document
- Root CAs added after December 2008 may have subsequently added third-
party subordinates that are not documented, unless those roots have
been re-audited since then (but the re-audit process/frequency does
not appear to be documented)
- There is no process for retroactively performing the full new
approval process
- Most root CAs included in NSS today have provided no documented and
audited procedures for approving and issuing sub-CAs
- Even with the new Subordinate CA procedure, root CA applicants can
refuse to disclose subordinate CAs if they consider that to be
"sensitive information"
- When a site presents a Subordinate CA with along with a chain up to
a trusted CA, the Mozilla client silently accepts the sub-CA and
caches it in the cert store
- If the user changes the trust bits on the cached cert (for example
to remove all privileges), those changes have no effect because all
trust bits default back to the root
For what it's worth, I'm increasingly convinced that the CA model is
fundamentally flawed.
On Feb 23, 5:03 pm, Stephen Schultze <sjschultze.use...@gmail.com>
wrote:
Eddy Nigg
> - If the user changes the trust bits on the cached cert (for example
> to remove all privileges), those changes have no effect because all
> trust bits default back to the root
>
The last one is not correct. If you remove the trust bit from a
particular intermediate CA certificate, the certificates issued from
that issuer will be untrusted. Unfortunately that happens when somebody
clicks on an intermediate CA inadvertently and doesn't edit (approve)
the trust flags. Very annoying.
> For what it's worth, I'm increasingly convinced that the CA model is
> fundamentally flawed.
>
Doesn't have to be. Just look at some CAs which do have requirements
such as a full audit on externally handled intermediate CAs or all
issuers are under the control of the parent CA. Additionally, this is
more or less what EV requires, making EV really the model to follow in
many respects.
Including most - if not all - problematic practices are simply
prohibited with EV. It's unfortunate the the important, basic
requirements don't apply for all SSL certificates.
David E. Ross
I believe that the certificate authorities for the roots added before
2009 are on notice that periodic audit reports are to be provided to the
Mozilla organization. If so, it then becomes the responsibility of the
reviewers of those reports to see if external sub-CAs are cited.
Since this is likely to become a form of renewal of the approvals of
those old CAs, such reviews provide the opportunity to question how
external sub-CAs are themselves audited or at least reviewed and what
policies they must follow.
If a legacy CA stonewalls such questioning, it would be most appropriate
to (1) removed that CA's root and (2) make a public statement as to why
the root has been removed.
aero...@gmail.com
I hate chiming in with "me too!", but I have to agree as well.
-Kyle H
Stephen Schultze
> On 03/02/2010 04:51 AM, Stephen Schultze:
> > fundamentally flawed.
>
> Doesn't have to be. Just look at some CAs which do have requirements
> such as a full audit on externally handled intermediate CAs or all
> issuers are under the control of the parent CA. Additionally, this is
> more or less what EV requires, making EV really the model to follow in
> many respects.
Yes, but when it comes to non-EV certs it doesn't matter if many (or
even most) CAs follow better practices. An attacker can just pick the
CA with the lowest standards because that CA has the same authority as
all the rest.
> Including most - if not all - problematic practices are simply
> prohibited with EV. It's unfortunate the the important, basic
> requirements don't apply for all SSL certificates.
Interesting. Where in EV/CAB standards does it address these Sub-CA
issues? I have read some of the documentation, but I am less familiar
with it.
Stephen Schultze
> I believe that the certificate authorities for the roots added before
> 2009 are on notice that periodic audit reports are to be provided to the
> Mozilla organization. If so, it then becomes the responsibility of the
> reviewers of those reports to see if external sub-CAs are cited.
>
> Since this is likely to become a form of renewal of the approvals of
> those old CAs, such reviews provide the opportunity to question how
> external sub-CAs are themselves audited or at least reviewed and what
> policies they must follow.
This seems like a good idea. Is it documented anywhere?
> If a legacy CA stonewalls such questioning, it would be most appropriate
> to (1) removed that CA's root and (2) make a public statement as to why
> the root has been removed.
This also seems like a good idea. My casual browsing of
mozilla.dev.security.policy and mozilla.dev.tech.crypto doesn't
indicate a high level of willingness on the part of Mozilla to remove
root certs (even in the case of demonstrated subpar sub-CA
practices... eg. Comodo) so as an outsider I am not terribly
optimistic.
Stephen Schultze
> On 03/02/2010 04:51 AM, Stephen Schultze:
> > - If the user changes the trust bits on the cached cert (for example
> > to remove all privileges), those changes have no effect because all
> > trust bits default back to the root
>
> The last one is not correct. If you remove the trust bit from a
> particular intermediate CA certificate, the certificates issued from
> that issuer will be untrusted. Unfortunately that happens when somebody
> clicks on an intermediate CA inadvertently and doesn't edit (approve)
> the trust flags. Very annoying.
What you describe seems to indicate that this has changed:
https://bugzilla.mozilla.org/show_bug.cgi?id=470897#c11
"Presently, there is no combination of trust flag settings that can be
set
through PSM to cause a subordinate CA cert to be actively distrusted
when
that cert is issued by a superior CA that is trusted. IOW, there's
no
"Distrust this cert, regardless of its issuer" trust flag now usable
in
Mozilla products. (There is one partially implemented in NSS, but it
is
not presently usable, and even if it was, there's no UI for it in
PSM.)"
Is this confirmed?
Kathleen Wilson
> Where a root from a CA signs an intermediate certificate used by an
> external CA to then sign subsidiary intermediate certificates or
> subscriber certificates, that situation needs to be disclosed. That
> disclosure should include documentation of what requirements are imposed
> by the CA owning the root upon the operations of external CAs. Further,
> the PUBLIC audit report for the CA owning the root must somehow indicate
> how and when the operations of the external CAs have been reviewed for
> compliance with those documented requirements.
I've added this text to the Potentially Problematic Practices wiki page:
https://wiki.mozilla.org/CA:Problematic_Practices#Allowing_external_entities_to_operate_subordinate_CAs
Kathleen
David E. Ross
Looks good.
Can you raise this issue with "legacy" CAs when your require new audit
reports from them?
Nelson Bolyard
> On Mar 1, 10:03 pm, Eddy Nigg <eddy_n...@startcom.org> wrote:
>> On 03/02/2010 04:51 AM, Stephen Schultze:
>>> - If the user changes the trust bits on the cached cert (for example
>>> to remove all privileges), those changes have no effect because all
>>> trust bits default back to the root
>> The last one is not correct. If you remove the trust bit from a
>> particular intermediate CA certificate, the certificates issued from
>> that issuer will be untrusted. Unfortunately that happens when
>> somebody clicks on an intermediate CA inadvertently and doesn't edit
>> (approve) the trust flags. Very annoying.
I'm not sure what Eddy was trying to say there, but I don't believe that
removing trust bits from an intermediate CA cert disables its subordinate
certs if that intermediate was issued by a trusted superior.
> What you describe seems to indicate that this has changed:
> https://bugzilla.mozilla.org/show_bug.cgi?id=470897#c11
>
> "Presently, there is no combination of trust flag settings that can be
> set through PSM to cause a subordinate CA cert to be actively distrusted
> when that cert is issued by a superior CA that is trusted. IOW, there's
> no "Distrust this cert, regardless of its issuer" trust flag now usable
> in Mozilla products. (There is one partially implemented in NSS, but it
> is not presently usable, and even if it was, there's no UI for it in
> PSM.)"
>
> Is this confirmed?
I wrote that bug comment. It is still true.
Nelson Bolyard
> I'm not sure if there's more that's going to be posted on this thread,
> but I thought I'd summarize my understanding so people can correct me
> if I'm wrong. To start, I think that the new CA Subordinate Checklist
> is a good thing (and it looks like a lot of work). Here is my
> understanding of the current status:
>
> - Third-party subordinate CAs can sign certs for any domain
True for SSL server certs,
- name constraints or other constraints are not implemented in NSS
False. NSS implements name constraints exactly according to RFC 3280.
The problem is that browsers continue to recognize and accept DNS names
in non-standard places, places where the standards do not allow DNS names
to be placed, and therefore are places where the DNS name constraints do
not apply.
RFC 3280 does not recognize the use of certificate Subject Common Name
attributes as holders of domain names, and the specification for name
constraints does not apply them to domain names found in subject common
names. Subject Common Names were intended to hold spoken names of people
and businesses, not DNS names. If we apply name constraints to all subject
common names, certs with people's or business's names in the subject common
names will all fail. If there was an algorithm that could 100% reliably
tell the difference between a string that is a DNS name and a string that is
NOT a DNS name, then we could apply name constraints to DNS names in common
names, and not apply name constraints to common names that are not DNS
names. But there is no algorithm that can tell the difference sufficiently
well. Consider: if "www" is a DNS name, then is "stephen"?
As long as browsers continue to honor DNS names found in Subject Common
Names, rather than in the standard place where they belong (Subject Alt
Names), name constraints will remain ineffective.
This is a browser fault, not a PKI fault not an NSS fault. Products that
use NSS and only recognize DNS names from the places where the standards
allow DNS names to be placed find that DNS names are fully constrained.
> - Most root CAs included in NSS today have provided no documented and
> audited procedures for approving and issuing sub-CAs
I'd say: Some. I don't think it's "most". I don't have numbers though.
> - When a site presents a Subordinate CA with along with a chain up to
> a trusted CA, the Mozilla client silently accepts the sub-CA and
> caches it in the cert store
Correct. They're cached without any trust bits. Any trust they have is
transitive, inherited from their trusted superior (if any).
> - If the user changes the trust bits on the cached cert (for example
> to remove all privileges), those changes have no effect because all
> trust bits default back to the root
The intermediate CA cert wouldn't likely have any trust bits in the first
place. The only reason I've ever seen for users to add trust bits to
intermediate CA certs is because they've chosen to distrust a root, but they
want to continue to trust some of that root's subordinates.
Now, if the root is distrusted, and you have been directly trusting a
subordinate CA, but then you decide to remove trust from the subordinate,
that will indeed cause trust to stop for the subtree anchored by that
subordinate (barring any subordinates of that subordinate that you have
directly trusted).
Eddy Nigg
>>> The last one is not correct. If you remove the trust bit from a
>>> particular intermediate CA certificate, the certificates issued from
>>> that issuer will be untrusted. Unfortunately that happens when
>>> somebody clicks on an intermediate CA inadvertently and doesn't edit
>>> (approve) the trust flags. Very annoying.
>>>
> I'm not sure what Eddy was trying to say there, but I don't believe that
> removing trust bits from an intermediate CA cert disables its subordinate
> certs if that intermediate was issued by a trusted superior.
>
Well, actually here is this weird thing when having imported CA
certificates to an eToken, by default only the web site trust bit is on.
When manually editing the trust flags, it works for the session, but the
default is back next time one inserts the token.
Obviously it's not possible to sign an email when the email trust bit is
off, which led me to believe that the intermediate CA does have some
capability (or not)?
Eddy Nigg
> True for SSL server certs,
>
> - name constraints or other constraints are not implemented in NSS
>
> False. NSS implements name constraints exactly according to RFC 3280.
> The problem is that browsers continue to recognize and accept DNS names
> in non-standard places, places where the standards do not allow DNS names
> to be placed, and therefore are places where the DNS name constraints do
> not apply.
>
So isn't it about time to implement RFC 3280 finally? I mean, NSS is
consumed mostly by Mozilla applications and not some weird devices which
still only recognize the CN field? What would the damage be in case NSS
will only look at the SAN extension from now on?
Kathleen Wilson
>
> Can you raise this issue with "legacy" CAs when your require new audit
> reports from them?
>
I've added it to my list of things to look into.
M.Hunstock
> What would the damage be in case NSS
> will only look at the SAN extension from now on?
I guess the damage would be that NSS would not recognize the millions of
"broken" certificates out there anymore.. Ever tried to include subject
alt names when generating a CSR with openssl in a shell? ;)
greetz
Gervase Markham
> RFC 3280 does not recognize the use of certificate Subject Common Name
> attributes as holders of domain names, and the specification for name
> constraints does not apply them to domain names found in subject common
> names. Subject Common Names were intended to hold spoken names of people
> and businesses, not DNS names.
Hypothetically: If the Mozilla CA policy were to mandate that certs had
to be issued using the right slot (i.e. SAN, not Common Name), what
would happen? Would all the CAs complain because there is software out
there which _only_ looks in the Common Name slot for the DNS name?
Gerv
Nelson Bolyard
It would be appropriate for Mozilla CA policy to mandate that CAs put
all DNS names for a cert into SANs. It would not be necessary to go
beyond that and disallow CAs to ALSO ADDITIONALLY put one DNS name in
the subject common name for the benefit of VERY old (more than 12 year
old) browsers that don't recognize SANs. It is only necessary to make
it clear that ALL the DNS names (not all but one) must go into the SAN.
Some CAs mistakenly believe that one primary DNS name should go into the
Subject Common Name and all the others into the SAN. That's wrong. ALL
should go into the SAN.
Then, modern browsers should stop paying attention to Subject common names.
Doesn't matter what CAs put there as long as browsers don't look there.
Moudrick M. Dadashov
M.D.
cell: +370-699-26662
Nelson Bolyard wrote:
It would be appropriate for Mozilla CA policy to mandate that CAs put all DNS names for a cert into SANs. It would not be necessary to go beyond that and disallow CAs to ALSO ADDITIONALLY put one DNS name in the subject common name for the benefit of VERY old (more than 12 year old) browsers that don't recognize SANs. It is only necessary to make it clear that ALL the DNS names (not all but one) must go into the SAN. Some CAs mistakenly believe that one primary DNS name should go into the Subject Common Name and all the others into the SAN. That's wrong. ALL should go into the SAN. Then, modern browsers should stop paying attention to Subject common names. Doesn't matter what CAs put there as long as browsers don't look there. _______________________________________________ dev-security-policy mailing list dev-secur...@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Eddy Nigg
I support Nelson's proposal. However there is another issue when some businesses register the names as domain names e.g. mycompany.com. Obviously mycompany.com in the Subject will be confusing anyway.
Kurt Seifried
> businesses register the names as domain names e.g. mycompany.com. Obviously
> mycompany.com in the Subject will be confusing anyway.
>
> How about a special stipulation for such cases, like introducing a space
> after dots? So it would become "mycompany. com"?
I checked the RFC's and sadly they don't say much of anything concrete
here. Shouldn't the common name be the legal trade name/incorporated
name/etc. that is being used by the company? If a company calls itself
"foo.com" then that is the name that should be in the name field. No
"foo[space].com" (which is not their legal name). If you start making
exceptions then how can we rely on the subject name actually being the
subject name?
-Kurt
Gervase Markham
> It would be appropriate for Mozilla CA policy to mandate that CAs put
> all DNS names for a cert into SANs. It would not be necessary to go
> beyond that and disallow CAs to ALSO ADDITIONALLY put one DNS name in
> the subject common name for the benefit of VERY old (more than 12 year
> old) browsers that don't recognize SANs. It is only necessary to make
> it clear that ALL the DNS names (not all but one) must go into the SAN.
And we don't know of any software which would break if it saw the same
name in two places?
> Some CAs mistakenly believe that one primary DNS name should go into the
> Subject Common Name and all the others into the SAN. That's wrong. ALL
> should go into the SAN.
This sounds like something for a Best Practices document...
Gerv
Eddy Nigg
> And we don't know of any software which would break if it saw the same
> name in two places?
>
Why should that break. Just find a StartCom issued certificate somewhere
and check it out.
Nelson B
> On 08/03/10 13:02, Nelson Bolyard wrote:
>> It would be appropriate for Mozilla CA policy to mandate that CAs put
>> all DNS names for a cert into SANs. It would not be necessary to go
>> beyond that and disallow CAs to ALSO ADDITIONALLY put one DNS name in
>> the subject common name for the benefit of VERY old (more than 12 year
>> old) browsers that don't recognize SANs. It is only necessary to make
>> it clear that ALL the DNS names (not all but one) must go into the SAN.
>
> And we don't know of any software which would break if it saw the same
> name in two places?
That's correct. We do not know of any such software.
Gervase Markham
> That's correct. We do not know of any such software.
My next step was going to be to write up a message to the CABForum
asking for this to be added to the in-development baseline document. But
actually, Nelson, you are probably much less likely to make a gaffe than
I am when writing. Would you have a moment to do that?
Gerv
Jean-Marc Desperrier
> [...] NSS implements name constraints exactly according to RFC 3280.
> [...] RFC 3280 does not recognize the use of certificate Subject Common Name
> attributes as holders of domain names, and the specification for name
> constraints does not apply them to domain names found in subject common
> names.
> common names, certs with people's or business's names in the subject common
> names will all fail.
Is it not possible to apply it only when verifying a cert as a SSL
server cert ?
You'd just have in the verification function a flag to apply the name
constraint to the CN, and set the code so that when it calls the
function in the context of verifying a SSL cert, the flag is set.
In fact the verification function should already have the knowledge of
whether or not it's verifying a SSL cert, since it also has to verify if
the whole chain is authorized for SSL or not.
Matt McCutchen
This is more or less the approach being pursued at:
https://bugzilla.mozilla.org/show_bug.cgi?id=394919
--
Matt
Matt McCutchen
wrote:
> Then, modern browsers should stop paying attention to Subject common names.
The bug for that is:
https://bugzilla.mozilla.org/show_bug.cgi?id=552346
--
Matt
Varga Viktor
Regardin these two, i would like to ask:
1) Was there any policy change about the intermediate certs, follwoign the results of this thread?
2) Wants the Firefox an end date for the "DNS in CN"? (if it is declared with enough time, maybe moves forward the market)
Üdvözlettel/Regards,
Varga Viktor
Üzemeltetési és Vevőszolgálati Vezető
IT Service and Customers Service Executive
Netlock Kft.
> _______________________________________________
> dev-security-policy mailing list
> dev-secur...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy
>
> _______________________________________________________________________
> Ezt az e-mailt virus- es SPAM-szuresnek vetettuk ala a filter:mail MessageLabs
> rendszerrel. Tovabbi informacio: http://www.filtermax.hu
>
> This email has been scanned for viruses and SPAM by the filter:mail
> MessageLabs System. More information: http://www.filtermax.hu
> ________________________________________________________________________
_______________________________________________________________________
Ezt az e-mailt virus- es SPAM-szuresnek vetettuk ala a filter:mail MessageLabs rendszerrel. Tovabbi informacio: http://www.filtermax.hu
This email has been scanned for viruses and SPAM by the filter:mail MessageLabs System. More information: http://www.filtermax.hu ________________________________________________________________________________________
Kathleen Wilson
> As I see, the original subject is far from the topic.
>
> Regardin these two, i would like to ask:
>
> 1) Was there any policy change about the intermediate certs, follwoign the results of this thread?
There has been discussion about this within Mozilla. We believe there is
the need for a multi-faceted approach, which will take time to address.
The facets include, but may not be limited to:
-- Require certain things be documented in the CP/CPS - our focus is on
policies and enforcement/auditing, not on publicly disclosing customer names
-- Possible standards discussions -- in regards to DNS names in SANs and CN
-- Possible code changes -- e.g. enforcement of certain restrictions for
sub-CAs.
-- Possible changes to Mozilla CA policy -- e.g. all DNS names in SAN,
and possibly other restrictions for sub-CAs.
>
> 2) Wants the Firefox an end date for the "DNS in CN"? (if it is declared with enough time, maybe moves forward the market)
>
Possibly.
Mozilla is still taking this discussion under consideration, and plans
to follow-up on it. Further information and discussion will be forthcoming.
Kathleen
PS: I still intend to update the wiki page
(https://wiki.mozilla.org/CA:SubordinateCA_checklist) in regards to the
terminology that Frank clarified in the discussion called "Terminology
and policy in relation to subordinate CAs". However, that is not
intended as the final solution. As mentioned above, there will be future
follow-up and discussion.
David E. Ross
> There has been discussion about this within Mozilla. We believe there is
> the need for a multi-faceted approach, which will take time to address.
> The facets include, but may not be limited to:
>
> -- Require certain things be documented in the CP/CPS - our focus is on
> policies and enforcement/auditing, not on publicly disclosing customer names
>
> -- Possible standards discussions -- in regards to DNS names in SANs and CN
>
> -- Possible code changes -- e.g. enforcement of certain restrictions for
> sub-CAs.
>
> -- Possible changes to Mozilla CA policy -- e.g. all DNS names in SAN,
> and possibly other restrictions for sub-CAs.
When a change to the policy is drafted, please post a message here with
the bug number.
Varga Viktor
> > policies and enforcement/auditing, not on publicly disclosing customer names
> >
> > -- Possible standards discussions -- in regards to DNS names in SANs and CN
> >
> > -- Possible code changes -- e.g. enforcement of certain restrictions for
> > sub-CAs.
> >
> > -- Possible changes to Mozilla CA policy -- e.g. all DNS names in SAN,
> > and possibly other restrictions for sub-CAs.
>
> the bug number.
>
An maybe a wiki update on the main CA wiki page too. :) Monitored. :)
Üdvözlettel/Regards,
Varga Viktor
Üzemeltetési és Vevőszolgálati Vezető
IT Service and Customers Service Executive
Netlock Kft.
_______________________________________________________________________