On 09/18/2008 10:29 PM, Nelson B Bolyard: > > After verifying that the signatures are valid in the chain, all the > way to a trusted root, then yes.
And what exactly prevents you from verifying the signatures of the received chain (by whatever means you constructed the chain) all the way to a trusted root? What does it matter if you received the sub-ordinate CA certificate from: 1.) The Server 2.) The AIA CA Issuer URL 3.) Previously stored in authorities 4.) UI input box from the user 5.) International Space Station > If the signatures don't pass the test, > then no. Exactly! > The crucial difference is that when using certs from the SSL > server, we can construct the chain, and validate all its signatures, YES! > without doing fetches from URLs in the certs first. What does that matter? Seriously! Who cares? > But when trying to > complete a chain by fetching certs from URLs in AIA extensions, we cannot > validate the signature in the cert from which the URL is taken until > after we've gone and attempted to fetch certs from the URL in the > unvalidated cert Of course...so discharge the received invalid obtained CA certificate and proceed with the error. > a URL supplied by the (potential) attacker. I call that nonsense! If you believe what you are saying you can't rely on any server sending a certificate chain, because every server can be a (potential) attacker! > Isn't this obvious? No > > Think about this. Using certutil, I can construct a certificate that > has an issuer name that exactly matches (every bit) the subject name > of one of your CA's CA certs, So? Does it match the signature as well? > but that has an AIA extension containing > a URL that does not go to the server your real AIA's use, but goes to > a completely different server. Of course...but it doesn't matter, the signature never matches. > The cert I create will not have a > signature that can be validated with your real CA cert Right > but as an attacker, > I don't care because the damage will be done before the relying party > discovers that my cert was not really issued by your CA. More nonsense! If the signature doesn't match you can't construct a valid chain up to a trusted root and you return an error. The same error you return today when the certificate can't be validated up to a trusted root. EXACTLY the same thing! > Not unless it has the private key of the builtin root. It can create a > cert that has an issuer name that matches a built-in root, but the signature > will not validate. EXACTLY! You are saying it yourself! > The security or vulnerability is all > controlled by which operation is done first, the signature verification > of the chain, or the fetching or external data (certs, CRLs, OCSP) based > on the contents of those certs. Fist you try to construct a valid chain - being it with the certificates the server supplied, by the AIA extensions or by looking at the local auth store... > > Again the obvious difference is that in once case, the relying party > goes out and fetches from URLs in a cert of unknown origin, and in the > other case, it does not. That's wrong! Not the relying party is doing it, but the software is doing it! The software fetches those missing certificates, tries to build the chain and validate this chain. The software returns the either the error and continues the process (of validating the CRL, OCSP etc). The relying party is absolutely passive at this stage, there is nothing to do at this stage then wait for the site to appear. > The concern is NOT that the relying party will be fooled into accepting > a bogus cert as legitimate. The concern is that, before the relying > party determines that the cert is bogus, it will have acted as a proxy > for the attacker by fetching from an attacker-supplied URL. WHAT? You are fetching most likely a certificate...but even if it's something else, the software can perform its usual checks as it should do with anything which is supplied - including the CA chain from the server. > Being able > to be tricked into acting as such a proxy is a vulnerability. Nonono...this proxy-thing has nothing to do with it. Where is this proxy? Where is the vulnerability exactly? -- Regards Signer: Eddy Nigg, StartCom Ltd. Jabber: [EMAIL PROTECTED] Blog: https://blog.startcom.org _______________________________________________ dev-tech-crypto mailing list [email protected] https://lists.mozilla.org/listinfo/dev-tech-crypto
