Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

CA Communication - May 12, 2014

55 views
Skip to first unread message

Kathleen Wilson

unread,
May 12, 2014, 1:40:27 PM5/12/14
to mozilla-dev-s...@lists.mozilla.org
All,

The final draft of the CA Communication is here:
https://wiki.mozilla.org/CA:Communications#May_12.2C_2014

If you have further comments or feedback on this, please send your input
now.
Otherwise, I will send the communication (via email) this afternoon.

Thanks,
Kathleen

Kurt Roeckx

unread,
May 12, 2014, 2:07:23 PM5/12/14
to Kathleen Wilson, mozilla-dev-s...@lists.mozilla.org
On Mon, May 12, 2014 at 10:40:27AM -0700, Kathleen Wilson wrote:
> All,
>
> The final draft of the CA Communication is here:
> https://wiki.mozilla.org/CA:Communications#May_12.2C_2014

So I've asked about this before but I think you never replied. It
doesn't mention anything about the EV audit. Is that intentional?


Kurt

Kathleen Wilson

unread,
May 12, 2014, 2:42:44 PM5/12/14
to mozilla-dev-s...@lists.mozilla.org
Sorry, guess I missed that question.

Usually the CAs that have EV enabled send me both their non-EV and EV
audit statements at the same time. It's something I check for too.
So, while action #1 doesn't specifically say anything about the EV
audit, I will be sure to follow up with any EV-enabled CA who forgets to
send me the EV audit statement too.

Thanks,
Kathleen

Rob Stradling

unread,
May 12, 2014, 3:28:57 PM5/12/14
to Kathleen Wilson, mozilla-dev-s...@lists.mozilla.org
On 12/05/14 18:40, Kathleen Wilson wrote:
> All,
>
> The final draft of the CA Communication is here:
> https://wiki.mozilla.org/CA:Communications#May_12.2C_2014
>
> If you have further comments or feedback on this, please send your input
> now.
> Otherwise, I will send the communication (via email) this afternoon.

Kathleen,

https://bugzilla.mozilla.org/show_bug.cgi?id=991815#c24
...sounded like a reasonable plan to me.

Yet AFAICT somewhere between comment 24 and comment 28 you've elected to
bypass the CABForum process.

The BRs permit OCSP Responses for Intermediate CA Certificates to be
valid for <=12 months. Suddenly declaring that validity periods of >10
days are forbidden is likely to take quite a few CAs by surprise.
Calling this something for "CAs to _fix_" is likely to prompt "Why, what
rule have we broken?" questions from CAs.

<=12 months are permitted so that CAs don't have to access their offline
root keys frequently, so I think you should expect a backlash from CAs
that would consider it onerous to have to access their offline root keys
every <=10 days.

And once the CAs learn that this is only a temporary measure until
Mozilla implement something akin to CRLSets for intermediate certificate
revocation, well, that will just rub salt into their wounds!

(BTW, Comodo don't have a problem with <=10 days for intermediate OCSP
response validity periods, and personally I would like to see it set
even lower than that. But could we please introduce change in an
orderly fashion?)

--
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online

Jeremy Rowley

unread,
May 12, 2014, 3:45:16 PM5/12/14
to Rob Stradling, Kathleen Wilson, mozilla-dev-s...@lists.mozilla.org
+1. This is especially true in the federal space where some intermediates
are stored offline most of the time. Per Section 4.9.7 of the FBCA CP,
these CAs use a 31-day interval for status information. Bringing the CA
online to generate responses every 10 days will actually make those CAs less
secure.

Jeremy
_______________________________________________
dev-security-policy mailing list
dev-secur...@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Kathleen Wilson

unread,
May 12, 2014, 4:40:05 PM5/12/14
to mozilla-dev-s...@lists.mozilla.org
>
> https://bugzilla.mozilla.org/show_bug.cgi?id=991815#c24
> ...sounded like a reasonable plan to me.
>
> Yet AFAICT somewhere between comment 24 and comment 28 you've elected to
> bypass the CABForum process.
>
> The BRs permit OCSP Responses for Intermediate CA Certificates to be valid
> for <=12 months. Suddenly declaring that validity periods of >10 days are
> forbidden is likely to take quite a few CAs by surprise.
> Calling this something for "CAs to _fix_" is likely to prompt "Why, what
> rule have we broken?" questions from CAs.


OK. I removed it from the "Things for CAs to Fix" section, and left it
in the "Future Considerations" section.

https://wiki.mozilla.org/SecurityEngineering/mozpkix-testing#Things_for_CAs_to_Fix

I also updated bug #1009110 with this information.

Thanks,
Kathleen

Patrick Kobly

unread,
May 14, 2014, 1:06:57 PM5/14/14
to mozilla-dev-s...@lists.mozilla.org
On Monday, 12 May 2014 13:45:16 UTC-6, Jeremy Rowley wrote:
> +1. This is especially true in the federal space where some intermediates
>
> are stored offline most of the time. Per Section 4.9.7 of the FBCA CP,
>
> these CAs use a 31-day interval for status information. Bringing the CA
>
> online to generate responses every 10 days will actually make those CAs less
>
> secure.

Perhaps I'm dense and missing something or perhaps this isn't the right place to be asking. Why would this necessitate bringing the CA online when responses can be signed by an Authorized Responder (i.e. cert with EKU id-kp-OCSPSigning)?

FWIW, Rob's concerns regarding the change process are certainly reasonable.

PK

Jeremy Rowley

unread,
May 14, 2014, 2:42:34 PM5/14/14
to Patrick Kobly, mozilla-dev-s...@lists.mozilla.org
Not everyone signs with responders since they add bulk and complexity into
the system.

-----Original Message-----
From: dev-security-policy
[mailto:dev-security-policy-bounces+jeremy.rowley=digice...@lists.mozilla
.org] On Behalf Of Patrick Kobly
Sent: Wednesday, May 14, 2014 11:07 AM
To: mozilla-dev-s...@lists.mozilla.org
Subject: Re: CA Communication - May 12, 2014

On Monday, 12 May 2014 13:45:16 UTC-6, Jeremy Rowley wrote:
> +1. This is especially true in the federal space where some
intermediates
>
> are stored offline most of the time. Per Section 4.9.7 of the FBCA CP,
>
> these CAs use a 31-day interval for status information. Bringing the CA
>
> online to generate responses every 10 days will actually make those CAs
less
>
> secure.

Perhaps I'm dense and missing something or perhaps this isn't the right
place to be asking. Why would this necessitate bringing the CA online when
responses can be signed by an Authorized Responder (i.e. cert with EKU
id-kp-OCSPSigning)?

FWIW, Rob's concerns regarding the change process are certainly reasonable.

PK

Brian Smith

unread,
May 14, 2014, 3:42:34 PM5/14/14
to Patrick Kobly, mozilla-dev-s...@lists.mozilla.org
On Wed, May 14, 2014 at 10:06 AM, Patrick Kobly <pat...@kobly.com> wrote:

> Perhaps I'm dense and missing something or perhaps this isn't the right
> place to be asking. Why would this necessitate bringing the CA online when
> responses can be signed by an Authorized Responder (i.e. cert with EKU
> id-kp-OCSPSigning)?
>

Right. Bulk preproduction of direct-signed OCSP responses is another way of
handling it. Nobody wants CA certificates to be online more than otherwise
necessary just to support shorter validity periods for OCSP responses.


> FWIW, Rob's concerns regarding the change process are certainly reasonable.
>

We did not intentionally want to short-circuit any process. I implemented
the restriction to 10 days due to a misunderstanding of the baseline
requirements, and then we decided my misunderstanding is better than what
the BRs would say, so we considered leaving my misunderstanding in the code
while we concurrently worked to improve the BRs to match my
misunderstanding. Ultimately, we decided to revert to the less-reasonable
but more compatible behavior.

It is OK (good even) for us to add additional requirements that go beyond
the baseline & EV requirements and not everything has to be approved
through CAB Forum. We do it all the time (otherwise our CA program
documentation would consist solely of "See the Baseline Requirements and EV
Requirements"). Google is doing the same with their proposed CT
requirements for EV. In this case, though, it was just an accident.

Cheers,
Brian
0 new messages