Yet more undisclosed intermediates

[Rob Stradling]

"ACTION 6" of Mozilla's September 2018 CA Communication [1] reminded CAs
of the Mozilla Root Store Policy requirement [2] that
non-technically-constrained intermediate CA certificates...
"MUST be publicly disclosed in the CCADB by the CA that has their
certificate included in Mozilla's root program. The CA with a
certificate included in Mozilla's root program MUST disclose this
information within a week of certificate creation, and before any
such subordinate CA is allowed to issue certificates."

In their responses to "ACTION 6" [3], most CAs indicated that...
"We are aware of the requirements for intermediate certificate
disclosure and have processes in place to ensure that these
requirements are met"

There are currently 20 undisclosed non-technically-constrained
intermediates, belonging to 6 Root Owners, on "Rob's naughty list" [4]
(snapshot at [5]). All 20 were undisclosed and listed (on [4]) on the
day the responses to [1] were due (September 30th), which means that
they have not been disclosed "within a week of certificate creation".

So, ISTM that the "processes in place to ensure that these requirements
are met" are insufficient/broken for at least the following Root Owners:
- Certicámara
- DigiCert
- DocuSign (OpenTrust/Keynectis)
- SECOM Trust Systems CO., LTD.
- SwissSign AG
- Telia Company (formerly TeliaSonera)

Wayne, Kathleen:
Given the number of times that all the CAs in Mozilla's Root Program
have been reminded about Mozilla's requirements for disclosing
intermediate certs, I wouldn't blame you if you decided to add these 20
intermediate certs [5] to OneCRL immediately!


[1]
https://ccadb-public.secure.force.com/mozillacommunications/CACommunicationSurveySample?CACommunicationId=a051J00003rMGLL

[2]
https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/#532-publicly-disclosed-and-audited

[3]
https://ccadb-public.secure.force.com/mozillacommunications/CACommResponsesOnlyReport?CommunicationId=a051J00003rMGLL&QuestionId=Q00078,Q00079

[4] https://crt.sh/mozilla-disclosures#undisclosed

[5] https://crt.sh/reports/20181009_MozillaDisclosures.html#undisclosed

--
Rob Stradling
Senior Research & Development Scientist
Email: R...@ComodoCA.com

[Jakob Bohm]

[ Please reply to list, Mozilla NNTP<->mail gateway seems to insert
wrong Reply-To ]

It appears from the data that SwissSign has reacted to the requirement
by starting to log some of their existing intermediaries in CT, instead
of in CCADB. At least at a cursory glance.

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

[Jakob Bohm]

[ Please reply to list, Mozilla NNTP<->mail gateway seems to insert
wrong Reply-To ]

Telia is a notable case as this seems to be a brand new Intermediary
created but not disclosed 1 month ago.

On 09/10/2018 12:43, Rob Stradling wrote:

[Wayne Thayer]

Thank you Rob.

On Tue, Oct 9, 2018 at 3:43 AM Rob Stradling via dev-security-policy <
dev-secur...@lists.mozilla.org> wrote:

> "ACTION 6" of Mozilla's September 2018 CA Communication [1] reminded CAs
> of the Mozilla Root Store Policy requirement [2] that
> non-technically-constrained intermediate CA certificates...
> "MUST be publicly disclosed in the CCADB by the CA that has their
> certificate included in Mozilla's root program. The CA with a
> certificate included in Mozilla's root program MUST disclose this
> information within a week of certificate creation, and before any
> such subordinate CA is allowed to issue certificates."
>
> In their responses to "ACTION 6" [3], most CAs indicated that...
> "We are aware of the requirements for intermediate certificate
> disclosure and have processes in place to ensure that these
> requirements are met"
>

