Bug 1910322 Comment 35 Edit History

Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.

Hi DigiCert,

I don't know whether this is a question, a recommendation, a request for clarification, or just highlighting a detail for the attention of other participants in the ecosystem. Regardless, I'd appreciate your thoughts.

The error which occurred in this bug was two-fold, but only one of which was a compliance issue:
* The domain validation system generated random values intended for use with Method 7 of the TLS Baseline Requirements, where the random value was expected to be used as a subdomain of the Applicant's Authorization Domain Name.
 * While the generation of such a random value without an underscore character prepended to the random value contributed to this bug, it is itself not a non-compliance.
* The domain validation system queried DNS names and accepted them as valid Authorization Domain Names where the queried hostname was not in-scope of what could be considered a valid Authorization Domain Name.
 * This is the core non-compliance present in this incident. The domain validation system should never have been able to validate a subdomain which did not begin with an underscore character as demonstrating domain control for a parent domain.

While I'm under the impression that this is understood and has been addressed, it's not 100% clear and listed action items don't indicate this as being directly addressed. 
To provide clarity to the community, can you confirm that the domain validation system is no longer capable of accepting a request to query a DNS zone which is incapable of qualifying as a valid Authorization Domain Name for the FQDN intended to be validated? Similarly, if a query were performed against a hostname of the format [rnd].domain.com, the resultant domain validation would be limited to the specific FQDN queried rather than its parent zone?

Phrased differently, the following points in the domain validation workflow seem to necessitate changes based on the descriptions in this bug; have changes been made to or functionality confirmed in these components to ensure a similar issue could not present itself again?
1. Random Value Generation
2. Requests internal to the Domain Validation System to perform a Domain Control Validation lookup for a given FQDN
3. The Domain Validation System's interpretation of retrieved DNS records and association thereof with stored domain approvals

While my understanding is that DigiCert has addressed these things, part of my motivation for asking is to present these interactions differently with the intent that it could allow other CAs to perform additional confirmation of their own system functionality/logic.
Hi DigiCert,

I don't know whether this is a question, a recommendation, a request for clarification, or just highlighting a detail for the attention of other participants in the ecosystem. Regardless, I'd appreciate your thoughts.

The error which occurred in this bug was two-fold, but only one of which was a compliance issue:
* The domain validation system generated random values intended for use with Method 7 of the TLS Baseline Requirements, where the random value was expected to be used as a subdomain of the Applicant's Authorization Domain Name.
  * While the generation of such a random value without an underscore character prepended to the random value contributed to this bug, it is itself not a non-compliance.
* The domain validation system queried DNS names and accepted them as valid Authorization Domain Names where the queried hostname was not in-scope of what could be considered a valid Authorization Domain Name.
  * This is the core non-compliance present in this incident. The domain validation system should never have been able to validate a subdomain which did not begin with an underscore character as demonstrating domain control for a parent domain.

While I'm under the impression that this is understood and has been addressed, it's not 100% clear and listed action items don't indicate this as being directly addressed. 
To provide clarity to the community, can you confirm that the domain validation system is no longer capable of accepting a request to query a DNS zone which is incapable of qualifying as a valid Authorization Domain Name for the FQDN intended to be validated? Similarly, if a query were performed against a hostname of the format [rnd].domain.com, the resultant domain validation would be limited to the specific FQDN queried rather than its parent zone?

Phrased differently, the following points in the domain validation workflow seem to necessitate changes based on the descriptions in this bug; have changes been made to or functionality confirmed in these components to ensure a similar issue could not present itself again?
1. Random Value Generation
2. Requests internal to the Domain Validation System to perform a Domain Control Validation lookup for a given FQDN
3. The Domain Validation System's interpretation of retrieved DNS records and association thereof with stored domain approvals

While my understanding is that DigiCert has addressed these things, part of my motivation for asking is to present these interactions differently with the intent that it could allow other CAs to perform additional confirmation of their own system functionality/logic.

Back to Bug 1910322 Comment 35