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

Define api for delegated credentials #67 #69

Merged
merged 1 commit into from
Mar 23, 2021
Merged

Define api for delegated credentials #67 #69

merged 1 commit into from
Mar 23, 2021

Conversation

claucece
Copy link
Contributor

@claucece claucece commented Mar 18, 2021

Ready for review.

This should solve #63 as well.

@claucece claucece marked this pull request as draft March 18, 2021 20:48
@claucece claucece marked this pull request as ready for review March 18, 2021 22:04
@claucece
Copy link
Contributor Author

@armfazh @lukevalenta @Lekensteyn ready for review now. Thanks!

@claucece claucece requested a review from cjpatton March 18, 2021 22:14
@claucece claucece changed the title [DRAFT] Define api for delegated credentials #67 Define api for delegated credentials #67 Mar 18, 2021
Copy link
Contributor

@cjpatton cjpatton left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I like the API changes. One concern sticks out to me: If I'm understanding the code correctly, the client (resp. server) may use a DC whose signature algorithm isn't supported by the peer. I may be wrong :)

src/crypto/tls/common.go Outdated Show resolved Hide resolved
src/crypto/tls/delegated_credentials_test.go Outdated Show resolved Hide resolved
src/crypto/tls/delegated_credentials_test.go Outdated Show resolved Hide resolved
src/crypto/tls/handshake_client_tls13.go Outdated Show resolved Hide resolved
src/crypto/tls/handshake_client_tls13.go Outdated Show resolved Hide resolved
src/crypto/tls/handshake_server_tls13.go Outdated Show resolved Hide resolved
src/crypto/tls/handshake_client_tls13.go Show resolved Hide resolved
src/crypto/tls/handshake_client_tls13.go Outdated Show resolved Hide resolved
@cjpatton cjpatton self-requested a review March 19, 2021 15:40
@claucece
Copy link
Contributor Author

@cjpatton addressed now. Let me know what you think now ;)

One concern sticks out to me: If I'm understanding the code correctly, the client (resp. server) may use a DC whose signature algorithm isn't supported by the peer. I may be wrong :)

When you get a DC from storage you check which one you will used based on the other's peer signature algorithm advertised by either the clientHelloInfo or certificateRequestInfo, so it will not be able to use anything that wasn't advertised there in the handshake.

Copy link
Contributor

@Lekensteyn Lekensteyn left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If I understand correctly, the point of this change is to provide the DC in a single callback via GetCertificate rather than two (GetCertificate followed by GetDelegatedCredential)?

Could you include the motivation for the change in the commit message? Thanks, it looks good with minor comments!

src/crypto/tls/delegated_credentials_test.go Outdated Show resolved Hide resolved
@@ -446,7 +462,9 @@ func testServerGetCertificate(ch *ClientHelloInfo) (*Certificate, error) {
}

