Several questions from the agent

[li harry]

Hi:

    I'm sorry I just started CT. In the past few days, I have checked a lot of CT related information. Since I have a preliminary understanding of CT, in the process of using browsers, I thought of some questions about using CT in browsers. I wonder if you can help me understand it.

    1.  Mainstream browsers trust CT, is the CT they trust a source?

    2. There are many CT institutions, are the logs of each CT institution synchronized with each other?

    3. Does CT theoretically log all certificates issued by a CA?

    3. Through the rfc6962 standard, I found that some CT organizations' APIs cannot be accessed, such as Symantec, Certly, Sectigo ... , these urls are obtained from https://www.gstatic.com/ct/log_list/all_logs_list.json.

   Looking forward to your reply, thank you very much.

[Devon O'Brien]

Hello! I've answered some of your questions in-line; hopefully they provide some clarity. At a high level, you might find the following resources to be helpful/informative:

High-level overview of CT: https://certificate.transparency.dev/

A fantastic introduction to CT: https://blog.cloudflare.com/introducing-certificate-transparency-and-nimbus/

Chrome's CT Policy with explainers: https://goo.gl/chrome/ct-policy

Apple's CT Policy: https://support.apple.com/en-us/HT205280

On Friday, July 15, 2022 at 1:48:32 AM UTC-7 liqing...@gmail.com wrote:

Hi:

    I'm sorry I just started CT. In the past few days, I have checked a lot of CT related information. Since I have a preliminary understanding of CT, in the process of using browsers, I thought of some questions about using CT in browsers. I wonder if you can help me understand it.

    1.  Mainstream browsers trust CT, is the CT they trust a source?

I'm not 100% sure I understand the question, but CT is designed to be a layer of accountability for the Web PKI without adding a layer of trust. CT-enforcing user agents ship a list of recognized CT log keys in their browser/OS and use these keys to verify SCT signatures to ensure that the certificate has been submitted for public logging before trusting that certificate. These user agents also monitor these logs for compliance with their requirements and some additionally audit these logs to help ensure they are behaving consistently and are not presenting different views to different parties (which could facilitate hiding certificate mis-issuance).

 

    2. There are many CT institutions, are the logs of each CT institution synchronized with each other?

In general, no, CT logs aren't in sync with one another, though they generally all accept certificates from the majority of widely-trusted CAs. The vast majority of entries in a CT log are from CAs submitting (pre)certificates right at issuance time, and CAs can be configured to submit to specific subsets of logs. Certificates in one log are sometimes submitted to another by interested parties, which increases the coverage of certificates, but this is not done to completion. Additionally, many logs specify an expiry range and only accept certificates that expire within that range, leading to additional differences between logs.

 

    3. Does CT theoretically log all certificates issued by a CA?

The short answer to this question is "no".

While TLS certificates are required to present SCTs to CT-enforcing user agents like Chrome and Apple TLS clients, both of these user agents do not mandate that all certificates from a CA be logged as a matter of policy. For example, S/MIME certificates are not required to be logged (and there are good reasons not to, since they often contain personally identifiable information). Additionally, TLS certificates issued from private or publicly-trusted CAs that do not need to validate in CT-enforcing user agents may also never be submitted to CT logs.

 

    3. Through the rfc6962 standard, I found that some CT organizations' APIs cannot be accessed, such as Symantec, Certly, Sectigo ... , these urls are obtained from https://www.gstatic.com/ct/log_list/all_logs_list.json.

This specific file tracks all CT logs that are known to Google, both past and present. Many of those logs have been offline for several years and others were never recognized by CT-enforcing user agents at all. If you are looking for a list of CT Logs that are currently recognized by CT-enforcing browsers, these are the lists you are interested in:

Chrome: https://www.gstatic.com/ct/log_list/v3/log_list.json

Apple: https://valid.apple.com/ct/log_list/current_log_list.json

[li harry]

 Devon O'Brien Thank you very much for your reply, your reply has helped me a lot. I didn't describe it clearly for question 1, and your answer to question 3 reminded me of some other questions. Please help me.

  

  1.  Mainstream browsers trust CT, is the CT they trust a source?

I'm not 100% sure I understand the question, but CT is designed to be a layer of accountability for the Web PKI without adding a layer of trust. CT-enforcing user agents ship a list of recognized CT log keys in their browser/OS and use these keys to verify SCT signatures to ensure that the certificate has been submitted for public logging before trusting that certificate. These user agents also monitor these logs for compliance with their requirements and some additionally audit these logs to help ensure they are behaving consistently and are not presenting different views to different parties (which could facilitate hiding certificate mis-issuance).

    

    1.1 For this question, I want to know whether all proxies are trusted with their own sources. For example, Google has its own CT logs, Apple also has its own CT logs, whether the chrome browser only checks Google's CT logs when requesting (through Google's own CT logs) Determine whether there are multiple CA registrations), or will check the CT logs of Google and Apple at the same time.

     3. Does CT theoretically log all certificates issued by a CA?

