-
Notifications
You must be signed in to change notification settings - Fork 565
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
RFC: When verifying, only use data after it is considered acceptable #2482
Closed
Closed
Changes from all commits
Commits
Show all changes
43 commits
Select commit
Hold shift + click to select a range
f8299e8
Rename sig to untrustedSignature
mtrmac a155a19
Rename cert to untrustedCert
mtrmac cb0f9eb
Rename chain to untrustedChain
mtrmac 2ce0cd0
Rename CheckOpts.IntermediateCerts to UntrustedIntermediateCerts
mtrmac f44d639
Rename pool to untrustedPool
mtrmac 17cad99
Rename cert to untrustedCert
mtrmac 58380e3
Rename parameters to TrustedCert to indicate untrusted...
mtrmac 21d19e8
Rename TrustedCert to CertificateSignedByTrustedRoot
mtrmac 5ae11b5
Introduce a correctlySignedCert variable
mtrmac 5de8a27
Rename cert to correctlySignedCert
mtrmac 9831a1d
Rename validateCertIdentity to validateCertSubject
mtrmac e3d4d9e
Rename cert to correctlySignedCert
mtrmac 9286e3a
Split validateIssuerPolicy from CheckCertificatePolicy
mtrmac b8ad87a
Validate the certificate issuer before worrying about the subject
mtrmac 784d491
Rename CheckCertificatePolicy to CheckCertificateIssuerAndSubject
mtrmac d4a62a5
Only create a verifier from a certificate _after_ it passes conditions.
mtrmac 5120f37
Only worry about certificate issuer and subject if the SCT is acceptable
mtrmac 8aa0f7d
Split ValidateAndUnpackCert
mtrmac bc50a08
Replace ValidateAndUnpackCert in verifyInternal by its components
mtrmac 91c6593
Warn more explicitly in some functions that ignore certificate validi…
mtrmac 0d4bda1
Rename sig to untrustedSig
mtrmac 8b4421e
Rename ts to untrustedTimestamp
mtrmac e7b3199
Rename b64sig to untrustedB64Sig
mtrmac 43564e8
Rename signedPayload to untrustedPayload
mtrmac 0ace845
Rename rawSig to untrustedRawSig
mtrmac 07ffbb8
Rename tsBytes to untrustedTSAArtifact
mtrmac c37d3f8
Rename sig to untrustedSig
mtrmac d7028e7
Rename bundle to untrustedBundle
mtrmac 7136f69
Rename parameters of VerifySET
mtrmac c9c92e2
Introduce acceptableBundleBody
mtrmac 5aa2e8e
Only validate the public key and signature _after_ we accept the SET
mtrmac b150bcf
Rename payload to untrustedPayload
mtrmac 7428fc3
Rename signature to untrustedSignature
mtrmac ea498b2
Document VerifyBundle a bit more
mtrmac 0321492
Rename pemBytes to untrustedPEMBytes
mtrmac 0771a5a
Rename sig to untrustedSig
mtrmac 28cb652
Rename pem to untrustedPEM
mtrmac 5c35a52
Rename b64sig to untrustedB64sig
mtrmac 66a6644
Rename payload to untrustedPayload
mtrmac 75cd9e8
BEHAVIOR CHANGE: Don't check against current time if we have a RFC 31…
mtrmac 2c2f0da
Eliminate the redundant cert variable
mtrmac 36f9fa1
Introduce acceptableCert
mtrmac deebfc5
Update comments in verifyInternal
mtrmac File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Oops, something went wrong.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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.
Could we keep the same name,
IntermediateCerts
?I would prefer we don't used "Untrusted" in the name. This term comes from openssl from what I've seen, and I personally don't think it's correct to only use intermediate certificates for chain building ("untrusted"). Intermediates should be trusted, or at least come from a trusted source.
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.
This one is confusing. These particular ones are coming from a trusted source, so I can agree to see it named the same. The ones found on the registry through CertChain are untrusted intermediates
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.
Yes, see
co.UntrustedIntermediateCerts = untrustedPool
. So, in that sense, I think changing the name ofCheckOpts
toUntrustedIntermediateCerts
has been a success exactly because the trusted nature of those coming fromfulcio.GetIntermediates
is insufficient to make the field trusted.(I’m also not sure what a “trusted intermediate” means. Is that a root of trust, i.e. a non-intermediate root? Or an intermediate that we still require to be correctly signed by a root of trust, i.e. something where we don’t actually require any trust?)
Actually, what I really think is that the caller-provided policy should be immutable and should not be modified to hold single-instance data within
verify.go
at all. Then we might even more precisely differentiate betweenand potentially make different decisions based on those details. That would be a different PR.
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.
For a core library function, I think we should not be opinionated if the certificates are trusted or untrusted. For example, we don't know where the root certificate came from either when the checkopts is populated. I don't see a reason to distinguish between untrusted and trusted in the CheckOpts. Internally, we can name variables differently based on their source.
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… don’t know what that would mean.
The verification code must be certain about which data is a part of the root of trust that is, by necessity, assumed valid, and which data is part of the external attack surface that is, by default, suspect. At the very least these two categories are 100% distinct. There might be even more categories in between (e.g. the intermediate certificates might be more trusted than the underlying signatures, but they are still potentially a part of the attack surface).
(And then the API should help the caller of the API express its assumptions clearly, and to help expose any incorrect assumptions the caller might be making.
From that point of view, calling the certificates “untrusted” is good for the caller, because it tells the caller the caller doesn’t need to make much effort at all to ensure validity of the data. “A trusted system is one whose failure would break a security policy”.)
I don’t care at all about the individual naming of the options. If you don’t want the field to be named
Untrusted
, and to instead have aCheckOpts.{TrustedSigVerifier,TrustedRootCerts}
, sure, that might be even more explicit. If you think the distinction between trusted and untrusted data is sufficient to express in comments and doesn’t need to be in field names, that’s not my preference but I can live with that just fine.But I read the above as suggesting that it doesn’t make a difference whether the data is trusted or not, and I just don’t know what to do with that. Probably I’m completely misunderstanding your point.