Re: The CAA DNS Operator Exception Is Problematic
On Wed, Feb 10, 2021 at 02:21:53AM +, Nick Lamb via dev-security-policy wrote: > On Mon, 8 Feb 2021 13:40:05 -0500 > Andrew Ayer via dev-security-policy > wrote: > > > The BRs permit CAs to bypass CAA checking for a domain if "the CA or > > an Affiliate of the CA is the DNS Operator (as defined in RFC 7719) > > of the domain's DNS." > > Hmm. Would this exemption be less dangerous for a CA which is the > Registry for the TLD ? I understand this would remove one way to shoot yourself in the foot. > [...], but it seems like it's pretty clear > that either you are the registry for some TLD or you aren't, and so > that confusion ought not to arise in this case. The argument is that theoretically this could work, but in practice people get this wrong. Examples were given that confusion in fact happens. -- pozdrawiam / best regards Wojtek Porczyk Graphene / Invisible Things Lab I do not fear computers, I fear lack of them. -- Isaac Asimov signature.asc Description: PGP signature ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Policy 2.7.1: MRSP Issue #192: Require information about auditor qualifications in the audit report
On Thu, Nov 05, 2020 at 11:48:20AM -0500, Ryan Sleevi via dev-security-policy wrote: > competency is with individuals, not organizations. [snip] > I find the appeal to redundancy and the NAB, and further, the suggestion of > GDPR, to be a bit insulting to this community. This opposition to > transparency fundamentally undermines the trust in ETSI provided audits, or > this appeal to the eIDAS scheme, which has limited relevance given it's a > fundamentally different audit scheme, beggars belief. If you'd like to > raise Fear/Uncertainty/Doubt about GDPR, I believe you owe this community a > precise and detailed explanation about what you believe, relevant to the > auditor professional experience, would be problematic. Not the original poster, but 1) I understand that the very general language of OP, which you dismiss as FUD, is because this is "consult your own lawyer" area; 2) contrary to what you have written, the onus is on Mozilla to demonstrate the compliance with GDPR and not the other way around. If Mozilla (or you personally, in your capacity as peer, doesn't matter) intend to keep track of competency of people (like "physical people" and not corporations), those people (at least those, who perform audits in Europe) have certain rights from Mozilla under GDPR. You can't have it both ways -- either you keep trust in organisations and ignore GDPR, or you keep trust in people, and then you have all those GDPR requirements. Those are not hard to fulfill, but they would have to be thought through before the policy takes effect. I have found nothing in either the proposed change, or your response, that this problem has been thought through. For example, art. 13 of GDPR specifies that the data subject (the auditor) is to be provided with information that the data about her/him is processed. In the spirit of transparency, could you post an example notice which would be sent to the auditor in question? What would be the legal basis? (art. 6) If (e) or (f), the auditor has a right to object; what would happen after the objection? Have Mozilla appointed a representative in the EU (art. 27)? (I just checked and I have found only "Attn: Legal" address in USA). If not, why? If yes, what's his/her name and contact details? -- pozdrawiam / best regards Wojtek Porczyk I do not fear computers, I fear lack of them. -- Isaac Asimov signature.asc Description: PGP signature ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Proposal: Make readable CPSes easier to find
On Tue, Apr 21, 2020 at 01:23:49AM -0400, Ryan Sleevi via dev-security-policy wrote: > On Mon, Apr 20, 2020 at 10:04 PM Matt Palmer via dev-security-policy > wrote: > > 2. Make the cPSuri actually point to the relevant CPS > > That doesn’t really capture what a CPS is. There can be many relevant CPSes > to a single certificate, both for a single path and multiple paths. That’s > literally how audits came to be - to support the model of multiple CPSes. > > So a statement like “the relevant CPS” is going to be flawed, for better or > worse. That’s a much bigger change to make (in how policies are managed). > Despite the merits of forbidding the policy-based approach proposed by the > ABA PAG, the problem reporting email is probably the least compelling > reason for scrapping that :( > > However, that seems moot if addressed as above? I don't see the contradiction. CA could embed values like https://ca.example/cps?serial=123abc and make sure that only documents relevant to the certificate in question are listed. This statement, snipped from above: > This is exactly the sort of case CCADB is supremely positioned to solve, > efficiently. In fact, all of these problems can be addressed by CCADB > improvements, providing programmatically readable data while also making > use of efficiencies and economies of scale. makes me curious: do you think CCADB could be leveraged to provide such a list? To make it recommended (or even mandatory) to link to CCADB-provided query mechanism for such documents. -- pozdrawiam / best regards _.-._ Wojtek Porczyk .-^' '^-. Invisible Things Lab |'-.-^-.-'| | | | | I do not fear computers,| '-.-' | I fear lack of them.'-._ : ,-' -- Isaac Asimov `^-^-_> signature.asc Description: PGP signature ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Is issuing a certificate for a previously-reported compromised private key misissuance?
On Thu, Mar 19, 2020 at 05:30:31AM -0500, Ryan Sleevi via dev-security-policy wrote: > [...] but given that some negligent and > irresponsible CAs kept agitating to reduce revocation requirements than > protect users, the ballot was kept simple. > [...] I worry the same set of negligent and irresponsible > CAs will try to advocate for more CA discretion when revocation, such as > allowing the CA to avoid revoking when they’ve mislead the community as to > what they do (CP/CPS violations) or demonstrated gross incompetence (such > as easily detected spelling issues in jurisdiction information). > > I would hope no CA would be so irresponsible as to try to bring that up > during such a discussion. If I'm reading this correctly, you're labeling some CAs as negligent, irresponsible and incompetent basing on the discussion and/or voting in CA/B Forum. But those are adjectives that are inverse of what is required of CAs to have roots included in root store [0]. Additionally, I've seen multiple statements, some of them under official hats, that Mozilla treats CA conduct holisticaly when assessing trust (I don't have reference handy). Do you think that Mozilla may in the future consider voting or discussing "wrong" (for any definition of "wrong") as having impact on general trust that Mozilla has placed in a particular CA? (Maybe I'm exaggerating, but just think of it: " Issues. Issue X: failure to vote YES on ballot "). [0] "Including any CA carries a level of risk that is measured, in part, by the past record of the CA (or lack thereof), their responsiveness (or lack thereof), and the level of competence and precision demonstrated by the CA during the inclusion process."; "Having a root certificate you control included in Mozilla's root store is a major ongoing responsibility" (both from https://wiki.mozilla.org/CA/Application_Process) -- pozdrawiam / best regards _.-._ Wojtek Porczyk .-^' '^-. (under personal hat) |'-.-^-.-'| | | | | I do not fear computers,| '-.-' | I fear lack of them.'-._ : ,-' -- Isaac Asimov `^-^-_> signature.asc Description: PGP signature ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
