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: Policy 2.5 Proposal: Make it clear that Mozilla policy has wider scope than the BRs

[Gervase Markham via dev-security-policy]

On 08/06/17 19:46, Jakob Bohm wrote:
> How about the following, which seems more correct

Yes; I'm not sure why David thought the original version's two sentences
were contradicting rach other.

> Insofar as the Baseline Requirements attempt to define their own scope,
> the scope of this policy (section 1.1) overrides that. Mozilla
> thus requires CA operations relating to issuance of all SSL certificates
> in the scope of this policy to conform to the Baseline Requirements.

This is marginally better; wording updated :-)

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