416842 - Add Cisco Root CA Cert

Status: RESOLVED WONTFIX

(CA Program :: CA Certificate Root Program, task)

Description

[Jamison Budacki]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.12) Gecko/20080201 Firefox/2.0.0.12
Build Identifier: 

TABLE OF CONTENTS:
1.	INTRODUCTION		
2.	CORPORATE ADDRESS INFORMATION:	
3.	CORPORATE WEB SITE:	
4.	NUMBER OF ROOTS SUBMITTED:	
5.	WHO ARE THE TARGETED USERS FOR CERTIFICATES SIGNED BY THIS ROOT CERTIFICATE?	
6.	WHAT IS THE BUSINESS PURPOSE OF CERTIFICATES ISSUED BY THIS ROOT CA?  WHAT BUSINESS IS THIS ROOT ENABLING?:	
7.	WHAT IS DONE TO VALIDATE THE IDENTITY OF SOMEONE REQUESTING A CERTIFICATE ISSUED FROM THIS ROOT?	
8.	POINTERS TO CERTIFICATE PRACTICE STATEMENT:	
9.	WHICH THIRD PARTY AUDITS HAS YOUR CA PRACTICE HAS UNDERGONE.	
10.	ENGAGE A LICENSED AUDITOR OF THE WEBTRUST FOR CAS PROGRAM AND COMPLETE THAT PROCESS.	
11.	AUDIT REPORT	
12.	FURTHER INFORMATION ABOUT THE ROOT CERTIFICATE	
12.1	ROOT CERTIFICATE	
12.2	ROOT CERTIFICATE SUBJECT NAME	
12.3	VALIDITY DATES	
12.4	SHA-1 THUMBPRINT	
12.5	DESIRED EXTENDED KEY USAGE (EKU)	
12.6	CERTIFICATE ISSUED FROM THE ROOT FOR CHAIN VALIDATION	
13.	CONCLUSION	


 

1.	Introduction

This document outlines the information for inclusion of the Cisco Root CA 2048, CRCA, within the certificate store for Mozilla.

 
2.	Corporate Address Information:

Cisco Systems, Inc.
170 West Tasman Dr.
San Jose, CA 95134
USA

3.	Corporate Web Site:
 
http://www.cisco.com
 
 
4.	Number of Roots submitted:

	Cisco is submitting one root certificate authority: Cisco Root CA 2048 (CRCA2048).  Cisco currently does not foresee any future submission of additional Root CAs but does not want to rule out the possibility of future submissions.

5.	Who are the targeted users for certificates signed by this root certificate?
 
The primary purpose of this request is to support the consumer and small and medium business (SMB) segments globally.  While enterprise customers can and will benefit from this request, the consumer and SMB markets do not always have the staff or knowledge to distribute the CRCA2048 root certificate through typical administration methodologies.
    
Consumer:  Currently Cisco holds a leading role in many consumer based products through its wholly owned subsidiaries Linksys and Scientific Atlanta.  The ability to authenticate devices and corresponding software through the use of a trust anchor within Mozilla browser will protect users from installing fraudulent equipment and/or software and allow for feature set enhancements to be made available to this market segment.
 
Small and Medium Business:  The same issues apply as in the consumer market.  Currently Cisco holds a leading networking equipment provider role in this market while the desktop is market is rapidly accepting the Mozilla browser.
 
Enterprise Customer: The same issues also apply here to enterprises that are not able to distribute root CA certificate to their Enterprise.  Enterprises that are able to utilize the Enterprise Trust method of root cert distribution will still benefit by having the Cisco Root CA pre-embedded because domain administrators would not be forced to create, test, and execute the needed changes. 

 
6.	What is the business purpose of certificates issued by this Root CA?  What business is this root enabling?:

Cisco is experiencing an extraordinary surge in the need to authenticate Cisco Systems' (and its wholly owned subsidiaries - Scientific Atlanta, Linksys, etc...) hardware and software for customer provisioning, feature set enhancement, and product authenticity.
Cisco, like Mozilla, recognizes that the benefits of implementing a strong PKI solution to perform these functions is critical to protecting its customer base from counterfeit or malicious products while also enabling more secure feature sets.

Cisco is aggressively working to PKI-enable its products, particularly those targeted at the Small to Medium business level and consumer markets. The ability to leverage a pre-embedded certificate within the Mozilla browser is crucial to providing assurances to users of both Mozilla and Cisco Systems. Embedding of the Cisco Root CA certificate into the Mozilla root store will result mutual benefits for our shared customers by providing more seamless security features and a smoother browsing experience when administering Cisco products.


7.	What is done to validate the identity of someone requesting a certificate issued from this root?
 
	Cisco Systems will ONLY issue certificates from CRCA2048 to Cisco-owned and managed subordinate Certificate Authorities.  The root and subordinate CAs will NEVER issue certificates to non-Cisco entities.  Subordinate CAs must meet internal support and security requirements that include the use of FIPS compliant Hardware Security Modules.  All identity verification of sub-CAs is performed by Cisco PKI administrators who witness the sub-CA key and CSR generation ceremony and hand-carry the CSR to the offline Root CA for signing.
 
8.	Pointers to Certificate Practice Statement:
 
 http://www.cisco.com/security/pki/policies/index.html
 
9.	Which third party audits has your CA practice has undergone.
 
CRCA 2048 has successfully completed 2 WebTrust audits conducted by Price Waterhouse Coopers LLC.  See section 12 for link.
 
 
10.	Engage a licensed auditor of the WebTrust for CAs program and complete that process.

Cisco Systems engaged Ernst & Young to assist in preparations for the initial WebTrust audit which was subsequently performed by PricewaterhouseCoopers.  Cisco Systems will maintain the WebTrust audit and will continue to provide successful attestations as required to keep the Root CA in compliance with the AICPA WebTrust for CAs criteria.  Cisco has successfully completed 2 WebTrust audits to date.  Cisco may request another AICPA approved WebTrust auditor to conduct current and future attestations as the company sees fit.


11.	Audit Report
   
Our latest publicly available WebTrust report can be found at the following link: https://cert.webtrust.org/ViewSeal?id=728.  

12.	Further information about the Root Certificate

12.1	Root Certificate
The Cisco Root CA 2048 certificate is publicly available at http://www.cisco.com/security/pki/certs/crca2048.cer

Here is the PEM encoded CRCA2048 certificate:

-----BEGIN CERTIFICATE-----
MIIDQzCCAiugAwIBAgIQX/h7KCtU3I1CoxW1aMmt/zANBgkqhkiG9w0BAQUFADA1
MRYwFAYDVQQKEw1DaXNjbyBTeXN0ZW1zMRswGQYDVQQDExJDaXNjbyBSb290IENB
IDIwNDgwHhcNMDQwNTE0MjAxNzEyWhcNMjkwNTE0MjAyNTQyWjA1MRYwFAYDVQQK
Ew1DaXNjbyBTeXN0ZW1zMRswGQYDVQQDExJDaXNjbyBSb290IENBIDIwNDgwggEg
MA0GCSqGSIb3DQEBAQUAA4IBDQAwggEIAoIBAQCwmrmrp68Kd6ficba0ZmKUeIhH
xmJVhEAyv8CrLqUccda8bnuoqrpu0hWISEWdovyD0My5jOAmaHBKeN8hF570YQXJ
FcjPFto1YYmUQ6iEqDGYeJu5Tm8sUxJszR2tKyS7McQr/4NEb7Y9JHcJ6r8qqB9q
VvYgDxFUl4F1pyXOWWqCZe+36ufijXWLbvLdT6ZeYpzPEApk0E5tzivMW/VgpSdH
jWn0f84bcN5wGyDWbs2mAag8EtKpP6BrXruOIIt6keO1aO6g58QBdKhTCytKmg9l
Eg6CTY5j/e/rmxrbU6YTYK/CfdfHbBcl1HP7R2RQgYCUTOG/rksc35LtLgXfAgED
o1EwTzALBgNVHQ8EBAMCAYYwDwYDVR0TAQH/BAUwAwEB/zAdBgNVHQ4EFgQUJ/PI
FR5umgIJFq0roIlgX9p7L6owEAYJKwYBBAGCNxUBBAMCAQAwDQYJKoZIhvcNAQEF
BQADggEBAJ2dhISjQal8dwy3U8pORFBi71R803UXHOjgxkhLtv5MOhmBVrBW7hmW
Yqpao2TB9k5UM8Z3/sUcuuVdJcr18JOagxEu5sv4dEX+5wW4q+ffy0vhN4TauYuX
cB7w4ovXsNgOnbFp1iqRe6lJT37mjpXYgyc81WhJDtSd9i7rp77rMKSsH0T8lasz
Bvt9YAretIpjsJyp8qS5UwGH0GikJ3+r/+n6yUA4iGe0OcaEb1fJU9u6ju7AQ7L4
CYNu/2bPPu8Xs1gYJQk0XuPL1hS27PKSb3TkL4Eq1ZKR4OCXPDJoBYVL0fdX4lId
kxpUnwVwwEpxYB5DC2Ae/qPOgRnhCzU=
-----END CERTIFICATE-----




12.2	 Root Certificate Subject Name
CN = Cisco Root CA 2048, O = Cisco Systems

12.3	Validity Dates
notValidBefore	: May 14, 2004 20:17:12 GMT
notValidAfter	: May 14, 2029 20:25:42 GMT

12.4	SHA-1 Thumbprint
de 99 0c ed 99 e0 43 1f 60 ed c3 93 7e 7c d5 bf 0e d9 e5 fa

12.5	Desired extended key usage (EKU)
Server Authentication
Client Authentication
Code Signing
Secure Email
Time Stamping
IP security end system
IP security tunnel termination
IP security user
Encrypting File System
Smart Card Logon
Digital Rights
IP Security IKE Intermediate

12.6	Certificate issued from the root for Chain validation
Cisco Manufacturing Sub-CA:

-----BEGIN CERTIFICATE-----
MIIE2TCCA8GgAwIBAgIKamlnswAAAAAAAzANBgkqhkiG9w0BAQUFADA1MRYwFAYD
VQQKEw1DaXNjbyBTeXN0ZW1zMRswGQYDVQQDExJDaXNjbyBSb290IENBIDIwNDgw
HhcNMDUwNjEwMjIxNjAxWhcNMjkwNTE0MjAyNTQyWjA5MRYwFAYDVQQKEw1DaXNj
byBTeXN0ZW1zMR8wHQYDVQQDExZDaXNjbyBNYW51ZmFjdHVyaW5nIENBMIIBIDAN
BgkqhkiG9w0BAQEFAAOCAQ0AMIIBCAKCAQEAoMX33JaUNRXx9JlOu5tB4X3beRaR
u/NU8kFKlDJiYskj95rnu5t56AcpTjD1rhvFIVZGsPj05o6BuBbMqJuF0kKB23zL
lKkRYRIcXOozIByaFqd925kGauI2r+z4Cv+YZwf0MO6l+IgaqujHPBzO7kj9zVw3
8YaTnj1xdX007ksUqcApewUQ74eeaTEw9Ug2P9irzhXi6FifPmJxBIcmpBViASWq
1d/JyVu4yaEHe75okpOTIKhsvRV100RdRUvsqNpgx9jI1cjtQeH1X1eOUzKTSdXZ
D/g2qgfEMkHFp68dGf/2c5k5WnNnYhM0DR9elXBSZBcG7FNcXNtq6jUAQQIBA6OC
AecwggHjMBIGA1UdEwEB/wQIMAYBAf8CAQAwHQYDVR0OBBYEFNDFIiarT0Zg7K4F
kcfcWtGwR/dsMAsGA1UdDwQEAwIBhjAQBgkrBgEEAYI3FQEEAwIBADAZBgkrBgEE
AYI3FAIEDB4KAFMAdQBiAEMAQTAfBgNVHSMEGDAWgBQn88gVHm6aAgkWrSugiWBf
2nsvqjBDBgNVHR8EPDA6MDigNqA0hjJodHRwOi8vd3d3LmNpc2NvLmNvbS9zZWN1
cml0eS9wa2kvY3JsL2NyY2EyMDQ4LmNybDBQBggrBgEFBQcBAQREMEIwQAYIKwYB
BQUHMAKGNGh0dHA6Ly93d3cuY2lzY28uY29tL3NlY3VyaXR5L3BraS9jZXJ0cy9j
cmNhMjA0OC5jZXIwXAYDVR0gBFUwUzBRBgorBgEEAQkVAQIAMEMwQQYIKwYBBQUH
AgEWNWh0dHA6Ly93d3cuY2lzY28uY29tL3NlY3VyaXR5L3BraS9wb2xpY2llcy9p
bmRleC5odG1sMF4GA1UdJQRXMFUGCCsGAQUFBwMBBggrBgEFBQcDAgYIKwYBBQUH
AwUGCCsGAQUFBwMGBggrBgEFBQcDBwYKKwYBBAGCNwoDAQYKKwYBBAGCNxQCAQYJ
KwYBBAGCNxUGMA0GCSqGSIb3DQEBBQUAA4IBAQAw8zAtjPLKN0pkmSQpCvKGqkLV
I+ii6itvaSN6go4cTAnPpE+rhC836WVg0ZrG2PML9d7QJwBcbx2RvdFOWFEdyeP3
OOfTC9Fovo4ipUsG4eakqjN9GnW6JvNwxmEApcN5JlunGdGTjaubEBEpH6GC/f08
S25l3JNFBemvM2tnIwcGhiLa69yHz1khQhrpz3B1iOAkPV19TpY4gJfVb/Cbcdi6
YBmlsGGGrd1lZva5J6LuL2GbuqEwYf2+rDUU+bgtlwavw+9tzD0865XpgdOKXrbO
+nmka9eiV2TEP0zJ2+iC7AFm1BCIolblPFft6QKoSJFjB6thJksaE5/k3Npf
-----END CERTIFICATE-----

13.	Conclusion
Cisco Systems Inc. looks forward to working with Mozilla completing this request.  Please contact the Cisco PKI team using the contact information provided above for any questions or concerns.


Reproducible: Always

Steps to Reproduce:
1.
2.
3.

Comment 1

[Frank Hecker]

I've scanned over the request above, and also looked briefly at the CP and CPS. I have a few questions:

1. My understanding is as follows: This root issues CA certs to one or more Cisco-controlled subordinate CAs, including the Cisco Manufacturing Sub-CA mentioned above. From the description I presume that (among other things) the subordinate CA issues end entity certs for use in Cisco-manufactured network devices. Thus, for example, a Linksys home gateway box might come with a cert and private key for its embedded web server, so that a Firefox user configuring the device would be able to connect to the web-based administrative interface on an SSL/TLS connection. (In which case having the Cisco root CA cert pre-loaded in Firefox would enable error-free validation of the device's cert.) Do I have this right?

2. Continuing on from the above: What other general types of certificate are issued from within the CA hierarchy rooted the Cisco Root CA 2048? In particular, do sub-CAs under the Cisco root issue certificates for such public-facing uses as Cisco external web sites or S/MIME certs for Cisco employees and contractors? (I mention these because, in addition to the scenario of the Firefox user administering a network device, these are examples of cases where a typical Mozilla user might encounter end entity certs issued out of the Cisco hierarchy.)

3. A follow-up to question 2: As I read section 12.5 above, the request is for the root CA cert to be marked as a trust anchor not only for SSL use (e.g., for web-based administration of Cisco devices) but also for secure email and object signing. Can you provide examples for the latter two uses?

4. The CPS and CP you link to are only for the root, and don't mention policies and procedures for the subordinate CAs. Do you have comparable publicly available CP and CPS documents for the subordinate CAs, especially for the ones that issue certs that might be encountered by typical Mozilla users.

5. The CP and CPS mention CRLs for the root CA, but don't provide any information on where the CRLs might be downloaded. Is there a URL (or URLs) where these can be found?

6. Do you provide any sort of OCSP support? The CP and CPS don't mention OCSP, but I thought I'd ask just to be sure.

7. The CP and CPS are provided as Word documents, and moreover have some sort of "password to modify" scheme that may or may not be supported in non-Microsoft software. Could you all also provide these documents in PDF format, for the convenience of people who don't have Word or Word-compatible software?

Comment 2

[Nelson Bolyard (seldom reads bugmail)]

In question 1 of comment 1 above, Frank asks if this PKI will be used to 
issue End Entity SSL server certs to be used by (sent out by) https servers 
built into Cisco-Manufactured network devices, for purposes of identifying
those devices to browser users (e.g. an https admin interface for home and
small business routers).  

I think this is equivalent to asking if a Cisco-manufactured network device 
that will be distributed to customers through (say) retail distribution, qualifies as a "Cisco entity" for purposes of the statement (in comment 0)
that "The root and subordinate CAs will NEVER issue certificates to non-Cisco entities.'    

That is a crucial question.  Each of the possible answers (yes and no) has 
its own set of follow-on questions.  Let me ask the first of each of those 
sets of follow-on questions here.

If the answer is Yes, if Cisco-manufactured devices will come with https server certs pre-installed, then the next crucial question is: how will the network device be identified in the certificate so that a browser that connects to this server will not get a "host name mismatch" error?  

If the answer is No, then is it correct that the alternative is that this PKI 
will be used only to issue certs to server products that are owned and operated by Cisco itself, some of which may be accessible from the Internet?

Comment 3

[Frank Hecker]

I've added an entry for Cisco to the pending requests list:

http://www.mozilla.org/projects/security/certs/pending/#Cisco

Please double-check the information and post any corrections, additions, etc., here.

Comment 4

[Nelson Bolyard (seldom reads bugmail)]

Frank, the URL you gave in comment 3 serves up: 500: Internal Server Error

Comment 5

[Frank Hecker]

(In reply to comment #4)
> Frank, the URL you gave in comment 3 serves up: 500: Internal Server Error

Works for me. I've seen that error before. It may have something to do either with periodic maintenance on www.mozilla.org, or with updating of www.mozilla.org when the underlying CVS repository changes. It seems to be transient.

Comment 6

[Nelson Bolyard (seldom reads bugmail)]

Status is: awaiting answers to the questions in comment 1 and comment 2.

Comment 7

[Nelson Bolyard (seldom reads bugmail)]

According to http://www.mozilla.org/projects/security/certs/pending/ 
as of this date, the information in this request is incomplete. 
The request is waiting for more information from the applicant.

Comment 8

[Jamison Budacki]

Answers are still being worked on as many members of our team have beem traveling.

Thank you,

Jamison Budacki

Comment 9

[Alex Wight]

To Frank's questions:
1. [SSL] - Firefox users will open TLS/SSL connections to Cisco devices in order to perform administrative tasks.  We realize that the CommonName mismatch issue might arise, however, in devices such as home routers where the default administration IP address is 192.168.1.1, that can be placed into the CommonName field to avoid name mismatches except in cases where a consumer manually changes it.  To that end, a device having a certificate which chains to a trusted root authority will still provide a Firefox user more trust benefit than one which chains to an unknown authority, even if there is a name mismatch.

To answer Nelson Bolyard's question about if a Cisco-manufactured, retail-distributed network device qualifies as a "Cisco entity", it does qualify as a Cisco entity at the time the certificate is issued, which is the time when any identity proofing must occur.  At the time of issuance the device is a Cisco entity under Cisco's control.   

2. [Other types of certs] - No other general types of certificates are issued from within the CA hierarchy rooted at Cisco Root CA 2048.  Cisco does not issue certificates for Cisco web sites or S/MIME certs for Cisco employees and contractors under this root.

3. [S/MIME and object signing] - Cisco envisions S/MIME messages being sent by devices for monitoring alerts and other administrative functions where users must be notified by email.  Of course we run into the same name mismatch issue here as we do with SSL, but again a message signed with a certificate which chains to a trusted root authority will still provide a Thunderbird user more trust benefit than one which chains to a completely unknown authority, despite the (consistently predictable) name mismatch.  Cisco also envisions the development of signed Firefox extensions and Add-ons for administration of Cisco devices.

4. [additional CP/CPS] - Only the root's CP and CPS are available for public consumption.

5. [CRL locations] - The location of the current CRL can be found at http://www.cisco.com/security/pki/crl/crca2048.crl.  It can also be found in the crlDistributionPoints extension of the example sub-CA certificate in section 12.6 above.

6. [OCSP support] - At this time no OCSP support is provided.

7. [PDF docs] - PDF versions are now available at the same location http://www.cisco.com/security/pki/policies/index.html

Thanks very much for your time and consideration.

Best regards,
-Alex Wight

PKI Architect, Cisco Systems

Comment 10

[Nelson Bolyard (seldom reads bugmail)]

Alex, thanks for the additional information.  

Please also attach to this bug (or add as a comment in PEM form) an example 
of a typical EE cert issued to a typical retail device.

Here are some additional questions that I believe are relevant to evaluating
this request.  

Does every EE cert issued have a unique serial number?  (Mozilla products
will absolutely require that the issued certs have unique serial numbers.)

Is there any way for the owner of the product to extract from the device
the private key associated with the device's cert?  Is there a way for the
admin to "back up" and "restore" the device's cert and private key?  

Is there any unique identifying information about the device in the cert's
subject name or subject alt name, such as a device serial number?  
Or do all certs for devices appear to have the same subject identity?  

Will Cisco's CA(s) ever issue a cert for a network device other than at 
time of manufacture?  

Can a customer get another cert from Cisco after acquiring the product?
Can a customer request a customized cert from Cisco at time of order?

Positive answers to those questions may or may not be good things.

You're right that having a device cert that chains to a trusted root CA will 
give users a stronger sense of validity of the cert and the security of the 
connection.  That may or may not be a good thing.  

As you know, the point of certs is to assure the relying party that the 
network peer with which he is communicating is the peer he intended and not 
some impostor.  This is accomplished by strongly binding a key to a unique 
identity that is known to the relying party and has been verified by the 
issuer.  Channel encryption without authentication of the remote peer's 
identity is very weak security.  

If all these device certs look essentially the same (same subject name, 
subject alt name, etc.), such that the user and the user's browser cannot 
readily distinguish their identities, then numerous attacks are easily 
accomplished.

If all (or even most) of the installed products use the same IP address, and 
that IP address is essentially the only name in the cert that the browser can
seek to match, then from the browser's perspective, all these boxes are 
interchangeable and indistinguishable.  A user's box could be replaced by an 
attacker's box (which routes traffic in a way unexpected by the user), and 
the user might never know because the cert would validate and the browser 
would not alert the user because the identity would not have changed.

In such a case, a user would actually be MORE secure if his browser did NOT
automatically accept all certs for the devices from that same manufacturer,
but instead required the user to approve (one time) in his browser the one
cert that uniquely belongs to his own device.  Firefox 3 has an improved
ability to do that.

If Firefox is to accept certs from a CA that issues many nearly- 
indistinguishable certs, then perhaps a new UI needs to be devised that 
clearly distinguishes between communication with unidentified peers and 
communication with strongly identified peers (such as banks).  

Depending on the answers to the above questions, I think we may be able to 
devise a good solution to these challenges, but it may not be as simple as 
merely adding this root CA cert to Mozilla's trusted CA list.

Comment 11

[Alex Wight]

Hi Nelson,
  I'll answer your questions in the same order as you posed them.
  
  Here's an example of a very typical EE cert issued to a Cisco 7941G IP Phone.
-----BEGIN CERTIFICATE-----
MIIEgTCCA2mgAwIBAgIKdRaB6AAAAA2LfzANBgkqhkiG9w0BAQUFADA5MRYwFAYD
VQQKEw1DaXNjbyBTeXN0ZW1zMR8wHQYDVQQDExZDaXNjbyBNYW51ZmFjdHVyaW5n
IENBMB4XDTA4MDMxMTAzMTk1M1oXDTE4MDMxMTAzMjk1M1owUDEbMBkGA1UEChMS
Q2lzY28gU3lzdGVtcyBJbmMuMQ4wDAYDVQQLEwVFVlZCVTEhMB8GA1UEAxMYQ1At
Nzk0MUctU0VQMDAxRjlFQUI2OEMwMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIB
CgKCAQEAqEGxnx/uMfLYn/XRiX5sEGhdsqmkVmSJ62AkVfShFvNzDllB1mGhg+ts
aDE/okC3JS3eOkzmXD3v+RKOhMCh1hZFYGRhPP2myEQI59CfGzYv/vOATkDi+FcZ
inVN6mexkXe0XQiwhCfR0cFRxWC7hCComnqfirDzkL/FuFFKvebBJifFhc1lNtGU
+ofyn7uexvZ7ffJLhOBmY4dsgr2Um6yseUPq/A/L4G5cbSOiIV3ZgdtWcFDqpghQ
PI5rNCbhssf3tQXG9VSZxjtabG29ntvOtRG5NL+YmXNhNpFcvv9Q6gxqby21isXP
IraNDMOR8ziFAFf1jQ1paQ4maPGNXwIDAQABo4IBcjCCAW4wCwYDVR0PBAQDAgTw
MCoGA1UdJQEB/wQgMB4GCCsGAQUFBwMBBggrBgEFBQcDAgYIKwYBBQUHAwUwIwYD
VR0RBBwwGoYYQ1AtNzk0MUctU0VQMDAxRjlFQUI2OEMwMB0GA1UdDgQWBBRCRsG1
rx0k3HLRGbcjMzNMu1xuxzAfBgNVHSMEGDAWgBTQxSImq09GYOyuBZHH3FrRsEf3
bDA/BgNVHR8EODA2MDSgMqAwhi5odHRwOi8vd3d3LmNpc2NvLmNvbS9zZWN1cml0
eS9wa2kvY3JsL2NtY2EuY3JsMEwGCCsGAQUFBwEBBEAwPjA8BggrBgEFBQcwAoYw
aHR0cDovL3d3dy5jaXNjby5jb20vc2VjdXJpdHkvcGtpL2NlcnRzL2NtY2EuY2Vy
MD8GCSsGAQQBgjcUAgQyHjAASQBQAFMARQBDAEkAbgB0AGUAcgBtAGUAZABpAGEA
dABlAE8AZgBmAGwAaQBuAGUwDQYJKoZIhvcNAQEFBQADggEBAAobFZKnp82m8AOA
GyPXvzsNaao/MquOTBsnAeKQNqZ4rtB1cuqkvVtiuSWC3DD6KY33sn3d6t9JbIfW
wXHEp+Fq/fEtlaSThBib3HB/LCMsr6EU01DsSeCaSZO++PcS9QKXy01Ubo6WUhTZ
SVEF5gSDje+NxQ3WetZbbXtYvLal47/LX0m87W3MAGOB/GYAQpF7qQLOpXaE54az
GQG0S3v4gbohMSDnxITbyKZPT+nRZm3mwJBdUyW1Xi7RojbQEIslE5CucorVDN2i
E4D+XOIWtsijzzmlwj4sLItMSSTOzC3pQiBRqoWHOqQ4YbVo4mGVcI4O+/AHcFVU
UcP2Ck4=
-----END CERTIFICATE-----

Every EE certificate not only has a unique X.509 certificate serial number, but also a unique Cisco device serial number which in this example is represented in the Common Name field.  There is also a movement within Cisco to move to a standard naming practice where the device serial number and productID are placed into the X.500 serialNumber field (OID=2.5.4.5) within the subjectDN.  

It is not possible for the owner of the device to extract the private key from the device, for backup puposes or otherwise.

See the two paragraphs above - there is currently a standard within Cisco to place the device serial number and productID into the serialNumber field of the subjectDN.  

Cisco will not issue certificates to devices post-manufacturing time.  The liability concerns are simply too great.

Cisco customers cannot get another cert after acquiring the product.  There is no mechanism to create new keys and install new certificates after a device has been finalized in manufacturing.  The certificate profile is determined during the product design phase and is very difficult for our team to modify after production shipments have begun, but is certainly not customizable by a customer.

Cheers,
-Alex

Comment 12

[Nelson Bolyard (seldom reads bugmail)]

Alex,  

Thanks for the cert, and for the answers to my questions.  After examining
it, I have a few more questions.

- Is this certificate representative of the ones upon which a Mozilla browser would be expected to rely for the benefit of the consumer and small business 
user, as described in comment 0 above?  Or would the certs upon which Mozilla
browsers would be expected to rely going to differ from this one with respect
to different (e.g. additional) cert extensions, or entries within cert 
extensions?  (Hint: I suspect this cert is missing something.)

I extracted the following info from the cert in comment 11.

> Data:
>     Version: 3 (0x2)
>     Serial Number:  75:16:81:e8:00:00:00:0d:8b:7f
>     Signature Algorithm: PKCS #1 SHA-1 With RSA Encryption
>     Issuer: "CN=Cisco Manufacturing CA,O=Cisco Systems"
>     Validity:
>         Not Before: Tue Mar 11 03:19:53 2008
>         Not After : Sun Mar 11 03:29:53 2018
>     Subject: "CN=CP-7941G-SEP001F9EAB68C0,OU=EVVBU,O=Cisco Systems Inc."
>     Subject Public Key Info:
>         Public Key Algorithm: PKCS #1 RSA Encryption
>         RSA Public Key:  [snipped]
>     Signed Extensions:
>         Name: Certificate Key Usage
>         Usages: Digital Signature
>                 Non-Repudiation
>                 Key Encipherment
>                 Data Encipherment
> 
>         Name: Extended Key Usage
>         Critical: True
>             TLS Web Server Authentication Certificate
>             TLS Web Client Authentication Certificate
>             OID.1.3.6.1.5.5.7.3.5  (id-kp-ipsecEndSystem obsolete(?))
> 
>         Name: Certificate Subject Alt Name
>         URI: "CP-7941G-SEP001F9EAB68C0"
> 
>         Name: Certificate Subject Key ID
>         Data:
>             42:46:c1:b5:af:1d:24:dc:72:d1:19:b7:23:33:33:4c:
>             bb:5c:6e:c7
> 
>         Name: Certificate Authority Key Identifier
>         Key ID:
>             d0:c5:22:26:ab:4f:46:60:ec:ae:05:91:c7:dc:5a:d1:
>             b0:47:f7:6c
> 
>         Name: CRL Distribution Points
>         URI: "http://www.cisco.com/security/pki/crl/cmca.crl"
> 
>         Name: Authority Information Access
>         Method: PKIX CA issuers access method
>         Location:
>             URI: "http://www.cisco.com/security/pki/certs/cmca.cer"
> 
>         Name: Microsoft Enrollment Cert Type Extension
>         Data: "IPSECIntermediateOffline"
> 
> Signature Algorithm: PKCS #1 SHA-1 With RSA Encryption

This appears reasonable for use as an SSL client authentication cert, 
where the authenticated identity is that of the device, not its user 
(of course).  

However, for the purpose of authenticating an SSL server, this cert seems to 
lack any of the identification info that a browser could verify against the 
content of a URL to assure itself that the certificate it had received identifies the peer server (device) that it intended to reach, and not for 
some other device (perhaps from the same manufacturer) acting as a 
substitute/impostor.  In particular, it lacks both a DNS name and an IP 
address from the subject Alt Name extension.

The consequence of that absence is this: if the browser contacts a server
that presents this cert, the browser cannot determine that this cert belongs 
to the server that the browser user intended to reach, not even if the 
browser can validate the certificate has having been issued by a known and 
trusted issuer. Nothing in this certificate can be matched against the 
content of the URL that led the browser to this server.

So, the browser will treat this as a "host name mismatch" (which means
that it could not confirm the cert's identity against the information
given in the URL).  The browser will then not honor the cert unless and 
until the user creates a "security exception" for the certificate, binding 
that cert to the host name/address in the URL that reached this server 
(a multi-step UI procedure).  

Creating a security exception is necessary to overcome any cert validation 
errors, such as cert issued by an unknown issuer or untrusted issuer, or 
"host name mismatch".  Whether a cert has an unknown issuer, or a host name
mismatch, or other errors, or some combination thereof, the only way for the 
user to overcome those errors is to create a security exception.

It seems to me that the point of adding a root CA cert to Mozilla's list of 
trusted CA certs is to obviate the security exception creation process.  

If adding the CA cert to the list of known and trusted (by default) issuers
does not obviate the security exception creation process for the browser user, 
because the certs issued by this CA have other issues (besides unknown issuer) 
that necessitate creating a security exception, then IMO, little or no purpose 
is served by adding that CA cert to the trusted CA cert list.  

In my opinion, Mozilla ought not admit a CA's cert to the trusted list 
if the certs issued by that CA will routinely require the creation of 
security exceptions to be useful to the Mozilla browser user.  We REALLY 
don't want to get users trained to routinely create security exceptions 
for certs that fail validation and/or identity authentication.  We don't
want to send the message that creating security exceptions is a good and
normal action to do.

Can we solve the browser-cannot-verify-server's-identity problem through
any change to the cert?

Comment 13

[Frank Hecker]

To add to Nelson's comments: I can think of ways to address the underlying issues Nelson's concerned about, but they involve some fundamental changes in the user "out of the box" experience in terms of installing network devices.

As an example, for a home network gateway box a typical configuration step is to connect one's PC to the device and then use a browser to connect to 192.168.1.1 or some other private IP address. An alternative would be to have the user connect to some device-specific domain name, e.g., sn12345.model6789.cisco.com, with the exact serial and model numbers, or even the domain name itself, available from a label on the device. My understanding is that these devices typically have a built-in DNS nameserver, so that domain name could then be resolved to 192.168.1.1 or whatever private address was appropriate. The device's SSL certificate could then have that device-specific domain name in the subjectAltName extension, so the browser could verify that it was connecting to the right device and no other.

Nelson can correct me if I'm wrong, but I think a scheme like this could address the issues he raises. However I don't know if it's implementable in the context of what Cisco is currently doing or planning to do.

Comment 14

[Alex Wight]

Hi guys,
  Sorry the example certificate wasn't what you were looking for.  We were asked to, "Please ...add as a comment in PEM form) an example of a typical EE cert issued to a typical retail device".  The example EE cert provided was issued to a typical Cisco IP Phone.  It will, of course, give a name mismatch if an SSL session were established with the server side using that certificate.  Cisco does not currently manufacture devices with certificates having any IP address or DNS names in the CommonName or subjectAltName fields, so there is no typical example certificate we can give you which adheres to the schemes we've been discussing.  We could create an example certificate that aligns with the hypothetical solutions we're discussing but it wouldn't be representative of the typical EE cert issued to a typical retail device.
 
  It was mentioned that, "We REALLY don't want to get users trained to routinely create security exceptions for certs that fail validation and/or identity authentication" and we *completely* agree with this philosophy.  Currently all Linksys home routers ship with a self-signed certificate with "CN=Linksys", which is conditioning users to routinely ignore SSL security messages by just clicking OK to get to the router administration interface.  The problem which you're implying will be avoided by disallowing Cisco's root to be included in the Mozilla root store is actually occurring rampantly as we speak.  Introducing Cisco's trusted root will, at a minimum, eliminate one of the two security messages users currently encounter.  We can work toward a solution to eliminate both security messages, but we strongly believe that eliminating half of a typical Firefox user's security warning messages aligns with our common philosophy.
 
  There's a fundamental question surrounding all of this - who is the authority to say which DNS entry (IP address) is bound to a particular key pair, when the IP address is not internet-routable and is duplicated millions of times over on the inside interface of everyone's home routers?  Commercial CAs are authoritative because they can identify with reasonable surety whether a domain name is owned by a particular entity and then rely on accuracy in DNS resolution to route an SSL session to the correct internet-routable IP address.  As we stand today, what entity can say with reasonable surety who "owns" a non-internet-routable IP address (who owns 192.168.1.1)?  
 
  Commercial CAs base the trust of their SSL certificate programs on the world's DNS and routing infrastructure because that infrastructure is the authority on how to correctly route to those IP addresses.  On the inside interface of a home router, only the entity deciding on where the route goes can be trusted with binding that IP address with a public key - there's no other information available to base the binding on.  In the route between the user's browser and the inside interface of their home router, the router itself is the only real authority on where the route to 192.168.1.1 goes.
  
  Unfortunately, we don't think Frank's suggestion could be implemented because most home devices do not have a built-in DNS server, and those that do don't often get used by the average consumer - the router uses their ISP's DNS.
 
 Please let me know what our next steps are to proceed.
 Thanks,
 -Alex

Comment 15

[Nelson Bolyard (seldom reads bugmail)]

In Firefox 3, all certificate-related security messages are combined into one.
It's an error page, rather than a dialog.  And it takes more than one click
to bypass it.  So, the proposed scheme of putting the Cisco root into Firefox, 
while the issued certs continue to have name mismatch errors, will not alter 
the user experience.  The user will still get the one page and be stumped.

I'm surprised to hear that "most (Cisco) home devices do not have a built-in
DNS server".  My (non-Cisco) cheapo home wireless router has a built-in 
caching DNS server that all the LAN-side clients use as their server.  
(The built-in DHCP server serves up its own LAN IP address as the DNS server.)
It strikes me as pretty simple for the manufacturer to hack that DNS server
to always know some reserved name (e.g. CP-7941G-SEP001F9EAB68C0.cisco.com) 
that is unique to the local system (the name in the box's cert), and always serve up its local LAN IP address for that name without doing a WAN-side DNS lookup.  

I think that using a unique host name, rather than an IP address, in the cert
is preferable for several reasons, including:
- it gives the user the freedom to change the LAN-side IP address of the box
(I presume the Cisco boxes already have that ability).
- It doesn't allow one box to spoof for all the others from that manufacturer.

Comment 16

[Frank Hecker]

I've been talking to the folks from Cisco about this request, and based on those conversations I'm going to WONTFIX this particular request. Cisco may come back with a revamped request in future, one that takes into account the various issues that have been raised.

Comment 17

[Eddy Nigg (StartCom)]

Frank or Kathleen, please update and/or remove the entry at http://www.mozilla.org/projects/security/certs/pending/#Cisco