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

Reply via email to