Update Mozilla policy regarding version 1.1.3 of the BRs?

[Kathleen Wilson]

All,

The CA/Browser forum has introduced version 1.1.3 of the Baseline
Requirements. The new version, as well as the previously published
versions are available here: https://www.cabforum.org/documents.html

Currently Mozilla�s CA Certificate Policy says the following.
http://www.mozilla.org/projects/security/certs/policy/InclusionPolicy.html
�12. CA operations and issuance of certificates to be used for
SSL-enabled servers must also conform to *version 1.1* of the CA/Browser
Forum Baseline Requirements for the Issuance and Management of
Publicly-Trusted Certificates.�

I propose that we update Mozilla�s CA Certificate Policy to require
conformance with version 1.1.3 of the BRs.

The significant changes between version 1.1 and version 1.1.3 of the BRs
are the addition of the following sections and BRs.

+ �Document History�
+ �Relevant Compliance Dates� table
+ BR 10.2.5, Subordinate CA Private Keys
+ BR 11.1.3, Wildcard Domain Validation
+ BR 11.1.4, New gTLD Domains
+ BR 13.1.6, Reasons for Revoking a Subordinate CA Certificate
+ BR 13.2.7, Certificate Suspension
+ Appendix A, (4) General requirements for public keys
+ Appendix B, (4) All Certificates


Please review these new sections and BRs, and reply in this discussion
if you see a potential reason why we should not adopt these changes and
make version 1.1.3 of the BRs required in Mozilla�s CA Certificate Policy.

I will appreciate your thoughtful and constructive input in this discussion.

Thanks,
Kathleen

[Jeremy Rowley]

The change in 13.2.7 clarifies that you can't use certificate suspension for
SSL certificates. I believe most CAs already don't permit suspension since
a certificate that is added to a CRL should never be removed until after its
expiration (BR 13.2.4). .

Jeremy

-----Original Message-----
From:
dev-security-policy-bounces+jeremy.rowley=digice...@lists.mozilla.org
[mailto:dev-security-policy-bounces+jeremy.rowley=digice...@lists.mozilla
.org] On Behalf Of Man Ho@Certizen
Sent: Thursday, April 11, 2013 10:08 AM
To: 'Kathleen Wilson'; mozilla-dev-s...@lists.mozilla.org
Subject: RE: Update Mozilla policy regarding version 1.1.3 of the BRs?

Dear Kathleen,

Noted that the BR 13.2.7 is added, i.e. "The Repository MUST NOT include
entries that indicate that a Certificate is suspended.".

However, referring to the definition of Repository in the BR, it said:

Repository: An online database containing publicly-disclosed PKI governance
documents (such as Certificate Policies and Certification Practice
Statements) and Certificate status information, either in the form of a CRL
or an OCSP response.

And the status information is elaborate in 7.1.2 as:

Status: That the CA maintains a 24 x 7 publicly-accessible Repository with
current information regarding the status (valid or revoked) of all unexpired
Certificates.

It seems that BR 13.2.7 is contradicting to the above two descriptions. In
fact, I believe that it doesn't follow the current practice of most CAs.

Best regards

Man Ho
Certizen, as the operator of Hongkong Post Certification Authority.

> -----Original Message-----
> From: dev-security-policy-bounces+manho=certiz...@lists.mozilla.org
> [mailto:dev-security-policy-
> bounces+manho=certiz...@lists.mozilla.org] On Behalf Of Kathleen
> Wilson
> Sent: Wednesday, April 10, 2013 2:15 AM
> To: mozilla-dev-s...@lists.mozilla.org
> Subject: Update Mozilla policy regarding version 1.1.3 of the BRs?
>
> All,
>
> The CA/Browser forum has introduced version 1.1.3 of the Baseline
> Requirements. The new version, as well as the previously published
> versions are available here: https://www.cabforum.org/documents.html
>

> Currently Mozilla's CA Certificate Policy says the following.
> http://www.mozilla.org/projects/security/certs/policy/InclusionPolicy.
> h
> tml

