Responses to CA Communications

[Kathleen Wilson]

As many of you are already aware, I am posting responses to the CA
Communication here:
https://wiki.mozilla.org/CA:Communications#January_2013_Responses

Please note that there are *many* responses in my inbox that I have not
gotten to yet. It will take me a while to get all of the responses
recorded, so an empty row in the spreadsheet does *not* mean that the CA
has not yet responded. It probably just means that I haven't yet
recorded their response.

Also, please note that as I am updating the spreadsheet I am requesting
that each CA double-check that I have properly recorded their answers.
Therefore, answers may be changed as I work through my inbox.

Kathleen

[Kathleen Wilson]

I am still working through the CA responses in my inbox.

Kathleen

[Kathleen Wilson]

All,

As you know, I am summarizing responses to the recent CA Communication here:
https://wiki.mozilla.org/CA:Communications#January_2013_Responses
Here are the trends that I am seeing.


Action #1: Mozilla Policy Update Readiness

In regards to the changes to version 2.1 of Mozilla's CA Certificate
policy, most CAs stated that they were already in compliance with the
changes, or would be able to comply with the new requirements according
to the time frames listed on the wiki page
(https://wiki.mozilla.org/CA:CertPolicyUpdates#Transitioning_to_the_Updated_Policy_Version_2.1).

Most of the CAs that answered with "C" (need more time) stated that they
need more time to comply with the Baseline Requirements. They were OK
with the time frames allowed for transitioning their intermediate
certificates.

There are a couple CAs whose included root certs only have the email
trust bit enabled, and those root certs sign end-entity certs directly,
as required by legacy software. These CAs have requested a long-term
exception to Mozilla's new policy requiring intermediate issuing
certificates.
I added a bullet point to the wiki page to address this.
https://wiki.mozilla.org/CA:CertPolicyUpdates#Transitioning_to_the_Updated_Policy_Version_2.1
"Item #6, fourth bullet: "maintain a certificate hierarchy such that the
included certificate does not directly issue end-entity certificates to
customers (e.g., the included certificate signs intermediate issuing
certificates);"
- As of February 15, 2014 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.
- Exceptions may be granted for root certificates that only have the
email (S/MIME) trust bit enabled, and do not have the websites (SSL/TLS)
or code signing trust bits enabled."



Action #2: Baseline Requirements Readiness

The BRs that CAs most commonly stated that they need more time to comply
with are:
- BR 9.2.1, "Subject Alternative Name Extension"
- BR 9.6, "Certificate Serial Number"
- BR 13.2.2, "Repository" (OCSP)
- Appendix B, "Certificate Extensions (Normative)"
- Appendix C, "User Agent Verification (Normative)"

For in-premise operations, most CAs stated that they expect to comply
with the BRs by June 2013.

Several CAs stated that they need more time to help their subordinate
CAs comply with the BRs.

I am considering adding a sub-bullet to the wiki page to take these
requests into account. See the third sub-bullet (proposed) below...
https://wiki.mozilla.org/CA:CertPolicyUpdates#Transitioning_to_the_Updated_Policy_Version_2.1
"Item #13: "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."
- As of February 2013, SSL certificate issuance must also be audited
according to the Baseline Requirements. (see details above)
- All other dates are as specified by the CA/Browser Forum.
- The first BR audit for each CA and subCA may include a list of BRs
that the CA (or subCA) is not yet in compliance with. The second BR
audit (the following year) is expected to confirm that the issues that
were listed in the previous BR audit have been resolved."


Action #3: Scan Cert DB

Many CAs are still working on this action item. The most common issues
are 1024-bit certs and certs being issued with sequential serial numbers
and insufficient entropy.


Action #4: Deprecate issuance of SSL certificates containing a Reserved
IP Address or Internal Server Name.

For CAs who issue this type of cert, many said that they will stop
issuance earlier than is required in BR 9.2.1, but several said that
they will use the dates listed in BR 9.2.1.


Kathleen

[Gervase Markham]

On 11/02/13 22:31, Kathleen Wilson wrote:
> I added a bullet point to the wiki page to address this.
> https://wiki.mozilla.org/CA:CertPolicyUpdates#Transitioning_to_the_Updated_Policy_Version_2.1
>
> "Item #6, fourth bullet: "maintain a certificate hierarchy such that the
> included certificate does not directly issue end-entity certificates to
> customers (e.g., the included certificate signs intermediate issuing
> certificates);"
> - As of February 15, 2014 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.
> - Exceptions may be granted for root certificates that only have the
> email (S/MIME) trust bit enabled, and do not have the websites (SSL/TLS)
> or code signing trust bits enabled."

Do we think there is a different risk profile for this activity for
S/MIME certs as opposed to SSL certs?

> Action #2: Baseline Requirements Readiness
>
> The BRs that CAs most commonly stated that they need more time to comply
> with are:
> - BR 9.2.1, "Subject Alternative Name Extension"

Do we know which part of 9.2.1 they have problems with? Is it:

A) Having to issue every cert with a SAN;
B) Notifying customers about the deprecation of Internal Server Names;
C) Not issuing ISNs with an expiry date later than 1st Nov 2015

? None of these seem deeply complex to implement.

> - BR 13.2.2, "Repository" (OCSP)

I assume the problem here is standing up an OCSP server?

> - Appendix C, "User Agent Verification (Normative)"

Blimey. If a CA has a problem putting up a few test websites with their
own certs on, then that's not particularly impressive. This doesn't even
involve sub-CAs; it only requires one set of websites per root.

> - The first BR audit for each CA and subCA may include a list of BRs
> that the CA (or subCA) is not yet in compliance with. The second BR
> audit (the following year) is expected to confirm that the issues that
> were listed in the previous BR audit have been resolved."

Doesn't this effectively push out the BR requirements for 1 more year?
I'm not sure I agree with that. They've had a lot of warning that this
is coming - in previous CA communications, for a start.

Gerv

[Kathleen Wilson]

On 2/13/13 3:43 AM, Gervase Markham wrote:
> On 11/02/13 22:31, Kathleen Wilson wrote:
>> I added a bullet point to the wiki page to address this.
>> https://wiki.mozilla.org/CA:CertPolicyUpdates#Transitioning_to_the_Updated_Policy_Version_2.1
>>
>> "Item #6, fourth bullet: "maintain a certificate hierarchy such that the
>> included certificate does not directly issue end-entity certificates to
>> customers (e.g., the included certificate signs intermediate issuing
>> certificates);"
>> - As of February 15, 2014 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.
>> - Exceptions may be granted for root certificates that only have the
>> email (S/MIME) trust bit enabled, and do not have the websites (SSL/TLS)
>> or code signing trust bits enabled."
>
> Do we think there is a different risk profile for this activity for
> S/MIME certs as opposed to SSL certs?
>

