2018. december 6., csütörtök 23:31:42 UTC+1 időpontban Peter Gutmann a
következőt írta:
>
> So just to make sure I've got this right, implementations are needing to add
> dummy TLS EKUs to non-TLS certs in order for them to "work"? In that case why
> not add a signalling EKU or policy value, a bit like Microsoft's
> systemHealthLoophole EKU (I don't know what its official name is, 1 3 6 1 4 1
> 311 47 1 3) where the normal systemHealth key usage is meant to indicate
> compliance with a system or corporate security policy and the
> systemHealthLoophole key usage is for systems that don't comply with the
> policy but that need a systemHealth certificate anyway.
>
> In theory there's the anyExtendedKeyUsage that seems to do something like
> this:
>
> If a CA includes extended key usages to satisfy such applications,
> but does not wish to restrict usages of the key, the CA can include
> the special KeyPurposeId anyExtendedKeyUsage in addition to the
> particular key purposes required by the applications.
>
> but thats vague enough, and little-supported enough, that expecting existing
> implementations to handle it correctly out of the box seems pretty risky.
> Better to define a new EKU, "tlsCompabitility", telling the relying party that
> the TLS EKUs are present for compatibility purposes and can be ignored if it's
> a non-TLS use.
>
> Peter.
Absolutely agree.
The main reason to use EKU values is to define the targeted usage of the
certificate and the belonging keys. The EKU should be clear enough for the
software vendors to be able to select the proper certificate for their
application. The good separation and detailed requirement specification would
help the CAs to issue proper certificates.
If the present EKUs are not enough to fulfil this requirement a possible
solution can be to define further EKU values as you have proposed.
The alternative solution can be the way which was introduced by the European
regulation in the ETSI EN 319 412-5 which defines QCStatements for the
certificate profiles.
They are mandatory in the EU qualified certificates but can be used optionally
in other certificates too.
The existing proper QCStatement for the website authentication (TLS)
certificates is:
0.4.0.1862.1.6.3
id-etsi-qct-web OBJECT IDENTIFIER ::= { id-etsi-qcs-QcType 3 }
-- Certificate for website authentication as defined in Regulation (EU) No
910/2014
I have just asked the registration of this OID in the OID Repository at
oid-info.com
Sándor
_______________________________________________
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy
