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

Reply via email to