Re: Policy 2.7.1: MRSP Issue #218: Clarify CRL requirements for End Entity Certificates

[Ben Wilson via dev-security-policy]

iously CAs shouldn't issue leaf certs directly from roots, but
>>> > nonetheless the technical capability does exist.  However, currently
>>> CAs
>>> > can't edit Root Certificate records in the CCADB, which makes
>>> populating
>>> > these new field(s) "in all situations" rather hard.
>>> >
>>> > Since OneCRL covers revocations of intermediate certs, may I suggest
>>> that
>>> > CAs should only be required to populate these new field(s) in
>>> intermediate
>>> > certificate records (and not in root certificate records)?
>>> >
>>> > Relatedly, "A CA technically capable of...that the CCADB field" seems
>>> > wrong.  CCADB "CA Owner" records don't/won't contain the new field(s).
>>> > Similar language elsewhere in the policy (section 5.3.2) says "All
>>> > certificates that are capable of being used to..." (rather than "All
>>> > CAs...").
>>> >
>>> > Technically-constrained intermediate certs don't have to be disclosed
>>> to
>>> > CCADB, but "in all situations where the CA is enabled for server
>>> > certificate issuance" clearly includes technically-constrained
>>> > intermediates.  How would a CA populate the "Full CRL Issued By This
>>> CA"
>>> > field for a technically-constrained intermediate cert that has
>>> > (legitimately) not been disclosed to CCADB?
>>> >
>>> > --
>>> > *From:* dev-security-policy <
>>> dev-security-policy-boun...@lists.mozilla.org>
>>> > on behalf of Ben Wilson via dev-security-policy <
>>> > dev-security-policy@lists.mozilla.org>
>>> > *Sent:* 08 January 2021 01:00
>>> > *To:* mozilla-dev-security-policy <
>>> > mozilla-dev-security-pol...@lists.mozilla.org>
>>> > *Subject:* Policy 2.7.1: MRSP Issue #218: Clarify CRL requirements for
>>> > End Entity Certificates
>>> >
>>> > CAUTION: This email originated from outside of the organization. Do not
>>> > click links or open attachments unless you recognize the sender and
>>> know
>>> > the content is safe.
>>> >
>>> >
>>> > This is the last issue that I have marked for discussion in relation to
>>> > version 2.7.1 of the Mozilla Root Store Policy
>>> > <
>>> >
>>> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.mozilla.org%2Fen-US%2Fabout%2Fgovernance%2Fpolicies%2Fsecurity-group%2Fcerts%2Fpolicy%2Fdata=04%7C01%7Crob%40sectigo.com%7C65685639e2bf45be5f6f08d8b370cf17%7C0e9c48946caa465d96604b6968b49fb7%7C0%7C0%7C637456644391892862%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=shOhNu8IGrT0iSSt2LY4E6LQlsr6y435Vv%2BNezNCh98%3Dreserved=0
>>> > >.
>>> > It is identified and discussed in GitHub Issue #218
>>> > <
>>> >
>>> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fmozilla%2Fpkipolicy%2Fissues%2F218data=04%7C01%7Crob%40sectigo.com%7C65685639e2bf45be5f6f08d8b370cf17%7C0e9c48946caa465d96604b6968b49fb7%7C0%7C0%7C637456644391892862%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=Zb0abofrs3IaJzX9nkEnFf6RbyCemLYIi%2B7l4SmUz5U%3Dreserved=0
>>> >
>>> > for the MRSP.
>>> >
>>> > I will soon update everyone on the status of the other 13 discussion
>>> items
>>> > already presented, as some of them are in need of revision based on
>>> > comments received thus far.
>>> >
>>> > While subsection (b) of section 7.1.2.3 of the Baseline Requirements
>>> makes
>>> > a cRLDistributionPoint (CDP) in end entity certificates optional,
>>> Mozilla
>>> > still desires that CRL-based revocation information be available
>>> because
>>> > CRLite uses CRLs to construct its revocation filters.  (Apple also uses
>>> > such CRL information in its certificate validation processes and, as I
>>> > understand, is making a similar request of CAs with respect to the new
>>> > CCADB field, discussed below.)
>>> >
>>> > While all such CRL information is needed, large CRLs are disfavored
>>> because
>>> > of the time they take to download and process.  Thus, CAs shard,
>>> partition,
>>> > or "scope" their CRLs into sma

Re: Policy 2.7.1: MRSP Issue #218: Clarify CRL requirements for End Entity Certificates

[Ben Wilson via dev-security-policy]

quot;A CA technically capable of...that the CCADB field" seems
>> > wrong.  CCADB "CA Owner" records don't/won't contain the new field(s).
>> > Similar language elsewhere in the policy (section 5.3.2) says "All
>> > certificates that are capable of being used to..." (rather than "All
>> > CAs...").
>> >
>> > Technically-constrained intermediate certs don't have to be disclosed to
>> > CCADB, but "in all situations where the CA is enabled for server
>> > certificate issuance" clearly includes technically-constrained
>> > intermediates.  How would a CA populate the "Full CRL Issued By This CA"
>> > field for a technically-constrained intermediate cert that has
>> > (legitimately) not been disclosed to CCADB?
>> >
>> > --
>> > *From:* dev-security-policy <
>> dev-security-policy-boun...@lists.mozilla.org>
>> > on behalf of Ben Wilson via dev-security-policy <
>> > dev-security-policy@lists.mozilla.org>
>> > *Sent:* 08 January 2021 01:00
>> > *To:* mozilla-dev-security-policy <
>> > mozilla-dev-security-pol...@lists.mozilla.org>
>> > *Subject:* Policy 2.7.1: MRSP Issue #218: Clarify CRL requirements for
>> > End Entity Certificates
>> >
>> > CAUTION: This email originated from outside of the organization. Do not
>> > click links or open attachments unless you recognize the sender and know
>> > the content is safe.
>> >
>> >
>> > This is the last issue that I have marked for discussion in relation to
>> > version 2.7.1 of the Mozilla Root Store Policy
>> > <
>> >
>> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.mozilla.org%2Fen-US%2Fabout%2Fgovernance%2Fpolicies%2Fsecurity-group%2Fcerts%2Fpolicy%2Fdata=04%7C01%7Crob%40sectigo.com%7C65685639e2bf45be5f6f08d8b370cf17%7C0e9c48946caa465d96604b6968b49fb7%7C0%7C0%7C637456644391892862%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=shOhNu8IGrT0iSSt2LY4E6LQlsr6y435Vv%2BNezNCh98%3Dreserved=0
>> > >.
>> > It is identified and discussed in GitHub Issue #218
>> > <
>> >
>> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fmozilla%2Fpkipolicy%2Fissues%2F218data=04%7C01%7Crob%40sectigo.com%7C65685639e2bf45be5f6f08d8b370cf17%7C0e9c48946caa465d96604b6968b49fb7%7C0%7C0%7C637456644391892862%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=Zb0abofrs3IaJzX9nkEnFf6RbyCemLYIi%2B7l4SmUz5U%3Dreserved=0
>> >
>> > for the MRSP.
>> >
>> > I will soon update everyone on the status of the other 13 discussion
>> items
>> > already presented, as some of them are in need of revision based on
>> > comments received thus far.
>> >
>> > While subsection (b) of section 7.1.2.3 of the Baseline Requirements
>> makes
>> > a cRLDistributionPoint (CDP) in end entity certificates optional,
>> Mozilla
>> > still desires that CRL-based revocation information be available because
>> > CRLite uses CRLs to construct its revocation filters.  (Apple also uses
>> > such CRL information in its certificate validation processes and, as I
>> > understand, is making a similar request of CAs with respect to the new
>> > CCADB field, discussed below.)
>> >
>> > While all such CRL information is needed, large CRLs are disfavored
>> because
>> > of the time they take to download and process.  Thus, CAs shard,
>> partition,
>> > or "scope" their CRLs into smaller chunks. Section 5 of RFC 5280
>> explains,
>> > "Each CRL has a particular scope.  The CRL scope is the set of
>> certificates
>> > that could appear on a given CRL. … A complete CRL lists all unexpired
>> > certificates, within its scope, that have been revoked for one of the
>> > revocation reasons covered by the CRL scope.  A *full and complete CRL*
>> > lists all unexpired certificates issued by a CA that have been revoked
>> for
>> > any reason." (Emphasis added.)
>> >
>> > There is a new field in the CCADB for CAs to include information needed
>> for
>> > browsers or others to construct a "full and complete CRL", i.e. to
>> gather
>> > information from CAs that don't include the CRL path to their "full and
>> > complete CRL" in end entity certificates they issue. This new CCADB
>> field
>> > i

Re: Policy 2.7.1: MRSP Issue #218: Clarify CRL requirements for End Entity Certificates

[Aaron Gable via dev-security-policy]

I think that an explicit carve-out for time-scoped CRLs is a very good idea.

In the case that this change to the MRSP is adopted, I suspect that LE
would scope CRLs by notAfter quite tightly, with perhaps one CRL per 24 or
even 6 hours of issuance. We would pick a small interval such that we could
guarantee that each CRL would still be a reasonable size even in the face
of a mass revocation event.

Producing CRLs at that rate, it would be very valuable to be able to
gracefully age CRLs out once there is no possibility for a revocation
status update for any certificate in their scope.

Aaron

On Sun, Jan 24, 2021 at 10:22 AM Ben Wilson via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> All,
>
> Another suggestion came in for clarification that hasn't been raised on the
> list yet, so I'll try and explain the scenario here.
>
> Normally, a CA must publish and update its CRLs until the end of the CA
> certificate's expiration. However, I think that some CAs partition their
> CRLs based on issuance time, e.g., all certificates issued during January
> 2021. And all of those certificates would expire after the applicable
> validity period.  I think CAs don't continue to regenerate or reissue those
> types of partitioned CRLs which only contain certificates that have
> expired.  So maybe we need to add an express exception that allows CAs to
> omit those obsolete CRLs from the JSON file -- as long as the JSON file
> contains the equivalent of  a "full and complete" CRL.
>
> Thoughts?
>
> Thanks,
> Ben
>
>
> On Wed, Jan 13, 2021 at 8:57 AM Rob Stradling  wrote:
>
> > Hi Ben.
> >
> > > *A CA technically capable of issuing server certificates MUST ensure
> > that
> > > the CCADB field "Full CRL Issued By This CA" contains either the URL
> for
> > > the full and complete CRL or the URL for the JSON file containing all
> > URLs
> > > for CRLs that when combined are the equivalent of the full and complete
> > CRL*
> >
> > As a consumer of this data (crt.sh), I'd much prefer to see "Full CRL
> > Issued By This CA" and "the URL for the JSON file" as 2 separate fields
> in
> > the CCADB.  CAs would then be expected to fill in one field or the other,
> > but not both.  Is that possible?
> >
> > To ensure that these JSON files can be programmatically parsed, I suggest
> > specifying the requirement a bit more strictly.  Something like this:
> >   "...or the URL for a file that contains only a JSON Array, whose
> > elements are URLs of DER encoded CRLs that when combined are the
> equivalent
> > of a full and complete CRL"
> >
> > > I propose that this new CCADB field be populated in all situations
> where
> > the CA is enabled for server certificate issuance.
> >
> > Most Root Certificates are "enabled for server certificate issuance".
> > Obviously CAs shouldn't issue leaf certs directly from roots, but
> > nonetheless the technical capability does exist.  However, currently CAs
> > can't edit Root Certificate records in the CCADB, which makes populating
> > these new field(s) "in all situations" rather hard.
> >
> > Since OneCRL covers revocations of intermediate certs, may I suggest that
> > CAs should only be required to populate these new field(s) in
> intermediate
> > certificate records (and not in root certificate records)?
> >
> > Relatedly, "A CA technically capable of...that the CCADB field" seems
> > wrong.  CCADB "CA Owner" records don't/won't contain the new field(s).
> > Similar language elsewhere in the policy (section 5.3.2) says "All
> > certificates that are capable of being used to..." (rather than "All
> > CAs...").
> >
> > Technically-constrained intermediate certs don't have to be disclosed to
> > CCADB, but "in all situations where the CA is enabled for server
> > certificate issuance" clearly includes technically-constrained
> > intermediates.  How would a CA populate the "Full CRL Issued By This CA"
> > field for a technically-constrained intermediate cert that has
> > (legitimately) not been disclosed to CCADB?
> >
> > --
> > *From:* dev-security-policy <
> dev-security-policy-boun...@lists.mozilla.org>
> > on behalf of Ben Wilson via dev-security-policy <
> > dev-security-policy@lists.mozilla.org>
> > *Sent:* 08 January 2021 01:00
> > *To:* mozilla-dev-security-policy <
> > mozilla-dev-security-pol...@lists.mozilla.org>
> > *Subject:* Policy 2.7.1: MRSP Is

Re: Policy 2.7.1: MRSP Issue #218: Clarify CRL requirements for End Entity Certificates

[Rob Stradling via dev-security-policy]

Hi Ben.

> *A CA technically capable of issuing server certificates MUST ensure that
> the CCADB field "Full CRL Issued By This CA" contains either the URL for
> the full and complete CRL or the URL for the JSON file containing all URLs
> for CRLs that when combined are the equivalent of the full and complete CRL*

As a consumer of this data (crt.sh), I'd much prefer to see "Full CRL Issued By 
This CA" and "the URL for the JSON file" as 2 separate fields in the CCADB.  
CAs would then be expected to fill in one field or the other, but not both.  Is 
that possible?

To ensure that these JSON files can be programmatically parsed, I suggest 
specifying the requirement a bit more strictly.  Something like this:
  "...or the URL for a file that contains only a JSON Array, whose elements are 
URLs of DER encoded CRLs that when combined are the equivalent of a full and 
complete CRL"

> I propose that this new CCADB field be populated in all situations where the 
> CA is enabled for server certificate issuance.

Most Root Certificates are "enabled for server certificate issuance".  
Obviously CAs shouldn't issue leaf certs directly from roots, but nonetheless 
the technical capability does exist.  However, currently CAs can't edit Root 
Certificate records in the CCADB, which makes populating these new field(s) "in 
all situations" rather hard.

Since OneCRL covers revocations of intermediate certs, may I suggest that CAs 
should only be required to populate these new field(s) in intermediate 
certificate records (and not in root certificate records)?

Relatedly, "A CA technically capable of...that the CCADB field" seems wrong.  
CCADB "CA Owner" records don't/won't contain the new field(s).  Similar 
language elsewhere in the policy (section 5.3.2) says "All certificates that 
are capable of being used to..." (rather than "All CAs...").

Technically-constrained intermediate certs don't have to be disclosed to CCADB, 
but "in all situations where the CA is enabled for server certificate issuance" 
clearly includes technically-constrained intermediates.  How would a CA 
populate the "Full CRL Issued By This CA" field for a technically-constrained 
intermediate cert that has (legitimately) not been disclosed to CCADB?


From: dev-security-policy  on 
behalf of Ben Wilson via dev-security-policy 

Sent: 08 January 2021 01:00
To: mozilla-dev-security-policy 
Subject: Policy 2.7.1: MRSP Issue #218: Clarify CRL requirements for End Entity 
Certificates

CAUTION: This email originated from outside of the organization. Do not click 
links or open attachments unless you recognize the sender and know the content 
is safe.


