[Servercert-wg] Ballot SC30: Disclosure of Registration / Incorporating Agency

[Pedro FUENTES]

Hello,
I understand your rational.

My opinion was just that disclosing a first source a limited timeframe doesn’t affect to transparency and audibility in terms of proving which source was used for each certificate (audits happen typically after issuance). I just thought that sometimes processes like updating a webpage where the list is published can be done by another team and this can delay issuances… but if this was discussed and ruled out, then I’m fine.

Best,
Pedro

> On 17 Jun 2020, at 15:53, Ryan Sleevi <sleevi at google.com> wrote:
> 
> 
> 
> On Wed, Jun 17, 2020 at 9:36 AM Pedro FUENTES <pfuentes at wisekey.com <mailto:pfuentes at wisekey.com>> wrote:
> Hello,
> I’d have a comment on the proposed wording, but I don’t find the right way to post it on GitHub.
> 
> You can use https://github.com/cabforum/documents/pull/194 <https://github.com/cabforum/documents/pull/194> to do this (in the Files tab, you can click + next to any line to leave an in-line comment, as well as suggest changes)
>  
> Would it be acceptable to allow a certain margin to disclose the agency “after x days of issuance”, instead of forcing it to be always “prior”? 
> 
> My rational is trying to cover the situation where it comes a request from a country/region unusual for the CA and it has to use a new agency that wasn’t listed yet. This would allow that the CA can issue the certificate after choosing the right agency, and it should still commit to disclose the sources, but this wouldn’t block the issuance. A reasonable time could be 3 days, for example.
> 
> This was discussed in the Validation WG, but unfortunately, this fails to meet the goal of ensuring transparency and auditability. The intent is, just like any other validation process, the validation needs to be completed before you actually issue. 
> 
> The process is designed to be so incredibly lightweight that post-facto disclosure should not be necessary, and no different than validating new documents. If you anticipate significant challenges disclosing, above and beyond the validation process, it would be useful to explain why.
> 
> The danger of such an allowance is, unsurprisingly, that such disclosures fail to happen. It also makes it indistinguishable from misissuance. Finally, it doesn't help the overall goal, which is having concrete data about these scenarios, that can be neutrally, objectively, and independently assessed, which of course is critical to finding a viable long-term solution to ensure cross-CA consistency.
> 
> So yes, this was discussed, but it also was rejected. It's difficult to see how such post-facto disclosure would be able to meet these goals. Please let me know if there was something overlooked, however!


WISeKey SA
Pedro Fuentes
CSO - Trust Services Manager
Office: + 41 (0) 22 594 30 00
Mobile: + 41 (0) 791 274 790
Address: 29, Rte de Pré-Bois - CP 853 | Geneva 1215 CH - Switzerland
Stay connected with WISeKey <http://www.wisekey.com/>

THIS IS A TRUSTED MAIL: This message is digitally signed with a WISeKey identity. If you get a mail from WISeKey please check the signature to avoid security risks

CONFIDENTIALITY: This email and any files transmitted with it can be confidential and it’s intended solely for the use of the individual or entity to which they are addressed. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. If you have received this email in error please notify the sender

DISCLAIMER: WISeKey does not warrant the accuracy or completeness of this message and does not accept any liability for any errors or omissions herein as this message has been transmitted over a public network. Internet communications cannot be guaranteed to be secure or error-free as information may be intercepted, corrupted, or contain viruses. Attachments to this e-mail are checked for viruses; however, we do not accept any liability for any damage sustained by viruses and therefore you are kindly requested to check for viruses upon receipt.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/servercert-wg/attachments/20200617/e6137b43/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3408 bytes
Desc: not available
URL: <http://lists.cabforum.org/pipermail/servercert-wg/attachments/20200617/e6137b43/attachment-0001.p7s>