> In fact, every CA except Trustis (no longer issuing certificates) and
Certicamara (still hasn't responded) indicated that they comply with this
policy.

There are currently 20 undisclosed non-technically-constrained
> intermediates, belonging to 6 Root Owners, on "Rob's naughty list" [4]
> (snapshot at [5]). All 20 were undisclosed and listed (on [4]) on the
> day the responses to [1] were due (September 30th), which means that
> they have not been disclosed "within a week of certificate creation".
>
> So, ISTM that the "processes in place to ensure that these requirements
> are met" are insufficient/broken for at least the following Root Owners:
> - Certicámara
>

These are the same four that I reported to Certicamara back in April via
https://bugzilla.mozilla.org/show_bug.cgi?id=1455128 I emailed them
yesterday about this and their failure to respond to the September CA
Communication.

- DigiCert
>

Looks like DigiCert disclosed these within a few hours of your email.

- DocuSign (OpenTrust/Keynectis)
>

I filed https://bugzilla.mozilla.org/show_bug.cgi?id=1497700

- SECOM Trust Systems CO., LTD.
> - SwissSign AG
>

This is incredibly disappointing given
https://bugzilla.mozilla.org/show_bug.cgi?id=1455132 (among other recent
SwissSign issues)

- Telia Company (formerly TeliaSonera)
>

> I reopened https://bugzilla.mozilla.org/show_bug.cgi?id=1451953 This is
also disappointing given Telia's other recent issues.

Wayne, Kathleen:
> Given the number of times that all the CAs in Mozilla's Root Program
> have been reminded about Mozilla's requirements for disclosing
> intermediate certs, I wouldn't blame you if you decided to add these 20
> intermediate certs [5] to OneCRL immediately!
>
>

I think we should give this serious consideration, although it doesn't help
with the majority of these that are trusted for email.

>
> [1]
>
> https://ccadb-public.secure.force.com/mozillacommunications/CACommunicationSurveySample?CACommunicationId=a051J00003rMGLL
>
> [2]
>
> https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/#532-publicly-disclosed-and-audited
>
> [3]
>
> https://ccadb-public.secure.force.com/mozillacommunications/CACommResponsesOnlyReport?CommunicationId=a051J00003rMGLL&QuestionId=Q00078,Q00079
>
> [4] https://crt.sh/mozilla-disclosures#undisclosed
>
> [5] https://crt.sh/reports/20181009_MozillaDisclosures.html#undisclosed
>

[Rob Stradling]

On 09/10/2018 23:53, Wayne Thayer wrote:
<snip>

>    - DigiCert
>
> Looks like DigiCert disclosed these within a few hours of your email.

Yes, but I hope that DigiCert will provide an incident report so that we
can understand why DigiCert's "processes in place to ensure that these
requirements are met" failed in this case.

[Rob Stradling]

On 09/10/2018 23:53, Wayne Thayer wrote:

> On Tue, Oct 9, 2018 at 3:43 AM Rob Stradling wrote:<snip>

> Wayne, Kathleen:
> Given the number of times that all the CAs in Mozilla's Root Program
> have been reminded about Mozilla's requirements for disclosing
> intermediate certs, I wouldn't blame you if you decided to add these 20
> intermediate certs [5] to OneCRL immediately!
>
> I think we should give this serious consideration, although it doesn't
> help with the majority of these that are trusted for email.

Hi Wayne. Did you give this serious consideration?

An Izenpe intermediate cert [1] has been known to crt.sh (see [2]) for
well over a month, but hasn't yet been disclosed to the CCADB.


[1] https://crt.sh/?id=966433897

[2] https://crt.sh/mozilla-disclosures

--
Rob Stradling
Senior Research & Development Scientist

Sectigo Limited

[in...@izenpe.com]

We're reviewing what happened with this subCA, because it's reported to the CCADB (like all other subCAs). At the moment we've seen that there are two different entries in the crt.sh with the same serial number, but different fingerprints:

https://crt.sh/?id=1477430 -> disclosed
https://crt.sh/?id=966433897 -> not disclosed

This CA is not new, so there wouldn’t be any problem. But we continue analyzing what happened.

Thanks for the information.
Regards

[Rob Stradling]

On 02/01/2019 13:44, info--- via dev-security-policy wrote:
> El miércoles, 2 de enero de 2019, 12:49:52 (UTC+1), Rob Stradling escribió:

> We're reviewing what happened with this subCA, because it's reported to the CCADB (like all other subCAs). At the moment we've seen that there are two different entries in the crt.sh with the same serial number, but different fingerprints:
>
> https://crt.sh/?id=1477430 -> disclosed
> https://crt.sh/?id=966433897 -> not disclosed
>
> This CA is not new, so there wouldn’t be any problem. But we continue analyzing what happened.

Thanks Oscar. You're right: 966433897 is a duplicate of 1477430, and so
this is *not* a violation of Mozilla's intermediate cert disclosure
requirement.

The only difference between the two certs is the encoding of the
signature parameters in the part of the certificate that is not covered
by the CA's signature. Anyone could create any number of "different"
certs with malformed signature parameters that share the same
CA-produced signature, and for this we can't blame the CA. As it
happens though, 966433897 is slightly less malformed than 1477430.

It's unfortunate that some CT logs accept, or used to accept, certs with
malformed signature parameters (in the part of the cert not covered by
the CA's signature).

Izenpe did make one related mistake when issuing this cert back in
(presumably) 2010 though: the signature parameters in the TBSCertificate
are omitted, whereas they should be an ASN.1 NULL (and so
https://crt.sh/?id=1477430&opt=cablint reports the error "RSA signatures
must have a parameter specified").

[Wayne Thayer]

On Wed, Jan 2, 2019 at 7:10 AM Rob Stradling via dev-security-policy <
dev-secur...@lists.mozilla.org> wrote:

> On 02/01/2019 13:44, info--- via dev-security-policy wrote:
> > El miércoles, 2 de enero de 2019, 12:49:52 (UTC+1), Rob Stradling
> escribió:

> >> On 09/10/2018 23:53, Wayne Thayer wrote:
> >>> On Tue, Oct 9, 2018 at 3:43 AM Rob Stradling wrote:<snip>
> >>> Wayne, Kathleen:
> >>> Given the number of times that all the CAs in Mozilla's Root
> Program
> >>> have been reminded about Mozilla's requirements for disclosing
> >>> intermediate certs, I wouldn't blame you if you decided to add
> these 20
> >>> intermediate certs [5] to OneCRL immediately!
> >>>
> >>> I think we should give this serious consideration, although it doesn't
> >>> help with the majority of these that are trusted for email.
> >>
> >> Hi Wayne. Did you give this serious consideration?
> >>
>

The options to consider are:
1. Continue with current policy of treating non-disclosure of unconstrained
intermediates as an incident. This could eventually lead to having the
offending intermediate added to OneCRL, but in practice it never has
because disclosure is not difficult.
2. Change our policy to state that any undisclosed intermediate we discover
will be immediately and permanently added to OneCRL.
3. Wait for the "intermediate preloading" feature to ship in Firefox. As
currently defined, this is not an enforcement mechanism for disclosure, but
it could be.
4. Assume that CT enforcement will (eventually, on some undefined timeline
for Firefox) force intermediate disclosures and eliminate the need for
Mozilla to require CAs to manually disclose serverAuth intermediates in
CCADB.

I don't expect options 3 and 4 to be viable for S/MIME certificates anytime
soon, so different options might be chosen for TLS and S/MIME.

I'm interested to hear if anyone has opinions on these options.

Thanks,

Wayne

[Ryan Sleevi]

On Wed, Jan 2, 2019 at 11:18 AM Wayne Thayer via dev-security-policy <
dev-secur...@lists.mozilla.org> wrote:

> The options to consider are:
> 1. Continue with current policy of treating non-disclosure of unconstrained
> intermediates as an incident. This could eventually lead to having the
> offending intermediate added to OneCRL, but in practice it never has
> because disclosure is not difficult.
> 2. Change our policy to state that any undisclosed intermediate we discover
> will be immediately and permanently added to OneCRL.
> 3. Wait for the "intermediate preloading" feature to ship in Firefox. As
> currently defined, this is not an enforcement mechanism for disclosure, but
> it could be.
> 4. Assume that CT enforcement will (eventually, on some undefined timeline
> for Firefox) force intermediate disclosures and eliminate the need for
> Mozilla to require CAs to manually disclose serverAuth intermediates in
> CCADB.
>

Given the timescales of intermediates (5-10 years) vs other certificates,
it's unclear how #4 would be done. I suspect that, between #3 and #4, that
#3 is probably functionally far more attractive, and operationally cleaner
for CAs (given the offline nature of intermediate signing ceremonies due to
the root key material).

I think of the first two, #2 is more appealing than #1, as it avoids the
needs to distinguish malice from operational failure, and thus provides
something clear and automatable (from the client side), thus removing the
necessity of discussion. #3 simply moves this from a "permanent" state to a
"temporary" state, which doesn't seem like it changes much for Subscribers,
but is friendlier to CAs that have operational failures.

So it sounds like a combination of #3+#1 (treating it as an incident, but
allowing for temporary blocking) may be a balanced approach if leniency for
operational mistakes are desired, otherwise, #2 seems the easiest to set
expectations and not have to litigate/renegotiate/investigate every time it
happens. #4 is just a different technical means to approaching some
variation of #3/#2, but with different tradeoffs, and less predictability
(embedded proofs vs TLS-delivered / OCSP stapled proofs)

Thus, a preference is:
#2
(combination of #3 + #1)
#4

[Jakob Bohm]

On 02/01/2019 17:17, Wayne Thayer wrote:
> On Wed, Jan 2, 2019 at 7:10 AM Rob Stradling via dev-security-policy <
> dev-secur...@lists.mozilla.org> wrote:
>
>> On 02/01/2019 13:44, info--- via dev-security-policy wrote:
>>> El miércoles, 2 de enero de 2019, 12:49:52 (UTC+1), Rob Stradling
>> escribió:
>>>> On 09/10/2018 23:53, Wayne Thayer wrote:
>>>>> On Tue, Oct 9, 2018 at 3:43 AM Rob Stradling wrote:<snip>
>>>>> Wayne, Kathleen:
>>>>> Given the number of times that all the CAs in Mozilla's Root
>> Program
>>>>> have been reminded about Mozilla's requirements for disclosing
>>>>> intermediate certs, I wouldn't blame you if you decided to add
>> these 20
>>>>> intermediate certs [5] to OneCRL immediately!
>>>>>
>>>>> I think we should give this serious consideration, although it doesn't
>>>>> help with the majority of these that are trusted for email.
>>>>
>>>> Hi Wayne. Did you give this serious consideration?
>>>>
>>
> The options to consider are:
> 1. Continue with current policy of treating non-disclosure of unconstrained
> intermediates as an incident. This could eventually lead to having the
> offending intermediate added to OneCRL, but in practice it never has
> because disclosure is not difficult.

No comment

> 2. Change our policy to state that any undisclosed intermediate we discover
> will be immediately and permanently added to OneCRL.

This needs adding some logical criteria, notably:

- Allow the SubCA certificate itself and any related technical
signatures (CRL, OCSP signer, test site signatures etc.) and deeper
SubSubCAs to be generated and added to CT as part of the signing
ceremony before submission. This of cause within the reporting
deadline already specified in Mozilla policy for new SubCAs.

- Send a stern warning e-mail to the CA contact when 2/3 of the time
between SubCA generation and deadline expiry has passed.

- Include a manual review to check for misidentification of SubCA
submission policy violations (such as the Izenpe case earlier today).

- An exception if there was a relevant CCADB issue (downtime,
configuration, account problems etc.) during the CCADB submission
deadline.

- In OneCRL, add a separate OneCRL reason marker for SubCAs revoked in
for this reason only. This to allow extremely space or bandwidth
constrained OneCRL consumers to omit those, as well as to provide
truthful error messages in full clients such as Firefox.

> 3. Wait for the "intermediate preloading" feature to ship in Firefox. As
> currently defined, this is not an enforcement mechanism for disclosure, but
> it could be.

Note however that there is always the issue that "intermediate
preloading" will typically only update along the browser/mailclient
/other software release schedule while SubCAs can be validly created and
disclosed at any time (in practice: On the CAs root ceremony schedule).

> 4. Assume that CT enforcement will (eventually, on some undefined timeline
> for Firefox) force intermediate disclosures and eliminate the need for
> Mozilla to require CAs to manually disclose serverAuth intermediates in
> CCADB.
>

CT disclosed SubCAs not in CCADB are the typical case of currently
detected violations. Thus CT enforcement would not fix this unless CT
enforcement causes the CCADB disclosure rule to be removed/relaxed as
redundant.

> I don't expect options 3 and 4 to be viable for S/MIME certificates anytime
> soon, so different options might be chosen for TLS and S/MIME.
>
> I'm interested to hear if anyone has opinions on these options.
>

[Ryan Sleevi]

On Wed, Jan 2, 2019 at 1:32 PM Jakob Bohm via dev-security-policy <
dev-secur...@lists.mozilla.org> wrote:

> > 2. Change our policy to state that any undisclosed intermediate we
> discover
> > will be immediately and permanently added to OneCRL.
>

> This needs adding some logical criteria, notably:
>

It's not clear what you feel drives these requirements. A few selected
comments below.

> - Send a stern warning e-mail to the CA contact when 2/3 of the time
> between SubCA generation and deadline expiry has passed.
>

Could you explain why you see this being required?

> - In OneCRL, add a separate OneCRL reason marker for SubCAs revoked in
> for this reason only. This to allow extremely space or bandwidth
> constrained OneCRL consumers to omit those, as well as to provide
> truthful error messages in full clients such as Firefox.
>

This one is more interesting. There is only one OneCRL consumer, and the
question of product UI or behaviour is not really part of this Forum (note:
policy). It seems like this is working backward from a requirement - you
think there should be a different error message - and then trying to imply
how to meet that, without really clearly stating that.

Could you instead elaborate on what you see the desired end-states are,
rather than enumerating the proposed intermediate steps?

[Wayne Thayer]

On Wed, Jan 2, 2019 at 11:32 AM Jakob Bohm via dev-security-policy <
dev-secur...@lists.mozilla.org> wrote:

> On 02/01/2019 17:17, Wayne Thayer wrote:

> > The options to consider are:
> > 1. Continue with current policy of treating non-disclosure of
> unconstrained
> > intermediates as an incident. This could eventually lead to having the
> > offending intermediate added to OneCRL, but in practice it never has
> > because disclosure is not difficult.
>

> No comment

>
> > 2. Change our policy to state that any undisclosed intermediate we
> discover
> > will be immediately and permanently added to OneCRL.
>

> This needs adding some logical criteria, notably:
>

> - Allow the SubCA certificate itself and any related technical
> signatures (CRL, OCSP signer, test site signatures etc.) and deeper
> SubSubCAs to be generated and added to CT as part of the signing
> ceremony before submission. This of cause within the reporting
> deadline already specified in Mozilla policy for new SubCAs.
>

> - Send a stern warning e-mail to the CA contact when 2/3 of the time
> between SubCA generation and deadline expiry has passed.
>

> How do we know about the SubCA if it hasn't been disclosed? By the time
the SubCA appears in CT, the 1-week disclosure deadline has very likely

passed.

- Include a manual review to check for misidentification of SubCA
> submission policy violations (such as the Izenpe case earlier today).
>
> - An exception if there was a relevant CCADB issue (downtime,
> configuration, account problems etc.) during the CCADB submission
> deadline.
>

> - In OneCRL, add a separate OneCRL reason marker for SubCAs revoked in
> for this reason only. This to allow extremely space or bandwidth
> constrained OneCRL consumers to omit those, as well as to provide
> truthful error messages in full clients such as Firefox.
>

> > 3. Wait for the "intermediate preloading" feature to ship in Firefox. As
> > currently defined, this is not an enforcement mechanism for disclosure,
> but
> > it could be.
>

> Note however that there is always the issue that "intermediate
> preloading" will typically only update along the browser/mailclient
> /other software release schedule while SubCAs can be validly created and
> disclosed at any time (in practice: On the CAs root ceremony schedule).
>

> Intermediate preloading will use the same distribution mechanism as
OneCRL. Yes, there will be some delay before a new intermediate is known by
most/all clients, but the timescale is hours, not weeks.

> 4. Assume that CT enforcement will (eventually, on some undefined timeline
> > for Firefox) force intermediate disclosures and eliminate the need for
> > Mozilla to require CAs to manually disclose serverAuth intermediates in
> > CCADB.
> >
>

> CT disclosed SubCAs not in CCADB are the typical case of currently
> detected violations. Thus CT enforcement would not fix this unless CT
> enforcement causes the CCADB disclosure rule to be removed/relaxed as
> redundant.
>
>

Yes, the idea is that CT could remove the need to enforce intermediate
disclosures via policy.

> I don't expect options 3 and 4 to be viable for S/MIME certificates
> anytime
> > soon, so different options might be chosen for TLS and S/MIME.
> >
> > I'm interested to hear if anyone has opinions on these options.
> >
>
>

> 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

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

[Jakob Bohm]

There is the date fields in the SubCA certificate itself, as well as any
embedded CT data (assuming the parent CA is correctly CT-logged).

This e-mail is simply to reduce the frequency of "Oops, we did
everything else, except log into CCADB and manually add the cert".

And by sending it before the established policy deadline, the policy isn't
weakened.

> - Include a manual review to check for misidentification of SubCA
>> submission policy violations (such as the Izenpe case earlier today).
>>
>> - An exception if there was a relevant CCADB issue (downtime,
>> configuration, account problems etc.) during the CCADB submission
>> deadline.
>>
>> - In OneCRL, add a separate OneCRL reason marker for SubCAs revoked in
>> for this reason only. This to allow extremely space or bandwidth
>> constrained OneCRL consumers to omit those, as well as to provide
>> truthful error messages in full clients such as Firefox.
>>

Because someone else asked:

Since others are consuming the Mozilla root list, some of those may want
to also consume OneCRL. If they distribute OneCRL over an extremely low
bandwidth protocol to low-memory devices (IoT etc.) they may wish to filter
out these "blocked for policy reasons only" entries in a proxy of their own
design, using scarce resources only for more severe revocations.

The clearer error message would be a secondary use of the data (to be
discussed in the UI design forums).

Here I am simply suggesting making this data about the decisions of the
Mozilla root program available in computer readable form, while giving
two examples of why this data might be useful outside this forum.

>>> 3. Wait for the "intermediate preloading" feature to ship in Firefox. As
>>> currently defined, this is not an enforcement mechanism for disclosure,
>> but
>>> it could be.
>>
>> Note however that there is always the issue that "intermediate
>> preloading" will typically only update along the browser/mailclient
>> /other software release schedule while SubCAs can be validly created and
>> disclosed at any time (in practice: On the CAs root ceremony schedule).
>>
>> Intermediate preloading will use the same distribution mechanism as
> OneCRL. Yes, there will be some delay before a new intermediate is known by
> most/all clients, but the timescale is hours, not weeks.
>

Ah, I wasn't aware, I thought is would be in the NSS root data blob, like a
few SubCAs historically included in other root stores.

>> 4. Assume that CT enforcement will (eventually, on some undefined timeline
>>> for Firefox) force intermediate disclosures and eliminate the need for
>>> Mozilla to require CAs to manually disclose serverAuth intermediates in
>>> CCADB.
>>>
>>
>> CT disclosed SubCAs not in CCADB are the typical case of currently
>> detected violations. Thus CT enforcement would not fix this unless CT
>> enforcement causes the CCADB disclosure rule to be removed/relaxed as
>> redundant.
>>
>>
> Yes, the idea is that CT could remove the need to enforce intermediate
> disclosures via policy.
>

There should still be a policy requirement to disclose unconstrained 3rd
party SubCAs, along with the relevant policy data.

[Kurt Roeckx]

On 2019-01-03 16:25, Jakob Bohm wrote:
> There is the date fields in the SubCA certificate itself, as well as any
> embedded CT data (assuming the parent CA is correctly CT-logged).

Do you expect precertificates for CA certificates?

I currently don't know if there are any requirements for logging CA
certificates in CT. I assume it was only for subscriber certificates,
but I didn't check what Google's current policy is. So it's possible
that a CA certificate is only be logged the first time a subscriber
certificate is generated.


Kurt

[Jakob Bohm]

Again, this is e-mail reminder is only useful in cases where the CA
gave a good opportunity for early enough detection. CT logging with or
without CT-logged precertificates is something that a CA might automate
as part of their scripted root key usage ceremony, unlike uploading a
copy of the certificate to a SalesForce hosted web site (I would
consider it prudent to keep public Internet web browsers outside the
secure cage where the root key is accessed).

Even if the SubCA itself is not CT logged, some of the related
technical certificates might be.

[Rob Stradling]

On 02/01/2019 22:40, Wayne Thayer via dev-security-policy wrote:
<snip>

> Yes, the idea is that CT could remove the need to enforce intermediate
> disclosures via policy.

Hi Wayne. That seems at odds with (my understanding of) the purpose of
the disclosure requirement.

The relevant phrase in the Mozilla Root Store Policy is "publicly
disclosed and audited". The CCADB captures audit information, whereas
CT logs do not.

How would Mozilla check that a CT-logged intermediate is covered by an
appropriate audit, if the CA is no longer required to disclose that
information to the CCADB?

[Rob Stradling]

On 02/01/2019 14:10, Rob Stradling via dev-security-policy wrote:
> On 02/01/2019 13:44, info--- via dev-security-policy wrote:

<snip>

>> We're reviewing what happened with this subCA, because it's reported to the CCADB (like all other subCAs). At the moment we've seen that there are two different entries in the crt.sh with the same serial number, but different fingerprints:
>>
>> https://crt.sh/?id=1477430 -> disclosed
>> https://crt.sh/?id=966433897 -> not disclosed
>>
>> This CA is not new, so there wouldn’t be any problem. But we continue analyzing what happened.
>
> Thanks Oscar. You're right: 966433897 is a duplicate of 1477430, and so
> this is *not* a violation of Mozilla's intermediate cert disclosure
> requirement.
>
> The only difference between the two certs is the encoding of the
> signature parameters in the part of the certificate that is not covered
> by the CA's signature. Anyone could create any number of "different"
> certs with malformed signature parameters that share the same
> CA-produced signature, and for this we can't blame the CA. As it
> happens though, 966433897 is slightly less malformed than 1477430.
>
> It's unfortunate that some CT logs accept, or used to accept, certs with
> malformed signature parameters (in the part of the cert not covered by
> the CA's signature).
>
> Izenpe did make one related mistake when issuing this cert back in
> (presumably) 2010 though: the signature parameters in the TBSCertificate
> are omitted, whereas they should be an ASN.1 NULL (and so
> https://crt.sh/?id=1477430&opt=cablint reports the error "RSA signatures
> must have a parameter specified").

To deal with this false positive, I've just deleted crt.sh ID 966433897
and reassigned its log entry records to 1477430.

[Wayne Thayer]

On Mon, Jan 7, 2019 at 6:05 AM Rob Stradling <r...@sectigo.com> wrote:

> On 02/01/2019 22:40, Wayne Thayer via dev-security-policy wrote:
> <snip>
> > Yes, the idea is that CT could remove the need to enforce intermediate
> > disclosures via policy.
>
> Hi Wayne. That seems at odds with (my understanding of) the purpose of
> the disclosure requirement.
>
> The relevant phrase in the Mozilla Root Store Policy is "publicly
> disclosed and audited". The CCADB captures audit information, whereas
> CT logs do not.
>
> How would Mozilla check that a CT-logged intermediate is covered by an
> appropriate audit, if the CA is no longer required to disclose that
> information to the CCADB?
>

> That is a valid point, and combined with Ryan and Kurt's comments about
option #4, seems to eliminate CT as a replacement for the intermediate
disclosure requirement.

I believe that our aim should be to force disclosure before an intermediate
can be used successfully in Firefox, not to render an intermediate that is
discovered prior to disclosure unusable.Option #2 (immediately and
permanently add undisclosed intermediates to OneCRL) also relies on
discovery of the undisclosed intermediate and some mechanism for
automatically loading it into OneCRL, and that makes it fragile -
especially when Jacob's proposed modifications are added in to the mix.

I think Ryan's second choice of option 1 (treat non-disclosure as an
incident) plus option 3 (enforce disclosure in Firefox via intermediate
preloading) is the best approach to enforcing Mozilla's intermediate
disclosure policy. Unless there are additional comments, I will plan to
recommend that Mozilla implement option 3 once intermediate preloading has
been deployed.

Thanks everyone for your input on this topic.

- Wayne