Grace Periods for Mozilla CA Certificate Policy V2.1

[Kathleen Wilson]

All,

In regards to the proposed policy updates that are shown in red text here:
http://www.mozilla.org/projects/security/certs/policy/WorkInProgress/InclusionPolicy.html

We need to determine the expectations for when CAs will need to be
compliant with the updated policy, which will be version 2.1, after it
is published.

I have created a proposal for what this may look like here:
https://wiki.mozilla.org/CA:CertPolicyUpdates#Transitioning_to_the_Updated_Policy_Version_2.1

I will greatly appreciate your thoughtful and constructive feedback on this.

Kathleen

[Kathleen Wilson]

Why I proposed the time frames that I did...

>> Grace Period: As of <12 months after v2.1 published> there shall be
no more end-entity certificates being issued to customers that are
directly signed by a trust anchor that is included in NSS.

There are only a couple of these, and they will need time to create new
hierarchies, etc. If their change also requires that they create and
include a new root cert in NSS, they may need more time, but I don't
want to leave this open-ended.


>> Grace Period (re the new #9): All new externally-operated
subordinate CAs must meet this requirement as of <3 months after v2.1
published>. All pre-existing externally-operated subordinate CAs must
meet this requirement by <18 months after v2.1 published>

Very large enterprise customers will have to request the funding in
their annual budget cycles, and may end up with significant IT impact.
For instance, if one of these very large enterprise customers decides
that they will be audited and publicly disclosed, they will probably
need to invest in infrastructure to separate out their subCA systems
from the rest of their operations, in order to make the 3rd party audit
possible.

It is possible that there will be some very large enterprise customers
who may need more time than this. I would like to identify a reasonable
date that everyone should strive to achieve, and handle the very large
enterprise customers as exceptions if they can justify why they need to
take an exception. This isn't normally the way we do things, but it may
be needed in a small number of cases.

Kathleen

[Carsten.D...@t-systems.com]

Hi Kathleen, All,

> >> Grace Period (re the new #9): All new externally-operated
> subordinate CAs must meet this requirement as of <3 months after v2.1
> published>. All pre-existing externally-operated subordinate CAs must
> meet this requirement by <18 months after v2.1 published>

As T-System has raised concerns regarding #9 before, we would like to give
some feedback.

> Very large enterprise customers will have to request the funding in
> their annual budget cycles, and may end up with significant IT impact.
> For instance, if one of these very large enterprise customers decides
> that they will be audited and publicly disclosed, they will probably
> need to invest in infrastructure to separate out their subCA systems
> from the rest of their operations, in order to make the 3rd party
> audit possible.

We have started investigations with our large enterprise Sub-CAs for possible solutions to comply with Mozilla's new policy V2.1 . Currently there are different scenarios under discussion. As you assumed, all would have a definite impact to already existing infrastructure. Anyhow - the suggested roadmap (18 months) would give time to implement the needed changes.

In case of technical constraints:
As the current Sub-CA certificates will have to include additional information (EKU, Path Length & Name Constraints) we would have to set up new Sub-CA certificates in parallel and start issuing new EE certificates from this "augmented" Sub-CAs. Therefore the first question would be, whether this is still a "pre-existing" Sub-CA in regards to your requirement - from a technical point of view this clearly is a "new" one, which would significantly reduce the grace period from 18 to 3 months. I guess, this should be a valid question for all enterprise Sub-CAs, which are not planning to conduct an independent audit.

The more important question is how we would ensure that there is no impact for the valid EE certificates issued in the past. We assume that it is not Mozilla's intention to revoke and re-issue thousands of web server even worse ten thousands smartcards enterprise customers have issued. Especially in case of smartcards issued across Europe this would lead to an enormous effort - both, financial and organizational.

Best regards,
Carsten

Carsten Dahlenkamp
T-Systems International GmbH
Trust Center Applications
Untere Industriestraße 20, 57250 Netphen, Germany
+49 271 708-1643 (Tel.)
E-Mail: carsten.d...@t-systems.com
http://www.t-systems.com, http://www.telesec.de

[Steve Roylance]

Hi Carsten.

I'm not sure if it helps, but GlobalSign is also busy planning to either
renew any existing CA's (Adding name constraints) or moving our customers
to an external rather than internal auditing model. The latter is
difficult to quantify in terms of cost, structure, timeframe etc and
therefore (in my opinion) we'll end up constraining all issuing CA's.

This leads to the existing, non constrained CAs. As you pointed out, they
still need to produce CRLs and/or OCSP response until such time that the
last certificate has expired. This could be up to 3 years. Whilst all
parties wish to accelerate the demise of the current implementations,
moving to new infrastructure as soon as possible, it's very likely that
there will sill be 'unconstrained' certificates alive in the future that
were created prior to the new rules. I feel this is fine and I would
suspect that this was always understood by everyone to be a controlled
replacement exercise, but I thought it best to state it to the list to be
safe.

Steve



On 18/05/2012 14:01, "Carsten.D...@t-systems.com"

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

[Kathleen Wilson]

> This leads to the existing, non constrained CAs. As you pointed out, they
> still need to produce CRLs and/or OCSP response until such time that the
> last certificate has expired. This could be up to 3 years. Whilst all
> parties wish to accelerate the demise of the current implementations,
> moving to new infrastructure as soon as possible, it's very likely that
> there will sill be 'unconstrained' certificates alive in the future that
> were created prior to the new rules. I feel this is fine and I would
> suspect that this was always understood by everyone to be a controlled
> replacement exercise, but I thought it best to state it to the list to be
> safe.
>

As we have done in the past, I was assuming that existing end-entity
certs would be grandfathered in.

I added *for new certificate issuance*...

"Grace Period: All new externally-operated subordinate CAs must meet

this requirement as of <3 months after v2.1 published>. All pre-existing

externally-operated subordinate CAs must meet this requirement for new
certificate issuance by <18 months after v2.1 published>"

Does that help?

>> As the current Sub-CA certificates will have to include additional

>> information (EKU, Path Length& Name Constraints) we would have to set

>> up new Sub-CA certificates in parallel and start issuing new EE certificates
>> from this "augmented" Sub-CAs. Therefore the first question would be,
>> whether this is still a "pre-existing" Sub-CA in regards to your requirement
> - from a technical point of view this clearly is a "new" one, which would
>> significantly reduce the grace period from 18 to 3 months. I guess, this
>> should be a valid question for all enterprise Sub-CAs, which are not
>> planning to conduct an independent audit.

The text is meant to be from a technical point of view. Should I add the
word "certificates" to make that more clear? Then it would become:

""Grace Period: All new externally-operated subordinate CA certificates

must meet this requirement as of <3 months after v2.1 published>."

Kathleen

[Steve Roylance]

Hi Kathleen.

That's clear from my side and matches my view of what's realistically
expected from us.

Thanks and have a nice weekend.

Steve

[Steve Schultze]

On 5/18/12 12:02 PM, Kathleen Wilson wrote:
> I added *for new certificate issuance*...
>
> "Grace Period: All new externally-operated subordinate CAs must meet
> this requirement as of <3 months after v2.1 published>. All pre-existing
> externally-operated subordinate CAs must meet this requirement for new
> certificate issuance by <18 months after v2.1 published>"
>
> Does that help?

So, just to play this out... our threat model is that a SubCA (or an
attacker who compromises a SubCA) falsely issues certificates to itself
or others that do not in fact control the domain listed in he cert. Our
assumption is that the contents of the certificates are unreliable
because the issuer does not meet the requirements.

The proposal is to nevertheless continue trusting the issuance date in
EE certs.

So if I'm an attacker who has compromised a SubCA, the proposed changes
don't affect me until the SubCA itself expires. I just issue certs to
myself with an issuance date prior to the "cutoff."

So the 18-month or 3-month transition timeline is irrelevant, and the
relevant timeline is the expiration date of the (undisclosed) SubCAs in
existence.

Or am I missing something?

[ianG]

On 19/05/12 05:29 AM, Steve Schultze wrote:
> On 5/18/12 12:02 PM, Kathleen Wilson wrote:

>> I added *for new certificate issuance*...
>>
>> "Grace Period: All new externally-operated subordinate CAs must meet
>> this requirement as of <3 months after v2.1 published>. All pre-existing
>> externally-operated subordinate CAs must meet this requirement for new
>> certificate issuance by <18 months after v2.1 published>"
>>
>> Does that help?
>

> So, just to play this out... our threat model is that a SubCA (or an
> attacker who compromises a SubCA) falsely issues certificates to itself
> or others that do not in fact control the domain listed in he cert. Our
> assumption is that the contents of the certificates are unreliable
> because the issuer does not meet the requirements.
>
> The proposal is to nevertheless continue trusting the issuance date in
> EE certs.

No, the proposal supports the old business model until the cut-off
period. This says nothing about other mitigations such as e.g.
revocation in the event of compromise.

> So if I'm an attacker who has compromised a SubCA, the proposed changes
> don't affect me until the SubCA itself expires. I just issue certs to
> myself with an issuance date prior to the "cutoff."
>
> So the 18-month or 3-month transition timeline is irrelevant, and the
> relevant timeline is the expiration date of the (undisclosed) SubCAs in
> existence.
>
> Or am I missing something?

The way I read it, the proposal seeks to reduce overall risk for future
events, before they happen.

When an actual event occurs, there are other mitigations that will be
employed to reduce the costs of that event. Typically, the vendor will
revoke the subCA or CA certificate.

The two work together: before and after mitigations to reduce overall
risk. No one mitigation is likely to work entirely or 100%, given the
soft nature of the product (unclear claims mixed with limited-effect
crypto). A bundle of before- & after-mitigations is good.

iang

[Carsten.D...@t-systems.com]

Kathleen,

Thanks for the clarification.

> As we have done in the past, I was assuming that existing end-entity
> certs would be grandfathered in.

Sorry for being a nitpicker - seems I tend to read things that are indeed not intended.


> "Grace Period: All new externally-operated subordinate CAs must meet

> this requirement as of <3 months after v2.1 published>. All pre-existing

> externally-operated subordinate CAs must meet this requirement for new
> certificate issuance by <18 months after v2.1 published>"
>
> Does that help?

That's crystal clear for me now and it will give us enough time to migrate to a compliant solution without too much pressure.

Enjoy the weekend,

Carsten


Carsten Dahlenkamp
T-Systems International GmbH
Trust Center Applications
Untere Industriestraße 20, 57250 Netphen, Germany
+49 271 708-1643 (Tel.)
E-Mail: carsten.d...@t-systems.com
http://www.t-systems.com, http://www.telesec.de

> >> As the current Sub-CA certificates will have to include additional

> >> information (EKU, Path Length& Name Constraints) we would have to

> set
> >> up new Sub-CA certificates in parallel and start issuing new EE
> certificates
> >> from this "augmented" Sub-CAs. Therefore the first question would
> be,
> >> whether this is still a "pre-existing" Sub-CA in regards to your
> requirement
> > - from a technical point of view this clearly is a "new" one, which
> would
> >> significantly reduce the grace period from 18 to 3 months. I guess,
> this
> >> should be a valid question for all enterprise Sub-CAs, which are
> not
> >> planning to conduct an independent audit.
>
>

> The text is meant to be from a technical point of view. Should I add
> the
> word "certificates" to make that more clear? Then it would become:
>

> ""Grace Period: All new externally-operated subordinate CA

> certificates

> must meet this requirement as of <3 months after v2.1 published>."
>

> Kathleen

[Steve Schultze]

On 5/18/12 10:42 PM, ianG wrote:
> On 19/05/12 05:29 AM, Steve Schultze wrote:
>> On 5/18/12 12:02 PM, Kathleen Wilson wrote:
>>> I added *for new certificate issuance*...
>>>
>>> "Grace Period: All new externally-operated subordinate CAs must meet
>>> this requirement as of <3 months after v2.1 published>. All pre-existing
>>> externally-operated subordinate CAs must meet this requirement for new
>>> certificate issuance by <18 months after v2.1 published>"
>>>
>>> Does that help?
>>
>> So, just to play this out... our threat model is that a SubCA (or an
>> attacker who compromises a SubCA) falsely issues certificates to itself
>> or others that do not in fact control the domain listed in he cert. Our
>> assumption is that the contents of the certificates are unreliable
>> because the issuer does not meet the requirements.
>>
>> The proposal is to nevertheless continue trusting the issuance date in
>> EE certs.
>
>
> No, the proposal supports the old business model until the cut-off
> period. This says nothing about other mitigations such as e.g.
> revocation in the event of compromise.

I don't think this answers my question, but honestly I can't tell
specifically what you're talking about.

I'm not asking about "in the event of a [known] compromise." I'm asking
about the threat model in question, namely unknown compromises, the
damage of which is exacerbated by unconstrained subordinate CAs.

I'm asking Kathleen/Mozilla whether, after the date of transition, EE
cert issuance dates will be trusted by default for
non-domain-constrained SubCAs? If so, the "cutoff" dates are ineffectual.

>> So if I'm an attacker who has compromised a SubCA, the proposed changes
>> don't affect me until the SubCA itself expires. I just issue certs to
>> myself with an issuance date prior to the "cutoff."
>>
>> So the 18-month or 3-month transition timeline is irrelevant, and the
>> relevant timeline is the expiration date of the (undisclosed) SubCAs in
>> existence.
>>
>> Or am I missing something?
>
>
> The way I read it, the proposal seeks to reduce overall risk for future
> events, before they happen.
>
> When an actual event occurs, there are other mitigations that will be
> employed to reduce the costs of that event. Typically, the vendor will
> revoke the subCA or CA certificate.
>
> The two work together: before and after mitigations to reduce overall
> risk. No one mitigation is likely to work entirely or 100%, given the
> soft nature of the product (unclear claims mixed with limited-effect
> crypto). A bundle of before- & after-mitigations is good.

Sure, but that doesn't really answer the basic question above.

[ianG]

Hi Steve

On 21/05/12 06:01 AM, Steve Schultze wrote:
> On 5/18/12 10:42 PM, ianG wrote:

>> On 19/05/12 05:29 AM, Steve Schultze wrote:
>>> On 5/18/12 12:02 PM, Kathleen Wilson wrote:
>>>> I added *for new certificate issuance*...
>>>>
>>>> "Grace Period: All new externally-operated subordinate CAs must meet
>>>> this requirement as of <3 months after v2.1 published>. All
>>>> pre-existing
>>>> externally-operated subordinate CAs must meet this requirement for new
>>>> certificate issuance by <18 months after v2.1 published>"
>>>>
>>>> Does that help?
>>>
>>> So, just to play this out... our threat model is that a SubCA (or an
>>> attacker who compromises a SubCA) falsely issues certificates to itself
>>> or others that do not in fact control the domain listed in he cert. Our
>>> assumption is that the contents of the certificates are unreliable
>>> because the issuer does not meet the requirements.
>>>
>>> The proposal is to nevertheless continue trusting the issuance date in
>>> EE certs.
>>
>>
>> No, the proposal supports the old business model until the cut-off
>> period. This says nothing about other mitigations such as e.g.
>> revocation in the event of compromise.
>

> I don't think this answers my question, but honestly I can't tell
> specifically what you're talking about.
>
> I'm not asking about "in the event of a [known] compromise." I'm asking
> about the threat model in question, namely unknown compromises, the
> damage of which is exacerbated by unconstrained subordinate CAs.

Ah I see. You are assuming that some unconstrained sub-CAs are issuing
improper certificates, and we don't & won't know. Yes, that is the
concern that brought us here in the first place.

> I'm asking Kathleen/Mozilla whether, after the date of transition, EE
> cert issuance dates will be trusted by default for
> non-domain-constrained SubCAs? If so, the "cutoff" dates are ineffectual.

The cut-off date for those certs is the cut-off dates listed, plus any
expiry time.

In analysing the problem we probably have to decide whether the sub-CAs
in question are mostly issuing improper certs, or only slightly. If
mostly, then we should probably request revocation of all end-entity
certs at the cut-off date, because they are the bulk of the problem.
(Actually, if our assessment is "mostly" we should simply revoke all CAs
issuing such sub-CAs.)

OTOH if there are only a few bad apples, we don't necessarily want to
punish those who do the right thing for the sins of the others. So we
stop the practice of unconstrained sub-CAs, and accept that any unknown
improper certificates now have an extended timeline of cut-off + x
years. This latter risk is also reduced because the MITMing of certs is
typically much more focussed than that - short term opportunity.

Also, the practice is pretty much declared illegal so even if a CA has
followed all the new Mozilla business rules, the existence of an MITM
cert from such a sub-CA will still result in our CA revocation
procedures. There is no grandfathering of MITMing, just grace periods
for unconstrained external sub-CAs.

In more practical words, if any certificate is discovered that is an
MITM improperly issued, this becomes a bug to revoke that CA. Correct
me if I'm wrong? Because the CAs have been notified that this practice
is improper in any guise.



iang

>>> So if I'm an attacker who has compromised a SubCA, the proposed changes
>>> don't affect me until the SubCA itself expires. I just issue certs to
>>> myself with an issuance date prior to the "cutoff."
>>>
>>> So the 18-month or 3-month transition timeline is irrelevant, and the
>>> relevant timeline is the expiration date of the (undisclosed) SubCAs in
>>> existence.
>>>
>>> Or am I missing something?
>>
>>
>> The way I read it, the proposal seeks to reduce overall risk for future
>> events, before they happen.
>>
>> When an actual event occurs, there are other mitigations that will be
>> employed to reduce the costs of that event. Typically, the vendor will
>> revoke the subCA or CA certificate.
>>
>> The two work together: before and after mitigations to reduce overall
>> risk. No one mitigation is likely to work entirely or 100%, given the
>> soft nature of the product (unclear claims mixed with limited-effect
>> crypto). A bundle of before- & after-mitigations is good.
>

> Sure, but that doesn't really answer the basic question above.
>

[Steve Schultze]

Are or will, or will be compromised.

>> I'm asking Kathleen/Mozilla whether, after the date of transition, EE
>> cert issuance dates will be trusted by default for
>> non-domain-constrained SubCAs? If so, the "cutoff" dates are ineffectual.
>
> The cut-off date for those certs is the cut-off dates listed, plus any

I think you're still not getting it. There's the "expires on" date in
the EE certs. Then there's the "expires on" date in the SubCA cert.
Then there's this 3 or 18 month "grace" period that is being discussed.

The only "cut-off" that, it seems, would actually be
enforced/enforceable in the threat model we are assuming is the "expires
on" date in the SubCA cert. Bad or compromised SubCAs will simply issue
certs with issued/expired dates prior to the "grace period" cutoff.

That is the problem I am describing, and I am curious to know if anybody
can express why this isn't actually a problem.

> In analysing the problem we probably have to decide whether the sub-CAs
> in question are mostly issuing improper certs, or only slightly.

No, that is not directly relevant to the threat model, and unknowable in
any case... which of course is part of the problem.

[Stephen Schultze]

On 5/20/12 10:36 PM, Steve Schultze wrote:
> On 5/20/12 9:40 PM, ianG wrote:
>> On 21/05/12 06:01 AM, Steve Schultze wrote:
>>> I'm asking Kathleen/Mozilla whether, after the date of transition, EE
>>> cert issuance dates will be trusted by default for
>>> non-domain-constrained SubCAs? If so, the "cutoff" dates are
>>> ineffectual.
>>
>> The cut-off date for those certs is the cut-off dates listed, plus any
>
> I think you're still not getting it. There's the "expires on" date in
> the EE certs. Then there's the "expires on" date in the SubCA cert.
> Then there's this 3 or 18 month "grace" period that is being discussed.
>
> The only "cut-off" that, it seems, would actually be
> enforced/enforceable in the threat model we are assuming is the "expires
> on" date in the SubCA cert. Bad or compromised SubCAs will simply issue
> certs with issued/expired dates prior to the "grace period" cutoff.
>
> That is the problem I am describing, and I am curious to know if anybody
> can express why this isn't actually a problem.

Seeing no response from Mozilla on this matter, I presume that it is in
fact true that the proposed grace periods are ineffectual for the reason
I described.

If that's the case, I propose that instead of trying to enforce some
kind of grace period, we instead take the approach that as of the date
of any new approval or annual "renewal" of audit documentation, the CA
in question will be held to the new standard for all EE certs that chain
to its roots.

[Kathleen Wilson]

I've tried to incorporate this, see updated wiki page:

https://wiki.mozilla.org/CA:CertPolicyUpdates#Transitioning_to_the_Updated_Policy_Version_2.1


Thanks,
Kathleen

[Stephen Schultze]

Cool. If you change "for all end-entity certificates that is issues" to
"for all end-entity certificates that chain to its roots" and I think it
gets the job done.