On 08/05/2017 12:16, Gervase Markham wrote:
On 05/05/17 22:21, Jakob Bohm wrote:
The issue would be implementations that only check the EE cert for
their desired EKU (such as ServerAuth checking for a TLS client or
EmailProtection checking for a mail client).  In other words, relying
parties whose software would accept a chain such as

root CA (no EKUs) => SubCA (EmailProtection) => EE cert (ServerAuth).

Do you know of any such implementations?

I am not sure.  I suspect such simple implementations (that only check
for the specifically desired EKU in the EE cert) were common in the
past, and I don't know if all implementations have switched to the
interpretation that CA EKUs act as constraints on child EKUs.

This simple implementation kind would correspond to interpreting the
EKUs in a CA cert to describe the abilities of the CA cert itself (i.e.
it could reasonable list only CA related uses such as CertSign,
CRLSign, OCSPSign).  (Not checked for typos).


One other question: Does your proposal allow a TCSC that covers both
ServerAuth and EmailProtection for the domains of the same organization?

I don't believe my proposal forbids this. Do you think it should?


These questions were directed at Dimitris' wording.

Does Mozilla as a Browser implementer have any policy or technical
requirements on certificates that Mozilla products can use for
ClientAuth

No policy requirements to my knowledge. There may be technical
requirements (e.g. now we've turned off SHA-1 support, I doubt that
works with ClientAuth either).




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

Reply via email to