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.
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
