On 08/02/2017 10:55, Gervase Markham wrote:
On 07/02/17 19:15, Jakob Bohm wrote:
Point 2 does not apply if the certificate is an OCSP signing certificate
manually issued directly from a root.
Should be point 1 (on OCSP signing certificate is an EE cert)
Nope, I'm fairly sure I mean point 2. Rules about intermediate certs
don't apply when there's no intermediate cert.
Ahh, missed the "issued directly from a root" part.
3) Any intermediate between the Mozilla trusted CA root and the issuing
intermidiate:
* Has an appropriate pathlen: constraint consistent with the pathlen to
all its EE issuing lower intermediate certs.
* Is used only for issuing lower intermediate certs, OCSP signing certs
and CRLs. The OCSP signing certs and CRLs being used exclusively for
revocation checking certs issued by the intermediate itself.
Please provide rationale for your suggested changes.
A weaker variation of point 2 for intermediaries between the root and
the EE issuing intermediaries. One beneficial use could be to issue a
single higher level intermediary which will then be the parent of
most/all subsequently issued SHA-1 intermediaries, thus reducing the
exposure of the root key to SHA-1. I seem to recall that the OCSP and
CRL technical standards genereally require/assume that the second
bullet will be true anyway, though there may be obscure ways to issue
revocation information via a grandparent CA certificate.
CAs may only sign SHA-1 hashes over intermediate certificates which
chain up to roots in Mozilla's program if the certificate to be signed
is a duplicate of an existing SHA-1 intermediate certificate with the
only changes being all of:
* a new key (of the same size);
or larger
* a new serial number (of the same length);
or longer
No; identical. The logic is that allowing length changes makes it more
possible for someone to construct a collision.
My logic is that adding additional entropy to a serial number whose
length is fully controlled by CA procedures can increase the
mitigations against SHA-1 weaknesses. For example if the existing CA
setup uses all bits of the old serial number length for non-random
values, then the required 64 random bits can simply be appended or
prepended.
None of the above applies to root certificates voluntarily
withdrawn from the Mozilla root program.
This is implied everywhere.
But is worth reminding about in this case. Also the phrasing was meant
to indicate that they do not have to wait indefinitely for Mozilla to
roll out the withdrawal to all clients.
Root certificates previously withdrawn for this purpose are encouraged
to report this fact to Mozilla by ???? and to maintain valid entries in
the CCADB for such roots, all for the benefit of organizations that
maintain or service software that are or interoperate with such older
software.
This would be a different matter, and one for the CCADB policy. We would
need to have a very good reason for requiring CAs to keep information in
the CCADB which did not relate to our root program.
Note that I wrote "encouraged" not "required". As in it would be nice
if they did, and potentially beneficial to the CA as a way of telling
maintainers of trust stores for such legacy systems to please not
remove such CA root certs just because the are no longer in the Mozilla
root program.
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
[email protected]
https://lists.mozilla.org/listinfo/dev-security-policy