This is the last issue that I have marked for discussion in relation to
version 2.7.1 of the Mozilla Root Store Policy
<https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.mozilla.org%2Fen-US%2Fabout%2Fgovernance%2Fpolicies%2Fsecurity-group%2Fcerts%2Fpolicy%2Fdata=04%7C01%7Crob%40sectigo.com%7C65685639e2bf45be5f6f08d8b370cf17%7C0e9c48946caa465d96604b6968b49fb7%7C0%7C0%7C637456644391892862%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=shOhNu8IGrT0iSSt2LY4E6LQlsr6y435Vv%2BNezNCh98%3Dreserved=0>.
It is identified and discussed in GitHub Issue #218
<https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fmozilla%2Fpkipolicy%2Fissues%2F218data=04%7C01%7Crob%40sectigo.com%7C65685639e2bf45be5f6f08d8b370cf17%7C0e9c48946caa465d96604b6968b49fb7%7C0%7C0%7C637456644391892862%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=Zb0abofrs3IaJzX9nkEnFf6RbyCemLYIi%2B7l4SmUz5U%3Dreserved=0>
 for the MRSP.

I will soon update everyone on the status of the other 13 discussion items
already presented, as some of them are in need of revision based on
comments received thus far.

While subsection (b) of section 7.1.2.3 of the Baseline Requirements makes
a cRLDistributionPoint (CDP) in end entity certificates optional, Mozilla
still desires that CRL-based revocation information be available because
CRLite uses CRLs to construct its revocation filters.  (Apple also uses
such CRL information in its certificate validation processes and, as I
understand, is making a similar request of CAs with respect to the new
CCADB field, discussed below.)

While all such CRL information is needed, large CRLs are disfavored because
of the time they take to download and process.  Thus, CAs shard, partition,
or "scope" their CRLs into smaller chunks. Section 5 of RFC 5280 explains,
"Each CRL has a particular scope.  The CRL scope is the set of certificates
that could appear on a given CRL. … A complete CRL lists all unexpired
certificates, within its scope, that have been revoked for one of the
revocation

Re: Policy 2.7.1: MRSP Issue #218: Clarify CRL requirements for End Entity Certificates

[Corey Bonnell via dev-security-policy]

Hi Ben,
A few follow-up questions and comments:

1) What are the expectations regarding availability for such CRLs? Do the 
availability requirements in BR 4.10.2 stand for these CRLs even if such CRL 
pointers are not encoded in end-entity certificates?
2) What is the expectation for populating the CRLDP in end-entity S/MIME 
certificates? If no change in policy for S/MIME end-entity certificates is 
desired, then I think the text should be further qualified with "CAs SHOULD 
place the URL for the associated CRL within the crlDistributionPoints extension 
of issued *server* certificates".

Thanks,
Corey

On Thursday, January 7, 2021 at 8:00:46 PM UTC-5, Ben Wilson wrote:
> This is the last issue that I have marked for discussion in relation to 
> version 2.7.1 of the Mozilla Root Store Policy 
> .
>  
> It is identified and discussed in GitHub Issue #218 
>  for the MRSP. 
> 
> I will soon update everyone on the status of the other 13 discussion items 
> already presented, as some of them are in need of revision based on 
> comments received thus far. 
> 
> While subsection (b) of section 7.1.2.3 of the Baseline Requirements makes 
> a cRLDistributionPoint (CDP) in end entity certificates optional, Mozilla 
> still desires that CRL-based revocation information be available because 
> CRLite uses CRLs to construct its revocation filters. (Apple also uses 
> such CRL information in its certificate validation processes and, as I 
> understand, is making a similar request of CAs with respect to the new 
> CCADB field, discussed below.) 
> 
> While all such CRL information is needed, large CRLs are disfavored because 
> of the time they take to download and process. Thus, CAs shard, partition, 
> or "scope" their CRLs into smaller chunks. Section 5 of RFC 5280 explains, 
> "Each CRL has a particular scope. The CRL scope is the set of certificates 
> that could appear on a given CRL. … A complete CRL lists all unexpired 
> certificates, within its scope, that have been revoked for one of the 
> revocation reasons covered by the CRL scope. A *full and complete CRL* 
> lists all unexpired certificates issued by a CA that have been revoked for 
> any reason." (Emphasis added.) 
> 
> There is a new field in the CCADB for CAs to include information needed for 
> browsers or others to construct a "full and complete CRL", i.e. to gather 
> information from CAs that don't include the CRL path to their "full and 
> complete CRL" in end entity certificates they issue. This new CCADB field 
> is called "Full CRL Issued By This CA" and is located under the heading 
> "Pertaining to Certificates Issued by this CA." Rather than condition the 
> requirement that CAs fill in this information in the CCADB only when they 
> don't include a CDP to a full and complete CRL, I propose that this new 
> CCADB field be populated in all situations where the CA is enabled for 
> server certificate issuance. In cases where the CA shards or partitions its 
> CRL, the CA must provide a JSON-based list of CRLs that when combined are 
> the equivalent of the full and complete CRL. 
> 
> Proposed language to add to section 6 of the Mozilla Root Store Policy is 
> as follows: 
> 
> *CAs SHOULD place the URL for the associated CRL within the 
> crlDistributionPoints extension of issued certificates. A CA MAY omit the 
> crlDistributionPoint extension, if permitted by applicable requirements and 
> policies, such as the Baseline Requirements. * 
> 
> *A CA technically capable of issuing server certificates MUST ensure that 
> the CCADB field "Full CRL Issued By This CA" contains either the URL for 
> the full and complete CRL or the URL for the JSON file containing all URLs 
> for CRLs that when combined are the equivalent of the full and complete CRL* 
> . 
> 
> 
> I look forward to your comments and suggestions. 
> 
> Ben
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Policy 2.7.1: MRSP Issue #218: Clarify CRL requirements for End Entity Certificates

[Ryan Hurst via dev-security-policy]

On Thursday, January 7, 2021 at 5:00:46 PM UTC-8, Ben Wilson wrote:
> This is the last issue that I have marked for discussion in relation to 
> version 2.7.1 of the Mozilla Root Store Policy 
> .
>  
> It is identified and discussed in GitHub Issue #218 
>  for the MRSP. 
> 
> I will soon update everyone on the status of the other 13 discussion items 
> already presented, as some of them are in need of revision based on 
> comments received thus far. 
> 
> While subsection (b) of section 7.1.2.3 of the Baseline Requirements makes 
> a cRLDistributionPoint (CDP) in end entity certificates optional, Mozilla 
> still desires that CRL-based revocation information be available because 
> CRLite uses CRLs to construct its revocation filters. (Apple also uses 
> such CRL information in its certificate validation processes and, as I 
> understand, is making a similar request of CAs with respect to the new 
> CCADB field, discussed below.) 
> 
> While all such CRL information is needed, large CRLs are disfavored because 
> of the time they take to download and process. Thus, CAs shard, partition, 
> or "scope" their CRLs into smaller chunks. Section 5 of RFC 5280 explains, 
> "Each CRL has a particular scope. The CRL scope is the set of certificates 
> that could appear on a given CRL. … A complete CRL lists all unexpired 
> certificates, within its scope, that have been revoked for one of the 
> revocation reasons covered by the CRL scope. A *full and complete CRL* 
> lists all unexpired certificates issued by a CA that have been revoked for 
> any reason." (Emphasis added.) 
> 
> There is a new field in the CCADB for CAs to include information needed for 
> browsers or others to construct a "full and complete CRL", i.e. to gather 
> information from CAs that don't include the CRL path to their "full and 
> complete CRL" in end entity certificates they issue. This new CCADB field 
> is called "Full CRL Issued By This CA" and is located under the heading 
> "Pertaining to Certificates Issued by this CA." Rather than condition the 
> requirement that CAs fill in this information in the CCADB only when they 
> don't include a CDP to a full and complete CRL, I propose that this new 
> CCADB field be populated in all situations where the CA is enabled for 
> server certificate issuance. In cases where the CA shards or partitions its 
> CRL, the CA must provide a JSON-based list of CRLs that when combined are 
> the equivalent of the full and complete CRL. 
> 
> Proposed language to add to section 6 of the Mozilla Root Store Policy is 
> as follows: 
> 
> *CAs SHOULD place the URL for the associated CRL within the 
> crlDistributionPoints extension of issued certificates. A CA MAY omit the 
> crlDistributionPoint extension, if permitted by applicable requirements and 
> policies, such as the Baseline Requirements. * 
> 
> *A CA technically capable of issuing server certificates MUST ensure that 
> the CCADB field "Full CRL Issued By This CA" contains either the URL for 
> the full and complete CRL or the URL for the JSON file containing all URLs 
> for CRLs that when combined are the equivalent of the full and complete CRL* 
> . 
> 
> 
> I look forward to your comments and suggestions. 
> 
> Ben
I think this text strikes a good balance.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Policy 2.7.1: MRSP Issue #218: Clarify CRL requirements for End Entity Certificates

[Ben Wilson via dev-security-policy]

This is the last issue that I have marked for discussion in relation to
version 2.7.1 of the Mozilla Root Store Policy
.
It is identified and discussed in GitHub Issue #218
 for the MRSP.

I will soon update everyone on the status of the other 13 discussion items
already presented, as some of them are in need of revision based on
comments received thus far.

While subsection (b) of section 7.1.2.3 of the Baseline Requirements makes
a cRLDistributionPoint (CDP) in end entity certificates optional, Mozilla
still desires that CRL-based revocation information be available because
CRLite uses CRLs to construct its revocation filters.  (Apple also uses
such CRL information in its certificate validation processes and, as I
understand, is making a similar request of CAs with respect to the new
CCADB field, discussed below.)

While all such CRL information is needed, large CRLs are disfavored because
of the time they take to download and process.  Thus, CAs shard, partition,
or "scope" their CRLs into smaller chunks. Section 5 of RFC 5280 explains,
"Each CRL has a particular scope.  The CRL scope is the set of certificates
that could appear on a given CRL. … A complete CRL lists all unexpired
certificates, within its scope, that have been revoked for one of the
revocation reasons covered by the CRL scope.  A *full and complete CRL*
lists all unexpired certificates issued by a CA that have been revoked for
any reason." (Emphasis added.)

There is a new field in the CCADB for CAs to include information needed for
browsers or others to construct a "full and complete CRL", i.e. to gather
information from CAs that don't include the CRL path to their "full and
complete CRL" in end entity certificates they issue. This new CCADB field
is called "Full CRL Issued By This CA" and is located under the heading
"Pertaining to Certificates Issued by this CA." Rather than condition the
requirement that CAs fill in this information in the CCADB only when they
don't include a CDP to a full and complete CRL, I propose that this new
CCADB field be populated in all situations where the CA is enabled for
server certificate issuance. In cases where the CA shards or partitions its
CRL, the CA must provide a JSON-based list of CRLs that when combined are
the equivalent of the full and complete CRL.

Proposed language to add to section 6 of the Mozilla Root Store Policy is
as follows:

*CAs SHOULD place the URL for the associated CRL within the
crlDistributionPoints extension of issued certificates. A CA MAY omit the
crlDistributionPoint extension, if permitted by applicable requirements and
policies, such as the Baseline Requirements. *

*A CA technically capable of issuing server certificates MUST ensure that
the CCADB field "Full CRL Issued By This CA" contains either the URL for
the full and complete CRL or the URL for the JSON file containing all URLs
for CRLs that when combined are the equivalent of the full and complete CRL*
.


I look forward to your comments and suggestions.

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