Thanks Jakob, I think you summed things up well. -tom
On 27 July 2018 at 01:46, Jakob Bohm via dev-security-policy <[email protected]> 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. > > > 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 _______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
