Re: New undisclosed intermediates

[Gervase Markham via dev-security-policy]

On 09/06/17 16:37, Jakob Bohm wrote:
> This seems to directly violate the often proposed (but apparently not
> yet enacted) rule that different root certs must have different keys
> (if that rule has been incorporated into a current policy).

This has come up enough times now that I've filed an issue for it:
https://github.com/mozilla/pkipolicy/issues/88

People with opinions on one side or the other should feel free to add
comments.

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

Re: New undisclosed intermediates

[Jonathan Rudenberg via dev-security-policy]

> On Jun 8, 2017, at 05:17, Gervase Markham via dev-security-policy 
>  wrote:
> 
> On 08/06/17 00:42, Jonathan Rudenberg wrote:
>> Yet another batch of undisclosed intermediates has shown up in CT:
> 
> Like, seriously?

Another one appeared this weekend:

https://crt.sh/?sha256=0330286df3612c0e968dcd518a7a316d5e0790d1ca324b906b0ef017c0be3ea7
 (WoSign DV SSL CA issued by Certum just under a month ago)

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

Re: New undisclosed intermediates

[Rob Stradling via dev-security-policy]

On 08/06/17 14:15, Rob Stradling via dev-security-policy wrote:

On 08/06/17 13:24, Kurt Roeckx via dev-security-policy wrote:

On 2017-06-08 14:16, Rob Stradling wrote:
crt.sh collates revocation information from all known CRL 
Distribution Point URLs for each CA.  The CDP URLs listed at 
https://crt.sh/?id=12729173 were observed in other certs issued by 
the same CA:


Sorry, I meant to write "listed at https://crt.sh/?id=149444544;.


That shows:
http://www.cert.fnmt.es/crls/ARLFNMTRCM.crl


This CA tends to put multiple CRL URLs in a single DistributionPoint, 
rather than put each CRL URL in its own DistributionPoint.  Most CAs do 
the latter, but IINM the former is also valid (see [1]).


Currently, crt.sh only processes the first URL in each 
DistributionPoint.  (Bug at [2] - I'm treating it as GENERAL_NAME rather 
than GENERAL_NAMES - I'll get that fixed).


Fixed.

crt.sh now processes all CRL URLs that have been observed in all 
"fullName" DistributionPoints (rather than just the first URL in each 
"fullName").


http://www.cert.fnmt.es/crls/ARLFNMTRCM.crl isn't the first CDP URL in 
any DistributionPoint of any cert known to crt.sh, and so crt.sh hasn't 
noticed that URL yet.


crt.sh has now noticed and processed this CRL successfully, and 
therefore the error messages have now disappeared from 
https://crt.sh/?id=149444544, etc.



But tries to use:
http://www.cert.fnmt.es.testa.eu/crls/ARLFNMTRCMEU.crl


This is the first CDP URL in these two certs:
https://crt.sh/?id=50915068
https://crt.sh/?id=50915069


[1] https://tools.ietf.org/html/rfc5280#section-4.2.1.13
   "If the DistributionPointName contains multiple values, each name
describes a different mechanism to obtain the same CRL.  For example,
the same CRL could be available for retrieval through both LDAP and
HTTP.

[2] https://github.com/crtsh/libx509pq/blob/master/x509pq.c#L2513


--
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online

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

Re: New undisclosed intermediates

[Ángel via dev-security-policy]

On 2017-06-08 at 04:31 -0700, richmoore44--- via dev-security-policy
wrote:
> This one is interesting since the domain name of the CRL resolves to an RFC 
> 1918 IP address. Surely that is a violation of the baseline requirements.
> 
> https://crt.sh/?sha256=b82210cde9ddea0e14be29af647e4b32f96ed2a9ef1aa5baa9cc64b38b6c01ca
> 
> Regards
> 
> Rich.


Nope. The domain name of the CRL (www.cert.fnmt.es.testa.eu) does not
resolve to an RFC 1918 IP address. It directly doesn't resolve.
10.0.1.10 is the dns server used by crt.sh

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

Re: New undisclosed intermediates

[Ángel via dev-security-policy]

On 2017-06-08 at 04:31 -0700, richmoore44--- via dev-security-policy
wrote:
> This one is interesting since the domain name of the CRL resolves to an RFC 
> 1918 IP address. Surely that is a violation of the baseline requirements.
> 
> https://crt.sh/?sha256=b82210cde9ddea0e14be29af647e4b32f96ed2a9ef1aa5baa9cc64b38b6c01ca
> 
> Regards
> 
> Rich.

Nope. The domain name of the CRL (www.cert.fnmt.es.testa.eu) is not
resolving to an RFC 1918 IP address. It plainly doesn't resolve.
10.0.1.10 is the dns server used by crt.sh


Rafa, can you take a look at this?

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

Re: New undisclosed intermediates

[Matthew Hardeman via dev-security-policy]

On Friday, June 9, 2017 at 11:52:53 AM UTC-5, Ryan Sleevi wrote:

> So that would be an arguement for disclosing both self-signed and
> self-issued certificates, and align with the "Disclose what the key does"
> mentality.

That was essentially the point I was trying to make.  Of all the things to 
watch, one would think that the usage and management of the key is among the 
most essential.

Using that key to sign an X.509 certificate, even a self-signed, self-issued 
one, is a use of that key.  Was the object of its use in that instance, 
creating the self-signed certificate, an issuance which gets properly recorded 
in the appropriate systems to be considered part of the overall corpus of 
certificate issuances which will be sampled in an audit?

(Presumably an auditor sampling a given signer's activity utilizes the original 
log closest to the HSM system and demands particulars of a random sampling of 
the signature events?)
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: New undisclosed intermediates

[Ryan Sleevi via dev-security-policy]

On Thu, Jun 8, 2017 at 10:16 PM, Peter Bowen via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
>
> There are two important things about self-issued certificates:
>
> 1) They cannot expand the scope of what is allowed.
> Cross-certificates can create alternative paths with different
> restrictions.  Self-issued certificates do not provide alternative
> paths that may have fewer constraints.
>
> 2) There is no way for a "parent" CA to prevent them from existing.
> Even if the only cross-sign has a path length constraint of zero, the
> "child" CA can issue self-issued certificates all day long.  If they
> are self-signed there is no real value in disclosing them, given #1.
>
> I think that it is reasonable to say that self-signed certificates are
> out of scope.
>

Right, a self-signed certificate is also self-issued, but a self-issued
certificate is not necessarily self-signed (e.g. in the event of key
rollover).

The question of whether self-signed should be in scope is largely related
to the question of trust anchor configuration and expression, and making
sure that mozilla::pkix is internally consistent with its evaluation of
trust anchors and self-consistent with the policy.

That is, consider https://tools.ietf.org/html/rfc5280#section-6.1.1 of RFC
5280 - the trust anchor may be provided in the form of a self-signed
certificate, which nominally encompasses the Subject field and
subjectPublicKeyInfo, but may also be used to derive additional constraints
as the input for 6.1.1. If mozilla::pkix consistently applies the
constraints expressed in the root cert (e.g. nameConstraints, as were
relied upon with HARICA), then a self-signed certificate is no concern.
However, if there is any disconnect - for example, using the merely the
Subject/SPKI for purposes of trust anchor evaluation, but then using the
certificate supplied as the basis for constraints, then you could bypass
constraints imposed via the root store.

Note: That would be a (logic) bug in mozilla::pkix, rather than an
intrinsic bug in the CAs' operations, and so it's probably easier and more
comprehensive to just fix that bug (IF it exists; I am fairly confident
Brian considered this scenario when initially writing it)

To the question of self-issued, there absolutely are risks to those, and we
should make sure they're disclosed. The most obvious case would be key
rotation events - that is, you have (Subject A, Key A) as the self-signed
(and self-issued) root in the Mozilla Store, and then it self-issues
(Subject A, Key B) as a key rotation. You may have an Intermediate,
(Intermediate C), which is signed by either Key A or cross-signed by Key B,
thus either chain works. However, the reason you want disclosure is that
you want to ensure that the creation and operation of Key B has been
appropriately audited - that someone isn't relying on a
misinterpretation/loophole to somehow consider (Subject A, Key B) as out of
scope, since it absolutely participates in the trust evaluation chain.

