You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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?
The text was updated successfully, but these errors were encountered:
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).
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
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:
The text was updated successfully, but these errors were encountered: