[Intro; long time lurker but I rarely post, but given this is an open question not directly tied to any CA or official capacity my opinions are..]
On 08/18/2017 05:02 PM, Gervase Markham via dev-security-policy wrote: > Sometimes, CAs apply for inclusion with new, clean roots. Other times, > CAs apply to include roots which already have a history of issuance. The > previous certs issued by that CA aren't always all BR-compliant. Which > is in one sense understandable, because up to this point the CA has not > been bound by the BRs. Heck, the CA may never even have heard of the BRs > until they come to apply - although this seems less likely than it would > once have been. > > What should our policy be regarding BR compliance for certificates > issued by a root requesting inclusion, which were issued before the date > of their request? Do we: > Iff the CA has known non-BR compliant certs issued I would be in favor of the CA setting up a new, clean root certificate for the inclusion in the root program at this point, and require all the certificates issued by the approved root to be BR compliant. > A) Require all certs be BR-compliant going forward, but grandfather in > the old ones; or > B) Require that any non-BR-compliant old certs be revoked; or > C) Require that any seriously (TBD) non-BR-compliant old certs be > revoked; or > If new root required for non-BR compliant history, the issues above seems mitigated D) something else? Yes please -- ---------------------------- Kristian Fiskerstrand Blog: https://blog.sumptuouscapital.com Twitter: @krifisk ---------------------------- Public OpenPGP keyblock at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 ---------------------------- Nil satis nisi optimum Nothing but the best is good enough
signature.asc
Description: OpenPGP digital signature
_______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
