Re: About upcoming limits on trusted certificates

[Ryan Sleevi via dev-security-policy]

On Sat, Mar 14, 2020 at 2:54 PM Nick Lamb via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> On Thu, 5 Mar 2020 14:15:17 +
> Nick Lamb via dev-security-policy
>  wrote:
>
> > There is some value in policy alone but there's also substantial
> > independent value in writing the policy into the code. Would Mozilla
> > accept third party work to implement something like #908125 ? I
> > appreciate you don't work for them any more Wayne, perhaps Kathleen or
> > somebody else who does can answer?
>
> I never saw any reply on this topic and so my assumption is that at
> best such a patch would be in the big pile of volunteer stuff maybe
> nobody has time to look at.


Writing code is usually the last step, and can be premature during the
discussion phase, because it tends to unnecessary anchor the conversation.

As I understand it Apple's intent is that Safari will not accept a
> certificate with a lifetime of (let's say for this example) 500 days,
> but this would not necessarily become a violation of their root store
> policy. Such a certificate could exist and (absent decisions here) it
> would work in Firefox but not Safari. More practically, it would work
> in some TLS-based internal system that trusts public roots, but not in
> Safari, which would be just fine for a backend system that was never
> actually intended to be used by web browsers.


That understanding does not seem consistent with past messaging.

This would make it like SCT enforcement in Safari or Chrome. Google
> doesn't propose to distrust a CA which issues certificates without
> logging them - it just ensures the Chrome browser doesn't trust those
> certificates until it is shown proof they were logged, which might be
> hours or weeks later.


Correct, in that like Apple, Chrome offers folks who own and administer the
device to configure exceptions regarding logging.

I think it’s important to highlight that these are meaningfully different,
however, in that lifetime (and reuse) can be objectively qualified
independent of policy, while policies like CT or “publicly trusted” are
semi-dependent upon policy (e.g. the set of trusted logs or CAs). Root
stores have fairly consistently treated violations of objectively
quantifiable criteria as root store program violations/incidents. A more
apt example is Mozilla policy with respect to signature algorithms.

As I understand it Google's own CA deliberately
> does this in fact.


No, that’s not correct.

If that understanding is correct (again the poor communication from
> Apple which I already disapproved of doesn't help me) then in having an
> unenforced root store policy about this, rather than enforcement but no
> policy change, Mozilla would be standing alone.


As an aside, the asides don’t help. Let’s at least recognize this is Apple
engaging more than they have in the past two decades, and appreciate that
they’ve been willing to discuss to the limits they have. Baby steps, and
positive changes should be recognized as such.

I do disagree the suggestion of “standing alone”. Policy and enforcement
are complementary yet independent actions.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: About upcoming limits on trusted certificates

[Nick Lamb via dev-security-policy]

On Thu, 5 Mar 2020 14:15:17 +
Nick Lamb via dev-security-policy
 wrote:

> There is some value in policy alone but there's also substantial
> independent value in writing the policy into the code. Would Mozilla
> accept third party work to implement something like #908125 ? I
> appreciate you don't work for them any more Wayne, perhaps Kathleen or
> somebody else who does can answer?

I never saw any reply on this topic and so my assumption is that at
best such a patch would be in the big pile of volunteer stuff maybe
nobody has time to look at.


After some further thought this gives me a real concern that maybe is
an error (in which case I'm sure somebody here will be delighted to
correct me)

As I understand it Apple's intent is that Safari will not accept a
certificate with a lifetime of (let's say for this example) 500 days,
but this would not necessarily become a violation of their root store
policy. Such a certificate could exist and (absent decisions here) it
would work in Firefox but not Safari. More practically, it would work
in some TLS-based internal system that trusts public roots, but not in
Safari, which would be just fine for a backend system that was never
actually intended to be used by web browsers.

This would make it like SCT enforcement in Safari or Chrome. Google
doesn't propose to distrust a CA which issues certificates without
logging them - it just ensures the Chrome browser doesn't trust those
certificates until it is shown proof they were logged, which might be
hours or weeks later. As I understand it Google's own CA deliberately
does this in fact.

If that understanding is correct (again the poor communication from
Apple which I already disapproved of doesn't help me) then in having an
unenforced root store policy about this, rather than enforcement but no
policy change, Mozilla would be standing alone.

That has much larger implications, so if that's what we're talking
about here we need to be clear about it.


Nick.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Acceptable forms of evidence for key compromise

[Wayne Thayer via dev-security-policy]

I've created https://github.com/mozilla/pkipolicy/issues/205 to consider
adding a requirement to a future version of Mozilla policy for CAs to
either support a standardized mechanism for proving key compromise, or to
publish acceptable mechanism(s) in their CPS.

- Wayne

On Mon, Mar 2, 2020 at 2:38 PM Corey Bonnell via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> Using ACME as the revocation reporting mechanism moves the issue from
> using a bespoke proof-of-possession/revocation request protocol to a known
> address (i.e., the problem-reporting address disclosed in each CA’s
> CPS/CCADB) to an issue of using a known proof-of-possession/revocation
> protocol to a largely non-discoverable address (i.e., the “revoke-cert”
> endpoint of each CA’s ACME server).
>
>
>
> There is no central registry of ACME directory URLs, so still significant
> work would be required to make ACME’s “revoke-cert” endpoint useful across
> CAs.
>
>
>
> As an alternative, a standard “revocation request” format could be
> developed that leverages the relative discoverability of each CA’s
> problem-reporting mechanism.
>
>
>
> Thanks,
>
> Corey
>
>
>
> From: Rob Stradling 
> Sent: Monday, March 2, 2020 4:31 PM
> To: Nick Lamb ; mozilla-dev-security-policy <
> mozilla-dev-security-pol...@lists.mozilla.org>; Corey Bonnell <
> cbonn...@securetrust.com>
> Cc: Matt Palmer 
> Subject: Re: Acceptable forms of evidence for key compromise
>
>
>
> "I do think there's value in developing some standard mechanism to request
> revocation/demonstrate possession of the private key."
>
>
>
> Such as https://tools.ietf.org/html/rfc8555#section-7.6 <
> https://scanmail.trustwave.com/?c=4062=lfvd3rlkzXccymkP6MZsFT-gOI-ZJlGuK4Mm7tnSoQ=5=https%3a%2f%2ftools%2eietf%2eorg%2fhtml%2frfc8555%23section-7%2e6>
> ?
>
>
>
> ISTM that any CA could stand up a standalone "revokeCert" API that only
> accepts proofs signed by the private key associated with the certificate,
> without that CA having to implement the rest of RFC8555.  Would this count
> as a "standard mechanism" (given that it's a portion of a Standards Track
> RFC)?  If so, why don't we simply say that this is the "standard mechanism"?
>
>
>
> @Matt: I read your tweet (
> https://twitter.com/tobermatt/status/1232779464783695873 <
> https://scanmail.trustwave.com/?c=4062=lfvd3rlkzXccymkP6MZsFT-gOI-ZJlGuK9l05N2C8g=5=https%3a%2f%2ftwitter%2ecom%2ftobermatt%2fstatus%2f1232779464783695873>
> ) as proposing this idea, but ISTM that you've stopped slightly short of
> actually proposing it in this list thread.  
>
>
>
> @Sleevi: JWS certainly isn't my favourite format, but ISTM that the WebPKI
> is kinda stuck with it now (see RFC8555).
>
>
>
>   _
>
> From: dev-security-policy   > on behalf of
> Corey Bonnell via dev-security-policy <
> dev-security-policy@lists.mozilla.org  dev-security-policy@lists.mozilla.org> >
> Sent: 02 March 2020 19:48
> To: Nick Lamb mailto:n...@tlrmx.org> >;
> mozilla-dev-security-policy   >
> Cc: Matt Palmer mailto:mpal...@hezmatt.org> >
> Subject: RE: Acceptable forms of evidence for key compromise
>
>
>
> CAUTION: This email originated from outside of the organization. Do not
> click links or open attachments unless you recognize the sender and know
> the content is safe.
>
>
> There was quite a bit of discussion on the development of a standard
> revocation request format on LAMPS WG mailing list two years ago in the
> wake
> of the Trustico mass revocation:
> https://mailarchive.ietf.org/arch/msg/spasm/qeVHLeG6-Q_47QKNdyOOxsAT3Zk/ <
> https://scanmail.trustwave.com/?c=4062=lfvd3rlkzXccymkP6MZsFT-gOI-ZJlGuK4xz54WB8A=5=https%3a%2f%2fmailarchive%2eietf%2eorg%2farch%2fmsg%2fspasm%2fqeVHLeG6-Q%5f47QKNdyOOxsAT3Zk%2f>
> .
> Nothing was developed in terms of a concrete proposal specifying a
> revocation
> request format/protocol, but the pros/cons of such were hashed out pretty
> thoroughly.
>
> I do think there's value in developing some standard mechanism to request
> revocation/demonstrate possession of the private key. The use of such a
> mechanism would reduce the burden of work for those reporting key
> compromises,
> as the reporter would not need to learn how to demonstrate possession the
> private key 15 different ways to 15 different CAs. And CAs would benefit
> from
> such a mechanism, as they wouldn't need to spend support cycles working
> with
> the reporter to arrive at a suitable means to demonstrate possession or
> have
> to learn some exoteric software tooling that the reporter is using to prove
> possession.
>
> Thanks,
> Corey
>
> -Original Message-
> From: dev-security-policy   > On
> Behalf Of Nick Lamb via dev-security-policy
> Sent: Monday, March 2, 2020 2:35 PM
> To: dev-security-policy@lists.mozilla.org  dev-security-policy@lists.mozilla.org>
> Cc: Matt Palmer