On 27/07/2018 08:46, Jakob Bohm wrote:
On 26/07/2018 23:04, Matthew Hardeman wrote:
On Thu, Jul 26, 2018 at 2:23 PM, Tom Delmas via dev-security-policy <
[email protected]> wrote:
The party actually running the authoritative DNS servers is in control
of the domain.
I'm not sure I agree. They can control the domain, but they are supposed
to be subordinate of the domain owner. If they did something without the
owner consent/approval, it really looks like a domain hijacking.
But the agreement under which they're supposed to be subordinate to the
domain owner is a private matter between the domain owner and the party
managing the authoritative DNS. Even if this were domain hijacking, a
certificate issued that relied upon a proper domain validation method is
still proper issuance, technically. Once this comes to light, there
may be
grounds for the proper owner to get the certificate revoked, but the
initial issuance was proper as long as the validation was properly
performed.
I'm not suggesting that the CA did anything untoward in issuing this
certificate. I am not suggesting that at all.
My opinion is that if the CA was aware that the owner didn't ask/consent
to that issuance, If it's not a misissuance according to the BRs, it
should
be.
Others can weigh in, but I'm fairly certain that it is not misissuance
according to the BRs. Furthermore, with respect to issuance via domain
validation, there's an intentional focus on demonstrated control rather
than ownership, as ownership is a concept which can't really be securely
validated in an automated fashion. As such, I suspect it's unlikely that
the industry or browsers would accept such a change.
I see this as a clear case of the profound confusion caused by the
community sometimes conflating "formal rule violation" with
"misissuance".
It would be much more useful to keep these concepts separate but
overlapping:
- A BR/MozPolicy/CPS/CP violation is when a certificate didn't follow
the official rules in some way and must therefore be revoked as a matter
of compliance.
- An actual misissuance is when a certificate was issued for a private
key held by a party other than the party identified in the certificate
(in Subject Name, SAN etc.), or to a party specifically not authorized
to hold such a certificate regardless of the identity (typically applies
to SubCA, CRL-signing, OCSP-signing, timestamping or other certificate
types where relying party trust doesn't check the actual name in the
certificate).
From these concepts, revocation requirements could then be reasonably
classified according to the combinations (in addition to any specifics
of a situation):
- Rule violation plus actual misissuance. This is bad, the 24 hours or
faster revocation rule should definitely be invoked.
- Rule compliant misissuance. This will inevitably happen some times,
for example if an attacker successfully spoofs all the things checked by
a CA or exploits a loophole in the compliant procedures. This is the
reason why there must be an efficient revocation process for these
cases.
- Rule violation, but otherwise correct issuance. This covers any kind
of formal violation where the ground truth of the certified matter can
still be proven. Ranging from formatting errors (like having "-" in a
field that should just be omitted, putting the real name with spaces in
the common name as originally envisioned in X.509, encoding CA:False
etc.) over potentially dangerous errors (like having a 24 byte serial
number, which prevents some clients from checking revocation should it
ever become necessary) to directly dangerous errors (like having an
unverified DNS-syntax name in CN, or not including enough randomness in
the serial number of an SHA-1 certificate).
- Situation-changed no-longer valid issuance. This is when (as
recently discussed in a concrete case) a completely valid certificate
contains information which is no longer true due to later events, such
as a domain being sold without transfer of certificate private keys or a
certified entity (in OV/EV certs) ceasing to exist (company dissolved,
person dead and estate disbursed).
- Situation unchanged, but subject requests revocation. Also common.
As there has been some misunderstandings, let me clarify that the above
was posted to point out the following:
- Compliance with every policy in the world does not mean a certificate
was not misissued in a way that requires fast revocation. Arguing that
because policies were followed there was no misissuance is confused.
This was the mistake made in the post I responded to.
- The complete absence of misissuance and policy violations does not
imply that there are no reasons to revoke a certificate, perhaps
quickly.
- Not every formal policy violation should be considered egregious.
Over the years the polices regulating CAs have grown in number and
volume and tend to cover everything from rules to avoid very dangerous
practices to minutia of browser/client/protocol compatibility. It
makes perfect sense for the community to distinguish these, either
formally or on a case by case basis rather than blindly applying a
legalistic zero tolerance approach. I am specifically not suggesting
that CAs should be allowed to decide this on their own or proposing
how specific rules and cases should be classified, merely pointing out
that there are such differences.
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
[email protected]
https://lists.mozilla.org/listinfo/dev-security-policy
