I agree. I've actually thought about adding definitions of categories of misissuance to the BRs before. Some of the requirements like revocation are really hard to write and understand if you don't first categorize all the misissuance use cases, many of which are very, very different. And just when I think I have a reasonable ontology of them in my head ... someone usually goes and invents a new one.
Despite how much people like to talk about it, misissuance isn't a defined term anywhere, AFAIK. It can lead to a lot confusing discussions, even among experts at the CA/Browser Forum. -Tim > -----Original Message----- > From: dev-security-policy <dev-security-policy- > bounces+tim.hollebeek=digicert....@lists.mozilla.org> On Behalf Of Jakob > Bohm via dev-security-policy > Sent: Friday, July 27, 2018 2:46 AM > To: mozilla-dev-security-pol...@lists.mozilla.org > Subject: Re: Possible violation of CAA by nazwa.pl > > On 26/07/2018 23:04, Matthew Hardeman wrote: > > On Thu, Jul 26, 2018 at 2:23 PM, Tom Delmas via dev-security-policy < > > dev-security-policy@lists.mozilla.org> 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://clicktime.symantec.com/a/1/IoXGhI-fe8kwNzM3g- > ij3FzWAbGFvMrNtD2R3BT4VXU=?d=7wLlWeFFMkVrq2bKotxDJwtyC74b57sB5 > 4x-MgkeSS_T0hgGR_NUsGfosSO-6VXNZNEApN- > 6cYoMqLiiYe3lGXMEJ9gzcEkJ3PsMPCg6umwu97ns0vPxoryh1m7GdjwdgbZcu > eX0M5fiPjh0_- > mO7Jnjt9ruhcNezF3pVz1DhkQCzcj0FYnQbKDfLAh43Gxt3OdSVb9TxbtDLbgKGJ > W3WyeGcVY4tMSClly4-6y7fwBjenlra16rb- > kI3L4t8J4BMAmK9JfLrXZ78LsAueqLB-Xg- > wzZUyThkRRctCgaJ1UoLwTRAlRJAwKyNYr51VSAr19zzejj40TKydAk6b2Uhc2yV > FvWZh77j2KE6QVqL788xrFfgAXuw2iMEOYVnXY1UiJtQj9lOOPmmcS9lQYg2uN > 5TPcKEyvqxY09C1C6-jhHC8NOucgr1V9Q- > 0whF7Ai1KwOSw%3D%3D&u=https%3A%2F%2Fwww.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://clicktime.symantec.com/a/1/ZvCXcGC_eekz0mymNP4JR8nwQjSjXnJW > 3IqfLUaizek=?d=7wLlWeFFMkVrq2bKotxDJwtyC74b57sB54x- > MgkeSS_T0hgGR_NUsGfosSO-6VXNZNEApN- > 6cYoMqLiiYe3lGXMEJ9gzcEkJ3PsMPCg6umwu97ns0vPxoryh1m7GdjwdgbZcu > eX0M5fiPjh0_- > mO7Jnjt9ruhcNezF3pVz1DhkQCzcj0FYnQbKDfLAh43Gxt3OdSVb9TxbtDLbgKGJ > W3WyeGcVY4tMSClly4-6y7fwBjenlra16rb- > kI3L4t8J4BMAmK9JfLrXZ78LsAueqLB-Xg- > wzZUyThkRRctCgaJ1UoLwTRAlRJAwKyNYr51VSAr19zzejj40TKydAk6b2Uhc2yV > FvWZh77j2KE6QVqL788xrFfgAXuw2iMEOYVnXY1UiJtQj9lOOPmmcS9lQYg2uN > 5TPcKEyvqxY09C1C6-jhHC8NOucgr1V9Q- > 0whF7Ai1KwOSw%3D%3D&u=https%3A%2F%2Flists.mozilla.org%2Flistinfo% > 2Fdev-security-policy
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