There's a secondary question related to self-signed, in which their
disclosure can help detect and remedy configuration issues and/or path
building issues, and so it serves a public interest/public good to have
those disclosed, but it's unclear whether that public interest/public good
is necessary to mandate via policy.

That is, consider the following scenario:
- "For Root or Intermediate Certificates that are disclosed, CAs are not
required to disclose self-signed variations of these certificates.
Self-signed shall mean that the Certificate's Subject and Issuer are
byte-for-byte identical, that the Certificate's Subject is byte-for-byte
identical with a Certificate already disclosed to Mozilla, and the
Certificate's subjectPublicKeyInfo is byte-for-byte identical with the same
already-disclosed certificate"

You can have the following scenarios:
- Duplicate serial numbers (would break NSS, since NSS is ... poorly
believing in the X.500 DIT in this respect)
- Cross-certification paths that confound and/or break clients (such paths
were why Red Hat patched in several legacy roots back to NSS in their
distribution, due to the behaviours of OpenSSL-and-other-libraries with
respect to validation)
- Improperly encoding / not adhering to the BRs in the issuance of that
self-signed certificate

So that would be an arguement for disclosing both self-signed and
self-issued certificates, and align with the "Disclose what the key does"
mentality.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: New undisclosed intermediates

[Peter Bowen via dev-security-policy]

On Fri, Jun 9, 2017 at 9:11 AM, Matthew Hardeman via
dev-security-policy  wrote:
> For these self-signed roots which have a certificate subject and key which 
> match to a different certificate which is in a trusted path (like an 
> intermediate to a trusted root), the concern is that the mere existence of 
> the certificate speaks to a signature produced by a private key which DOES 
> have the privileged status of extending the trust of the Web PKI.
>
> The question then is whether that signature was properly accounted for, 
> audited, etc.
>
> Additionally, if said root is in active use, are the issuances descending 
> from _that_ self-signed root being audited?  If not, that's a problem, 
> because those certificates could just be served up with the same-subject, 
> same-key trusted intermediate and chain to publicly trusted roots, all 
> without having been actually issued from the trusted intermediate.

I think there is some confusion here.  Certificates do not sign
certificates.  The existence of mulitiple self-signed certificates
with the same {subject, public key} combination does not imply there
are multiple issuers.  Further, audits does not audit root
_certificates_, they audit CA operations.  The audit will look at
practices for signing certificates but you cannot audit an object
itself.

Additionally, there is nothing that says a CA operator may not have
multiple issuers that have the same private key and use the same
issuer name.  The only requirement is that they avoid serial number
collision and that the CRL contain the union of both revocations.

The mere existence of multiple self-signed certificates does not
change any of this.

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

Re: New undisclosed intermediates

[Matthew Hardeman via dev-security-policy]

For these self-signed roots which have a certificate subject and key which 
match to a different certificate which is in a trusted path (like an 
intermediate to a trusted root), the concern is that the mere existence of the 
certificate speaks to a signature produced by a private key which DOES have the 
privileged status of extending the trust of the Web PKI.

The question then is whether that signature was properly accounted for, 
audited, etc.

Additionally, if said root is in active use, are the issuances descending from 
_that_ self-signed root being audited?  If not, that's a problem, because those 
certificates could just be served up with the same-subject, same-key trusted 
intermediate and chain to publicly trusted roots, all without having been 
actually issued from the trusted intermediate.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: New undisclosed intermediates

[Jakob Bohm via dev-security-policy]

On 09/06/2017 12:29, Rob Stradling wrote:

On 09/06/17 11:16, Jakob Bohm via dev-security-policy wrote:


What in the policy says they become in-scope from a certificate chain
that isn't "anchored" at a Mozilla trusted root?

And would someone please post those alleged certificate chains 
*explicitly* here, not just say they saw it "somehow".


Hi Jakob.  Let me run through one of them as an example:

https://crt.sh/?id=12977063 is a self-signed root certificate that is 
also an NSS built-in trust anchor.


https://crt.sh/?id=149444544 is a self-signed root certificate that is 
_not_ an NSS built-in trust anchor.




Ah, that wasn't clear from the previous posts in this thread.

So basically, this is *identical* to one of the trusted roots, but with
a different self-signature hash algorithm (and for at least this pair, a
different serial number).

This seems to directly violate the often proposed (but apparently not
yet enacted) rule that different root certs must have different keys
(if that rule has been incorporated into a current policy).

It's also risky cryptographic practice, although for RSA, the PKCS#1
padding ensures no direct collision risk (but still, once the weaker
hash is broken, each of the certs previously signed with that hash
become a reason to distrust the root in software that does not filter
the hash algorithm for each issued certificate).  The safer design would
have been to create a new key pair and subject name, then set it up as a
cross-signed root, which would be a SubCA for those only trusting the
the older root.

Without the no-reuse rule, the most reasonable interpretation of such a
certificate is as a refresh of the same root CA, which must be disclosed
in the same way as any other such refresh (such as a change in the date
fields).  Both certificates must be subjected to the same audits,
disclosures and trust bits.  Both certificates must be somehow listed
in the entry for that root CA.




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-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: New undisclosed intermediates

[Gervase Markham via dev-security-policy]

On 09/06/17 11:29, Rob Stradling wrote:
> These two certs share the same Name and Key.  Therefore, the signature
> on the first can be verified by the public key in the second; and vice
> versa.  And clearly the Subject Name in each one matches the Issuer Name
> in the other.  This means that the first chains to the second, and also
> that the second chains to the first.

And a certificate issued by either can chain to either?

Do we have any idea what NSS does with a cert like
https://crt.sh/?id=149444544 when it's presented in a bundle by a
webserver which includes an EE cert which chains up to
https://crt.sh/?id=12977063 ?

It seems like one potential (if perhaps never build path) might be:

EE -> 149444544 -> 149444544 -> 149444544 ... -> 149444544 -> 12977063

?

I sort of seem to remember Brian or someone saying that mozilla::pkix
ignores self-issued certificates, but I'd like to have a definitive word.

> The policy says:
> "All certificates that are capable of being used to issue new
> certificates, and which directly or transitively chain to a certificate
> included in Mozilla's CA Certificate Program, MUST be operated in
> accordance with this policy and MUST either be technically constrained
> or be publicly disclosed and audited."

How would you reword the policy to exclude self-issued certificates?

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

Re: New undisclosed intermediates

[Gervase Markham via dev-security-policy]

On 08/06/17 15:37, Jeremy Rowley wrote:
> If you added them automatically to OneCRL, how would you create new
> intermediates? Would it be anything over X days old and undisclosed is
> automatically added? 

Yes, that :-) Sorry if that wasn't clear. The deadline, as of policy
2.5, is a week (section 5.3.2).

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

Re: New undisclosed intermediates

[Rob Stradling via dev-security-policy]

On 09/06/17 11:16, Jakob Bohm via dev-security-policy wrote:


What in the policy says they become in-scope from a certificate chain
that isn't "anchored" at a Mozilla trusted root?

And would someone please post those alleged certificate chains 
*explicitly* here, not just say they saw it "somehow".


Hi Jakob.  Let me run through one of them as an example:

https://crt.sh/?id=12977063 is a self-signed root certificate that is 
also an NSS built-in trust anchor.


https://crt.sh/?id=149444544 is a self-signed root certificate that is 
_not_ an NSS built-in trust anchor.


These two certs share the same Name and Key.  Therefore, the signature 
on the first can be verified by the public key in the second; and vice 
versa.  And clearly the Subject Name in each one matches the Issuer Name 
in the other.  This means that the first chains to the second, and also 
that the second chains to the first.


The policy says:
"All certificates that are capable of being used to issue new 
certificates, and which directly or transitively chain to a certificate 
included in Mozilla's CA Certificate Program, MUST be operated in 
accordance with this policy and MUST either be technically constrained 
or be publicly disclosed and audited."


--
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online

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

Re: New undisclosed intermediates

[Jakob Bohm via dev-security-policy]

On 09/06/2017 11:57, Rob Stradling wrote:

On 09/06/17 03:16, Peter Bowen via dev-security-policy wrote:

On Thu, Jun 8, 2017 at 7:09 PM, Jonathan Rudenberg via
dev-security-policy  wrote:


On Jun 8, 2017, at 20:43, Ben Wilson via dev-security-policy 
 wrote:


I don't believe that disclosure of root certificates is the 
responsibility
of a CA that has cross-certified a key.  For instance, the CCADB 
interface
talks in terms of "Intermediate CAs".  Root CAs are the 
responsibility of

browsers to upload.  I don't even have access to upload a "root"
certificate.


I think the Mozilla Root Store policy is pretty clear on this point:

All certificates that are capable of being used to issue new 
certificates, and which directly or transitively chain to a 
certificate included in Mozilla’s CA Certificate Program, MUST be 
operated in accordance with this policy and MUST either be 
technically constrained or be publicly disclosed and audited.


The self-signed certificates in the present set are all in scope for 
the disclosure policy because they are capable of being used to issue 
new certificates and chain to a certificate included in Mozilla’s CA 
Certificate Program. From the perspective of the Mozilla root store 
they look like intermediates because they can be used as 
intermediates in a valid path to a root certificate trusted by Mozilla.


There are two important things about self-issued certificates:

1) They cannot expand the scope of what is allowed.
Cross-certificates can create alternative paths with different
restrictions.  Self-issued certificates do not provide alternative
paths that may have fewer constraints.

2) There is no way for a "parent" CA to prevent them from existing.
Even if the only cross-sign has a path length constraint of zero, the
"child" CA can issue self-issued certificates all day long.  If they
are self-signed there is no real value in disclosing them, given #1.

I think that it is reasonable to say that self-signed certificates are
out of scope.


There's a signature chain, so they're clearly in scope (as far as the 
current policy is concerned).


The policy would need to be updated before we could say that they "*are* 
out of scope".


(FWIW, I agree that it's pointless for them to be in scope.  However, 
the policy trumps my opinion).




What in the policy says they become in-scope from a certificate chain
that isn't "anchored" at a Mozilla trusted root?

And would someone please post those alleged certificate chains 
*explicitly* here, not just say they saw it "somehow".




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-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: New undisclosed intermediates

[Rob Stradling via dev-security-policy]

On 09/06/17 03:16, Peter Bowen via dev-security-policy wrote:

On Thu, Jun 8, 2017 at 7:09 PM, Jonathan Rudenberg via
dev-security-policy  wrote:



On Jun 8, 2017, at 20:43, Ben Wilson via dev-security-policy 
 wrote:

I don't believe that disclosure of root certificates is the responsibility
of a CA that has cross-certified a key.  For instance, the CCADB interface
talks in terms of "Intermediate CAs".  Root CAs are the responsibility of
browsers to upload.  I don't even have access to upload a "root"
certificate.


I think the Mozilla Root Store policy is pretty clear on this point:


All certificates that are capable of being used to issue new certificates, and 
which directly or transitively chain to a certificate included in Mozilla’s CA 
Certificate Program, MUST be operated in accordance with this policy and MUST 
either be technically constrained or be publicly disclosed and audited.


The self-signed certificates in the present set are all in scope for the 
disclosure policy because they are capable of being used to issue new 
certificates and chain to a certificate included in Mozilla’s CA Certificate 
Program. From the perspective of the Mozilla root store they look like 
intermediates because they can be used as intermediates in a valid path to a 
root certificate trusted by Mozilla.


There are two important things about self-issued certificates:

1) They cannot expand the scope of what is allowed.
Cross-certificates can create alternative paths with different
restrictions.  Self-issued certificates do not provide alternative
paths that may have fewer constraints.

2) There is no way for a "parent" CA to prevent them from existing.
Even if the only cross-sign has a path length constraint of zero, the
"child" CA can issue self-issued certificates all day long.  If they
are self-signed there is no real value in disclosing them, given #1.

I think that it is reasonable to say that self-signed certificates are
out of scope.


There's a signature chain, so they're clearly in scope (as far as the 
current policy is concerned).


The policy would need to be updated before we could say that they "*are* 
out of scope".


(FWIW, I agree that it's pointless for them to be in scope.  However, 
the policy trumps my opinion).


--
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online

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

Re: New undisclosed intermediates

[Jakob Bohm via dev-security-policy]

On 09/06/2017 04:09, Jonathan Rudenberg wrote:



On Jun 8, 2017, at 20:43, Ben Wilson via dev-security-policy 
 wrote:

I don't believe that disclosure of root certificates is the responsibility
of a CA that has cross-certified a key.  For instance, the CCADB interface
talks in terms of "Intermediate CAs".  Root CAs are the responsibility of
browsers to upload.  I don't even have access to upload a "root"
certificate.


I think the Mozilla Root Store policy is pretty clear on this point:


All certificates that are capable of being used to issue new certificates, and 
which directly or transitively chain to a certificate included in Mozilla’s CA 
Certificate Program, MUST be operated in accordance with this policy and MUST 
either be technically constrained or be publicly disclosed and audited.


The self-signed certificates in the present set are all in scope for the 
disclosure policy because they are capable of being used to issue new 
certificates and chain to a certificate included in Mozilla’s CA Certificate 
Program. From the perspective of the Mozilla root store they look like 
intermediates because they can be used as intermediates in a valid path to a 
root certificate trusted by Mozilla.



This is getting awfully confusing.

What exactly about which specific certificates makes them both "self-
signed" and "part of a chain to a root in the Mozilla root store" ?

This seems to be a direct logical contradiction.

Here is how I see it:

If you are talking about two different certificates with the same public
key, then each such certificate needs to be considered separately.

If you are talking about two different certificates with the same
Subject Distinguished Name and optional id, but with different contents,
then again they need to be considered separately, as there is nothing
guaranteeing uniqueness of those fields.

If you are talking about two different certificates that differ only in 
the Issuer and Signature fields (and maybe in the serial number too), 
then again they need to be considered separately.


Chaining is defined by the tuple [Public Key, Subject, Optional Key ID],
deviating in either public key or subject certainly makes them unrelated
entities for chain building (except that sending irrelevant certificates
to the Browser can cause it to waste time comparing them).  Deviating in
the key ID may or may not cause certificates to not chain together
depending on the certificate checking library used (NSS being most
important for Mozilla, BouncyCastle and BoringSSL being of additional
interest for Chrome).

Certificates (not keys or names) that actually chain (as defined above)
to a root certificate in the CCADB are in scope for CCADB policy,
others are not.

Certificates that are in scope and have CA:TRUE in basic constraints
and/or CertificateSigning in Extended Key Usage or (maybe) have an
equivalent bit set in the historic Netscape/Mozilla key usage attribute
belong in CCADB.

Certificates that are in scope but lack all of these CA-usage flags are
end entity certificates that must satisfy Mozilla policy on correct
issuance (such as ownership checks, no RFC1918 addresses as SANs etc.).

Certificates that are not in scope are not in scope.

For example if a virus-scanning middle box has a locally generated root
CA trusted by the local clients (via configuration), and that virus
scanning middle box generates on-the fly certificates matching the names
(but not the keys) in the real public certificates it sees, then those
on-the fly certificates may have the same Subject as the real
certificates, but don't become in scope that way, even if they leak back
out through various forms of "telemetry".  Because there is no actual
way in which they would be trusted by a Mozilla browser that hasn't been
locally reconfigured to trust that local root CA.



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-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

RE: New undisclosed intermediates

[Ben Wilson via dev-security-policy]

That's right, Peter.  They should be out of scope unless browsers want to trust 
them and/or they are submitted to browsers for that purpose, in which case 
browsers should be responsible for inputting them into the CCADB.  

Aside from treating these as "intermediates" or "subordinates", there are two 
other ways to look at a self-signed root certificate.  First and more commonly, 
it is a certificate that someone created for submission as a trust anchor (and 
it is usually created prior to submitting the public key for 
cross-certification),  and, second, it is basically a stub branch--because it 
is signing itself--that is one way that these kinds of certificates appear in 
the CCADB.  I've gone ahead and uploaded these two root CA certificates as 
"intermediates" 
(https://crt.sh/?sha256=29d8ac29f9007a6ad7923fdade32ef814ba3c6751551cf765416e8dbd8ff7619
 and 
https://crt.sh/?sha256=c02739e63880368967bb27fedf0a5749aeaf62a2328c09a7a33e876b4f27adca),
 but I don't think that that is the right approach, IMO, and it would be nice 
if a policy existed that recognized my concerns.  

-Original Message-
From: Peter Bowen [mailto:pzbo...@gmail.com] 
Sent: Thursday, June 8, 2017 8:17 PM
To: Jonathan Rudenberg <jonat...@titanous.com>
Cc: Ben Wilson <ben.wil...@digicert.com>; 
mozilla-dev-security-pol...@lists.mozilla.org
Subject: Re: New undisclosed intermediates

On Thu, Jun 8, 2017 at 7:09 PM, Jonathan Rudenberg via dev-security-policy 
<dev-security-policy@lists.mozilla.org> wrote:
>
>> On Jun 8, 2017, at 20:43, Ben Wilson via dev-security-policy 
>> <dev-security-policy@lists.mozilla.org> wrote:
>>
>> I don't believe that disclosure of root certificates is the 
>> responsibility of a CA that has cross-certified a key.  For instance, 
>> the CCADB interface talks in terms of "Intermediate CAs".  Root CAs 
>> are the responsibility of browsers to upload.  I don't even have access to 
>> upload a "root"
>> certificate.
>
> I think the Mozilla Root Store policy is pretty clear on this point:
>
>> All certificates that are capable of being used to issue new certificates, 
>> and which directly or transitively chain to a certificate included in 
>> Mozilla’s CA Certificate Program, MUST be operated in accordance with this 
>> policy and MUST either be technically constrained or be publicly disclosed 
>> and audited.
>
> The self-signed certificates in the present set are all in scope for the 
> disclosure policy because they are capable of being used to issue new 
> certificates and chain to a certificate included in Mozilla’s CA Certificate 
> Program. From the perspective of the Mozilla root store they look like 
> intermediates because they can be used as intermediates in a valid path to a 
> root certificate trusted by Mozilla.

There are two important things about self-issued certificates:

1) They cannot expand the scope of what is allowed.
Cross-certificates can create alternative paths with different restrictions.  
Self-issued certificates do not provide alternative paths that may have fewer 
constraints.

2) There is no way for a "parent" CA to prevent them from existing.
Even if the only cross-sign has a path length constraint of zero, the "child" 
CA can issue self-issued certificates all day long.  If they are self-signed 
there is no real value in disclosing them, given #1.

I think that it is reasonable to say that self-signed certificates are out of 
scope.

Thanks,
Peter


smime.p7s
Description: S/MIME cryptographic signature
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: New undisclosed intermediates

[Peter Bowen via dev-security-policy]

On Thu, Jun 8, 2017 at 7:09 PM, Jonathan Rudenberg via
dev-security-policy  wrote:
>
>> On Jun 8, 2017, at 20:43, Ben Wilson via dev-security-policy 
>>  wrote:
>>
>> I don't believe that disclosure of root certificates is the responsibility
>> of a CA that has cross-certified a key.  For instance, the CCADB interface
>> talks in terms of "Intermediate CAs".  Root CAs are the responsibility of
>> browsers to upload.  I don't even have access to upload a "root"
>> certificate.
>
> I think the Mozilla Root Store policy is pretty clear on this point:
>
>> All certificates that are capable of being used to issue new certificates, 
>> and which directly or transitively chain to a certificate included in 
>> Mozilla’s CA Certificate Program, MUST be operated in accordance with this 
>> policy and MUST either be technically constrained or be publicly disclosed 
>> and audited.
>
> The self-signed certificates in the present set are all in scope for the 
> disclosure policy because they are capable of being used to issue new 
> certificates and chain to a certificate included in Mozilla’s CA Certificate 
> Program. From the perspective of the Mozilla root store they look like 
> intermediates because they can be used as intermediates in a valid path to a 
> root certificate trusted by Mozilla.

There are two important things about self-issued certificates:

1) They cannot expand the scope of what is allowed.
Cross-certificates can create alternative paths with different
restrictions.  Self-issued certificates do not provide alternative
paths that may have fewer constraints.

2) There is no way for a "parent" CA to prevent them from existing.
Even if the only cross-sign has a path length constraint of zero, the
"child" CA can issue self-issued certificates all day long.  If they
are self-signed there is no real value in disclosing them, given #1.

I think that it is reasonable to say that self-signed certificates are
out of scope.

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

Re: New undisclosed intermediates

[Jonathan Rudenberg via dev-security-policy]

> On Jun 8, 2017, at 20:43, Ben Wilson via dev-security-policy 
>  wrote:
> 
> I don't believe that disclosure of root certificates is the responsibility
> of a CA that has cross-certified a key.  For instance, the CCADB interface
> talks in terms of "Intermediate CAs".  Root CAs are the responsibility of
> browsers to upload.  I don't even have access to upload a "root"
> certificate.  

I think the Mozilla Root Store policy is pretty clear on this point:

> All certificates that are capable of being used to issue new certificates, 
> and which directly or transitively chain to a certificate included in 
> Mozilla’s CA Certificate Program, MUST be operated in accordance with this 
> policy and MUST either be technically constrained or be publicly disclosed 
> and audited.

The self-signed certificates in the present set are all in scope for the 
disclosure policy because they are capable of being used to issue new 
certificates and chain to a certificate included in Mozilla’s CA Certificate 
Program. From the perspective of the Mozilla root store they look like 
intermediates because they can be used as intermediates in a valid path to a 
root certificate trusted by Mozilla.

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

Re: New undisclosed intermediates

[Peter Bowen via dev-security-policy]

On Thu, Jun 8, 2017 at 7:02 PM, Matthew Hardeman via
dev-security-policy  wrote:
> On Thursday, June 8, 2017 at 7:44:08 PM UTC-5, Ben Wilson wrote:
>> I don't believe that disclosure of root certificates is the responsibility
>> of a CA that has cross-certified a key.  For instance, the CCADB interface
>> talks in terms of "Intermediate CAs".  Root CAs are the responsibility of
>> browsers to upload.  I don't even have access to upload a "root"
>> certificate.
>
> At least in terms of intention of disclosing the intermediates, I don't think 
> you've made a fair assessment of the situation.
>
> The responsibility to disclose must fall upon the signer.  Not the one who 
> was signed.
>
> Cross-signature certificates are, effectively, intermediates granting an 
> alternate / enhanced validation path to trust to a distinct, separate 
> hierarchy.
>
> While IdenTrust signs Let's Encrypt's intermediates rather than a cross-sign 
> of their root, the principle is ultimately the same.  The browser programs 
> clearly wish to have those who are positioned to grant trust accountable for 
> any such trust that they grant.
>
> It's one question if the other root is already in the trust store, but 
> imagine it's some large enterprise root that's been running, perhaps under 
> appropriate audits but maybe not, cross-signed by a widely trusted program 
> participant.
>
> Perhaps the text needs clarifying, but I find it hard to believe that any of 
> the browser programs is of the opinion that you can cross-sign someone else's 
> root cert and not disclose that.

I don't think that is the question at hand.  I think Ben means
"self-signed" or "self-issued" when he says "root" certificate.

I agree with Ben that self-signed certificates should be out of scope.
Self-issued certificates that are not self-signed probably should be
in scope.

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

Re: New undisclosed intermediates

[Matthew Hardeman via dev-security-policy]

On Thursday, June 8, 2017 at 7:44:08 PM UTC-5, Ben Wilson wrote:
> I don't believe that disclosure of root certificates is the responsibility
> of a CA that has cross-certified a key.  For instance, the CCADB interface
> talks in terms of "Intermediate CAs".  Root CAs are the responsibility of
> browsers to upload.  I don't even have access to upload a "root"
> certificate.  

At least in terms of intention of disclosing the intermediates, I don't think 
you've made a fair assessment of the situation.

The responsibility to disclose must fall upon the signer.  Not the one who was 
signed.

Cross-signature certificates are, effectively, intermediates granting an 
alternate / enhanced validation path to trust to a distinct, separate hierarchy.

While IdenTrust signs Let's Encrypt's intermediates rather than a cross-sign of 
their root, the principle is ultimately the same.  The browser programs clearly 
wish to have those who are positioned to grant trust accountable for any such 
trust that they grant.

It's one question if the other root is already in the trust store, but imagine 
it's some large enterprise root that's been running, perhaps under appropriate 
audits but maybe not, cross-signed by a widely trusted program participant.

Perhaps the text needs clarifying, but I find it hard to believe that any of 
the browser programs is of the opinion that you can cross-sign someone else's 
root cert and not disclose that.

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

RE: New undisclosed intermediates

[Ben Wilson via dev-security-policy]

I don't believe that disclosure of root certificates is the responsibility
of a CA that has cross-certified a key.  For instance, the CCADB interface
talks in terms of "Intermediate CAs".  Root CAs are the responsibility of
browsers to upload.  I don't even have access to upload a "root"
certificate.  

-Original Message-
From: dev-security-policy
[mailto:dev-security-policy-bounces+ben=digicert@lists.mozilla.org] On
Behalf Of Kurt Roeckx via dev-security-policy
Sent: Thursday, June 8, 2017 6:40 AM
To: mozilla-dev-security-pol...@lists.mozilla.org
Subject: Re: New undisclosed intermediates

On 2017-06-08 14:09, wiz...@ida.net wrote:
> But Censys lists it as a trusted intermediate chaining to a root (
ebc5570c29018c4d67b1aa127baf12f703b4611ebc17b7dab5573894179b93fa ) in NSS:
> 
> https://censys.io/certificates/b82210cde9ddea0e14be29af647e4b32f96ed2a
> 9ef1aa5baa9cc64b38b6c01ca/validation

I got confused by crt.sh, it's not obvious if a certificate is in some root
store or not. They have an other certificate
(https://crt.sh/?q=ebc5570c29018c4d67b1aa127baf12f703b4611ebc17b7dab55738941
79b93fa)
for the same CA that is in the root store.

I have no idea what common implementations do when trying to validate a
chain with such certificate in the middle.

> With respect to Gerv's question: given the ample time to disclose
intermediates, and given all CAs in the program indicated that they had,
seems reasonable to immediately add undisclosed ones that are discovered to
OneCRL. Other than some breakage, as already noted, main downside would seem
to be potentially large growth in OneCRL.

I think there are 2 solutions: OneCRL or a whitelist. OneCRL is probably
easier to do, no new code would need to be written in the browser or NSS. A
whitelist would mean that that list would need to get updated regularly and
that list is probably larger.


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


smime.p7s
Description: S/MIME cryptographic signature
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

RE: New undisclosed intermediates

[Jeremy Rowley via dev-security-policy]

If you added them automatically to OneCRL, how would you create new
intermediates? Would it be anything over X days old and undisclosed is
automatically added? If so, +1 from us.  I'm pretty sure the two CAs listed
from the Baltimore root don't believe these are publicly trusted
intermediates. 

-Original Message-
From: dev-security-policy
[mailto:dev-security-policy-bounces+jeremy.rowley=digicert.com@lists.mozilla
.org] On Behalf Of Gervase Markham via dev-security-policy
Sent: Thursday, June 8, 2017 3:17 AM
To: Jonathan Rudenberg <jonat...@titanous.com>;
mozilla-dev-security-pol...@lists.mozilla.org
Subject: Re: New undisclosed intermediates

On 08/06/17 00:42, Jonathan Rudenberg wrote:
> Yet another batch of undisclosed intermediates has shown up in CT:

Like, seriously?

Every CA in our program indicated that they would disclose all their
intermediates by June 30th, 2016:

https://ccadb-public.secure.force.com/mozillacommunications/CACommResponsesO
nlyReport?CommunicationId=a05o00iHdtx=Q4

I don't really want to switch to an intermediate whitelist because that
requires coding.

My patience is expiring. What CA can't keep track of the intermediates it
issues? How hard is that, really?

What downsides would there be, other than the obvious "some sites might
break", to us just adding any such intermediate certs directly to OneCRL?

Gerv

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


smime.p7s
Description: S/MIME cryptographic signature
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: New undisclosed intermediates

[Kurt Roeckx via dev-security-policy]

On 2017-06-08 14:09, wiz...@ida.net wrote:

But Censys lists it as a trusted intermediate chaining to a root ( 
ebc5570c29018c4d67b1aa127baf12f703b4611ebc17b7dab5573894179b93fa ) in NSS:

https://censys.io/certificates/b82210cde9ddea0e14be29af647e4b32f96ed2a9ef1aa5baa9cc64b38b6c01ca/validation


I got confused by crt.sh, it's not obvious if a certificate is in some 
root store or not. They have an other certificate 
(https://crt.sh/?q=ebc5570c29018c4d67b1aa127baf12f703b4611ebc17b7dab5573894179b93fa) 
for the same CA that is in the root store.


I have no idea what common implementations do when trying to validate a 
chain with such certificate in the middle.



With respect to Gerv's question: given the ample time to disclose 
intermediates, and given all CAs in the program indicated that they had, seems 
reasonable to immediately add undisclosed ones that are discovered to OneCRL. 
Other than some breakage, as already noted, main downside would seem to be 
potentially large growth in OneCRL.


I think there are 2 solutions: OneCRL or a whitelist. OneCRL is probably 
easier to do, no new code would need to be written in the browser or 
NSS. A whitelist would mean that that list would need to get updated 
regularly and that list is probably larger.



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

Re: New undisclosed intermediates

[Kurt Roeckx via dev-security-policy]

On 2017-06-08 14:16, Rob Stradling wrote:
crt.sh collates revocation information from all known CRL Distribution 
Point URLs for each CA.  The CDP URLs listed at 
https://crt.sh/?id=12729173 were observed in other certs issued by the  > same CA:


That shows:
http://www.cert.fnmt.es/crls/ARLFNMTRCM.crl

But tries to use:
http://www.cert.fnmt.es.testa.eu/crls/ARLFNMTRCMEU.crl


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

Re: New undisclosed intermediates

[Rob Stradling via dev-security-policy]

On 08/06/17 12:57, Kurt Roeckx via dev-security-policy wrote:

On 2017-06-08 13:31, richmoor...@gmail.com wrote:
This one is interesting since the domain name of the CRL resolves to 
an RFC 1918 IP address. Surely that is a violation of the baseline 
requirements.


https://crt.sh/?sha256=b82210cde9ddea0e14be29af647e4b32f96ed2a9ef1aa5baa9cc64b38b6c01ca 



That seems to be a root CA. It does not mention any CRL. I don't expect 
a root CA to have a CRL. I'm not sure from where crt.sh is getting the 
CRL URL.


crt.sh collates revocation information from all known CRL Distribution 
Point URLs for each CA.  The CDP URLs listed at 
https://crt.sh/?id=12729173 were observed in other certs issued by the 
same CA:


https://crt.sh/?Identity=%25=241

--
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online

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

Re: New undisclosed intermediates

[wizard--- via dev-security-policy]

But Censys lists it as a trusted intermediate chaining to a root ( 
ebc5570c29018c4d67b1aa127baf12f703b4611ebc17b7dab5573894179b93fa ) in NSS: 

https://censys.io/certificates/b82210cde9ddea0e14be29af647e4b32f96ed2a9ef1aa5baa9cc64b38b6c01ca/validation

With respect to Gerv's question: given the ample time to disclose 
intermediates, and given all CAs in the program indicated that they had, seems 
reasonable to immediately add undisclosed ones that are discovered to OneCRL. 
Other than some breakage, as already noted, main downside would seem to be 
potentially large growth in OneCRL.

On Thursday, June 8, 2017 at 7:58:51 AM UTC-4, Kurt Roeckx wrote:
> On 2017-06-08 13:31, richmoor...@gmail.com wrote:
> > This one is interesting since the domain name of the CRL resolves to an RFC 
> > 1918 IP address. Surely that is a violation of the baseline requirements.
> > 
> > https://crt.sh/?sha256=b82210cde9ddea0e14be29af647e4b32f96ed2a9ef1aa5baa9cc64b38b6c01ca
> 
> That seems to be a root CA. It does not mention any CRL. I don't expect 
> a root CA to have a CRL. I'm not sure from where crt.sh is getting the 
> CRL URL.
> 
> 
> Kurt

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

Re: New undisclosed intermediates

[Kurt Roeckx via dev-security-policy]

On 2017-06-08 13:31, richmoor...@gmail.com wrote:

This one is interesting since the domain name of the CRL resolves to an RFC 
1918 IP address. Surely that is a violation of the baseline requirements.

https://crt.sh/?sha256=b82210cde9ddea0e14be29af647e4b32f96ed2a9ef1aa5baa9cc64b38b6c01ca


That seems to be a root CA. It does not mention any CRL. I don't expect 
a root CA to have a CRL. I'm not sure from where crt.sh is getting the 
CRL URL.



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

Re: New undisclosed intermediates

[richmoore44--- via dev-security-policy]

This one is interesting since the domain name of the CRL resolves to an RFC 
1918 IP address. Surely that is a violation of the baseline requirements.

https://crt.sh/?sha256=b82210cde9ddea0e14be29af647e4b32f96ed2a9ef1aa5baa9cc64b38b6c01ca

Regards

Rich.


On Thursday, June 8, 2017 at 12:45:25 AM UTC+1, Jonathan Rudenberg wrote:
> > On Jun 5, 2017, at 09:29, Alex Gaynor via dev-security-policy 
> >  wrote:
> > 
> > Happy Monday!
> > 
> > Another week, another set of intermediate certs that have shown up in CT
> > without having been properly disclosed:
> > https://crt.sh/mozilla-disclosures#undisclosed
> 
> Yet another batch of undisclosed intermediates has shown up in CT:
> 
> - 
> https://crt.sh/?sha256=f01c1aca392882af152e9f01ecccd0afddd8aa35bf895b003198b1e8c752ddb8
> - 
> https://crt.sh/?sha256=29d8ac29f9007a6ad7923fdade32ef814ba3c6751551cf765416e8dbd8ff7619
> - 
> https://crt.sh/?sha256=c02739e63880368967bb27fedf0a5749aeaf62a2328c09a7a33e876b4f27adca
> - 
> https://crt.sh/?sha256=b82210cde9ddea0e14be29af647e4b32f96ed2a9ef1aa5baa9cc64b38b6c01ca
> - 
> https://crt.sh/?sha256=8e8c6ebf77dc73db3e38e93f4803e62b6b5933beb51ee4152f68d7aa14426b31
> - 
> https://crt.sh/?sha256=48db8801874e0e36b1b864603b31648b74e2322a8f9e4967a8f54bd1b8f594de
> - 
> https://crt.sh/?sha256=1bc400808ab07b775c811c631d75ab38fe7be7df6967f5b384bfe8dc9ef807c6
> - 
> https://crt.sh/?sha256=f1f072c64d69e573725533e83a601bb8b068f6699e59ba70eda2aecb28e06bfb

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

Re: New undisclosed intermediates

[Gervase Markham via dev-security-policy]

On 08/06/17 10:17, Gervase Markham wrote:
> What downsides would there be, other than the obvious "some sites might
> break", to us just adding any such intermediate certs directly to OneCRL?

We provide reports which allow CAs to download the stored intermediate
cert data:

https://ccadb-public.secure.force.com/mozilla/PublicAllIntermediateCertsCSV

So if they don't want this to happen to them, all they need to do is
write a script to download the data daily, compare it with their
internal records, and send out an alert when it finds a discrepancy.

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

Re: New undisclosed intermediates

[Gervase Markham via dev-security-policy]

On 08/06/17 00:42, Jonathan Rudenberg wrote:
> Yet another batch of undisclosed intermediates has shown up in CT:

Like, seriously?

Every CA in our program indicated that they would disclose all their
intermediates by June 30th, 2016:

https://ccadb-public.secure.force.com/mozillacommunications/CACommResponsesOnlyReport?CommunicationId=a05o00iHdtx=Q4

I don't really want to switch to an intermediate whitelist because that
requires coding.

My patience is expiring. What CA can't keep track of the intermediates
it issues? How hard is that, really?

What downsides would there be, other than the obvious "some sites might
break", to us just adding any such intermediate certs directly to OneCRL?

Gerv

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

Re: New undisclosed intermediates

[Jonathan Rudenberg via dev-security-policy]

> On Jun 7, 2017, at 21:56, Matthew Hardeman via dev-security-policy 
>  wrote:
> 
> On Wednesday, June 7, 2017 at 6:45:25 PM UTC-5, Jonathan Rudenberg wrote:
> 
>> Yet another batch of undisclosed intermediates has shown up in CT:
>> 
>> - 
>> https://crt.sh/?sha256=f01c1aca392882af152e9f01ecccd0afddd8aa35bf895b003198b1e8c752ddb8
>> - 
>> https://crt.sh/?sha256=29d8ac29f9007a6ad7923fdade32ef814ba3c6751551cf765416e8dbd8ff7619
>> - 
>> https://crt.sh/?sha256=c02739e63880368967bb27fedf0a5749aeaf62a2328c09a7a33e876b4f27adca
>> - 
>> https://crt.sh/?sha256=b82210cde9ddea0e14be29af647e4b32f96ed2a9ef1aa5baa9cc64b38b6c01ca
>> - 
>> https://crt.sh/?sha256=8e8c6ebf77dc73db3e38e93f4803e62b6b5933beb51ee4152f68d7aa14426b31
>> - 
>> https://crt.sh/?sha256=48db8801874e0e36b1b864603b31648b74e2322a8f9e4967a8f54bd1b8f594de
>> - 
>> https://crt.sh/?sha256=1bc400808ab07b775c811c631d75ab38fe7be7df6967f5b384bfe8dc9ef807c6
>> - 
>> https://crt.sh/?sha256=f1f072c64d69e573725533e83a601bb8b068f6699e59ba70eda2aecb28e06bfb
> 
> crt.sh seems to be unavailable / lagged at the moment, but before it went 
> down, I queried several of these.  MOST of those I queried seemed to be 
> self-issued / self-signed roots that I'm not sure are in the broader trust 
> stores directly.

Yes, they are self-signed, however they share a SPKI/Subject with one or more 
other certificates which make it possible to build paths to roots trusted by 
Mozilla.

Censys has a great visualization of this:

- 
https://censys.io/certificates/f01c1aca392882af152e9f01ecccd0afddd8aa35bf895b003198b1e8c752ddb8/validation
- 
https://censys.io/certificates/29d8ac29f9007a6ad7923fdade32ef814ba3c6751551cf765416e8dbd8ff7619/validation
- 
https://censys.io/certificates/c02739e63880368967bb27fedf0a5749aeaf62a2328c09a7a33e876b4f27adca/validation
- 
https://censys.io/certificates/c02739e63880368967bb27fedf0a5749aeaf62a2328c09a7a33e876b4f27adca/validation
- 
https://censys.io/certificates/b82210cde9ddea0e14be29af647e4b32f96ed2a9ef1aa5baa9cc64b38b6c01ca/validation
- 
https://censys.io/certificates/8e8c6ebf77dc73db3e38e93f4803e62b6b5933beb51ee4152f68d7aa14426b31/validation
- 
https://censys.io/certificates/1bc400808ab07b775c811c631d75ab38fe7be7df6967f5b384bfe8dc9ef807c6/validation

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

Re: New undisclosed intermediates

[Matthew Hardeman via dev-security-policy]

On Wednesday, June 7, 2017 at 6:45:25 PM UTC-5, Jonathan Rudenberg wrote:

> Yet another batch of undisclosed intermediates has shown up in CT:
> 
> - 
> https://crt.sh/?sha256=f01c1aca392882af152e9f01ecccd0afddd8aa35bf895b003198b1e8c752ddb8
> - 
> https://crt.sh/?sha256=29d8ac29f9007a6ad7923fdade32ef814ba3c6751551cf765416e8dbd8ff7619
> - 
> https://crt.sh/?sha256=c02739e63880368967bb27fedf0a5749aeaf62a2328c09a7a33e876b4f27adca
> - 
> https://crt.sh/?sha256=b82210cde9ddea0e14be29af647e4b32f96ed2a9ef1aa5baa9cc64b38b6c01ca
> - 
> https://crt.sh/?sha256=8e8c6ebf77dc73db3e38e93f4803e62b6b5933beb51ee4152f68d7aa14426b31
> - 
> https://crt.sh/?sha256=48db8801874e0e36b1b864603b31648b74e2322a8f9e4967a8f54bd1b8f594de
> - 
> https://crt.sh/?sha256=1bc400808ab07b775c811c631d75ab38fe7be7df6967f5b384bfe8dc9ef807c6
> - 
> https://crt.sh/?sha256=f1f072c64d69e573725533e83a601bb8b068f6699e59ba70eda2aecb28e06bfb

crt.sh seems to be unavailable / lagged at the moment, but before it went down, 
I queried several of these.  MOST of those I queried seemed to be self-issued / 
self-signed roots that I'm not sure are in the broader trust stores directly.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: New undisclosed intermediates

[Jonathan Rudenberg via dev-security-policy]

> On Jun 5, 2017, at 09:29, Alex Gaynor via dev-security-policy 
>  wrote:
> 
> Happy Monday!
> 
> Another week, another set of intermediate certs that have shown up in CT
> without having been properly disclosed:
> https://crt.sh/mozilla-disclosures#undisclosed

Yet another batch of undisclosed intermediates has shown up in CT:

- 
https://crt.sh/?sha256=f01c1aca392882af152e9f01ecccd0afddd8aa35bf895b003198b1e8c752ddb8
- 
https://crt.sh/?sha256=29d8ac29f9007a6ad7923fdade32ef814ba3c6751551cf765416e8dbd8ff7619
- 
https://crt.sh/?sha256=c02739e63880368967bb27fedf0a5749aeaf62a2328c09a7a33e876b4f27adca
- 
https://crt.sh/?sha256=b82210cde9ddea0e14be29af647e4b32f96ed2a9ef1aa5baa9cc64b38b6c01ca
- 
https://crt.sh/?sha256=8e8c6ebf77dc73db3e38e93f4803e62b6b5933beb51ee4152f68d7aa14426b31
- 
https://crt.sh/?sha256=48db8801874e0e36b1b864603b31648b74e2322a8f9e4967a8f54bd1b8f594de
- 
https://crt.sh/?sha256=1bc400808ab07b775c811c631d75ab38fe7be7df6967f5b384bfe8dc9ef807c6
- 
https://crt.sh/?sha256=f1f072c64d69e573725533e83a601bb8b068f6699e59ba70eda2aecb28e06bfb
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: New undisclosed intermediates

[Matthew Hardeman via dev-security-policy]

On Tuesday, June 6, 2017 at 4:14:00 AM UTC-5, Gervase Markham wrote:
> On 05/06/17 14:29, Alex Gaynor wrote:
> > As I've expressed before, I find it baffling that this still happens.
> 
> I am also disappointed. I have half a mind to keep track of how often
> this happens per CA, and impose a mandatory delay of 1 month per
> incident to that CA's next attempt to include a new root or get a trust
> bit or EV change in our store. :-)

I've wondered for quite some time why these circumstances aren't regarded as 
equivalent to mis-issuance?

I recognize that they likely are not mis-issuance of a certificate in any 
traditional sense.  Likely these are all intended and meant to be issued and 
proper validation and cause for the issuance can be shown.

However...  Isn't the point of the CCADB to document these SubCAs, track 
audits, and build up the whole trust framework and provide rational, documented 
support for confidence in the ability to trust certificates issued descendant 
of these CAs?

If so, allowing issuance of a SubCA without requiring disclosure provides 
opportunities for these CAs to facilitate improper certificate issuance without 
necessarily suffering the full consequence.  It also deprives the public of the 
opportunity to critically examine these "hidden" parts of the trust 
infrastructure.

On that basis, it would seem that "concealing" a SubCA for a significant period 
of time has the consequence of benefiting the Root CA program participant 
without a corresponding "time to pay the piper" when the SubCA is discovered.

Why not adjust the program requirements such that:

If we are exposed to a SubCA chaining to an included root via any mechanism 
other than the included program participant directly disclosing said SubCA to 
us, having not previously had this SubCA properly disclosed to us, this will be 
regarded as a serious security incident which may require remediation.  (In 
other words, the program will just assume that in the absence of a prior 
disclosure, the disclosure, when/if it would come, says that an external SubCA 
without constraints of any sort was issued without any audits to your least 
favorite authoritarian regime.)

I think if any CA publicly said that this would be a substantive burden upon 
them that said CA should probably be subject to far greater scrutiny, as that 
would be evidence of poor procedural or organizational structure.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

RE: New undisclosed intermediates

[Inigo Barreira via dev-security-policy]

Hello all,

I also did it but it´s not reflected.
In my case was also my fault because I was disclosing a different one.

Best regards

Iñigo Barreira
CEO
StartCom CA Limited

-Original Message-
From: dev-security-policy
[mailto:dev-security-policy-bounces+inigo=startcomca@lists.mozilla.org]
On Behalf Of Stephen Davidson via dev-security-policy
Sent: martes, 6 de junio de 2017 15:59
To: Alex Gaynor <agay...@mozilla.com>; MozPol
<mozilla-dev-security-pol...@lists.mozilla.org>
Subject: RE: New undisclosed intermediates

Hello:

I acknowledge that QuoVadis Grid ICA2 was missing from the CCADB.  The
omission was human error (my own) when entering a group of issuing CAs into
SalesForce.  Ongoing, when new ICAs are created, the CCADB disclosure is
part of our process.

For the sake of clarity, that ICA is disclosed in our Repository and
included in our WebTrust audit reports.

Regards, Stephen
QuoVadis


-Original Message-
From: dev-security-policy
[mailto:dev-security-policy-bounces+s.davidson=quovadisglobal@lists.mozi
lla.org] On Behalf Of Alex Gaynor via dev-security-policy
Sent: Monday, June 5, 2017 10:30 AM
To: MozPol <mozilla-dev-security-pol...@lists.mozilla.org>
Subject: New undisclosed intermediates

Happy Monday!

Another week, another set of intermediate certs that have shown up in CT
without having been properly disclosed:
https://crt.sh/mozilla-disclosures#undisclosed

There are four intermediates here, and with exception of the StartCom one,
they were all issued more than a year ago.

As I've expressed before, I find it baffling that this still happens. To
approach this more productively, I'd be very appreciative if someone from a
CA could describe how they approach disclosing intermediates, where it fits
into their process, how they track progress, etc.

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



smime.p7s
Description: S/MIME cryptographic signature
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

RE: New undisclosed intermediates

[Stephen Davidson via dev-security-policy]

Hello:

I acknowledge that QuoVadis Grid ICA2 was missing from the CCADB.  The
omission was human error (my own) when entering a group of issuing CAs into
SalesForce.  Ongoing, when new ICAs are created, the CCADB disclosure is
part of our process.

For the sake of clarity, that ICA is disclosed in our Repository and
included in our WebTrust audit reports.

Regards, Stephen
QuoVadis


-Original Message-
From: dev-security-policy
[mailto:dev-security-policy-bounces+s.davidson=quovadisglobal@lists.mozi
lla.org] On Behalf Of Alex Gaynor via dev-security-policy
Sent: Monday, June 5, 2017 10:30 AM
To: MozPol <mozilla-dev-security-pol...@lists.mozilla.org>
Subject: New undisclosed intermediates

Happy Monday!

Another week, another set of intermediate certs that have shown up in CT
without having been properly disclosed:
https://crt.sh/mozilla-disclosures#undisclosed

There are four intermediates here, and with exception of the StartCom one,
they were all issued more than a year ago.

As I've expressed before, I find it baffling that this still happens. To
approach this more productively, I'd be very appreciative if someone from a
CA could describe how they approach disclosing intermediates, where it fits
into their process, how they track progress, etc.

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



smime.p7s
Description: S/MIME cryptographic signature
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: New undisclosed intermediates

[Rob Stradling via dev-security-policy]

On 06/06/17 14:22, Alex Gaynor via dev-security-policy wrote:

On Tue, Jun 6, 2017 at 9:05 AM, Ryan Sleevi via dev-security-policy <



Alex, do you have the specific list of CAs at the time of your posting?



Yes, it was:

* QuoVadis
* AC Camerfirma, S.A.
* Chunghwa Telecom Corporation
* Start Commercial (StartCom) Ltd.

QuoVadis disclosed their intermediate within a few hours of my email, the
others still have not.


"QuoVadis Grid ICA G2"
https://crt.sh/?q=74CE8C1631EF9F38E7A4197DA3F5474DBC34F001F2967C25B5999562BCC8C9D4

First seen by Censys just over a month ago:
https://censys.io/certificates/74ce8c1631ef9f38e7a4197da3f5474dbc34f001f2967c25b5999562bcc8c9d4

--
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online

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

Re: New undisclosed intermediates

[Alex Gaynor via dev-security-policy]

On Tue, Jun 6, 2017 at 9:05 AM, Ryan Sleevi via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> On Tue, Jun 6, 2017 at 5:13 AM, Gervase Markham via dev-security-policy <
> dev-security-policy@lists.mozilla.org> wrote:
>
> > On 05/06/17 14:29, Alex Gaynor wrote:
> > > As I've expressed before, I find it baffling that this still happens.
> >
> > I am also disappointed. I have half a mind to keep track of how often
> > this happens per CA, and impose a mandatory delay of 1 month per
> > incident to that CA's next attempt to include a new root or get a trust
> > bit or EV change in our store. :-)
> >
>
> A potential downside to that is that it favors incumbents, who often can
> continue to utilize existing root certificates, while new entrants would
> face a barrier to entry.
>
> That said, it absolutely should be getting tracked, per CA, as incident
> reports in Bugzilla and provided to the community.
>
> Alex, do you have the specific list of CAs at the time of your posting?
>
>
Yes, it was:

* QuoVadis
* AC Camerfirma, S.A.
* Chunghwa Telecom Corporation
* Start Commercial (StartCom) Ltd.

QuoVadis disclosed their intermediate within a few hours of my email, the
others still have not.


>
> > Aside from taking a note of how often this happens and it perhaps
> > appearing in a future CA investigation as part of evidence of
> > incompetence, does anyone else have ideas about how we can further
> > incentivise CA compliance with a requirement which was promulgated some
> > time ago, for which all the deadlines have passed, and which should be a
> > simple matter of paperwork?
> >
>
> Short of disabling trust bits on a 'go forward' basis (e.g. no new issuance
> after date X), most of the ideas favor existing legacy CAs at the expense
> of newer CAs.
>
> This is why I suggested the broader proposal of only adding root CAs with a
> defined 'shutdown' period (e.g. after 3-5 years), and requiring the
> frequent rotation of included root certificates. This ensures that the
> ability to distrust certificates on a go-forward basis is built into the
> ecosystem as the steady state, such that non-compliance, stalling tactics,
> incomplete disclosures, incomplete remediations, lack of addressing
> community questions and feedback, etc can all be appropriately addressed as
> the default state, with the only CAs continuing participation being those
> that are active and engaged with the community and the issues.
> ___
> dev-security-policy mailing list
> dev-security-policy@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy
>

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

Re: New undisclosed intermediates

[Ryan Sleevi via dev-security-policy]

On Tue, Jun 6, 2017 at 5:13 AM, Gervase Markham via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> On 05/06/17 14:29, Alex Gaynor wrote:
> > As I've expressed before, I find it baffling that this still happens.
>
> I am also disappointed. I have half a mind to keep track of how often
> this happens per CA, and impose a mandatory delay of 1 month per
> incident to that CA's next attempt to include a new root or get a trust
> bit or EV change in our store. :-)
>

A potential downside to that is that it favors incumbents, who often can
continue to utilize existing root certificates, while new entrants would
face a barrier to entry.

That said, it absolutely should be getting tracked, per CA, as incident
reports in Bugzilla and provided to the community.

Alex, do you have the specific list of CAs at the time of your posting?


> Aside from taking a note of how often this happens and it perhaps
> appearing in a future CA investigation as part of evidence of
> incompetence, does anyone else have ideas about how we can further
> incentivise CA compliance with a requirement which was promulgated some
> time ago, for which all the deadlines have passed, and which should be a
> simple matter of paperwork?
>

Short of disabling trust bits on a 'go forward' basis (e.g. no new issuance
after date X), most of the ideas favor existing legacy CAs at the expense
of newer CAs.

This is why I suggested the broader proposal of only adding root CAs with a
defined 'shutdown' period (e.g. after 3-5 years), and requiring the
frequent rotation of included root certificates. This ensures that the
ability to distrust certificates on a go-forward basis is built into the
ecosystem as the steady state, such that non-compliance, stalling tactics,
incomplete disclosures, incomplete remediations, lack of addressing
community questions and feedback, etc can all be appropriately addressed as
the default state, with the only CAs continuing participation being those
that are active and engaged with the community and the issues.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: New undisclosed intermediates

[Matt Palmer via dev-security-policy]

On Tue, Jun 06, 2017 at 10:13:20AM +0100, Gervase Markham via 
dev-security-policy wrote:
> Aside from taking a note of how often this happens and it perhaps
> appearing in a future CA investigation as part of evidence of
> incompetence, does anyone else have ideas about how we can further
> incentivise CA compliance with a requirement which was promulgated some
> time ago, for which all the deadlines have passed, and which should be a
> simple matter of paperwork?

"If we find 'em, rather than you telling us about them, they go in OneCRL
as soon as we come across them"?  It'll upset a few site operators because their
sites won't work, and the CA will have to work to fix, but hopefully not
enough certs will be issued before the intermediate surfaces to cause
sufficiently widespread pain.

Alternately, flag roots that have had submarine intermediates surface
before, and switch them to an intermediates whitelist approach.  That'll
cause some degree of pain and suffering for those CAs that can't manage to
remember to tell the CCADB when they issue, by delaying the utility of any
future intermediates until some time after they've finally got around to
submitting them (when the whitelist gets updated, whether that's via a new
release or otherwise).

- Matt

-- 
aren't they getting rarer than amigas now?  just without all that fuzzy
"good times" nostalgia?
-- Ron Lee, in #debian-devel, on Itanic

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

Re: New undisclosed intermediates

[Gervase Markham via dev-security-policy]

On 05/06/17 14:29, Alex Gaynor wrote:
> As I've expressed before, I find it baffling that this still happens.

I am also disappointed. I have half a mind to keep track of how often
this happens per CA, and impose a mandatory delay of 1 month per
incident to that CA's next attempt to include a new root or get a trust
bit or EV change in our store. :-)

Aside from taking a note of how often this happens and it perhaps
appearing in a future CA investigation as part of evidence of
incompetence, does anyone else have ideas about how we can further
incentivise CA compliance with a requirement which was promulgated some
time ago, for which all the deadlines have passed, and which should be a
simple matter of paperwork?

> To
> approach this more productively, I'd be very appreciative if someone from a
> CA could describe how they approach disclosing intermediates, where it fits
> into their process, how they track progress, etc.

Well, I suspect the processes are different per-CA, and if you get such
an explanation, it'll be from a CA which doesn't make this sort of
mistake :-)

Also, different CAs have different PKI complexities. While the deadline
we imposed on them for getting things in order has passed, I would be a
bit less grumpy about DigiCert discovering a 'new' old intermediate in
their Verizon-inherited mess that they didn't know about before, than if
some small CA with a simple PKI doesn't disclose one they issued a
couple of months ago.

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

New undisclosed intermediates

[Alex Gaynor via dev-security-policy]

Happy Monday!

Another week, another set of intermediate certs that have shown up in CT
without having been properly disclosed:
https://crt.sh/mozilla-disclosures#undisclosed

There are four intermediates here, and with exception of the StartCom one,
they were all issued more than a year ago.

As I've expressed before, I find it baffling that this still happens. To
approach this more productively, I'd be very appreciative if someone from a
CA could describe how they approach disclosing intermediates, where it fits
into their process, how they track progress, etc.

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