> "12. CA operations and issuance of certificates to be used for SSL-
> enabled servers must also conform to *version 1.1* of the CA/Browser
> Forum Baseline Requirements for the Issuance and Management of
> Publicly-Trusted Certificates."
>

> I propose that we update Mozilla's CA Certificate Policy to require

> conformance with version 1.1.3 of the BRs.
>
> The significant changes between version 1.1 and version 1.1.3 of the
> BRs are the addition of the following sections and BRs.
>

> + "Document History"
> + "Relevant Compliance Dates" table
> + BR 10.2.5, Subordinate CA Private Keys BR 11.1.3, Wildcard Domain
> + Validation BR 11.1.4, New gTLD Domains BR 13.1.6, Reasons for
> Revoking
> + a Subordinate CA Certificate BR 13.2.7, Certificate Suspension
> + Appendix A, (4) General requirements for public keys Appendix B, (4)
> + All Certificates

>
>
> Please review these new sections and BRs, and reply in this discussion
> if you see a potential reason why we should not adopt these changes

> and make version 1.1.3 of the BRs required in Mozilla's CA Certificate

> Policy.
>
> I will appreciate your thoughtful and constructive input in this
> discussion.
>
> Thanks,
> Kathleen

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

[Kathleen Wilson]

On 4/9/13 11:14 AM, Kathleen Wilson wrote:
> All,
>
> The CA/Browser forum has introduced version 1.1.3 of the Baseline
> Requirements. The new version, as well as the previously published
> versions are available here: https://www.cabforum.org/documents.html

><snip>

>
> I propose that we update Mozilla�s CA Certificate Policy to require
> conformance with version 1.1.3 of the BRs.
>

A concern has been raised regarding the addition of seciton 13.2.7:
"13.2.7 Certificate Suspension

The Repository MUST NOT include entries that indicate that a Certificate
is suspended."

Are there any other concerns about updating Mozilla's CA Certificate
policy to require CAs to comply with version 1.1.3 of the BRs?

Thanks,
Kathleen

[Kathleen Wilson]

On 4/23/13 5:33 PM, Kathleen Wilson wrote:
> On 4/9/13 11:14 AM, Kathleen Wilson wrote:
>> I propose that we update Mozilla�s CA Certificate Policy to require
>> conformance with version 1.1.3 of the BRs.
>
> A concern has been raised regarding the addition of seciton 13.2.7:
> "13.2.7 Certificate Suspension
> The Repository MUST NOT include entries that indicate that a Certificate
> is suspended."
>

I'm wondering what we should do about this concern.

I don't see why BR #13.2.7 is needed, or how it improves security.

I suppose we can add this to our list of BR exceptions in item #12 of
http://www.mozilla.org/projects/security/certs/policy/InclusionPolicy.html

Kathleen

[Man Ho@Certizen]

I agree to add this item in the exception list.

Man Ho

***Sent from my iphone.

Kathleen Wilson <kwi...@mozilla.com> 於 27 Apr, 2013 9:10 AM 寫道：

> On 4/23/13 5:33 PM, Kathleen Wilson wrote:

>> On 4/9/13 11:14 AM, Kathleen Wilson wrote:

>>> I propose that we update Mozilla’s CA Certificate Policy to require

>>> conformance with version 1.1.3 of the BRs.
>>
>> A concern has been raised regarding the addition of seciton 13.2.7:
>> "13.2.7 Certificate Suspension
>> The Repository MUST NOT include entries that indicate that a Certificate
>> is suspended."
>
>

> I'm wondering what we should do about this concern.
>
> I don't see why BR #13.2.7 is needed, or how it improves security.
>
> I suppose we can add this to our list of BR exceptions in item #12 of http://www.mozilla.org/projects/security/certs/policy/InclusionPolicy.html
>
> Kathleen
>
>

[Gervase Markham]

On 27/04/13 02:10, Kathleen Wilson wrote:
> I'm wondering what we should do about this concern.
>
> I don't see why BR #13.2.7 is needed, or how it improves security.

I think the idea is that no-one really knows what to do when a cert is
"suspended". "If you didn't trust it once, how can you ever trust it
again?", vs. "we need something short of revocation while we are
investigating".

How should Firefox's UI behave if we get a "suspended" response back?
Like "good"? Like "revoked"? Or a third state?

> I suppose we can add this to our list of BR exceptions in item #12 of
> http://www.mozilla.org/projects/security/certs/policy/InclusionPolicy.html

Can you give more details as to why people are concerned? Do they have
systems and processes which use this state, which can't be changed or
they don't want to change? Or is it because they have used it in the
past for certs which are not yet expired and so can't remove those entries?

Gerv

[Gervase Markham]

On 27/04/13 02:10, Kathleen Wilson wrote:

> I'm wondering what we should do about this concern.
>
> I don't see why BR #13.2.7 is needed, or how it improves security.

I think the idea is that no-one really knows what to do when a cert is
"suspended". "If you didn't trust it once, how can you ever trust it
again?", vs. "we need something short of revocation while we are
investigating".

How should Firefox's UI behave if we get a "suspended" response back?
Like "good"? Like "revoked"? Or a third state?

> I suppose we can add this to our list of BR exceptions in item #12 of
> http://www.mozilla.org/projects/security/certs/policy/InclusionPolicy.html

[Kathleen Wilson]

On 4/29/13 3:02 AM, Gervase Markham wrote:
> On 27/04/13 02:10, Kathleen Wilson wrote:
>> I'm wondering what we should do about this concern.
>>
>> I don't see why BR #13.2.7 is needed, or how it improves security.
>
> I think the idea is that no-one really knows what to do when a cert is
> "suspended". "If you didn't trust it once, how can you ever trust it
> again?", vs. "we need something short of revocation while we are
> investigating".
>
> How should Firefox's UI behave if we get a "suspended" response back?
> Like "good"? Like "revoked"? Or a third state?

It looks like "suspended" should be treated as "revoked". The only
difference being that the CA can un-suspend the cert once the concern
had been cleared.

>
>> I suppose we can add this to our list of BR exceptions in item #12 of
>> http://www.mozilla.org/projects/security/certs/policy/InclusionPolicy.html
>
> Can you give more details as to why people are concerned? Do they have
> systems and processes which use this state, which can't be changed or
> they don't want to change? Or is it because they have used it in the
> past for certs which are not yet expired and so can't remove those entries?
>

CAs have used CRLReason=certificateHold in their CRLs, and it is part of
RFC5280.

I don't see the point in making CAs change RFC5280-compliant behavior
when the change has zero impact on Mozilla users *and* doesn't improve
security of the internet.

Kathleen

[Gervase Markham]

On 30/04/13 01:55, Kathleen Wilson wrote:
> It looks like "suspended" should be treated as "revoked". The only
> difference being that the CA can un-suspend the cert once the concern
> had been cleared.

But isn't that guaranteed to confuse users? If a cert was revoked and
then becomes un-revoked?

>>> I suppose we can add this to our list of BR exceptions in item #12 of
>>> http://www.mozilla.org/projects/security/certs/policy/InclusionPolicy.html
>>
>> Can you give more details as to why people are concerned? Do they have
>> systems and processes which use this state, which can't be changed or
>> they don't want to change? Or is it because they have used it in the
>> past for certs which are not yet expired and so can't remove those
>> entries?
>
> CAs have used CRLReason=certificateHold in their CRLs, and it is part of
> RFC5280.
>
> I don't see the point in making CAs change RFC5280-compliant behavior
> when the change has zero impact on Mozilla users *and* doesn't improve
> security of the internet.

Do we think the BRs require this change to be implemented
retrospectively, or simply for future revocations?

We can go back to the CAB Forum and ask why this provision is there (my
explanation may not be adequate). But if the aim of the BRs is
consistency, and if a majority of CAs voted for this change, I think we
should at least do more investigation before simply diverging.

Gerv

[Ben Wilson]

I will put this on for a 5-minute discussion slot during the CAB Forum
meeting on Thursday. If we do not need to discuss it, we can skip to
another topic.

-----Original Message-----
From: dev-security-policy-bounces+ben=digice...@lists.mozilla.org
[mailto:dev-security-policy-bounces+ben=digice...@lists.mozilla.org] On
Behalf Of Gervase Markham
Sent: Tuesday, April 30, 2013 4:04 AM
To: Kathleen Wilson; mozilla-dev-s...@lists.mozilla.org

