(In reply to Ryan Sleevi from comment #11)
Naturally, the question that remains is largely one of understanding the decision making process, and whether there exists further opportunities to improve or clarify. One example is whether adversarial review is incorporated, and whether such “worst case interpretations” are encouraged (even if they may compete with specific product/marketing goals), and whether there is a process in place to seek further community clarification on jurisdictional issues such as this. It would be remiss to say “Sectigo made a bad call” without looking for further opportunities to set Sectigo - and all CAs - up for success in the future.
The original policy decision to include 0s in the case of a missing postalCode field occurred in the deep past, and understanding the thought process behind that decision is likely not possible. Let’s focus instead on how Sectigo operates in the present. We can discuss in detail how we evaluated and responded to this report when it came in.
When presented with this objection to a set of certificates, the first task was to refresh our understanding of the actual rules in the local region. The fact that a policy decision occurred in the past does not necessarily mean the current compliance team would support that same decision, particularly if at decision time it was a different decision maker at a different company with different ownership and a different philosophy.
We recognized that while a postal code of all 0s appears to be wrong, that doesn’t necessarily mean it is. As I stated in comment #8, there sometimes exist practices that appear strange to our eyes but are nonetheless the official, “correct” behavior in other regions. So we felt it was worthwhile to investigate. That investigation quickly left us believing that the certificates for the five countries apart from Hong Kong required revocation.
In the case of Hong Kong, we discovered the passage from the Hong Kong Post web site mentioned a few times in this thread, which spells out a specific set of codes that are available to be used. The argument against allowing these codes seems to hinge on two passages from the web site. Let’s address them individually.
The first is this sentence, “Postcode system is not in place in Hong Kong.” The belief seems to be that the statement “Postcode system is not in place in Hong Kong” is definitive proof of a second statement: “There are no allowable postal codes for Hong Kong.” That may seem sensible, but we have direct evidence that this second statement is not true. China Post, the official post office of mainland China, has designated 999077 as the postal code for Hong Kong addresses. Despite Hong Kong’s unusual status, China is of course the country governing that region.
So for sure there is at least one allowed postal code in Hong Kong, despite the published statement that postal codes are not used. Based on that we are of the belief that the postal code 999077 in a certificate issued to a Hong Kong address would be compliant with the BRs.
This is an important point because we concluded that “Postcode system is not in place in Hong Kong” definitively did not prove that “There are no allowable postal codes for Hong Kong,” as in fact we had established that there was at least one. At this point it was worth asking if there are other postal codes that are valid in the region as well.
Here we returned to the list given on the web site. Hong Kong post selected and published a specific list of discrete postal codes to use, at least one of which would have obvious communicative value to a human reading it (HKG). Since the permissible nature of 999077 demonstrates that the post office does not categorically disallow all postal codes, these others deserve evaluation on their merits. As discussed earlier on this thread, we felt it was significant that Hong Kong Post chose a discrete and specific list of codes to publish. Clearly these codes have status in the eyes of the post office superior to that of simply any random string. That imprimatur, along with the refutation of this idea that no postal code could ever be allowed, let us to conclude that these codes were permissible.
The second objection has been focused on this word “required.” We brought that up in our own internal review of these Hong Kong certificates. With the permission of the other participant, I am posting verbatim and unedited a portion of our thread on this exact point.
I presume Mathew is arguing that the statement "Postcode system is not in place in Hong Kong" equates to (BR 126.96.36.199) "not applicable", and that (emphasis mine) 'If it is required to input postcode of Hong Kong at website(s), you may leave the field blank or try to fill in with "000", "0000", "000000" or "HKG"...' is not relevant to this bug because the postalCode field is not required in certificates.
My response, unless you guys convince me otherwise, is that this is a permitted postal code
Having thought about this some more, I think I would argue that, at best, it's a "permitted placeholder" in cases where a website demands that a postal code field must have a value; but being a "permitted placeholder" doesn't make it a "permitted postal code" in certificates.
It's far from black and white in terms of obviousness though.
I’m going to push back on that argument. The interdiction in the BRs is to prevent the population of certificate fields with placeholders that have no actual, valid meaning in the system we use for physical addresses. That is not the case here. Hong Kong Post is stating that the values given below will be honored if they appear in the address on actual posted mail. They explicitly didn’t say, “Just stick in any old thing because we really don’t care.” Rather, they stated that these strings are the ones the system will handle correctly. While you don’t need to have any of them included for your mail to be delivered, these values are indeed valid for the postal code position on sent mail.
That’s entirely different from the examples given in the BRs, which are not deemed to be valid strings by the local mail delivery authorities.
Thank you for pushing on my ideas. That’s the point. In this case I remain convinced in the original position.
You ask specifically if we incorporate adversarial review and encourage consideration of “worst case interpretations.” I have long believed the answer to that is yes. That does not necessarily mean that we will ultimately decide we believe every worst case interpretation, of course. Some such interpretations are simply absurd. Take, for example, the apparent prohibition on CAs issuing certificates for their own sites. Yes, we discussed the worst case interpretation there, but we rejected it on the consensus that that prohibition was not the intention behind the rules.
Now, as we dig into the root causes of bug #1712188 and certificates ordered by our QA department, it appears that not all employees in all parts of the company feel this same “obligation to dissent.” That has been an eye opener for me and I think a number of others in leadership here. We are still working on our understanding and our more sweeping response to that revelation, and I expect much discussion of this point on that bug. But I can’t truly address this question here without acknowledging bug #1712188 and the work that has to go on over there.