if versOk && ch.SupportsDelegatedCredential {
return dcTestCerts["dcP256"], nil
serverCert := dcTestCerts["dcP256"]
serverCert.DelegatedCredentials = serverDC[dcCount:]
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

(Note for my understanding: initDCTest resets dcTestCerts and dcTestCerts["dcCertP256"] which is why it is okay for testServerGetCertificate to have side-effects such as overwriting dcTestCerts["dcP256"].DelegatedCredentials.)

I was wondering why serverDC[dcCount:] was used. Would serverDC[dcCount:dcCount+1] be sufficient to limit the test to a specific DC? Or is there a reason to include more than one?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It is more for testing with each specific DC and algorithm (a DC with ed25519, a Dc with eddsa256, etc). I'll prefer if the tests were only using one DC (it simplifies all) but is was requested by reviewers to test with them all.

Copy link
Contributor

@Lekensteyn Lekensteyn Mar 23, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So based on a private chat with Sofía, my understanding is that it deliberately includes more than one to test this code path:

for _, dcPair := range cert.DelegatedCredentials {
// The client must have sent the signature_algorithms in the DC extension: ensure it supports
// schemes we can use with this delegated credential.
if len(clientHello.SignatureSchemesDC) > 0 {
if _, err := selectSignatureSchemeDC(VersionTLS13, dcPair.DC, clientHello.SignatureSchemesDC); err == nil {
return &dcPair, nil
}
}
}

Copy link
Contributor

@cjpatton cjpatton left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

One final question from me: From the tests it appears as if a DC may still be used in the connection even if support for DCs was not indicated by the peer. Is this an artifact of the test code, or is this what's actually happening?

src/crypto/tls/delegated_credentials_test.go Outdated Show resolved Hide resolved
src/crypto/tls/delegated_credentials_test.go Outdated Show resolved Hide resolved
src/crypto/tls/handshake_client_tls13.go Show resolved Hide resolved
src/crypto/tls/handshake_server_tls13.go Show resolved Hide resolved
src/crypto/tls/handshake_client_tls13.go Outdated Show resolved Hide resolved
@claucece
Copy link
Contributor Author

If I understand correctly, the point of this change is to provide the DC in a single callback via GetCertificate rather than two (GetCertificate followed by GetDelegatedCredential)?
Could you include the motivation for the change in the commit message? Thanks, it looks good with minor comments!

Yes, the idea is to unify into single callback. I'll include in the commit message ;)

Copy link
Contributor

@cjpatton cjpatton left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

Copy link
Contributor

@armfazh armfazh left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

few nits

src/crypto/tls/common.go Outdated Show resolved Hide resolved
src/crypto/tls/common.go Outdated Show resolved Hide resolved
src/crypto/tls/handshake_server_tls13.go Outdated Show resolved Hide resolved
Copy link
Contributor

@Lekensteyn Lekensteyn left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

With an updated commit message with the motivation, it looks good to me.

…using the same mechanisms used to fetch certificates #67

Refactor new API

Address comments from review

Address comments from review 2

Address comments from review 3
@claucece
Copy link
Contributor Author

Commit message has been changed. Merging now.

@claucece claucece merged commit c5faf90 into cf Mar 23, 2021
claucece added a commit that referenced this pull request Mar 23, 2021
…using the same mechanisms used to fetch certificates #67 (#69)

Refactor new API

Address comments from review

Address comments from review 2

Address comments from review 3
@claucece claucece deleted the dc-api branch March 23, 2021 15:56
cjpatton pushed a commit that referenced this pull request Jul 13, 2021
…using the same mechanisms used to fetch certificates #67 (#69)

Refactor new API

Address comments from review

Address comments from review 2

Address comments from review 3
cjpatton pushed a commit that referenced this pull request Aug 20, 2021
crypto/tls: Implement draft-ietf-tls-subcerts-10

crypto/tls: fixes individual testing by adding insecure verify #62

crypto/tls: define api for delegated credentials so they are fetched using the same mechanisms used to fetch certificates #67 (#69)

Refactor new API

Address comments from review

Address comments from review 2

Address comments from review 3

crypto/tls: allow the usage of other keyUsage when checking for the dc extension #72 (#73)
cjpatton pushed a commit that referenced this pull request Aug 23, 2021
crypto/tls: Implement draft-ietf-tls-subcerts-10

crypto/tls: fixes individual testing by adding insecure verify #62

crypto/tls: define api for delegated credentials so they are fetched using the same mechanisms used to fetch certificates #67 (#69)

Refactor new API

Address comments from review

Address comments from review 2

Address comments from review 3

crypto/tls: allow the usage of other keyUsage when checking for the dc extension #72 (#73)
cjpatton pushed a commit that referenced this pull request Aug 23, 2021
crypto/tls: Implement draft-ietf-tls-subcerts-10

crypto/tls: fixes individual testing by adding insecure verify #62

crypto/tls: define api for delegated credentials so they are fetched using the same mechanisms used to fetch certificates #67 (#69)

Refactor new API

Address comments from review

Address comments from review 2

Address comments from review 3

crypto/tls: allow the usage of other keyUsage when checking for the dc extension #72 (#73)
cjpatton pushed a commit that referenced this pull request Aug 23, 2021
crypto/tls: Implement draft-ietf-tls-subcerts-10

crypto/tls: fixes individual testing by adding insecure verify #62

crypto/tls: define api for delegated credentials so they are fetched using the same mechanisms used to fetch certificates #67 (#69)

Refactor new API

Address comments from review

Address comments from review 2

Address comments from review 3

crypto/tls: allow the usage of other keyUsage when checking for the dc extension #72 (#73)
cjpatton pushed a commit that referenced this pull request Aug 23, 2021
crypto/tls: Implement draft-ietf-tls-subcerts-10

crypto/tls: fixes individual testing by adding insecure verify #62

crypto/tls: define api for delegated credentials so they are fetched using the same mechanisms used to fetch certificates #67 (#69)

Refactor new API

Address comments from review

Address comments from review 2

Address comments from review 3

crypto/tls: allow the usage of other keyUsage when checking for the dc extension #72 (#73)
cjpatton pushed a commit that referenced this pull request Aug 23, 2021
crypto/tls: Implement draft-ietf-tls-subcerts-10

crypto/tls: fixes individual testing by adding insecure verify #62

crypto/tls: define api for delegated credentials so they are fetched using the same mechanisms used to fetch certificates #67 (#69)

Refactor new API

Address comments from review

Address comments from review 2

Address comments from review 3

crypto/tls: allow the usage of other keyUsage when checking for the dc extension #72 (#73)
cjpatton pushed a commit that referenced this pull request Aug 23, 2021
crypto/tls: Implement draft-ietf-tls-subcerts-10

crypto/tls: fixes individual testing by adding insecure verify #62

crypto/tls: define api for delegated credentials so they are fetched using the same mechanisms used to fetch certificates #67 (#69)

Refactor new API

Address comments from review

Address comments from review 2

Address comments from review 3

crypto/tls: allow the usage of other keyUsage when checking for the dc extension #72 (#73)
cjpatton pushed a commit that referenced this pull request Aug 23, 2021
crypto/tls: Implement draft-ietf-tls-subcerts-10

crypto/tls: fixes individual testing by adding insecure verify #62

crypto/tls: define api for delegated credentials so they are fetched using the same mechanisms used to fetch certificates #67 (#69)

Refactor new API

Address comments from review

Address comments from review 2

Address comments from review 3

crypto/tls: allow the usage of other keyUsage when checking for the dc extension #72 (#73)
Lekensteyn pushed a commit that referenced this pull request Sep 24, 2021
…using the same mechanisms used to fetch certificates #67 (#69)

Refactor new API

Address comments from review

Address comments from review 2

Address comments from review 3
Lekensteyn pushed a commit that referenced this pull request Sep 24, 2021
…using the same mechanisms used to fetch certificates #67 (#69)

Refactor new API

Address comments from review

Address comments from review 2

Address comments from review 3
Lekensteyn pushed a commit that referenced this pull request Jan 11, 2022
…using the same mechanisms used to fetch certificates #67 (#69)

Refactor new API

Address comments from review

Address comments from review 2

Address comments from review 3
Lekensteyn pushed a commit that referenced this pull request Jan 14, 2022
…using the same mechanisms used to fetch certificates #67 (#69)

Refactor new API

Address comments from review

Address comments from review 2

Address comments from review 3
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 this pull request may close these issues.

4 participants