Subject: Re: Update Mozilla policy regarding version 1.1.3 of the BRs?

On 30/04/13 01:55, Kathleen Wilson wrote:

> It looks like "suspended" should be treated as "revoked". The only
> difference being that the CA can un-suspend the cert once the concern
> had been cleared.

But isn't that guaranteed to confuse users? If a cert was revoked and then
becomes un-revoked?

>>> I suppose we can add this to our list of BR exceptions in item #12
>>> of
>>> http://www.mozilla.org/projects/security/certs/policy/InclusionPolic
>>> y.html
>>
>> Can you give more details as to why people are concerned? Do they
>> have systems and processes which use this state, which can't be
>> changed or they don't want to change? Or is it because they have used
>> it in the past for certs which are not yet expired and so can't
>> remove those entries?
>
> CAs have used CRLReason=certificateHold in their CRLs, and it is part
> of RFC5280.
>
> I don't see the point in making CAs change RFC5280-compliant behavior
> when the change has zero impact on Mozilla users *and* doesn't improve
> security of the internet.

Do we think the BRs require this change to be implemented retrospectively,
or simply for future revocations?

We can go back to the CAB Forum and ask why this provision is there (my
explanation may not be adequate). But if the aim of the BRs is consistency,
and if a majority of CAs voted for this change, I think we should at least
do more investigation before simply diverging.

Gerv

[Kathleen Wilson]

Thanks Ben.

Here are my questions...

BR 13.2.7, Certificate Suspension, says: "The Repository MUST NOT

include entries that indicate that a Certificate is suspended."

1) Does that mean that CAs cannot put CRL reason code certificateHold
(as per RFC5280) in their CRLs?

2) What problem does this Baseline Requirement solve?

3) Does it really matter if the browsers don't do anything with the
certificateHold reason code?

4) What is the expectation of when/how CAs must become compliant with
this new BR?

5) What if a CA does not see the value of becoming compliant with this
BR because their use of this reason code is compliant with RFC5280? (For
this question, assume that the CA is compliant with all of the other BRs
-- will that impact internet users in any way?)

6) I completely missed the CAB Forum's discussion of the addition of
this BR. When I searched for it, I found that it was bunched together
with a few other changes. When should changes to the BRs be grouped
together? If the addition of a new BR is not important enough to stand
on its own, then should it really be added?


As per Gerv's earlier request, here is text from one CA's CPS
(translated into English):
"Suspension is the process of making a certificate to make it invalid
temporarily.
Revocation is the process of making a certificate to be invalid
permanently."
....
"Suspension can be described as placing a certificate on hold for a
brief period. This is useful for investigation to be carried out as to
the validity of the certificate when required. A Certificate is
suspended when:
- Verification as to whether the certificate has been issued containing
wrong or falsified information is in progress
- Soft copy of Revocation request signed by SA/RA is awaited
- Subscriber requests for suspension"


Thanks,
Kathleen

[Jeremy Rowley]

Before answering your questions, I think it's important to remember that
this only applies to SSL certificates. There are valid reasons to suspend a
client certificate.

BR 13.2.7, Certificate Suspension, says: "The Repository MUST NOT include

entries that indicate that a Certificate is suspended."

1) Does that mean that CAs cannot put CRL reason code certificateHold (as
per RFC5280) in their CRLs?

- They can. However, because of the way clients handle CRLS (including the
caching of CRLs) and the fact that disappearing CRL entries is a sign of
probable malicious behavior, CAs cannot remove the CRL entry once
established. This is the reason suspension doesn't work. In fact, this is
already a requirement under the version of the BRs previously adopted by
Mozilla (Section 13.2.4).

2) What problem does this Baseline Requirement solve?

- The problem is that most clients don't process delta CRLs. Once something
appears on a CRL, it can't effectively be removed. Also, the watching CRLs
helps detect compromised CAs since changing CRLs are an indication of
something going wrong with the CA. Besides, with the short issuance times
of today's certificates, a CA can reissue a certificate more effectively
than suspending and un-suspending an existing certificate.

