AuroraSupport/AuroraRuntime
2
1
Fork 0
Code Issues 28 Pull Requests Releases Wiki Activity

[*] Amend certstore comment

Browse Source
This commit is contained in:
Reece Wilson 2024-11-20 20:05:01 +00:00
parent 5abfb0eee0
commit 71a008dc49
1 changed files with 7 additions and 4 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

11
Source/Crypto/CA/AuCertificateStore.cpp
View File

@ -31,20 +31,23 @@ namespace Aurora::Crypto::CA
// Certificate parameter validation is your issue - the clients' implementation side with your expected profile parameters and state container
// of the peers connection and hostname,common-name pair. Such validation is not an issue for this relatively stateless * certificate store *.
//
// However, when *we* recurse a *chain*, we need to verify that the previous certificate the signator to the next, at this point it is our
// However, when *we* recurse a *chain*, we need to verify that the previous certificate is the signator to the next, at this point it is our
// responsibility to ensure some unsound certificates weren't injected into the middle of the chain to violate the "is trusted by a known root
// via a series of unknown middle-man certificates" test. Noting we dont care for testing CN and SANs; we only care about testing the PK infra
// which just to happens to include a signature test of the serialized ASN.1 properties from the anonymous root down to the chain[0] common name.
// These certificate chains, we have to assume they're arbitrary remote user data, and therefore could be severely malformed or manipulated.
// Any provided TLS stack will verify the chain[0] common name and profile parameters of the peer, however as the root-store validator, we need
// to vertify cert[1...n] eventually references a good known anon root authority without a breakage the chains of signatures.
// to vertify cert[0] || cert[1...n] eventually references a good known anon root authority without a breakage the chains of signatures.
//
// PS: Emphasis on anonymous. I've seen some certificate roots, *ahem google*, change their x509 container without changing their key.
// If we're hard-coding a series of CAs to trust, or even storing long term keychains, we're saying "we trust the owner of this key" to not
// be a dipshit, therefore we shouldn't need to worry about every minute detail of the CA - we only care about: 1) the binary public key,
// and 2) expiration time. It is therefore the case we only serialized these two properties. Do we really care that somebody we trust changed
// and 2) expiration time. It is therefore the case we only serialize these two properties. Do we really care that somebody we trust changed
// their their expiration time by an hour after reserializing their root cert? No, not really. Do we care that they added some SANs? Again,
// no. What about extended key uses? What are those? The extension RFC specifies use cases we couldn't care less about.
// no. What about extended key uses? What are those? The extension RFC specifies use cases we couldn't care less about. What about public
// key reuse in another format? That's not even possible, because most if not all public key formats are different ASN.1 sequences derived
// from OpenSSL said so defacto standards (regardless of how much unique input and power RFC and committee lawyers think they have).
//
// Any certificate revocation or further tests must come from another validator, perhaps connected to us via a "PinCheckTwoAnd" object.
//
// kAssumeRootIsSmart is used to satisfy this relationship test.