Thanks Jakob, I think you summed things up well.


On 27 July 2018 at 01:46, Jakob Bohm via dev-security-policy
<> 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 <
>>> 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.
> 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 mailing list

Reply via email to