3) Does it really matter if the browsers don't do anything with the
certificateHold reason code?

- No, but the reason code is not a problem for the CA. Many CAs don't
include any reason code in the CRL for their listings. The big problem that
was discussed in the Forum is the way CRLs are processed and cached.

4) What is the expectation of when/how CAs must become compliant with this
new BR?

- All CAs should already be compliant since Section 13.2.4 accomplishes
effectively the same thing. Section 13.2.4 because part of the SSL WebTrust
audit in January. The section should be part of ETSI soon, if not already.

5) What if a CA does not see the value of becoming compliant with this BR
because their use of this reason code is compliant with RFC5280? (For this
question, assume that the CA is compliant with all of the other BRs
-- will that impact internet users in any way?)

- The impact will be that you'll have many confused users. Some browsers
will list the certificate as revoked when the suspension ends. Others
won't. There is also the risk that some browsers treat certificateHold as
non-revoked. Since the CA doesn't have to change the certificate status
later, the certificate may never be revoked if the actual reason becomes key
compromise.

6) I completely missed the CAB Forum's discussion of the addition of this
BR. When I searched for it, I found that it was bunched together with a few
other changes. When should changes to the BRs be grouped together? If the
addition of a new BR is not important enough to stand on its own, then
should it really be added?

- There were several discussions on this topic. I can send them to you
separately, although I've highlighted the discussion above. The primary
issues that led to a prohibition on revocation were the lack of support for
suspension, the fact that re-issuance is a better process that avoids
browser issues, the fact that a CA with changing entries is a warning about
problems with the CA, and the burden on researchers trying to track this
type of information. The topics in revocation were grouped together in a
single ballot for convenience. We discussed them separately in meetings and
on the list but consolidated for the ballot.

As per Gerv's earlier request, here is text from one CA's CPS (translated
into English):
"Suspension is the process of making a certificate to make it invalid
temporarily.
Revocation is the process of making a certificate to be invalid
permanently."
....
"Suspension can be described as placing a certificate on hold for a brief
period. This is useful for investigation to be carried out as to the
validity of the certificate when required. A Certificate is suspended when:
- Verification as to whether the certificate has been issued containing
wrong or falsified information is in progress
- Soft copy of Revocation request signed by SA/RA is awaited
- Subscriber requests for suspension"

- Doesn't really work that way. When you place a cert on a CRL, it becomes,
more or less, permanently invalid. The biggest problem with suspension is
it uses the same mechanism as revocation, making distinguishing between the
two difficult.

[Kathleen Wilson]

On 5/1/13 12:30 PM, Jeremy Rowley wrote:
> Before answering your questions, I think it's important to remember that
> this only applies to SSL certificates. There are valid reasons to suspend a
> client certificate.
>
> BR 13.2.7, Certificate Suspension, says: "The Repository MUST NOT include
> entries that indicate that a Certificate is suspended."
>

Jeremy, Thank you for your thorough answers!

Now I understand the reasoning and clarification that this additional BR
provides.

I propose that we update Mozilla's policy to require version 1.1.3 of
the BRs, without calling out any new exceptions.

Kathleen

[Peter Gutmann]

Jeremy Rowley <jeremy...@digicert.com> writes:

>Before answering your questions, I think it's important to remember that this
>only applies to SSL certificates. There are valid reasons to suspend a client
>certificate.

>From memory when this came up on the PKIX list many years ago, the only reason
cert suspension exists is because some banking guys insisted that it be added
to the X.509 spec. No-one quite knew what to do with suspended certificates,
and it was unclear how you were supposed to unsuspend them. So the current
discussion is trying to read meaning into a hypothetical capability that may
or may not have been useful for the planned use of certificates for banking
about a decade ago. The best approach to this is just to say that you
shouldn't have certs suspended.

Peter.

[Kathleen Wilson]

On 5/5/13 7:16 PM, Man Ho@Certizen wrote:
> I feel the same anxiety as those banking guys if a CA (such as some CAs for
> banking industry) lost the capability to temporarily suspend a certificate. If
> any dispute against an issued certificate was raised, what a CA can do?
>
> No matter what, there are two possibilities. (1) If the CA kept the issued
> certificate active, CA may be blamed for its ignorance to the dispute. (2) If
> the CA revoked the issued certificate, CA may receive claim for the
> subscriber's lost (especially for other client certificate that was
> distributed in hardware token to the client).
>


I understand this anxiety in regards to resolving a dispute against an
issued certificate, but it sounds like suspending an SSL cert doesn't
really help. If browsers don't do anything with that CRL reason code,
then there's no point in putting it into the CRL.

Also, if browsers do start to treat suspended certs as revoked, then you
would still have problem #2 of the CA receiving claim for the
subscriber's lost business.

Kathleen

[Gordon Young]

a general question around this requirement. Why MUST a Repository not
provide the suspended status?
What is the risk?

I assume "Entries that indicate that a Certificate is suspended."
means certificateHold
(6) CRL reasonFlag per RFC5280.

Thanks,
~Gordon

On Tue, Apr 23, 2013 at 5:33 PM, Kathleen Wilson <kwi...@mozilla.com>wrote:

> On 4/9/13 11:14 AM, Kathleen Wilson wrote:
>

>> All,
>>
>> The CA/Browser forum has introduced version 1.1.3 of the Baseline
>> Requirements. The new version, as well as the previously published

>> versions are available here: https://www.cabforum.org/**documents.html<https://www.cabforum.org/documents.html>
>> <snip>
>>
>> I propose that we update Mozilla’s CA Certificate Policy to require

>> conformance with version 1.1.3 of the BRs.
>>
>>
>

> A concern has been raised regarding the addition of seciton 13.2.7:
> "13.2.7 Certificate Suspension

> The Repository MUST NOT include entries that indicate that a Certificate
> is suspended."
>
>

> Are there any other concerns about updating Mozilla's CA Certificate

> policy to require CAs to comply with version 1.1.3 of the BRs?
>
> Thanks,
> Kathleen
>
>
> ______________________________**_________________
> dev-security-policy mailing list
> dev-security-policy@lists.**mozilla.org<dev-secur...@lists.mozilla.org>
> https://lists.mozilla.org/**listinfo/dev-security-policy<https://lists.mozilla.org/listinfo/dev-security-policy>
>

[Kathleen Wilson]

On 5/7/13 4:45 PM, Gordon Young wrote:
>>> A concern has been raised regarding the addition of seciton 13.2.7:
>>> "13.2.7 Certificate Suspension
>>> The Repository MUST NOT include entries that indicate that a Certificate
>>> is suspended."
>

> a general question around this requirement. Why MUST a Repository not
> provide the suspended status?
> What is the risk?
>
> I assume "Entries that indicate that a Certificate is suspended."
> means certificateHold
> (6) CRL reasonFlag per RFC5280.
>

As per previous posts in this discussion, the certificateHold status was
not intended to be used for SSL certs.

certificateHold is basically used if someone has misplaced their token
or key, but they aren't sure yet if it's lost. For example suppose you
forgot where you left your badge. Such a scenario is not likely in terms
of an SSL server.

I understand the concern that was raised about needing time to
investigate a claim that an SSL cert was mis-issued or is being
inappropriately used. However, certificateHold should not be used as a
place-holder to allow the CA more time to investigate. The CA should
respond to such claims promptly, and make a decision about revocation.
Putting a certificateHold entry (for an SSL cert) into the CRL for a
couple of days doesn't add value.

Since the BRs are about SSL certs, and not about Signing (e.g. code
signing or email) certs, I think it is reasonable to expect CAs to
comply with BR #13.2.7.

Regarding BR #13.2.4: "Revocation entries on a CRL or OCSP Response MUST
NOT be removed until after the Expiry Date of the revoked Certificate."
For SSL certs, NSS currently doesn't care if an entry in the CRL
disappears because NSS does not persistently maintain whether a given
cert is revoked. But caching of CRL information is a reasonable feature
to add in the future.


Note for CAB Forum: BR #13.2.4 and #13.2.7 will need to be revisited if
the BRs are ever updated to also include Code Signing certs.


Kathleen