Uploaded image for project: 'EJBCA'
  1. EJBCA
  2. ECA-7105

Add ability to make a custom dynamic extension optional


    • Epic Name:
      Optional Custom Extension


      Customer Requirements

      Customer has a new use case that requires new capability for adding custom extensions as well as the NameConstraint extension via the ejbca-ws API. Specifically in Custom Extensions the customer needs to be able to: 

      • specify custom extension OID and value via ejbca-ws API 
      • enable this on a per certificate type basis
      • configure a set of permitted custom extension OIDs or perhaps OID arcs (a regex comes to mind) 

      The number of total extensions are expected to be 1-5 per request.

      Proposed Solution

      We propose adding in two features, both of which pertaining to the management of Custom Certificate Extensions:

      1. Adding a checkbox to the configuration screen labeled “Required” or similar, the default value being true (which would be the same as current functionality). Unchecking “Required”  would allow a request to contain the defined extension, but not require it. (See mockup below)
      2. Adding a wildcard identifier to Certificate Extension OIDs (making a “partial OID”). This identifier would only allow OIDs to match numbers and punctuation marks in accordance with the RFC.

      During issuance, the following evaluation will be made:

      1. All extensions defined in the request are counted and defined (as they are today)
      2. Those CCEs marked as required are checked for first, with issuance being rejected if any of the required extensions are missing.
      3. Of the remaining unmatched OIDs in the request:
        1. Non-wildcard OIDs are matched first
        2. After that wild-card-containing OIDs
      4. This evaluation is made with the following constraints:
        1. An extension in the request must match the encoding type defined in the CCE. For this reason several non-required extensions with the same OID/partial OID may be defined
        2. Each non-required CCE may only be matched once. If several extensions are expected which match the same partial OID, then several CCEs must be defined and available.
        3. If the request contains more extensions than could be matched, then it is rejected.
        4. If the request contains any extensions that couldn’t be matched, then it is rejected.


          Issue Links



              Unassigned Unassigned
              mikek Mike Agrenius Kushner
              0 Vote for this issue
              3 Start watching this issue