The short answer to this question is "no".

While TLS certificates are required to present SCTs to CT-enforcing user agents like Chrome and Apple TLS clients, both of these user agents do not mandate that all certificates from a CA be logged as a matter of policy. For example, S/MIME certificates are not required to be logged (and there are good reasons not to, since they often contain personally identifiable information). Additionally, TLS certificates issued from private or publicly-trusted CAs that do not need to validate in CT-enforcing user agents may also never be submitted to CT logs.

   

     3.1  Does a CT have all the public certificates, if not all the public certificates of the global CA, does the proxy still have certificate risks? If there are no public certificates issued by all the CAs, then the public certificate collection can account for the percentage of the total public certificates?

[Devon O'Brien]

On Mon, Jul 18, 2022 at 1:29 AM li harry <liqing...@gmail.com> wrote:

 Devon O'Brien Thank you very much for your reply, your reply has helped me a lot. I didn't describe it clearly for question 1, and your answer to question 3 reminded me of some other questions. Please help me.

  

  1.  Mainstream browsers trust CT, is the CT they trust a source?

I'm not 100% sure I understand the question, but CT is designed to be a layer of accountability for the Web PKI without adding a layer of trust. CT-enforcing user agents ship a list of recognized CT log keys in their browser/OS and use these keys to verify SCT signatures to ensure that the certificate has been submitted for public logging before trusting that certificate. These user agents also monitor these logs for compliance with their requirements and some additionally audit these logs to help ensure they are behaving consistently and are not presenting different views to different parties (which could facilitate hiding certificate mis-issuance).

    

    1.1 For this question, I want to know whether all proxies are trusted with their own sources. For example, Google has its own CT logs, Apple also has its own CT logs, whether the chrome browser only checks Google's CT logs when requesting (through Google's own CT logs) Determine whether there are multiple CA registrations), or will check the CT logs of Google and Apple at the same time.

So, there are two different concepts that are worth detangling here. Chrome and Apple both maintain a list of CT logs that are recognized by the respective browser/OS. These CT logs are operated by a wide variety of organizations, as reflected in the JSON fields in the log lists themselves. Examples of these organizations are Cloudflare, DigiCert, Let's Encrypt, Sectigo, TrustAsia. Google also happens to run CT logs of its own, and they are recognized in both Apple's and Chrome's CT log lists. Broadly speaking, Apple's and Google's lists are extremely close to one another and only tend to differ in timing of when logs are added or removed. Differences are permitted, though any time there is a discrepancy between the lists, it is harder for CAs to submit to a set of CT logs that satisfies both Apple's and Chrome's CT Policies. 

When validating a certificate, Chrome specifically checks against the Chrome CT log list and Apple clients check against the Apple CT Log list. These lists are hosted online in the links I provided, but they are also included in the source code of the browser/OS to be checked against when validating TLS certificates.

 

     3. Does CT theoretically log all certificates issued by a CA?

The short answer to this question is "no".

While TLS certificates are required to present SCTs to CT-enforcing user agents like Chrome and Apple TLS clients, both of these user agents do not mandate that all certificates from a CA be logged as a matter of policy. For example, S/MIME certificates are not required to be logged (and there are good reasons not to, since they often contain personally identifiable information). Additionally, TLS certificates issued from private or publicly-trusted CAs that do not need to validate in CT-enforcing user agents may also never be submitted to CT logs.

   

     3.1  Does a CT have all the public certificates, if not all the public certificates of the global CA, does the proxy still have certificate risks? If there are no public certificates issued by all the CAs, then the public certificate collection can account for the percentage of the total public certificates?

Can you explain what you mean by "proxy" here? If possible, it might be helpful to refer to parties in terms used by RFC 6962 so we can ensure we're on the same page. If you're asking about what percentage of certificates issued by a CA are logged to CT, this is a difficult question to answer. There are billions of certificates logged to CT, but since there is no requirement to log or even count certificates that aren't in CT, we can't reliably answer this question. What we can say is such certificates will not validate in CT-enforcing user agents because they will not be able to present the required SCTs from recognized CT logs, provided the CT logs are working properly and non-maliciously.

 

在2022年7月16日星期六 UTC+8 21:47:10<Devon O'Brien> 写道：

Hello! I've answered some of your questions in-line; hopefully they provide some clarity. At a high level, you might find the following resources to be helpful/informative:

High-level overview of CT: https://certificate.transparency.dev/

A fantastic introduction to CT: https://blog.cloudflare.com/introducing-certificate-transparency-and-nimbus/

Chrome's CT Policy with explainers: https://goo.gl/chrome/ct-policy

Apple's CT Policy: https://support.apple.com/en-us/HT205280

On Friday, July 15, 2022 at 1:48:32 AM UTC-7 liqing...@gmail.com wrote:

Hi:

    I'm sorry I just started CT. In the past few days, I have checked a lot of CT related information. Since I have a preliminary understanding of CT, in the process of using browsers, I thought of some questions about using CT in browsers. I wonder if you can help me understand it.

    1.  Mainstream browsers trust CT, is the CT they trust a source?

I'm not 100% sure I understand the question, but CT is designed to be a layer of accountability for the Web PKI without adding a layer of trust. CT-enforcing user agents ship a list of recognized CT log keys in their browser/OS and use these keys to verify SCT signatures to ensure that the certificate has been submitted for public logging before trusting that certificate. These user agents also monitor these logs for compliance with their requirements and some additionally audit these logs to help ensure they are behaving consistently and are not presenting different views to different parties (which could facilitate hiding certificate mis-issuance).

 

    2. There are many CT institutions, are the logs of each CT institution synchronized with each other?

In general, no, CT logs aren't in sync with one another, though they generally all accept certificates from the majority of widely-trusted CAs. The vast majority of entries in a CT log are from CAs submitting (pre)certificates right at issuance time, and CAs can be configured to submit to specific subsets of logs. Certificates in one log are sometimes submitted to another by interested parties, which increases the coverage of certificates, but this is not done to completion. Additionally, many logs specify an expiry range and only accept certificates that expire within that range, leading to additional differences between logs.

 

    3. Does CT theoretically log all certificates issued by a CA?

The short answer to this question is "no".

While TLS certificates are required to present SCTs to CT-enforcing user agents like Chrome and Apple TLS clients, both of these user agents do not mandate that all certificates from a CA be logged as a matter of policy. For example, S/MIME certificates are not required to be logged (and there are good reasons not to, since they often contain personally identifiable information). Additionally, TLS certificates issued from private or publicly-trusted CAs that do not need to validate in CT-enforcing user agents may also never be submitted to CT logs.

 

    3. Through the rfc6962 standard, I found that some CT organizations' APIs cannot be accessed, such as Symantec, Certly, Sectigo ... , these urls are obtained from https://www.gstatic.com/ct/log_list/all_logs_list.json.

This specific file tracks all CT logs that are known to Google, both past and present. Many of those logs have been offline for several years and others were never recognized by CT-enforcing user agents at all. If you are looking for a list of CT Logs that are currently recognized by CT-enforcing browsers, these are the lists you are interested in:

Chrome: https://www.gstatic.com/ct/log_list/v3/log_list.json

Apple: https://valid.apple.com/ct/log_list/current_log_list.json

 

   Looking forward to your reply, thank you very much.

--
You received this message because you are subscribed to the Google Groups "certificate-transparency" group.
To unsubscribe from this group and stop receiving emails from it, send an email to certificate-transp...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/certificate-transparency/14224db4-2ff5-42e4-a40b-30825e13d701n%40googlegroups.com.

[li harry]

       Thanks again Devon O'Brien for your reply. Your patience has helped me understand some of the confusion about certificates. 

        In a broad sense, each CT organization is independent, and their logs are theoretically similar, because there will be some differences in technical details such as update time and expiration time. The security of browser trust also depends on the CA. The security and coverage of the CT certificate trusted by the browser. 3.1 The proxy described in the question should be described as the browser, this question wants to ask whether the CT trusted by the browser can completely solve the problem of certificate spoofing. From your answer I It can be inferred that most problems can be solved, but this problem cannot be solved 100%. I don't know if I understand it right.

[Devon O'Brien]

Hello,

Happy to help. Regarding your last question, CT is not a 100% answer to preventing certificate spoofing; that is correct. CT's goal is to allow a time-bounded detection of certificate (mis)issuance for certificates that validate in CT-enforcing user agents. Notably, that time bound is related to the log's maximum merge delay (MMD) which is up to 24 hours and this is still a detection mechanism and not a prevention mechanism, so it is inherently reactive. Reliably preventing mis-issuance is a significantly more challenging problem that would require re-architecting a significant amount of the Web PKI as it exists today.

-Devon

[Trisha Lusby]

Ty for your help and it definitely makes me feel safer. 

To view this discussion on the web visit https://groups.google.com/d/msgid/certificate-transparency/be196262-a1b4-482a-a076-20804af0199an%40googlegroups.com.