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

x509-cert: Non-Repudiation set by default in builder #1281

Closed
zkonge opened this issue Dec 14, 2023 · 2 comments · Fixed by #1306
Closed

x509-cert: Non-Repudiation set by default in builder #1281

zkonge opened this issue Dec 14, 2023 · 2 comments · Fixed by #1306
Assignees

Comments

@zkonge
Copy link

zkonge commented Dec 14, 2023

let mut key_usage = KeyUsages::DigitalSignature | KeyUsages::NonRepudiation;

Is there any special reason to enable it by default?

I understand that the ETSI advises against combining the Non-Repudiation and other key usages.

In section 4.3.2 Key usage
https://www.etsi.org/deliver/etsi_en/319400_319499/31941202/02.03.00_20/en_31941202v020300a.pdf

@baloo baloo self-assigned this Jan 2, 2024
@baloo
Copy link
Member

baloo commented Jan 2, 2024

I was not aware of the ETSI document. I believe I went with the RFC5280 at the time:

For example, when an RSA key should be used only to verify signatures on
objects other than public key certificates and CRLs, the
digitalSignature and/or nonRepudiation bits would be asserted.

https://www.rfc-editor.org/rfc/rfc5280#section-4.2.1.3

I didn't see harm in putting it. That was a mistake.

I guess the Profile::Leaf should be further qualified to include the A/C/E types from the ETSI:

NAT-4.3.2-1: The key usage extension shall be present and shall contain one (and only one) of the key usage settings
defined in table 1 (A, B, C, D, E or F). Type A, C or E should be used to avoid mixed usage of keys.

baloo added a commit to baloo/formats that referenced this issue Jan 5, 2024
I tried to abide by the ETSI policy.
https://www.etsi.org/deliver/etsi_en/319400_319499/31941202/02.03.01_60/en_31941202v020301p.pdf

The policy recommends to make KeyUsage bits 0, 1, (2 and/or 4) exclusive.
This is meant to avoid making signing of commitments during
authentication.

This commit goes a bit further by making bit 2 and 4 exclusive. I don't
find a use-case for requiring both at the same time (and I would think
only key agreement is required.

Fixes RustCrypto#1281
@baloo
Copy link
Member

baloo commented Jan 5, 2024

@zkonge I published #1306 to fix this, if you could take a look, that would be appreciated.

baloo added a commit to baloo/formats that referenced this issue Jan 17, 2024
I tried to abide by the ETSI policy.
https://www.etsi.org/deliver/etsi_en/319400_319499/31941202/02.03.01_60/en_31941202v020301p.pdf

The policy recommends to make KeyUsage bits 0, 1, (2 and/or 4) exclusive.
This is meant to avoid making signing of commitments during
authentication.

This commit goes a bit further by making bit 2 and 4 exclusive. I don't
find a use-case for requiring both at the same time (and I would think
only key agreement is required.

Fixes RustCrypto#1281
baloo added a commit to baloo/formats that referenced this issue Jan 20, 2024
I tried to abide by the ETSI policy.
https://www.etsi.org/deliver/etsi_en/319400_319499/31941202/02.03.01_60/en_31941202v020301p.pdf

The policy recommends to make KeyUsage bits 0, 1, (2 and/or 4) exclusive.
This is meant to avoid making signing of commitments during
authentication.

This commit goes a bit further by making bit 2 and 4 exclusive. I don't
find a use-case for requiring both at the same time (and I would think
only key agreement is required.

Fixes RustCrypto#1281
baloo added a commit to baloo/formats that referenced this issue Jan 21, 2024
This is now providing a trait to be implemented by the consumer.

A number of implementation are available, including ones trying to abide
by CABF Baseline Requirements.

Fixes RustCrypto#1281
baloo added a commit to baloo/formats that referenced this issue Jan 21, 2024
This is now providing a trait to be implemented by the consumer.

A number of implementation are available, including ones trying to abide
by CABF Baseline Requirements.

Fixes RustCrypto#1281
baloo added a commit to baloo/formats that referenced this issue Jan 29, 2024
This is now providing a trait to be implemented by the consumer.

A number of implementation are available, including ones trying to abide
by CABF Baseline Requirements.

Fixes RustCrypto#1281
baloo added a commit to baloo/formats that referenced this issue Apr 30, 2024
This is now providing a trait to be implemented by the consumer.

A number of implementation are available, including ones trying to abide
by CABF Baseline Requirements.

Fixes RustCrypto#1281
baloo added a commit to baloo/formats that referenced this issue Apr 30, 2024
This is now providing a trait to be implemented by the consumer.

A number of implementation are available, including ones trying to abide
by CABF Baseline Requirements.

Fixes RustCrypto#1281
baloo added a commit to baloo/formats that referenced this issue Apr 30, 2024
This is now providing a trait to be implemented by the consumer.

A number of implementation are available, including ones trying to abide
by CABF Baseline Requirements.

Fixes RustCrypto#1281
baloo added a commit to baloo/formats that referenced this issue May 7, 2024
This is now providing a trait to be implemented by the consumer.

A number of implementation are available, including ones trying to abide
by CABF Baseline Requirements.

Fixes RustCrypto#1281
baloo added a commit to baloo/formats that referenced this issue May 7, 2024
This is now providing a trait to be implemented by the consumer.

A number of implementation are available, including ones trying to abide
by CABF Baseline Requirements.

Fixes RustCrypto#1281
baloo added a commit that referenced this issue May 13, 2024
This is now providing a trait to be implemented by the consumer.

A number of implementation are available, including ones trying to abide
by CABF Baseline Requirements.

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

Successfully merging a pull request may close this issue.

2 participants