Yes, because the damage that someone can do with a rogue S/MIME cert is
significantly less than the damage someone can do with a rogue SSL cert.

I am now of the opinion that we should delete the new sub-bullet from
item #6, and let the BRs handle it.

Currently Mozilla's proposed policy text is:
"6.We require that all CAs whose certificates are distributed with our
software products: ...
- maintain a certificate hierarchy such that the included certificate

does not directly issue end-entity certificates to customers (e.g., the

included certificate signs intermediate issuing certificates), as
described in CA/Browser Forum Baseline Requirement #12;"

Does anyone object to deleting this sub-bullet?

Letting the BRs handle this would not cover code signing certs, but
looking through the included roots
(http://tinyurl.com/MozillaBuiltInCAs), there are only three (old) root
certs that have the Code Signing trust bit enabled, and not the websites
(SSL) trust bit.

>> Action #2: Baseline Requirements Readiness
>>
>> The BRs that CAs most commonly stated that they need more time to comply
>> with are:
>> - BR 9.2.1, "Subject Alternative Name Extension"
>
> Do we know which part of 9.2.1 they have problems with? Is it:
>
> A) Having to issue every cert with a SAN;
> B) Notifying customers about the deprecation of Internal Server Names;
> C) Not issuing ISNs with an expiry date later than 1st Nov 2015
>


A) Having to issue every cert with a SAN;


> ? None of these seem deeply complex to implement.

They just need a little more time to implement it.

>
>> - BR 13.2.2, "Repository" (OCSP)
>
> I assume the problem here is standing up an OCSP server?

Yes. Some CAs need a little more time to do this. Some CAs have subCAs
that need even more time to do this.

>
>> - Appendix C, "User Agent Verification (Normative)"
>
> Blimey. If a CA has a problem putting up a few test websites with their
> own certs on, then that's not particularly impressive. This doesn't even
> involve sub-CAs; it only requires one set of websites per root.

It's not that it's a problem. It's just that there are some CAs who are
not members of the CAB Forum and did not notice this requirement in
Appendix C until recently. To tell you the truth, I hadn't noticed it
either.

Those CAs just need a little time to do get it done.

>
>> - The first BR audit for each CA and subCA may include a list of BRs
>> that the CA (or subCA) is not yet in compliance with. The second BR
>> audit (the following year) is expected to confirm that the issues that
>> were listed in the previous BR audit have been resolved."
>
> Doesn't this effectively push out the BR requirements for 1 more year?
> I'm not sure I agree with that. They've had a lot of warning that this
> is coming - in previous CA communications, for a start.
>

The previous CA communication (February 2012) informed CAs that the CAB
Forum was working on the BRs, and that we would update Mozilla policy to
require that CAs follow the BRs. It wasn't until the January 2013 CA
Communication that we stated that CAs should now be in compliance. I
think it is reasonable for CAs (especially those who are not CAB Forum
members) to request a little more time to implement certain BRs that
require changes to their infrastructure.

However, I want to make sure BR audits happen this year, so that any
issues get identified this year. I prefer that CAs get their first BR
audits done sooner with a couple exceptions noted, rather than later.

Kathleen

[Jeremy Rowley]

Hi Kathleen,

Can you elaborate on why you'd want or need an exception for s/MIME
certificates? One of the goals for requiring issuance through an
intermediate is to provide browsers a mechanism for disabling certificates
that are compromised or for illegal activities, presumably so that Mozilla
can avoid claims of contributory infringement in some cases. If the CA is
using a root to issue s/MIME and using the root to violate the rights of a
third party, wouldn't Mozilla want the ability to shut off the intermediate
without killing the entire root?

If anything, I think this requirement should be expanded and recommend
separate intermediates for SSL and s/MIME. Doing so permits Mozilla more
control over the CA, reduces the likelihood of a "too-large-to-fail"
situation, and is (or I thought it was) generally regarded as a good
practice in certificate issuance. Before you change this, I'd really like
to understand why any CA would ask for an exception.

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 Kathleen Wilson
Sent: Wednesday, February 13, 2013 12:27 PM
To: mozilla-dev-s...@lists.mozilla.org
Subject: Re: Responses to CA Communications

On 2/13/13 3:43 AM, Gervase Markham wrote:

> On 11/02/13 22:31, Kathleen Wilson wrote:
>> I added a bullet point to the wiki page to address this.
>> https://wiki.mozilla.org/CA:CertPolicyUpdates#Transitioning_to_the_Up
>> dated_Policy_Version_2.1
>>
>> "Item #6, fourth bullet: "maintain a certificate hierarchy such that
>> the included certificate does not directly issue end-entity
>> certificates to customers (e.g., the included certificate signs
>> intermediate issuing certificates);"
>> - As of February 15, 2014 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.
>> - Exceptions may be granted for root certificates that only have the
>> email (S/MIME) trust bit enabled, and do not have the websites
>> (SSL/TLS) or code signing trust bits enabled."
>
> Do we think there is a different risk profile for this activity for
> S/MIME certs as opposed to SSL certs?
>

Yes, because the damage that someone can do with a rogue S/MIME cert is
significantly less than the damage someone can do with a rogue SSL cert.

I am now of the opinion that we should delete the new sub-bullet from item
#6, and let the BRs handle it.

Currently Mozilla's proposed policy text is:
"6.We require that all CAs whose certificates are distributed with our
software products: ...

- maintain a certificate hierarchy such that the included certificate does

not directly issue end-entity certificates to customers (e.g., the included

certificate signs intermediate issuing certificates), as described in
CA/Browser Forum Baseline Requirement #12;"

Does anyone object to deleting this sub-bullet?

Letting the BRs handle this would not cover code signing certs, but looking
through the included roots (http://tinyurl.com/MozillaBuiltInCAs), there are
only three (old) root certs that have the Code Signing trust bit enabled,
and not the websites
(SSL) trust bit.

>> Action #2: Baseline Requirements Readiness
>>
>> The BRs that CAs most commonly stated that they need more time to
>> comply with are:
>> - BR 9.2.1, "Subject Alternative Name Extension"
>
> Do we know which part of 9.2.1 they have problems with? Is it:
>
> A) Having to issue every cert with a SAN;
> B) Notifying customers about the deprecation of Internal Server Names;
> C) Not issuing ISNs with an expiry date later than 1st Nov 2015
>


A) Having to issue every cert with a SAN;


> ? None of these seem deeply complex to implement.

They just need a little more time to implement it.


>

>> - BR 13.2.2, "Repository" (OCSP)
>
> I assume the problem here is standing up an OCSP server?

Yes. Some CAs need a little more time to do this. Some CAs have subCAs that
need even more time to do this.


>

>> - Appendix C, "User Agent Verification (Normative)"
>
> Blimey. If a CA has a problem putting up a few test websites with their
> own certs on, then that's not particularly impressive. This doesn't even
> involve sub-CAs; it only requires one set of websites per root.

It's not that it's a problem. It's just that there are some CAs who are
not members of the CAB Forum and did not notice this requirement in
Appendix C until recently. To tell you the truth, I hadn't noticed it
either.

Those CAs just need a little time to do get it done.


>

>> - The first BR audit for each CA and subCA may include a list of BRs
>> that the CA (or subCA) is not yet in compliance with. The second BR
>> audit (the following year) is expected to confirm that the issues that
>> were listed in the previous BR audit have been resolved."
>
> Doesn't this effectively push out the BR requirements for 1 more year?
> I'm not sure I agree with that. They've had a lot of warning that this
> is coming - in previous CA communications, for a start.
>

The previous CA communication (February 2012) informed CAs that the CAB
Forum was working on the BRs, and that we would update Mozilla policy to
require that CAs follow the BRs. It wasn't until the January 2013 CA
Communication that we stated that CAs should now be in compliance. I
think it is reasonable for CAs (especially those who are not CAB Forum
members) to request a little more time to implement certain BRs that
require changes to their infrastructure.

However, I want to make sure BR audits happen this year, so that any
issues get identified this year. I prefer that CAs get their first BR
audits done sooner with a couple exceptions noted, rather than later.

Kathleen

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

[Eddy Nigg]

On 02/13/2013 10:38 PM, From Jeremy Rowley:

> If anything, I think this requirement should be expanded and recommend
> separate intermediates for SSL and s/MIME. Doing so permits Mozilla more
> control over the CA, reduces the likelihood of a "too-large-to-fail"
> situation, and is (or I thought it was) generally regarded as a good
> practice in certificate issuance. Before you change this, I'd really like
> to understand why any CA would ask for an exception.

Dito here - in my opinion the above should be best practice, but
certainly never issue directly from the root. I hope we've covered this
extensively already.

--
Regards

Signer: Eddy Nigg, StartCom Ltd.
XMPP: star...@startcom.org
Blog: http://blog.startcom.org/
Twitter: http://twitter.com/eddy_nigg

[Kathleen Wilson]

On 2/13/13 2:37 PM, Eddy Nigg wrote:
> On 02/13/2013 10:38 PM, From Jeremy Rowley:
>> If anything, I think this requirement should be expanded and recommend
>> separate intermediates for SSL and s/MIME. Doing so permits Mozilla more
>> control over the CA, reduces the likelihood of a "too-large-to-fail"
>> situation, and is (or I thought it was) generally regarded as a good
>> practice in certificate issuance. Before you change this, I'd really
>> like
>> to understand why any CA would ask for an exception.
>
> Dito here - in my opinion the above should be best practice, but
> certainly never issue directly from the root. I hope we've covered this
> extensively already.
>

One of my goals for doing the recent CA Communication was to have CAs
review the proposed changes to Mozilla's CA Certificate Policy, and let
me know if they would not be able to meet any of the changes within the
allotted time frames. This particular item came up repeatedly in the
responses, so I would like to figure out how to address it. This is the
only issue now holding up official publication of version 2.1 of
Mozilla's CA Certificate policy.

The currently drafted text is: "maintain a certificate hierarchy such

that the included certificate does not directly issue end-entity
certificates to customers (e.g., the included certificate signs
intermediate issuing certificates), as described in CA/Browser Forum
Baseline Requirement #12;"

One problem with this is that there are a couple CAs (e.g. SUSCERTE,
India CCA) who applied for inclusion, but we told them to have their
subCAs apply for inclusion separately, as separate trust anchors. Are we
now going to require that these subCAs create additional intermediate
certificates?

I have also learned that some national certificate policies do not allow
the CA to sign intermediate certificates.

Another problem is that there are older root certs included in Mozilla's
program that have pathlength=0. For them to resolve this, they will
need to create a new root cert, go through our process to get it
included, and then migrate their customers to the new hierarchy. We
can't expect them to get this all done in the next year. So do we give
these roots an exception?

Another issue that some CAs are dealing with is that their customers
have legacy software that was written before intermediate certificates
were common. They will need to get their customers to update their
software, and then migrate to a new hierarchy. Do we give an longer-term
exception for these cases?

BR #12 also lists several exceptions to this rule. That's OK for SSL
certs, but doesn't solve the problems listed above. So then I guess I
would have to copy those exceptions into Mozilla' policy or the wiki page.

As I see it, I have three choices:

1) Leave the proposed bullet point as-is, but add a bunch of exceptions
to the wiki page.

2) Remove the proposed bullet point in this version of the policy. This
allows me to finish getting the policy published this week, with the
important changes regarding the BRs and constraining/disclosing
intermediate certs. SSL certs are covered by the BR. Then in the next
version of Mozilla's policy we can consider adding a new item to the
policy to address requirements for CA hierarchies containing SSL,
S/MIME, and Code Signing certs.

3) Go through another round of re-writing this bullet point, potentially
delaying publication of version 2.1 of the policy.


My vote is for #2 -- remove for now, deal with it in the next version.

Kathleen

[Rick Andrews]

I'd like to answer Jeremy and Eddy on why any CA would want an exception to the prohibition against issuing certs directly from the root.

We (Symantec) have roots dating back to the 90s that initially signed certs directly but now issue almost all certs via an intermediate. These roots (and the customers' legacy apps that require root issuance) pre-date the CA/Browser Forum and all modern browser policies. We didn't set out to violate any policy. We complied with the policy at the time, which was that issuing off the root was perfectly acceptable.

I agree 100% that any new (or relatively new) root should be held to the higher standard of issuing intermediates only. Another option, Kathleen, would be to grandfather in roots older than a certain date and apply the policy to roots created after that date. IMO, that's a good compromise.

[Rick Andrews]

[Jeremy Rowley]

Do you use the same root to directly issue both client and SSL certs? If
they are only SSL, the Baseline Requirements contain an exception for that
very situation. This exception limits root issuance to circumstances where
there is a substantial number of Relying Parties and where updating the
application would require a substantial economic outlay.

What I'm confused about is why Mozilla wouldn't want client certificates to
follow this same general principle.

I'd rather not see Mozilla permit business exceptions for older roots since
doing so provides a significant benefit to older CAs (from both a marketing
and performance perspective) and unnecessarily restricts a new CA's ability
to compete. Plus, those types of clauses tend to create limited monopoly
interests for the grandfathered CA by effectively tying a single certificate
provider to the legacy application. The baseline requirements handle the
situation in a fair manner that avoids unduly favoring one CA over another.
These same requirement can easily be applied to all certificate types with
the expectation that eventually all direct root issuance will cease.

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 Rick Andrews
Sent: Wednesday, February 13, 2013 6:56 PM
To: mozilla.dev.s...@googlegroups.com
Cc: mozilla-dev-s...@lists.mozilla.org
Subject: Re: Responses to CA Communications

[Brian Smith]

Kathleen Wilson wrote:
> On 2/13/13 3:43 AM, Gervase Markham wrote:
> I am now of the opinion that we should delete the new sub-bullet from
> item #6, and let the BRs handle it.
>
> Currently Mozilla's proposed policy text is:
> "6.We require that all CAs whose certificates are distributed with
> our software products: ...

> - maintain a certificate hierarchy such that the included certificate

> does not directly issue end-entity certificates to customers (e.g.,
> the > included certificate signs intermediate issuing certificates),
> as described in CA/Browser Forum Baseline Requirement #12;"
>

> Does anyone object to deleting this sub-bullet?

I think it is fine to delete the bullet and to let the BR handle it for now.

> > Do we know which part of 9.2.1 they have problems with? Is it:
> >
> > A) Having to issue every cert with a SAN;
> > B) Notifying customers about the deprecation of Internal Server
> > Names;
> > C) Not issuing ISNs with an expiry date later than 1st Nov 2015
>
> A) Having to issue every cert with a SAN;
>
> > ? None of these seem deeply complex to implement.
>
> They just need a little more time to implement it.

Did they say why it is difficult to comply with the requirement? The addition of the SAN extension seems like one of the easiest things for a CA to do.

> >> - BR 13.2.2, "Repository" (OCSP)
> >
> > I assume the problem here is standing up an OCSP server?
>
> Yes. Some CAs need a little more time to do this. Some CAs have
> subCAs that need even more time to do this.

To what extent is the delay caused by the need to stand up a *publicly-accessible* OCSP server? Would it change the story if we removed the requirement on the condition that OCSP stapling is used for EE certificates? Presumably, the CAs with external sub-CAs that are having trouble standing up a public-facing OCSP server could re-issue those intermediate certificates with the must-staple extension and we could honor that.

> However, I want to make sure BR audits happen this year, so that any
> issues get identified this year. I prefer that CAs get their first BR
> audits done sooner with a couple exceptions noted, rather than later.

We should communicate to CAs which things are really important and which are not. For example, whether or not an external sub-CA has a public OCSP responder or a public CRL distribution point is less important to us than OCSP stapling + must-staple, name constraints for external sub-CAs, and comprehensive sets of CRLs that can be used to distinguish revoked intermediate certs from revoked end-entity certs.

Cheers,
Brian

[Rick Andrews]

We don't currently issue S/MIME or client auth certs from these roots, although the S/MIME trust bit may still be set for them. I'll check. If those bits are still set, I'll file a bug to remove them. If Kathleen removes bullet point 4 as mentioned above, and leaves this to the BRs, I think that we are fully compliant with the BR language.

[Rick Andrews]

On Wednesday, February 13, 2013 6:20:44 PM UTC-8, Jeremy Rowley wrote:

[Kathleen Wilson]

I don't recall any of the CAs saying it would be difficult to do this.
Their responses were basically that they reviewed the BRs and found that
they need to resolve a set of things in order to be in compliance. This
is one of the items that was often included in their list.

>>>> - BR 13.2.2, "Repository" (OCSP)
>>>
>>> I assume the problem here is standing up an OCSP server?
>>
>> Yes. Some CAs need a little more time to do this. Some CAs have
>> subCAs that need even more time to do this.
>
> To what extent is the delay caused by the need to stand up a
> *publicly-accessible* OCSP server? Would it change the story if we
> removed the requirement on the condition that OCSP stapling is used
> for EE certificates? Presumably, the CAs with external sub-CAs that
> are having trouble standing up a public-facing OCSP server could
> re-issue those intermediate certificates with the must-staple
> extension and we could honor that.

Good questions. Unfortunately, I don't know the answers. The CAs would
just list OCSP as one of the things they need to implement.

>
>> However, I want to make sure BR audits happen this year, so that any
>> issues get identified this year. I prefer that CAs get their first BR
>> audits done sooner with a couple exceptions noted, rather than later.
>
> We should communicate to CAs which things are really important and
> which are not. For example, whether or not an external sub-CA has a
> public OCSP responder or a public CRL distribution point is less important
> to us than OCSP stapling + must-staple, name constraints for external
> sub-CAs, and comprehensive sets of CRLs that can be used to distinguish revoked
> intermediate certs from revoked end-entity certs.

That's a good point. We can provide a list of "reasonable" exceptions in
the wiki page.

Thanks,
Kathleen

[Ryan Sleevi]

On Wed, February 13, 2013 7:02 pm, Kathleen Wilson wrote:
> On 2/13/13 6:37 PM, Brian Smith wrote:

> I don't recall any of the CAs saying it would be difficult to do this.
> Their responses were basically that they reviewed the BRs and found that
> they need to resolve a set of things in order to be in compliance. This
> is one of the items that was often included in their list.

Related, the serial number issue is already an existing requirement of
Mozilla's CA policy, as listed on
http://www.mozilla.org/projects/security/certs/policy/MaintenancePolicy.html

Does it really make sense to grant an exception to CAs that have indicated
they're already non-compliant with Mozilla's stated best practices? This
has been a Mozilla requirement since Oct 11, 2010 -
https://wiki.mozilla.org/CA:Communications#October_11.2C_2010 . It would
seem like this should be a point of discussion for the Enforcement Policy
(
http://www.mozilla.org/projects/security/certs/policy/EnforcementPolicy.html
), rather than as an exception.

I should note that Mozilla's not unique in this requirement - Microsoft
has required 8 bytes (rather than Mozilla's 20 bits) of randomness as part
of the serial, as described at
http://social.technet.microsoft.com/wiki/contents/articles/1760.windows-root-certificate-program-technical-requirements.aspx
, for all certificates issued after December 31, 2010.

Given the overlap between Mozilla's and Microsoft's root programs, I'd be
surprised if the CAs that raised concerns are not also in Microsoft's
program, where they'd also be non-compliant.

>
>
>
> >>>> - BR 13.2.2, "Repository" (OCSP)
> >>>
> >>> I assume the problem here is standing up an OCSP server?
> >>
> >> Yes. Some CAs need a little more time to do this. Some CAs have
> >> subCAs that need even more time to do this.
> >
> > To what extent is the delay caused by the need to stand up a
> > *publicly-accessible* OCSP server? Would it change the story if we
> > removed the requirement on the condition that OCSP stapling is used
> > for EE certificates? Presumably, the CAs with external sub-CAs that
> > are having trouble standing up a public-facing OCSP server could
> > re-issue those intermediate certificates with the must-staple
> > extension and we could honor that.
>
>

> Good questions. Unfortunately, I don't know the answers. The CAs would
> just list OCSP as one of the things they need to implement.
>
>
> >

> >> However, I want to make sure BR audits happen this year, so that any
> >> issues get identified this year. I prefer that CAs get their first BR
> >> audits done sooner with a couple exceptions noted, rather than later.
> >
> > We should communicate to CAs which things are really important and
> > which are not. For example, whether or not an external sub-CA has a
> > public OCSP responder or a public CRL distribution point is less
> > important
> > to us than OCSP stapling + must-staple, name constraints for external
> > sub-CAs, and comprehensive sets of CRLs that can be used to distinguish
> > revoked
> > intermediate certs from revoked end-entity certs.
>
>

> That's a good point. We can provide a list of "reasonable" exceptions in
> the wiki page.
>
> Thanks,
> Kathleen
>
>

[Brian Smith]

Jeremy Rowley wrote:
> I'd rather not see Mozilla permit business exceptions for older roots

> doing so provides a significant benefit to older CAs (from both a
> marketing and performance perspective) and unnecessarily restricts
> a new CA's ability to compete. Plus, those types of clauses tend to
> create limited monopoly interests for the grandfathered CA by
> effectively tying a single certificate provider to the legacy
> application. The baseline requirements handle the situation in a
> fair manner that avoids unduly favoring one CA over
> another.

I agree 100%.

However, I disagree that the BR are reasonable here. From my limited involvement with CA inclusion discussions, I think we should start relying on incentives for good behavior more and dis-incentives for bad behavior less.

For example, above Jeremy noted above that a CA that issues certs directly from the root has a performance benefit over a CA that uses intermediates. But, AFAICT, there's no reason why we couldn't preload the intermediates of the CAs that opt into (and help define) an intermediate CA whitelisting mechanism and our new approach to revocation checking and CT, such that *those* CAs end up having a clear, distinct, and marketable advantage over CAs that do not opt in. And, I think we would feel good about creating *that* kind of inequality in the market.

> These same requirement can easily be applied to all certificate types
> with the expectation that eventually all direct root issuance will
> cease.

Right now, SSL certificates are the most important issue for us, and also that's what we understand best. To me, our current infrastructure doesn't seem well-suited to *successful* deployments of S/MIME, client authentication for SSL, and code signing *on the internet* (as opposed to enterprisy deployments). We should work on solving SSL-related problems first.

Cheers,
Brian

[Jeremy Rowley]

There are national policies that prevent use of an intermediate? That's
crazy! India and Suscrete should probably use intermediates since, by
nature of their inclusion in the trust store, their intermediates have
become root certificates.

Because removing #2 would permit issuance of code signing and client certs
directly from a root (a bad practice), wouldn't a better solution be to
replace the bullet point with more flexible language that alerts CAs that
Mozilla may tighten the requirements later? This would prevent a period of
bad practices while we wait for the next round of updates.

A short policy could be:
CAs should not issue end entity certificates directly from a certificate
embedded in Mozilla's root store unless there is clear technical or legal
requirement requiring the issuance of such certificates.

The "should" gives CAs room when direct issuance is required but provides a
clear warning that this practice may become obsolete in the near future.
The exception is limited to technical and legal reasons making it apparent
that this practice should be the exception rather than the norm.

An alternative is to use a modified baseline requirements policy:
CAs must not use root certificates to sign end entity certificates unless 1)
the laws in the CA's jurisdiction of operation prohibit use of
intermediates, 2) the CA cannot use the root certificate with intermediates
because of constraints associated with the root certificate, or 3) a legacy
application used by a substantial number of relying parties requires the use
of end entity certificates issued directly from the root certificate and the
application cannot be patched or replaced without substantial economic
outlay.

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 Kathleen Wilson
Sent: Wednesday, February 13, 2013 5:53 PM
To: mozilla-dev-s...@lists.mozilla.org
Subject: Re: Responses to CA Communications

On 2/13/13 2:37 PM, Eddy Nigg wrote:

> On 02/13/2013 10:38 PM, From Jeremy Rowley:
>> If anything, I think this requirement should be expanded and
>> recommend separate intermediates for SSL and s/MIME. Doing so
>> permits Mozilla more control over the CA, reduces the likelihood of a
"too-large-to-fail"
>> situation, and is (or I thought it was) generally regarded as a good
>> practice in certificate issuance. Before you change this, I'd really
>> like to understand why any CA would ask for an exception.
>
> Dito here - in my opinion the above should be best practice, but
> certainly never issue directly from the root. I hope we've covered
> this extensively already.
>

One of my goals for doing the recent CA Communication was to have CAs review
the proposed changes to Mozilla's CA Certificate Policy, and let me know if
they would not be able to meet any of the changes within the allotted time
frames. This particular item came up repeatedly in the responses, so I would
like to figure out how to address it. This is the only issue now holding up
official publication of version 2.1 of Mozilla's CA Certificate policy.

The currently drafted text is: "maintain a certificate hierarchy such that

the included certificate does not directly issue end-entity certificates to
customers (e.g., the included certificate signs intermediate issuing
certificates), as described in CA/Browser Forum Baseline Requirement #12;"

[alexand...@dsv-gruppe.de]

As you allready mentioned, the damage that someoane can cause with a rogue S/MIME cerificate is significantly less then the damage someone can do with a rogue SSL certificate.

Furthermore, some CAs cannot use the root certificate with intermediates
because of constraints regarding the root certificate (pathlength=0). Another issue that some CAs must deal with is that some national certificate policies do not allow the root certificate to sign intermediate certificates.

I think it is ok to apply choice #2.

Regards,
Alexandru

[alexand...@dsv-gruppe.de]

Am Donnerstag, 14. Februar 2013 01:52:48 UTC+1 schrieb Kathleen Wilson:

[Eddy Nigg]

On 02/14/2013 03:55 AM, From Rick Andrews:

> These roots (and the customers' legacy apps that require root issuance) pre-date the CA/Browser Forum and all modern browser policies

And how wise it is to use software that doesn't have the capability to
work correctly with CA chains? Are we talking about something predating
Windows 3 and older? I don't think it's worth to compromise for this,
seriously.

[Gervase Markham]

On 14/02/13 01:08, Kathleen Wilson wrote:
> One problem with this is that there are a couple CAs (e.g. SUSCERTE,
> India CCA) who applied for inclusion, but we told them to have their
> subCAs apply for inclusion separately, as separate trust anchors. Are
> we now going to require that these subCAs create additional
> intermediate certificates?

I would say yes. The point here is to avoid having the "thing which is
embedded in Mozilla" be online and issuing certificates regularly,
because that's a significant risk both to us and to them. The fact that
there's another cert above it in some hierarchy doesn't affect this point.

> I have also learned that some national certificate policies do not
> allow the CA to sign intermediate certificates.

They actively _forbid_ it? I'd like to hear more about that. But I would
sat that CAs issuing under such policies will need to issue from roots
not in our programme. The tension we put them under here is a catalyst
for them to approach the relevant national bodies and explain how their
policy is bogus.

> Another problem is that there are older root certs included in Mozilla's
> program that have pathlength=0. For them to resolve this, they will
> need to create a new root cert, go through our process to get it
> included, and then migrate their customers to the new hierarchy. We
> can't expect them to get this all done in the next year. So do we give
> these roots an exception?

Do these CAs claim that this requirement has come just now as a
surprise? (If they do, and we think they have a point, perhaps we might
consider sending more regular CA Communications.)

How many roots are involved? Do the CAs concerned have other roots in
our program which do not have this problem?

> Another issue that some CAs are dealing with is that their customers
> have legacy software that was written before intermediate certificates
> were common. They will need to get their customers to update their
> software, and then migrate to a new hierarchy. Do we give an
> longer-term exception for these cases?

Again, are they claiming that this requirement is a surprise?

Is this web server software which is exposed to the public internet? If
so, surely if it's that old then it's riddled with security holes? Our
focus is on SSL certs for the Internet; I am less concerned about
exceptions which are not in that category.

> 1) Leave the proposed bullet point as-is, but add a bunch of
> exceptions to the wiki page.

I think this is the best course of action. The list of exceptions may be
long initially, but we can then at least manage it down to zero over
time. If we push out the date for the requirement, there is less
incentive to clean things up IMO. We'll just find that, in a year's
time, there are another load of people requesting an exception.

If you think this would delay publication, then I would publish as-is
and we can do a "fast update" round to fix this particular issue,
publishing a 2.1.1 in a month or so.

Gerv

[alexand...@dsv-gruppe.de]

Am Donnerstag, 14. Februar 2013 12:31:13 UTC+1 schrieb Gervase Markham:
> On 14/02/13 01:08, Kathleen Wilson wrote
>

> > 1) Leave the proposed bullet point as-is, but add a bunch of
>
> > exceptions to the wiki page.
>
>
>
> I think this is the best course of action. The list of exceptions may be
>
> long initially, but we can then at least manage it down to zero over
>
> time. If we push out the date for the requirement, there is less
>
> incentive to clean things up IMO. We'll just find that, in a year's
>
> time, there are another load of people requesting an exception.
>
>
>
> If you think this would delay publication, then I would publish as-is
>
> and we can do a "fast update" round to fix this particular issue,
>
> publishing a 2.1.1 in a month or so.
>
>
>
> Gerv

What is the consequence of adding those exceptions to the wiki page?
Are these exceptions applying in relation to the Certificate Policy 2.1?

I think that a proper and fast solution is to remove the proposed bullet point and add a new item to the next policy to adress requirements for CA hierarchies containing SSL, S/MIME and code-signing. There is a different risk profile for S/MIME certificates as opposed for SSL certificates, so that it would be appropriate to adress the requirements (for CA hierarchies) separately.

Regards

[alexand...@dsv-gruppe.de]

Am Donnerstag, 14. Februar 2013 12:31:13 UTC+1 schrieb Gervase Markham:

> On 14/02/13 01:08, Kathleen Wilson wrote
>

> > 1) Leave the proposed bullet point as-is, but add a bunch of
>
> > exceptions to the wiki page.
>
>
>
> I think this is the best course of action. The list of exceptions may be
>
> long initially, but we can then at least manage it down to zero over
>
> time. If we push out the date for the requirement, there is less
>
> incentive to clean things up IMO. We'll just find that, in a year's
>
> time, there are another load of people requesting an exception.
>
>
>
> If you think this would delay publication, then I would publish as-is
>
> and we can do a "fast update" round to fix this particular issue,
>
> publishing a 2.1.1 in a month or so.
>
>
>
> Gerv

[Kathleen Wilson]

On 2/14/13 3:31 AM, Gervase Markham wrote:
> On 14/02/13 01:08, Kathleen Wilson wrote:
>> One problem with this is that there are a couple CAs (e.g. SUSCERTE,
>> India CCA) who applied for inclusion, but we told them to have their
>> subCAs apply for inclusion separately, as separate trust anchors. Are
>> we now going to require that these subCAs create additional
>> intermediate certificates?
>
> I would say yes. The point here is to avoid having the "thing which is
> embedded in Mozilla" be online and issuing certificates regularly,
> because that's a significant risk both to us and to them. The fact that
> there's another cert above it in some hierarchy doesn't affect this point.
>
>> I have also learned that some national certificate policies do not
>> allow the CA to sign intermediate certificates.
>
> They actively _forbid_ it? I'd like to hear more about that. But I would
> sat that CAs issuing under such policies will need to issue from roots
> not in our programme. The tension we put them under here is a catalyst
> for them to approach the relevant national bodies and explain how their
> policy is bogus.

One example is the national Danish Digital Signature (OCES) Certificate
Policy (OCES CP).

>
>> Another problem is that there are older root certs included in Mozilla's
>> program that have pathlength=0. For them to resolve this, they will
>> need to create a new root cert, go through our process to get it
>> included, and then migrate their customers to the new hierarchy. We
>> can't expect them to get this all done in the next year. So do we give
>> these roots an exception?
>
> Do these CAs claim that this requirement has come just now as a
> surprise? (If they do, and we think they have a point, perhaps we might
> consider sending more regular CA Communications.)
>
> How many roots are involved? Do the CAs concerned have other roots in
> our program which do not have this problem?
>

I am only aware of one root that has pathlength=0. That CA only has one
root included. Other CAs have said they will need to create new root
certs to comply, but did not specifically say that they have
pathlength=0 in their root.

>> 1) Leave the proposed bullet point as-is, but add a bunch of
>> exceptions to the wiki page.
>
> I think this is the best course of action. The list of exceptions may be
> long initially, but we can then at least manage it down to zero over
> time. If we push out the date for the requirement, there is less
> incentive to clean things up IMO. We'll just find that, in a year's
> time, there are another load of people requesting an exception.
>

We can go this route. We can continue to modify the wiki page to make
things more clear.

I updated the wiki page as follows
https://wiki.mozilla.org/CA:CertPolicyUpdates#Transitioning_to_the_Updated_Policy_Version_2.1
--
Item #6, fourth bullet: "maintain a certificate hierarchy such that the

included certificate does not directly issue end-entity certificates to
customers (e.g., the included certificate signs intermediate issuing
certificates), as described in CA/Browser Forum Baseline Requirement #12;"

- This requirement and the exceptions listed in BR #12 apply to SSL/TLS,
S/MIME, and Code Signing certificates.
- Root certificates and trust anchors that are already included in NSS
will be granted the time necessary to transition their existing
customers to a new hierarchy. For instance, if a root certificate has
pathlength=0, the CA shall create a new root certificate within the next
year and actively work to include the new root certificate in Mozilla's
program and transition their customers to the new hierarchy.
--

OK?

Kathleen

[Eddy Nigg]

On 02/14/2013 01:31 PM, From Gervase Markham:

> They actively _forbid_ it? I'd like to hear more about that.

There is some logic with that from the root CA perspective that
regulates them. They don't want to allow the CAs beneath to issue other
CA certificates, simply as that. The same as a root CA issuing
subordinate CA certificates, they'll limit those contactually or
technically so that they can't issue further CA certificates.

From the regulating root perspective they are right IMO.

[Eddy Nigg]

On 02/14/2013 10:42 AM, From alexand...@dsv-gruppe.de:

> As you allready mentioned, the damage that someoane can cause with a
> rogue S/MIME cerificate is significantly less then the damage someone
> can do with a rogue SSL certificate.

A CA root certificate that gets compromised in some way is always a
root, no matter what its primary purpose is. Except in case that root is
limited to issue only S/MIME certs, I don't think it makes a difference.
And since the form and way of compromise can't be always known upfront,
whatever limitations are set might not be enough to prevent fraudulent use.

[Brian Smith]

Gervase Markham wrote:
> On 14/02/13 01:08, Kathleen Wilson wrote:
> > Are we now going to require that these subCAs create additional
> > intermediate certificates?
>
> I would say yes. The point here is to avoid having the "thing which
> is embedded in Mozilla" be online and issuing certificates regularly,
> because that's a significant risk both to us and to them. The fact
> that there's another cert above it in some hierarchy doesn't affect
> this point.

What is the additional risk to us? AFAICT, the benefit of this require was mostly for browsers that do intermediate revocation fetching in the classic ways, which we've basically never done and which we seem unlikely to ever do. And our plan is to make it as easy to revoke a root as it is to revoke an intermediate. So, I'm not sure what benefit we actually receive from the requirement. However, the harm in the requirement is clear: it causes performances issues, it adds complexity, and it seems unenforceable anyway. Unless/until other browser makers complain that it is hurting them, maybe should just ignore the issue.

Cheers,
Brian

[Erwann Abalea]

Le jeudi 14 février 2013 17:50:10 UTC+1, Kathleen Wilson a écrit :
[...]

> I am only aware of one root that has pathlength=0. That CA only has one
> root included. Other CAs have said they will need to create new root
> certs to comply, but did not specifically say that they have
> pathlength=0 in their root.

Having a BasicConstraints:pathlen=0 in the trust anchor shouldn't be a problem.
The normative algorithm doesn't use this extension from the trust anchor to set the initial max pathlen value, it's set to the length of the chain found.

So it may be ugly to have a trust anchor with BasicConstraints:pathLen=0 sign a subordinate CA which in turn will sign subscriber certificates, but if the normalized algorithm is followed, it works ;)

[Jeremy Rowley]

As Gerv said, there is a significant security benefit in requiring CAs to
keep their root off-line, thus reducing the likelihood of a key compromise.
Revoking a root certificate might impact hundreds of thousands of websites.
Hopefully, CAs are using multiple intermediates for issuance, meaning that
revoking an intermediate will impact a much smaller number of sites.

The requirement is definitely not un-enforceable. The requirement has
become part of both ETSI and WebTrust audit criteria (for compliance with
the baseline standards). I expect that ETSI and WebTrust will likely apply
the same requirement to other types of certificates once a standard is
adopted, either by Mozilla or another group.

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 Brian Smith
Sent: Thursday, February 14, 2013 10:50 AM
To: Gervase Markham
Cc: mozilla-dev-s...@lists.mozilla.org
Subject: Re: Responses to CA Communications

[Kathleen Wilson]

I updated the wiki page based on this discussion...

https://wiki.mozilla.org/CA:CertPolicyUpdates#Transitioning_to_the_Updated_Policy_Version_2.1
--
Item #6, fourth bullet: "maintain a certificate hierarchy such that the

included certificate does not directly issue end-entity certificates to
customers (e.g., the included certificate signs intermediate issuing
certificates), as described in CA/Browser Forum Baseline Requirement #12;"

- This requirement and the exceptions listed in BR #12 apply to SSL/TLS,
S/MIME, and Code Signing certificates.

- Root certificates and trust anchors that are already included in NSS
will be granted the time necessary to transition their existing

customers to a new hierarchy. If needed, the CA shall create a new root
certificate within the next year (before February 2014) and actively

work to include the new root certificate in Mozilla's program and

transition their customers to the new hierarchy.

- Mozilla grants an exception to the trust anchors in Mozilla's program
that are signed by national policy root certificates whose corresponding
national policy does not allow the subordinate CA to issue other
subordinate CA certificates.
--

This is still open for further feedback and discussion.

Thanks,
Kathleen

[Brian Smith]

Jeremy Rowley wrote:
> Revoking a root certificate might impact hundreds of thousands of
> websites. Hopefully, CAs are using multiple intermediates for
> issuance, meaning that revoking an intermediate will impact a much
> smaller number of sites.

The requirement allows a CA to issue all its certificates from one intermediate though, so partitioning isn't a benefit of this requirement.

I am interested to know, though, how you partition your intermediates that issue public certificates in such a way that it would be reasonable to revoke one of them in response to a security incident. One obvious way to do it is to have a separate intermediate for each (large) customer. But, what about the smaller customers that all share an intermediate?

Cheers,
Brian

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

All,

Independent from the issues actually discussed I have a general concern.
Mozilla sent a communication to all rootCAs which includes a couple of clear requirements. A lot of them were either discussed longish in public or announced in some other way (e.g. recommended practice).
There are CAs spending time and effort following (or even participating) the discussions and the vendor's root programs. From my perspective a included rootCA should at least have a look at this regularly (AFAIK this is already a requirement of Mozilla's program).

I can say that at least for T-Systems it took a lot of time and effort to work on all those items to fulfill the requirements (for some even before the communication was sent). Recognizing the various answers and looking at the following discussion one may ask whether there are cases where some understand those items more than a "first draft for a negotiation" rather than requirements. (I'm trying to find a very very carefully wording here). To be honest, I already had to argue against this argumentation :-S

My concern is, that this procedure will lead to more and more people generally saying "we need more time" or "we cannot fulfill this at all" and wait what the next offer for a weaker compromise will be.

To get this clear - I recognize and absolutely appreciate that Kathleen is taking the CAs' concerns always very seriously and that she always try to find a way both Mozilla and the CAs can live with.

As said at the beginning, this is not regarding dedicated exceptions or whatever. I absolutely understand that there are special situations needing some kind of exceptions, grandfathering or things like that.

As usually: Just my 5 cents :-)

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...@external.t-systems.com
http://www.t-systems.com, http://www.telesec.de

> -----Original Message-----
> From: dev-security-policy-bounces+carsten.dahlenkamp=external.t-
> syste...@lists.mozilla.org [mailto:dev-security-policy-
> bounces+carsten.dahlenkamp=external.t-...@lists.mozilla.org]
> On Behalf Of Kathleen Wilson

> Sent: Monday, February 11, 2013 11:32 PM
> To: mozilla-dev-s...@lists.mozilla.org
> Subject: Re: Responses to CA Communications
>

> All,
>
> As you know, I am summarizing responses to the recent CA Communication
> here:
> https://wiki.mozilla.org/CA:Communications#January_2013_Responses
> Here are the trends that I am seeing.
>
>
> Action #1: Mozilla Policy Update Readiness
>
> In regards to the changes to version 2.1 of Mozilla's CA Certificate
> policy, most CAs stated that they were already in compliance with the
> changes, or would be able to comply with the new requirements
> according to the time frames listed on the wiki page
> (https://wiki.mozilla.org/CA:CertPolicyUpdates#Transitioning_to_the_Up
> dated_Policy_Version_2.1).
>
> Most of the CAs that answered with "C" (need more time) stated that
> they need more time to comply with the Baseline Requirements. They
> were OK with the time frames allowed for transitioning their
> intermediate certificates.
>
> There are a couple CAs whose included root certs only have the email
> trust bit enabled, and those root certs sign end-entity certs
> directly, as required by legacy software. These CAs have requested a
> long-term exception to Mozilla's new policy requiring intermediate
> issuing certificates.
> I added a bullet point to the wiki page to address this.
> https://wiki.mozilla.org/CA:CertPolicyUpdates#Transitioning_to_the_Upd
> ated_Policy_Version_2.1

> "Item #6, fourth bullet: "maintain a certificate hierarchy such that
> the included certificate does not directly issue end-entity
> certificates to customers (e.g., the included certificate signs

> intermediate issuing certificates);"
> - As of February 15, 2014 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.
> - Exceptions may be granted for root certificates that only have the
> email (S/MIME) trust bit enabled, and do not have the websites
> (SSL/TLS) or code signing trust bits enabled."
>
>
>
> Action #2: Baseline Requirements Readiness
>
> The BRs that CAs most commonly stated that they need more time to
> comply with are:
> - BR 9.2.1, "Subject Alternative Name Extension"
> - BR 9.6, "Certificate Serial Number"

> - BR 13.2.2, "Repository" (OCSP)

> - Appendix B, "Certificate Extensions (Normative)"
> - Appendix C, "User Agent Verification (Normative)"
>
> For in-premise operations, most CAs stated that they expect to comply
> with the BRs by June 2013.
>
> Several CAs stated that they need more time to help their subordinate
> CAs comply with the BRs.
>
> I am considering adding a sub-bullet to the wiki page to take these
> requests into account. See the third sub-bullet (proposed) below...
> https://wiki.mozilla.org/CA:CertPolicyUpdates#Transitioning_to_the_Upd
> ated_Policy_Version_2.1
> "Item #13: "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."
> - As of February 2013, SSL certificate issuance must also be audited
> according to the Baseline Requirements. (see details above)
> - All other dates are as specified by the CA/Browser Forum.
> - The first BR audit for each CA and subCA may include a list of BRs
> that the CA (or subCA) is not yet in compliance with. The second BR
> audit (the following year) is expected to confirm that the issues that
> were listed in the previous BR audit have been resolved."
>
>
> Action #3: Scan Cert DB
>
> Many CAs are still working on this action item. The most common issues
> are 1024-bit certs and certs being issued with sequential serial
> numbers and insufficient entropy.
>
>
> Action #4: Deprecate issuance of SSL certificates containing a
> Reserved IP Address or Internal Server Name.
>
> For CAs who issue this type of cert, many said that they will stop
> issuance earlier than is required in BR 9.2.1, but several said that
> they will use the dates listed in BR 9.2.1.
>
>
> Kathleen

[Erwann Abalea]

Le jeudi 31 janvier 2013 20:27:59 UTC+1, Kathleen Wilson a écrit :
> As many of you are already aware, I am posting responses to the CA

> Communication here:
> https://wiki.mozilla.org/CA:Communications#January_2013_Responses

There's at least 2 entities who gave wrong replies:
- Atos, response 3 was "A", which means "everything's clean in our database"; but they omitted to mention CA certificates without CRLDP, and CA certificates with non unique serial numbers
- TeliaSonera, response 2 was "A" which means "fully CABF BR compliant"; but they deliver certificates from the root, without OCSP, without SAN, and the CRL contains suspended certificates

I'm sure they're not alone.

[Kathleen Wilson]

On 4/18/13 2:35 AM, Erwann Abalea wrote:
> Le jeudi 31 janvier 2013 20:27:59 UTC+1, Kathleen Wilson a �crit :

Erwann, Thanks for pointing this out. I'll review their responses again.

Kathleen

[pekka.la...@teliasonera.com]

TeliaSonera hasn't given any wrong replies. At the time TeliaSonera gave the reply (January 2013) we thought we were fully compliant with CAB BR 1.1. The incorrect accusations and the actual facts are:

a) Certificates from the root
Not true after January 2013, until January 2013 almost all TeliaSonera certificates came from the root.

b) without OCSP
Not true after January 2013. TeliaSonera added OCSP service and AIA OCSP extension to server certificates in January 2013. However, OCSP is not on client or on sub CA certificates but CAB BR is targeted for server certificates only. We are adding OCSP also to all sub CA certificates in the next few weeks when we will resign them. There is no schedule to add OCSP to client certificates.

c) without SAN
Not true after August 2012. TeliaSonera has added SAN to all server certificates starting from August 2012.

d) CRL contains suspended certificates
This is true. TeliaSonera CA Policy states that suspension is possible and suspended certificates are automatically revoked within six months from suspension. However, BR #13.2.7 was added in version 1.1.3 of the Baseline Requirements in February 2013 after TeliaSonera response. TeliaSonera is currently investigating if and how to implement the new requirement. Note! Mozilla is discussing to put this requirement to BR exception list here: https://groups.google.com/forum/#!msg/mozilla.dev.security.policy/j4pS8H8P5Go/lmIKqpQvFSgJ