-
Notifications
You must be signed in to change notification settings - Fork 1.5k
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
X509 CustomPolicyBuilder
foundation.
#11559
base: main
Are you sure you want to change the base?
Changes from 3 commits
0b9082b
adc39ba
0852630
8ec4c19
66b8a6d
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -140,6 +140,7 @@ unencrypted | |
unicode | ||
unpadded | ||
unpadding | ||
validator | ||
Ventura | ||
verifier | ||
Verifier | ||
|
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -111,12 +111,22 @@ the root of trust: | |
|
||
.. versionadded:: 43.0.0 | ||
|
||
.. attribute:: subjects | ||
.. versionchanged:: 44.0.0 | ||
Renamed `subjects` to :attr:`sans`. | ||
Made `sans` optional, added :attr:`subject`. | ||
|
||
:type: list of :class:`~cryptography.x509.GeneralName` | ||
.. attribute:: subject | ||
|
||
:type: :class:`~cryptography.x509.Name` | ||
|
||
The subject presented in the verified client's certificate. | ||
|
||
.. attribute:: sans | ||
|
||
:type: list of :class:`~cryptography.x509.GeneralName` or None | ||
|
||
The subjects presented in the verified client's Subject Alternative Name | ||
extension. | ||
extension or `None` if the extension is not present. | ||
|
||
.. attribute:: chain | ||
|
||
|
@@ -129,6 +139,8 @@ the root of trust: | |
.. class:: ClientVerifier | ||
|
||
.. versionadded:: 43.0.0 | ||
.. versionchanged:: 44.0.0 | ||
Added :attr:`eku`. | ||
|
||
A ClientVerifier verifies client certificates. | ||
|
||
|
@@ -156,6 +168,18 @@ the root of trust: | |
:type: :class:`Store` | ||
|
||
The verifier's trust store. | ||
|
||
.. attribute:: eku | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I'd suggest pulling EKU handling out into its own PR, which can be reviewed on its own. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. The only thing this PR adds is the Just wanted to point that out. If you still want me to break it out, I'll do that of course. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Yeah if you wouldn't mind pulling it out that's an easy review that we can land entirely independently of the larger conversation and it makes future reviews of this PR easier. 😄 There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Done, I'll create the EKU PR once we are done with this one. |
||
|
||
:type: :class:`~cryptography.x509.ObjectIdentifier` or None | ||
|
||
The value of the Extended Key Usage extension required by this verifier | ||
If the verifier was built using :meth:`PolicyBuilder.build_client_verifier`, | ||
this will always be :attr:`~cryptography.x509.oid.ExtendedKeyUsageOID.CLIENT_AUTH`. | ||
|
||
:note: | ||
See :meth:`CustomPolicyBuilder.eku` documentation for how verification is affected | ||
when changing the required EKU or using a custom extension policy. | ||
|
||
.. method:: verify(leaf, intermediates) | ||
|
||
|
@@ -212,6 +236,18 @@ the root of trust: | |
|
||
The verifier's trust store. | ||
|
||
.. attribute:: eku | ||
|
||
:type: :class:`~cryptography.x509.ObjectIdentifier` | ||
|
||
The value of the Extended Key Usage extension required by this verifier | ||
If the verifier was built using :meth:`PolicyBuilder.build_server_verifier`, | ||
this will always be :attr:`~cryptography.x509.oid.ExtendedKeyUsageOID.SERVER_AUTH`. | ||
|
||
:note: | ||
See :meth:`CustomPolicyBuilder.eku` documentation for how verification is affected | ||
when changing the required EKU or using a custom extension policy. | ||
|
||
.. method:: verify(leaf, intermediates) | ||
|
||
Performs path validation on ``leaf``, returning a valid path | ||
|
@@ -294,3 +330,82 @@ the root of trust: | |
for server verification. | ||
|
||
:returns: An instance of :class:`ClientVerifier` | ||
|
||
.. class:: CustomPolicyBuilder | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Do we need a new There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Yeah, I also thought about that. That's definitely a possibility, but I prefer this version since it kind of follows the "make it hard to do insecure things" part of cryptography's philosophy. In this case it would be more like "make insecure things explicit", e.g. this would make using any of the "easier to get wrong" features more visible in a code review. The first paragraph from this comment of mine describes my motivation pretty well too. There's also a comment from @woodruffw where he describes why he prefers the In the end, I would be fine with both APIs, but I have grown to like the idea of a separate |
||
|
||
.. versionadded:: 44.0.0 | ||
|
||
A CustomPolicyBuilder provides a builder-style interface for constructing a | ||
Verifier, but provides additional control over the verification policy compared to :class:`PolicyBuilder`. | ||
|
||
.. method:: time(new_time) | ||
|
||
Sets the verifier's verification time. | ||
|
||
If not called explicitly, this is set to :meth:`datetime.datetime.now` | ||
when :meth:`build_server_verifier` or :meth:`build_client_verifier` | ||
is called. | ||
|
||
:param new_time: The :class:`datetime.datetime` to use in the verifier | ||
|
||
:returns: A new instance of :class:`PolicyBuilder` | ||
|
||
.. method:: store(new_store) | ||
|
||
Sets the verifier's trust store. | ||
|
||
:param new_store: The :class:`Store` to use in the verifier | ||
|
||
:returns: A new instance of :class:`PolicyBuilder` | ||
|
||
.. method:: max_chain_depth(new_max_chain_depth) | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Same for this, I think this could be in its own PR. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I am a bit surprised that you want this in it's own PR to be honest, since this functionality is already present on In any case, I'll wait for your reply for now. If you still want this in it's own PR, I would appreciate it if you could describe some of the motivation behind that, just so we are on the same page and I can scope the next PRs better. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Sorry, this was confusion by me -- I'd forgotten we had There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. The general motivation we have is to minimize the set of changes in all PRs so that we can focus heavily on the novel parts and iterate without the cognitive load of larger changes (where we need to ignore the things that don't matter). So yes, it may be a glorified copy-paste, but if it's uncontroversial we can then review/land it quickly and focus on the meatier bits 😄 There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I'm down to break this out as well, but getting mixed signals here, I will err on the side of leaving this in for now since other methods that are already on PolicyBuilder aren't getting their own PR. |
||
|
||
Sets the verifier's maximum chain building depth. | ||
|
||
This depth behaves tracks the length of the intermediate CA | ||
chain: a maximum depth of zero means that the leaf must be directly | ||
issued by a member of the store, a depth of one means no more than | ||
one intermediate CA, and so forth. Note that self-issued intermediates | ||
don't count against the chain depth, per RFC 5280. | ||
|
||
:param new_max_chain_depth: The maximum depth to allow in the verifier | ||
|
||
:returns: A new instance of :class:`PolicyBuilder` | ||
|
||
.. method:: eku(new_eku) | ||
|
||
Sets the Extended Key Usage required by the verifier's policy. | ||
|
||
If this method is not called, the EKU defaults to :attr:`~cryptography.x509.oid.ExtendedKeyUsageOID.SERVER_AUTH` | ||
if :meth:`build_server_verifier` is called, and :attr:`~cryptography.x509.oid.ExtendedKeyUsageOID.CLIENT_AUTH` if | ||
:meth:`build_client_verifier` is called. | ||
|
||
When using the default extension policies, only certificates | ||
with the Extended Key Usage extension containing the specified value | ||
will be accepted. To accept more than one EKU or any EKU, use an extension policy | ||
with a custom validator. The EKU set via this method is accessible to custom extension validator | ||
callbacks via the `policy` argument. | ||
|
||
:param ~cryptography.x509.ObjectIdentifier new_eku: | ||
|
||
:returns: A new instance of :class:`PolicyBuilder` | ||
|
||
.. method:: build_server_verifier(subject) | ||
|
||
Builds a verifier for verifying server certificates. | ||
|
||
:param subject: A :class:`Subject` to use in the verifier | ||
|
||
:returns: An instance of :class:`ServerVerifier` | ||
|
||
.. method:: build_client_verifier() | ||
|
||
Builds a verifier for verifying client certificates. | ||
|
||
.. warning:: | ||
|
||
This API is not suitable for website (i.e. server) certificate | ||
verification. You **must** use :meth:`build_server_verifier` | ||
for server verification. | ||
|
||
:returns: An instance of :class:`ClientVerifier` |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In general, usage of subject for anything is strongly discouraged at this point, because it's not type safe.
Moreoever, you don't really need the validator to do anything special for you, this is always
cert.subject
.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, agreed. This is the thing that I pointed out in my previous comment .
I think having just the
subjects
field but making it optional is fine. There could potentially be twoVerifiedClient
classes, one used withPolicyBuilder
, and the other used withCustomPolicyBuilder
, sincesubjects
only needs to be optional in the first case, but personally I think the increased implementation complexity is just not worth it.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I have removed
subject
and renamedsans
back tosubjects
(but kept it optional). I'm leaving the conversation unresolved in case there are some other concerns related to this.