Currently, certificate handling on Chrome OS is too complex.
The reasons are:
(*) we have three separate "sources" certificates:
S1. NSS:
S1.1 built-in token
S1.2 user's public slot (NSS softoken)
S1.3 user's private slot (chaps token accessed through NSS)
S1.4 system slot (chaps token accessed through NSS)
S2. Policy:
S2.1 Policy-pushed CA/server certificates
S2.2 Policy-pushed client certificates (imported into S1.3)
S3. Extensions:
S3.1 Extension-provided client certificates (e.g. for smartcard support) (chrome.certificateProvider API)
(*) we have many "consumers" of certificates:
C1. chrome://certificate-manager:
Listing/importing certificates
C2. Network requests: Cert verificatoin
Currently done through NSS, later through cert_verifier_builtin
C3. Network requests: Client certificate selection/signing
C4. APIs:
chrome.platformKeys, chrome.enterprise.platformKeys
Support cert management, cert verification, client cert usage
C5. wpa_supplicant: Client certificate usage for wifi/ethernet auth
C6. wpa_supplicant: Authentication server cert verification for wifi/ethernet auth
C7. chromeos networking code: Certificate querying/matching to configure C5/C6.
The main issues are:
I1. Each certificate "source" has a different API. Client cert consumers e.g. need to be aware of the different APIs, see e.g. CertificateManagerModel or
I2. Certificate "consumers" outside of chrome (C5/C6) can only access chaps-provided certificates (S1.3/S1.4).
I3. The API for NSS is not nice.
I4. We have a "plug-on" system for storing key metadata to decide if a key is "corporate" or not. It is not an integral part of the standard certificate abstractions and is pretty complex to use (https://cs.chromium.org/chromium/src/chrome/browser/chromeos/platform_keys/key_permissions.h).
In this effort, I'd like to address I1/I3 by:
- designing or reusing an API/service which provides CA and client certificate listing/operations and would abstract away from the specific source (S1..S3).
- changing the consumers inside chrome to use this API.
Possibly, we could also address I4 by integrating key metadata into the abstraction.
===
The ideal outcome would be that
(*) all consumers inside chrome can access all certificates through the same API, reducing complexity
(*) the API is based on X509Certificate objects and not on platform object such as "ScopedCERTCertificate"
(*) NSS functions are only used in the NSS-specific implementation of this API, so deprecating NSS could be done more easily as the next step
(*) The API provides first-class supports for tagging keys and then e.g. listing only keys that are tagged as "corporate" without going through additional hoops.
I'm assuming that we do not have to consider cert verification through NSS anymore in this effort, as we will completely migrate to cert_verifier_builtin soon.
===
Metadata/key tagging:
Previously, security has expressed concerns around bridging S3.1 Extension-provided client certificates <-> C4 chrome.platformKeys API without introducing a way to control which key is available on which surface/to which apps.
We currently have a "plug-on"
===
Out of scope for now:
Long-term, we might also want to attempt to bridge S3.1 extension-provided client certificates with C5 (wpa_supplicant) and possibly other system components, but this would require building a PKCS#11 module which works by using the abstraction introduced in this effort.
If we decided to really create a mojo-ified service which provides the API, this would probably be easier to do later if we want it.
===
Plan:
This could be my 20% project ;)
The plan would be to
(1) collect which "consumer" does what exactly with CA/server/client certificates in what way, and which certificates it cares for.
This should result in a "usages" doc.
(2) Develop an API based on this. Take into account the design of existing APIs, such as PKCS#11 and net's ClientCertIdentity. The result should be a DD we can discuss.
(3) Implement a service(?) which would offer this API and have access to the all cert sources.
(4) Gradually switch cert consumers to this API.
===
Comments?
Please tell me what you think about the general idea and if you think that any of the details I've listed don't make sense / contradict good design / go against our philosophy.
Currently, certificate handling on Chrome OS is too complex.
The reasons are:
(*) we have three separate "sources" certificates:
S1. NSS:
S1.1 built-in token
S1.2 user's public slot (NSS softoken)
S1.3 user's private slot (chaps token accessed through NSS)
S1.4 system slot (chaps token accessed through NSS)
S2. Policy:
S2.1 Policy-pushed CA/server certificates
S2.2 Policy-pushed client certificates (imported into S1.3)
S3. Extensions:
S3.1 Extension-provided client certificates (e.g. for smartcard support) (chrome.certificateProvider API)
(*) we have many "consumers" of certificates:
C1. chrome://certificate-manager:
Listing/importing certificates
C2. Network requests: Cert verificatoin
Currently done through NSS, later through cert_verifier_builtin
C3. Network requests: Client certificate selection/signing
C4. APIs:
chrome.platformKeys, chrome.enterprise.platformKeys
Support cert management, cert verification, client cert usage
C5. wpa_supplicant: Client certificate usage for wifi/ethernet auth
C6. wpa_supplicant: Authentication server cert verification for wifi/ethernet auth
C7. chromeos networking code: Certificate querying/matching to configure C5/C6.
The main issues are:
I1. Each certificate "source" has a different API. Client cert consumers e.g. need to be aware of the different APIs, see e.g. CertificateManagerModel or
I2. Certificate "consumers" outside of chrome (C5/C6) can only access chaps-provided certificates (S1.3/S1.4).
I3. The API for NSS is not nice.
I4. We have a "plug-on" system for storing key metadata to decide if a key is "corporate" or not. It is not an integral part of the standard certificate abstractions and is pretty complex to use (https://cs.chromium.org/chromium/src/chrome/browser/chromeos/platform_keys/key_permissions.h).
In this effort, I'd like to address I1/I3 by:
- designing or reusing an API/service which provides CA and client certificate listing/operations and would abstract away from the specific source (S1..S3).
- changing the consumers inside chrome to use this API.
Possibly, we could also address I4 by integrating key metadata into the abstraction.
===
The ideal outcome would be that
(*) all consumers inside chrome can access all certificates through the same API, reducing complexity
(*) the API is based on X509Certificate objects and not on platform object such as "ScopedCERTCertificate"
(*) NSS functions are only used in the NSS-specific implementation of this API, so deprecating NSS could be done more easily as the next step
(*) The API provides first-class supports for tagging keys and then e.g. listing only keys that are tagged as "corporate" without going through additional hoops, or only listing keys form some sources.
I'm assuming that we do not have to consider cert verification through NSS anymore in this effort, as we will completely migrate to cert_verifier_builtin soon.
===
Out of scope for now:
Long-term, we might also want to attempt to bridge S3.1 extension-provided client certificates with C5 (wpa_supplicant) and possibly other system components, but this would require building a PKCS#11 module which works by using the abstraction introduced in this effort.
If we decided to really create a mojo-ified service which provides the API, this would probably be easier to do later if we want it.
===
Plan:
This could be my 20% project ;)
The plan would be to
(1) collect which "consumer" does what exactly with CA/server/client certificates in what way, and which certificates it cares for.
This should result in a "usages" doc.
(2) Develop an API based on this. Take into account the design of existing APIs, such as PKCS#11 and net's ClientCertIdentity. The result should be a DD we can discuss.
(3) Implement a service(?) which would offer this API and have access to the all cert sources.
(4) Gradually switch cert consumers to this API.
===
Comments?
Please tell me what you think about the general idea and if you think that any of the details I've listed don't make sense / contradict good design / go against our philosophy.
Currently, certificate handling on Chrome OS is too complex.
The reasons are:
(*) we have three separate "sources" certificates:
S1. NSS:
S1.1 built-in token
S1.2 user's public slot (NSS softoken)
S1.3 user's private slot (chaps token accessed through NSS)
S1.4 system slot (chaps token accessed through NSS)
S2. Policy:
S2.1 Policy-pushed CA/server certificates
S2.2 Policy-pushed client certificates (imported into S1.3)
S3. Extensions:
S3.1 Extension-provided client certificates (e.g. for smartcard support) (chrome.certificateProvider API)
(*) we have many "consumers" of certificates:
C1. chrome://certificate-manager:
Listing/importing certificates
C2. Network requests: Cert verification
Currently done through NSS, later through cert_verifier_builtin
C3. Network requests: Client certificate selection/signing
C4. APIs:
chrome.platformKeys, chrome.enterprise.platformKeys
Support cert management, cert verification, client cert usage
C5. wpa_supplicant: Client certificate usage for wifi/ethernet auth
C6. wpa_supplicant: Authentication server cert verification for wifi/ethernet auth
C7. chromeos networking code: Certificate querying/matching to configure C5/C6.
The main issues are:
I1. Each certificate "source" has a different API. Client cert consumers e.g. need to be aware of the different APIs, see e.g. CertificateManagerModel or ClientCertStoreChromeOS
I2. Certificate "consumers" outside of chrome (C5/C6) can only access chaps-provided certificates (S1.3/S1.4).
I3. The API for NSS is not nice.
I4. We have a "plug-on" system for storing key metadata to decide if a key is "corporate" or not. It is not an integral part of the standard certificate abstractions and is pretty complex to use (https://cs.chromium.org/chromium/src/chrome/browser/chromeos/platform_keys/key_permissions.h).
In this effort, I'd like to address I1/I3/(I4) by:
- designing or reusing an API/service which provides CA and client certificate listing/operations and would abstract away from the specific source (S1..S3).
- changing the consumers inside chrome to use this API.
- Possibly, we could also address I4 by integrating key metadata into the abstraction.
===
The ideal outcome would be that
(*) all consumers inside chrome can access all certificates through the same API, reducing complexity
(*) the API is based on X509Certificate objects and not on platform object such as "ScopedCERTCertificate"
(*) NSS functions are only used in the NSS-specific implementation of this API, so deprecating NSS could be done more easily as the next step
(*) The API provides first-class supports for tagging keys and then e.g. listing only keys that are tagged as "corporate" without going through additional hoops, or only listing keys form some sources.
I'm assuming that we do not have to consider cert verification through NSS anymore in this effort, as we will completely migrate to cert_verifier_builtin soon.
===
Out of scope for now:
Long-term, we might also want to attempt to bridge S3.1 extension-provided client certificates with C5 (wpa_supplicant) and possibly other system components, but this would require building a PKCS#11 module which works by using the abstraction introduced in this effort.
If we decided to really create a mojo-ified service which provides the API, this would probably be easier to do later if we want it.
===
Plan:
This could be my 20% project ;)
The plan would be to
(1) collect which "consumer" does what exactly with CA/server/client certificates in what way, and which certificates it cares for.
This should result in a "usages" doc.
(2) Develop an API based on this. Take into account the design of existing APIs, such as PKCS#11 and net's ClientCertIdentity. The result should be a DD we can discuss.
(3) Implement a service(?) which would offer this API and have access to the all cert sources.
(4) Gradually switch cert consumers to this API.
===
Comments?
Please tell me what you think about the general idea and if you think that any of the details I've listed don't make sense / contradict good design / go against our philosophy.
Comment 1 by pmarko@chromium.org
, Oct 19