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

Certificate Transparency requirements connected to Google's CT Qualification

    Details

    • Type: Epic
    • Status: Closed
    • Priority: Critical
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: None
    • Component/s: None
    • Labels:
      None
    • Epic Name:
      Certificate Transparency requirements connected to Google's CT Qualification

      Description

      The new CT requirements are as follows:

      1. An SCT from a log qualified at the time of check is presented via the TLS extension OR is embedded within a 
      stapled OCSP response;
      AND there is at least one SCT from a Google Log, qualified at the time of check, presented via any method;
      AND there is at least one SCT from a non­Google Log, qualified at time of check, presented via any method.
      
      2. An Embedded SCT from a log qualified at the time of check is presented;
      AND there is at least one Embedded SCT from a Google Log, once or currently qualified; AND there is at least 
      one Embedded SCT from a non­Google Log, once or currently qualified;
      AND there are Embedded SCTs from AT LEAST the number of logs once or currently qualified shown in Table 1.
      

      We currently fulfill this criteria in the slightest sense. It's possible to mark a log as "mandatory", and in the Certificate Profile demand a span of min-max logs to be written to in the mandatory/non-mandatory categories. While this works, it means that:

      • All CPs must share a concept of which these two categories are
      • Since "mandatory" is the same is Google, it lobs all other logs into the same category. This might not be desirable for a CA hosting multiple different customers.
      • The concept of writing to a mandatory non-mandatory log is contradictory.

      We should instead:

      • Introduce a labeling system in System Configuration (which would in essence be Google/non-Google) which gives a bit more freedom. Each log should belong to one label and one label only. It should be possible to rename labels. It would be best avoided if possible to save labels as their own objects. (ECA-6303, ECA-6304, ECA-6305, ECA-6307)
      • In each Certificate Profile, we should add labels instead of individual logs, where at least one log line will be written to a log from each label. We should also specify a max and a min (see below for a variation on the theme). (ECA-6309)

      Additionally, the standard gives the following table for minimum number of logs to be written to:

      Lifetime of certificate Number of SCTs from distinct logs
      <15 months 2
      >= 15, <= 27 months 3
      > 27, <= 39 months 4
      > 39 months 5
      Note that, so long as one of the above conditions is met by some combination of SCTs presented in the 
      handshake, additional SCTs, regardless of the status of the SCT, will not affect the CT Qualification status 
      positively or negatively
      

      This means that the current min-value is dated, but should rather be set during issuance time based on the above table which should be configurable in System Configuration, as it can be presumed to be global. If the max value happens to be less than the derived min-value, then that exact number of logs should be written to. If the max value is blank, then the min-value is exact.

      We should instead:

      • Make the above table configurable in System Configuration, with the above values as default. (ECA-6310)
      • Source these values at issuance time according to the above description.

        Attachments

          Issue Links

            Activity

              People

              Assignee:
              mikek Mike Agrenius Kushner
              Reporter:
              mikek Mike Agrenius Kushner
              Votes:
              0 Vote for this issue
              Watchers:
              3 Start watching this issue

                Dates

                Created:
                Updated:
                Resolved: