On 31/05/2017 18:04, Gervase Markham wrote:
It has been suggested we need a formal definition of what we consider
mis-issuance. The closest we have is currently a couple of sentence in
section 7.3:
"A certificate that includes domain names that have not been verified
according to section 3.2.2.4 of the Baseline Requirements is considered
to be mis-issued. A certificate that is intended to be used only as an
end entity certificate but includes a keyUsage extension with values
keyCertSign and/or cRLSign or a basicConstraints extension with the cA
field set to true is considered to be mis-issued."
This is clearly not an exhaustive list; one would also want to include
BR violations, RFC violations, and insufficient EV vetting, at least.
The downside of defining it is that CAs might try and rules-lawyer us in
a particular situation.
Here's some proposed text which provides more clarity while hopefully
avoiding rules-lawyering:
"The category of mis-issued certificates includes (but is not limited
to) those issued to someone who should not have received them, those
containing information which was not properly validated, those having
incorrect technical constraints, and those using algorithms other than
those permitted."
How about: Any issued certificate which violates any applicable policy,
requirement or standard, which was not requested by all its alleged
subject(s) or which should otherwise not have been issued, is by
definition mis-issued. Policies and requirements include but are not
limited to this policy, the CCADB policy, the applicable CPS, and the
baseline requirements. Any piece of data which technically resembles an
X.509 or PKCS#6 extended certificate, and which is signed by the CA
private key is considered an issued certificate.
(Note: I mention the ancient PKCS#6 certificate type because mis-issuing
those is still mis-issuance, even if there is no current reason to
validly issue those).
(Note: The last sentence above was phrased to try to cover semi-garbled
certificates, without accidentally banning things like CRLs and OCSP
responses).
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
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy
