From 71a008dc498c3c3d90cdd14c600e39a28e7f7170 Mon Sep 17 00:00:00 2001 From: Jamie Reece Wilson Date: Wed, 20 Nov 2024 20:05:01 +0000 Subject: [PATCH] [*] Amend certstore comment --- Source/Crypto/CA/AuCertificateStore.cpp | 11 +++++++---- 1 file changed, 7 insertions(+), 4 deletions(-) diff --git a/Source/Crypto/CA/AuCertificateStore.cpp b/Source/Crypto/CA/AuCertificateStore.cpp index cd976a88..019e79f1 100755 --- a/Source/Crypto/CA/AuCertificateStore.cpp +++ b/Source/Crypto/CA/AuCertificateStore.cpp @@ -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.