(In reply to Ryan Sleevi from comment #11)
Thank you for acknowledging the issue. However, as a response, it does not really demonstrate why the issue occurred, and thus does not really provide assurance that similar issues won’t occur.
Understanding how something like this occurred is extremely important to understanding the steps being taken. At best, the current response feels like “We made a mistake, we fixed it, and we won’t make mistakes again”.
A useful explanation is to talk about how the system was designed, what controls you had then to ensure compliance, what teams were involved in reviewing the code and implementation, and what’s being done. Explaining more about what CA software you use, how it is designed and maintained, and how you approach compliance with 5280.
This isn’t about assigning blame or attempting to shame. It’s about trying to understand the full picture of how this happened, so we can have confidence it won’t happen again, and so we can help ensure other CAs do not make the same or similar mistakes. We want to learn from this issue, and we want to be confident that there’s a clear understanding about how this happened.
Given that RFC 5280 and the Baseline Requirements spell out the technical requirements very clearly, understanding how this was missed - not just that it was missed - is key. The only explanation we have to date is that folks thought UTF would be good. However, if the level of controls in the CA software are that fluid, and if trying to improve things for local users that important, how can we be assured that, say, sometime in the future someone might be handed a sub-CA cert? Maybe due to someone misconfiguring a profile, if users can change the profiles, or maybe something the CA does to help out, like it did with UTF? That’s the sort of ting we’re trying to understand, and the best thing a CA can do is comprehensively describe things.
Our certificate issuing system mainly includes RA and CA. RA for accepting applications and conducting preliminary review, mainly examining whether the information format is correct, such as whether the domain included in IANA’s Root Zone Database. The CA for issuing the certificate and verifying the format of issuing the certificate, such as encoding. All of this are following the requirements of RFC 5280 and Baseline Requirements.
The system was developed by our R&D department. Functional requirements will be reviewed by technical department, test department, operation department, maintenance department and compliance department. However, in our previous review, we may paid more attention on the functions of product, this cause some omission in the processing of some requirements, we need pay more attention on the review of code and rules
In the subsequent product update, we will strengthen the review of the code, conduct regular training of RFC 5280 and Baseline Requirements for new colleagues, so that more colleagues can understand the rules clearly, avoid similar things happen again
Thanks for the advice, which will greatly help us to improve ourselves.