New section to define the sLTSign bit of a key usage extension in a PKC

[Denisthemalice]

It is proposed to add a new section 9.

Status List Token signature bit of a key usage extension in a PKC (sLTSign)

The key usage extension of a PKC (Public Key Certificate) defines the purpose of the public key contained in the PKC In RFC 5280, section 4.2.1.3, the text states that "conforming CAs MUST include this extension in certificates that contain public keys that are used to validate digital signatures or other public key certificates or CRLs. When present, conforming CAs SHOULD mark this extension as critical". At the time RFC 5280 was written and published (2008), the concept of a Status Issuer did not existed.

This document states that conforming CAs MUST include this extension in certificates that contain public keys that are used to validate digital signatures or other public key certificates, CRLs or Status List Tokens. When present, conforming CAs SHOULD mark this extension as critical.

In RFC 5280, the following Object Identifier has been defined:
{joint-iso-itu-t(2) ds(5) certificateExtension(29) keyUsage(15)}. OID dot notation: 2.5.29.15

    id-ce-keyUsage OBJECT IDENTIFIER ::=  { id-ce 15 }
     KeyUsage ::= BIT STRING {
          digitalSignature        (0),
          nonRepudiation          (1), -- recent editions of X.509 have
                               -- renamed this bit to contentCommitment
          keyEncipherment         (2),
          dataEncipherment        (3),
          keyAgreement            (4),
          keyCertSign             (5),
          cRLSign                 (6),
          encipherOnly            (7),
          decipherOnly            (8) }

In order to allow an Issuer to designate a Status Issuer, an additional bit in the key usage extension is needed. The next usable bit is (9).

The following line is happened to this list:

       sLTSign                 (9)

with the following meaning:

The sLTSign bit is asserted when the subject public key can be used for verifying signatures on Status List Tokens.

The id-ce-keyUsage OBJECT IDENTIFIER ::= { id-ce 15 } then becomes:

    id-ce-keyUsage OBJECT IDENTIFIER ::=  { id-ce 15 }
     KeyUsage ::= BIT STRING {
          digitalSignature        (0),
          nonRepudiation          (1), -- recent editions of X.509 have
                               -- renamed this bit to contentCommitment
          keyEncipherment         (2),
          dataEncipherment        (3),
          keyAgreement            (4),
          keyCertSign             (5),
          cRLSign                 (6),
          encipherOnly            (7),
          decipherOnly            (8),
          sLTSign                 (9) }

Using the text previously proposed, a section 14.8 (Key Usage extension for Status issuer certificates) should be added into section 14 (IANA Considerations).

[paulbastian]

Editors Call:

• if we were to define something, we would define extended key usage identifiers and define an OID for that
• continue to discuss

[tplooker]

I have opened #246 where we are proposing to define an a new OID for use with EKU X.509 certificate extension because the KU extension you propose is really only suppose to be used to define basic cryptographic operations that the subject public key should be used for.