Adds an EKU based X.509 certificate extension

[tplooker]

Closes #234
Closes #235

[c2bo]

superseded by #248

I made comments in that PR

[paulbastian]

Close in favor of #248 (change included there)

[Denisthemalice]

Instead of using the Key Usage extension (Section 4.2.1. from RFC 5280) as initially proposed,
it has been noticed that the current proposal is to use the Extended Key Usage Extension (Section 4.2.1.12 from RFC 5280).

Section 4.2.1.12 (Extended Key Usage Extension) from RFC 5280 states:

This extension indicates one or more purposes for which the certified public key may be used, in addition to or in place of the basic purposes indicated in the key usage extension. In general, this extension will appear only in end entity certificates.

As the text states, this extension will not appear in a CA certificate. This means that the public key can be used for verifying Status List Tokens, but not for verifying end entity certificates. This is a better choice as it is more secure: the key from the CA and the key from the Status Issuer will be different.

Section 2.6 (OCSP Signature Authority Delegation) from RFC 6960 states:

A certificate's issuer explicitly delegates OCSP signing authority by issuing a certificate containing a unique value for the extended key usage extension (defined in [RFC5280], Section 4.2.1.12).

The new text states:

10. X.509 Certificate Extensions

10.1. Extended Key Usage Extension

[RFC5280] specifies the Extended Key Usage (EKU) X.509 certificate extension for use on end entity certificates. The extension indicates one or more purposes for which the certified public key is valid. The EKU extension can be used in conjunction with the Key Usage (KU) extension, which indicates the set of basic cryptographic operations for which the certified key may be used.

The following OID is defined for usage in the EKU extension``` id-kp OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) 3 } id-kp-oauthStatusListSigning OBJECT IDENTIFIER ::= { id-kp TBD }

The text is not sufficiently descriptive. It is proposed to use the following text instead:

10. X.509 Certificate Extensions

10.1. Extended Key Usage Extension

[RFC5280] specifies the Extended Key Usage (EKU) X.509 certificate extension for use on end entity certificates. A certificate's issuer explicitly delegates Status List Token signing authority by issuing a certificate containing a unique value for the extended key usage extension (originally defined in [RFC5280], Section 4.2.1.12).

The following additional key usage purpose is defined under the id-kp OBJECT IDENTIFIER ::= { id-pkix 3 } defined in RFC5280:

id-kp-StatusListTokenSigning OBJECT IDENTIFIER ::= { id-kp 10 }
-- The StatusListSigning OID is used when the subject public key can be used
-- for verifying Status List Tokens.

Let us now take a look, at section 9 (IANA Considerations) from RFC 5280. It states:

Extensions in certificates and CRLs are identified using object
identifiers. The objects are defined in an arc delegated by IANA to
the PKIX Working Group. No further action by IANA is necessary for
this document or any anticipated updates.

However, the OAuth WG is not the PKIX WG. If another WG would pick { id-kp 10 } for another purpose, there would be a collision.

This means that a sub-section should be added into section 14 (IANA Considerations).