Question about Baseline Requirements section #7.1.4.2

[Kathleen Wilson]

All,

Does section 7.1.4.2 of the CA/Browser Forum's Baseline Requirements only apply to end-entity certificates?

If yes, where does it specify that in the document?

This has come up in a few CA requests, due to errors we get when we run Kurt's x509lint test.
Example:
https://github.com/kroeckx/x509lint/issues/17
https://bugzilla.mozilla.org/show_bug.cgi?id=1099311#c17

Kathleen

[Peter Bowen]

Kathleen,

I believe that it does not apply to CA certificates, but I can see how
this is not clear.

To help understand the intent of this section, it is helpful to look
at the history of the section. 7.1.4.2 has not been substantially
changed since BR 1.3.0, which was the version that switched from the
old structure to the new RFC 3647 structure. As seen in
https://cabforum.org/wp-content/uploads/RFC3647_Comparison_Table_for_Baseline_Requirements.pdf,
7.1.4.2 was previously section 9.2 and 7.1.4.1 was previously section
9.1.

In 2015, the CA/Browser Forum passed ballot 148
(https://cabforum.org/2015/04/02/ballot-148-issuer-field-correction/)
which changed sections 9.1 and 9.2 and appears to clearly call out
that the intent is to require different content in the subjects for CA
certificates than end-entity certificates.

I agree that the BRs could be clearer, but it seems to me that the
only requirements are country and organization name.

Thanks
Peter

[Dimitris Zacharopoulos]

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

I also agree with Peter. For CA Certificates, there is a more specific
section (7.1.4.3 "Subject Information - Subordinate CA Certificates").
Also, the Name Forms for Root CA and Subordinate CA Certificates are
described in 7.1.2.1.e and 7.1.2.2.h respectively.

The CA/B Forum Policy Review WG made some effort
<https://cabforum.org/pipermail/policyreview/2016-April/000272.html> to
clarify this by merging information between these sections, but there
was not enough support to proceed.


Dimitris.

[Inigo Barreira]

Yes, I´m also agree. This was also taken into account when writting the ETSI
standards, and for the CA certs, the minumun is what Peter has indicated
plus the common name. We indicate that "... shall contain at least the
following attributes ....": countryName, organizationName and commonName
according to ITU-T X.520

[Peter Bowen]

On Tue, Jan 24, 2017 at 12:28 AM, Inigo Barreira <in...@startcomca.com> wrote:
> Yes, I´m also agree. This was also taken into account when writting the ETSI
> standards, and for the CA certs, the minumun is what Peter has indicated
> plus the common name. We indicate that "... shall contain at least the
> following attributes ....": countryName, organizationName and commonName
> according to ITU-T X.520

I think it would be completely reasonable for Mozilla to require a
commonName in an update to the policy. I thought it was there, but a
CA pushed back on a cablint error about not having one a while ago and
I wasn't able to find any proof it was required by any existing
program policy.

[Gervase Markham]

On 24/01/17 15:48, Peter Bowen wrote:
> I think it would be completely reasonable for Mozilla to require a
> commonName in an update to the policy. I thought it was there, but a
> CA pushed back on a cablint error about not having one a while ago and
> I wasn't able to find any proof it was required by any existing
> program policy.

So, require commonName for all non-EE certificates?

Gerv

[Peter Bowen]

On Tue, Jan 24, 2017 at 8:05 AM, Gervase Markham <ge...@mozilla.org> wrote:
> On 24/01/17 15:48, Peter Bowen wrote:

>> I think it would be completely reasonable for Mozilla to require a
>> commonName in an update to the policy. I thought it was there, but a
>> CA pushed back on a cablint error about not having one a while ago and
>> I wasn't able to find any proof it was required by any existing
>> program policy.
>

> So, require commonName for all non-EE certificates?

Yes. All certificates with basicConstraints:cA having a true value
must have a commonName type attribute in the subject (and only one
attribute of the type commonName, to preempt end another discussion).

[Kathleen Wilson]

Thanks, everyone, for your quick response.

I have updated the following to indicate that section 7.1.4.2 of the BRs only applies to end-entity certs.

https://bugzilla.mozilla.org/show_bug.cgi?id=1099311#c19
https://github.com/kroeckx/x509lint/issues/18
https://wiki.mozilla.org/CA:TestErrors#CA.2FBrowser_Forum_Baseline_Requirements_Errors

Gerv, I'm assuming that you will handle the policy (or BR?) update regarding the requirement for subject commonName to be present when basicConstraints:cA is true.
I filed a request to add this check to the x509lint tool:
https://github.com/kroeckx/x509lint/issues/19

Thanks,
Kathleen

[Kurt Roeckx]

On Mon, Jan 23, 2017 at 04:01:58PM -0800, Peter Bowen wrote:
> On Mon, Jan 23, 2017 at 3:32 PM, Kathleen Wilson <kwi...@mozilla.com> wrote:
> > Does section 7.1.4.2 of the CA/Browser Forum's Baseline Requirements only apply to end-entity certificates?
> >
> > If yes, where does it specify that in the document?
> >
> > This has come up in a few CA requests, due to errors we get when we run Kurt's x509lint test.
> > Example:
> > https://github.com/kroeckx/x509lint/issues/17
> > https://bugzilla.mozilla.org/show_bug.cgi?id=1099311#c17
>
> Kathleen,
>
> I believe that it does not apply to CA certificates, but I can see how
> this is not clear.
>
> To help understand the intent of this section, it is helpful to look
> at the history of the section. 7.1.4.2 has not been substantially
> changed since BR 1.3.0, which was the version that switched from the
> old structure to the new RFC 3647 structure. As seen in
> https://cabforum.org/wp-content/uploads/RFC3647_Comparison_Table_for_Baseline_Requirements.pdf,
> 7.1.4.2 was previously section 9.2 and 7.1.4.1 was previously section
> 9.1.
>
> In 2015, the CA/Browser Forum passed ballot 148
> (https://cabforum.org/2015/04/02/ballot-148-issuer-field-correction/)
> which changed sections 9.1 and 9.2 and appears to clearly call out
> that the intent is to require different content in the subjects for CA
> certificates than end-entity certificates.

It seems that for all of 1.2.4, 1.2.5 and 1.4.2 it's really the
same text, just in different section numbers.

But looking at this again, the current 7.1.4.3 is about
Subordinate CA certificates, so it could make sense that 7.1.4.2
(that starts with etact the same text) is not about all
certificates.

But I see no good reason why some of the rules applied to EE
certificates shouldn't be applied to CA certificates.


Kurt

[Jakob Bohm]

Well there are obvious examples, such as CA certificates being allowed
to have CA:TRUE, and less obvious examples, such as CA certificates
sometimes having much longer validity periods, even if this is only
used for things like revocation and timestamp validity after the
associated EE certificates expire.

Those obvious examples make it important to explicitly consider and
decide which of the EE requirements happen to be the same for CA
certs, and not just blindly copy rules.


Enjoy

Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark. Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded

[Gervase Markham]

On 24/01/17 06:50, Dimitris Zacharopoulos wrote:
> The CA/B Forum Policy Review WG made some effort
> <https://cabforum.org/pipermail/policyreview/2016-April/000272.html> to
> clarify this by merging information between these sections, but there
> was not enough support to proceed.

Dean's summary of the voting for ballot 167 contained the line: "It is
my understanding that the ballot proponents are preparing a revised
ballot that addresses some comments received during the voting period."

Is that still true?

Gerv

[Dimitris Zacharopoulos]

On 25/1/2017 1:25 μμ, Gervase Markham wrote:
> On 24/01/17 06:50, Dimitris Zacharopoulos wrote:

>> The CA/B Forum Policy Review WG made some effort
>> <https://cabforum.org/pipermail/policyreview/2016-April/000272.html> to
>> clarify this by merging information between these sections, but there
>> was not enough support to proceed.

> Dean's summary of the voting for ballot 167 contained the line: "It is
> my understanding that the ballot proponents are preparing a revised
> ballot that addresses some comments received during the voting period."
>
> Is that still true?
>
> Gerv
>

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

There wasn't enough support to proceed with these changes within the WG
to even form a ballot, so we dropped them and decided to proceed with
only minor changes. I think Ryan raised a concern that he would like the
"Name Forms" section, to remain separate. I would still prefer to keep
everything simple and aligned together with the CA Certificates, because
IMHO it is easier to configure (CA's side) and audit (Auditor's side)
the certificate profiles by looking one section of the BRs instead of many.

Dimitris.

[Dimitris Zacharopoulos]

On 25/1/2017 1:40 μμ, Dimitris Zacharopoulos wrote:
> On 25/1/2017 1:25 μμ, Gervase Markham wrote:
>> On 24/01/17 06:50, Dimitris Zacharopoulos wrote:

>>> The CA/B Forum Policy Review WG made some effort
>>> <https://cabforum.org/pipermail/policyreview/2016-April/000272.html> to
>>> clarify this by merging information between these sections, but there
>>> was not enough support to proceed.

>> Dean's summary of the voting for ballot 167 contained the line: "It is
>> my understanding that the ballot proponents are preparing a revised
>> ballot that addresses some comments received during the voting period."
>>
>> Is that still true?
>>
>> Gerv
>>

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

> There wasn't enough support to proceed with these changes within the
> WG to even form a ballot, so we dropped them and decided to proceed
> with only minor changes. I think Ryan raised a concern that he would
> like the "Name Forms" section, to remain separate. I would still
> prefer to keep everything simple and aligned together with the CA
> Certificates, because IMHO it is easier to configure (CA's side) and
> audit (Auditor's side) the certificate profiles by looking one section
> of the BRs instead of many.
>
> Dimitris.

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

167 "Baseline Requirements Corrections" did not pass due to lack quorum
and was resubmitted as ballot 168 "Baseline Requirements Corrections
(Revised)" which passed unanimously.

Dimitris.

[Dimitris Zacharopoulos]

On 25/1/2017 1:40 μμ, Dimitris Zacharopoulos wrote:
> On 25/1/2017 1:25 μμ, Gervase Markham wrote:
>> On 24/01/17 06:50, Dimitris Zacharopoulos wrote:

>>> The CA/B Forum Policy Review WG made some effort
>>> <https://cabforum.org/pipermail/policyreview/2016-April/000272.html> to
>>> clarify this by merging information between these sections, but there
>>> was not enough support to proceed.

>> Dean's summary of the voting for ballot 167 contained the line: "It is
>> my understanding that the ballot proponents are preparing a revised
>> ballot that addresses some comments received during the voting period."
>>
>> Is that still true?
>>
>> Gerv
>>

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

> There wasn't enough support to proceed with these changes within the
> WG to even form a ballot, so we dropped them and decided to proceed
> with only minor changes. I think Ryan raised a concern that he would
> like the "Name Forms" section, to remain separate. I would still
> prefer to keep everything simple and aligned together with the CA
> Certificates, because IMHO it is easier to configure (CA's side) and
> audit (Auditor's side) the certificate profiles by looking one section
> of the BRs instead of many.
>
> Dimitris.

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

[Gervase Markham]

On 24/01/17 19:09, Kathleen Wilson wrote:
> Gerv, I'm assuming that you will handle the policy (or BR?) update
> regarding the requirement for subject commonName to be present when
> basicConstraints:cA is true.

I think this would be best as an update to the BRs. However, we are
expecting a flood of motions after the ballot process reform passes, and
as this one is not that important, I will wait a little while before
introducing it.

Gerv

[Gervase Markham]

On 24/01/17 00:01, Peter Bowen wrote:
> I agree that the BRs could be clearer, but it seems to me that the
> only requirements are country and organization name.

Hi Peter,

Can you point me at which section requires those two fields?

Thanks,

Gerv

[Peter Bowen]

On Wed, Feb 8, 2017 at 4:28 AM, Gervase Markham <ge...@mozilla.org> wrote:
> On 24/01/17 00:01, Peter Bowen wrote:

>> I agree that the BRs could be clearer, but it seems to me that the
>> only requirements are country and organization name.
>

> Hi Peter,
>
> Can you point me at which section requires those two fields?

7.1.2.2 (h)