Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add option to whitelist KeyUsage/ExtendedKeyUsage #385

Open
predakanga opened this issue Oct 11, 2015 · 2 comments
Open

Add option to whitelist KeyUsage/ExtendedKeyUsage #385

predakanga opened this issue Oct 11, 2015 · 2 comments

Comments

@predakanga
Copy link

In integrating CFSSL with Netflix's Lemur project, I've hit a snag which could be solved by extending the CSRWhitelist mechanism to the KeyUsage and/or ExtendedKeyUsage fields.

I have a working proof-of-concept, but wanted to check whether this is the sort of thing that would be accepted upstream.

If it would be, there are a number of implementation questions that should be answered first, such as:

  • Should validateProfile ignore empty usages even when KUs are not whitelisted?
  • How should usages interact in a profile with KUs whitelisted - should it merge, mask, be ignored, or should they be mutually exclusive?
  • Should this support the "Extensions" field on a CSR, as well as the "Requested Extensions" field?
@grittygrease
Copy link
Contributor

First of all, thanks for your interest in this project. We currently do not copy the extensions from the CSR in CFSSL. Adding the ability for the requestor to select KU and EKU for the certificate via the API makes sense, but we need to make sure we maintain backwards compatibility.

I think this type of proposal would be accepted:

  • If the profile does not contain a whitelist, then the current behavior stays: all certificates get the KU and EKUs defined in the profile under "usages"
  • If the profile does contain a whitelist, then:
    • The profile usages becomes the maximal set of possible KU and EKU that can be created in the certificate. The set of usages set to "true" in the whitelist should be a subset of these usages.
    • All "Requested Extensions" from the CSR that satisfy the whitelist are added to the the certificate.
    • Allow usage-boolean pairs in the API request. Require the usages in the request to be a subset of the usages from the profile. Override the usages set above from the CSR with the usages from the request (remove those set to false, add those set to true).

Thoughts?

pboguslawski added a commit to ibpl/cfssl that referenced this issue Oct 15, 2019
This mod allowes one to define custom EKUs as OIDs in
Usages. It also allows one to copy EKUs from CSR using
CSRWhitelist (only EKUs present in profiles Usages may
be copied).

Related: cloudflare#385
Author-Change-Id: IB#1094896
@darkedges
Copy link
Contributor

I have created something similar with #1082

Currently not a whitelist, but can be easily added. If interested will try and do it this week.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants