On Thursday, June 1, 2017 at 8:03:33 AM UTC-5, Gervase Markham wrote: > > My point is not that we are entirely indifferent to such problems, but > that perhaps the category of "mis-issuance" is the wrong one for such > errors. I guess it depends what we mean by "mis-issuance" - which is the > entire point of this discussion! > > So, if mis-issuance means there is some sort of security problem, then > my original definition still seems like a good one to me. If > mis-issuance means any problem where the certificate is not as it should > be, then we need a wider definition. >
It was in that spirit that I raised the questions that I did. For example, when I mentioned "those containing information which was not properly validated", I meant to imply that in a rather tortured construction, taken ad absurdum, every bit and byte of that certificate is certainly "information" and the certificate overall most certainly contains every byte of itself. Having said that, can we literally say that a certificate is only properly issued if quite literally every byte within it has been "validated"? Or are we really just talking about the certificate subject? But not really because we also certainly mean that contents of certain certificate extensions, like SAN, contain only validated information. At the same time, though, what documentation would one draw upon to assert that serial number had been "validated"? Validated in this context generally means supported via documentation as true and correct. The serial number is meant to contain a random component. We can validate the mechanism that generated the serial numbe r, but we can not say that the serial number itself is validated. If a policy OID is added to the certificate, is it validated in the sense that my CP/CPS says that I may put OID X with meaning Y there? Or is it just a series of bytes which point to an OID within the OID tree assigned to my enterprise? I wonder if the pedant can use these arguments to call any certificate "mis-issued" under the proposed definition. If so, I wonder if we should care if such a tortured argument might be made. > I wonder whether we need a new word for certificates which are bogus for > a non-security-related reason. "Mis-constructed"? > _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
