On Sat, Nov 14, 2020 at 11:52 PM Nick Lamb <n...@tlrmx.org> wrote: > On Sat, 14 Nov 2020 17:05:26 -0500 > Ryan Sleevi <r...@sleevi.com> wrote: > > > I don't entirely appreciate being told that I don't know what I'm > > talking about, which is how this reply comes across, but as I've > > stated several times, the _original_ language is sufficient here, > > it's the modified language that's problematic. > > That part of my statement was erroneous - of the actual texts I've seen > proposed so far I prefer this amended proposal from Ben: > > "Section 4.9.12 of a CA's CP/CPS MUST clearly specify its accepted > methods that Subscribers, Relying Parties, Application Software > Suppliers, and other third parties may use to demonstrate private key > compromise. A CA MAY allow additional, alternative methods that do not > appear in section 4.9.12 of its CP/CPS." > > I can't tell from here whether you know what you're talking about, only > whether I know what you're talking about, and I confess after some > effort I don't believe I was getting any closer. > > Still, I believe this language can be further improved to achieve the > goals of #205. How about: > > "Section 4.9.12 of a CA's CP/CPS MUST clearly specify one or more > accepted methods that Subscribers, Relying Parties, Application Software > Suppliers, and other third parties may use to demonstrate private key > compromise. A CA MAY allow additional, alternative methods that do not > appear in section 4.9.12 of its CP/CPS." > > > This makes clear that the CA must have at least one of these "clearly > specified" accepted methods which ought to actually help Matt get some > traction. >
I can tell we're not making any progress here, as this doesn't really address the concerns I've highlighted twice. This would be a regression from the proposed language, and would be a further regression from the original language here. _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy