Re: Question regarding custom contextFactory for twisted.web.client.Agent
Glyph <[email protected]> Sun, 2 Jul 2017 23:15:32 -0700
| Newsgroups | gmane.comp.python.twisted.web |
|---|---|
| Message-ID | <[email protected]> |
--===============1037650328580861884== Content-Type: multipart/alternative; boundary="Apple-Mail=_0E770524-B4DF-4ED5-8718-04C4CBB4BA4E" --Apple-Mail=_0E770524-B4DF-4ED5-8718-04C4CBB4BA4E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On Jul 2, 2017, at 9:58 PM, Jason Litzinger <[email protected]> = wrote: >=20 >> The cryptography APIs for making certs are pretty straightforward and = well >> documented. But if another example helps, here's some code that = creates a >> self-signed ca cert and a client cert with an intermediate cert in = between: >>=20 >>=20 >> = https://github.com/LeastAuthority/txkube/blob/faa0374fcef6d089af39a98310f1= bd798eb54b08/src/txkube/test/test_authentication.py#L17-L29 >>=20 >> = https://github.com/LeastAuthority/txkube/blob/faa0374fcef6d089af39a98310f1= bd798eb54b08/src/txkube/test/test_authentication.py#L276-L309 >=20 > I'm diving into adding benchmarks for testing HTTPS and this has been > very helpful. I did have one question, in the cert function > neither the pubkey or privkey parameters are used, rather, a_key is > always used as both the public and the signing key. Is that > intentional? >=20 > Or, should the public key be the pubkey value and the signing key the > privkey value? Meaning, each cert uses the supplied public key and = the > signing order is: >=20 > a signs a > a signs b > b signs c >=20 > If so, do you want me to send you a PR for this change? I don't know much about txkube, but my understanding of certificate = chains suggests that this is what it is trying to test. It looks like = this might succeed by accident since everything is signed by the root, = and therefore trusted? It also appears to be implied that the chain is verified somehow, but = the invariant is actually just about the subject/issuer pairs: = https://github.com/LeastAuthority/txkube/blob/faa0374fcef6d089af39a98310f1= bd798eb54b08/src/txkube/_authentication.py#L47-L59 = <https://github.com/LeastAuthority/txkube/blob/faa0374fcef6d089af39a98310f= 1bd798eb54b08/src/txkube/_authentication.py#L47-L59> so something else = must be validating the chain. -glyph= --Apple-Mail=_0E770524-B4DF-4ED5-8718-04C4CBB4BA4E Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii <html><head><meta http-equiv=3D"Content-Type" content=3D"text/html = charset=3Dus-ascii"></head><body style=3D"word-wrap: break-word; = -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" = class=3D""><br class=3D""><div><blockquote type=3D"cite" class=3D""><div = class=3D"">On Jul 2, 2017, at 9:58 PM, Jason Litzinger <<a = href=3D"mailto:[email protected]" = class=3D"">[email protected]</a>> wrote:</div><br = class=3D"Apple-interchange-newline"><div class=3D""><div = class=3D""><blockquote type=3D"cite" class=3D"">The cryptography APIs = for making certs are pretty straightforward and well<br = class=3D"">documented. But if another example helps, here's some = code that creates a<br class=3D"">self-signed ca cert and a client cert = with an intermediate cert in between:<br class=3D""><br class=3D""><br = class=3D""><a = href=3D"https://github.com/LeastAuthority/txkube/blob/faa0374fcef6d089af39= a98310f1bd798eb54b08/src/txkube/test/test_authentication.py#L17-L29" = class=3D"">https://github.com/LeastAuthority/txkube/blob/faa0374fcef6d089a= f39a98310f1bd798eb54b08/src/txkube/test/test_authentication.py#L17-L29</a>= <br class=3D""><br = class=3D"">https://github.com/LeastAuthority/txkube/blob/faa0374fcef6d089a= f39a98310f1bd798eb54b08/src/txkube/test/test_authentication.py#L276-L309<b= r class=3D""></blockquote><br class=3D"">I'm diving into adding = benchmarks for testing HTTPS and this has been<br class=3D"">very = helpful. I did have one question, in the cert function<br = class=3D"">neither the pubkey or privkey parameters are used, rather, = a_key is<br class=3D"">always used as both the public and the signing = key. Is that<br class=3D"">intentional?<br class=3D""><br = class=3D"">Or, should the public key be the pubkey value and the signing = key the<br class=3D"">privkey value? Meaning, each cert uses the = supplied public key and the<br class=3D"">signing order is:<br = class=3D""><br class=3D""> a signs a<br class=3D""> = a signs b<br class=3D""> b signs = c<br class=3D""><br class=3D"">If so, do you want me to send you a PR = for this change?<br class=3D""></div></div></blockquote></div><br = class=3D""><div class=3D"">I don't know much about txkube, but my = understanding of certificate chains suggests that this is what it is = trying to test. It looks like this might succeed by accident since = everything is signed by the root, and therefore trusted?</div><div = class=3D""><br class=3D""></div><div class=3D"">It also appears to be = implied that the chain is verified somehow, but the invariant is = actually just about the subject/issuer pairs: <a = href=3D"https://github.com/LeastAuthority/txkube/blob/faa0374fcef6d089af39= a98310f1bd798eb54b08/src/txkube/_authentication.py#L47-L59" = class=3D"">https://github.com/LeastAuthority/txkube/blob/faa0374fcef6d089a= f39a98310f1bd798eb54b08/src/txkube/_authentication.py#L47-L59</a> so = something else must be validating the chain.</div><div class=3D""><br = class=3D""></div><div class=3D"">-glyph</div></body></html>= --Apple-Mail=_0E770524-B4DF-4ED5-8718-04C4CBB4BA4E-- --===============1037650328580861884== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: inline X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KVHdpc3RlZC13 ZWIgbWFpbGluZyBsaXN0ClR3aXN0ZWQtd2ViQHR3aXN0ZWRtYXRyaXguY29tCmh0dHBzOi8vdHdp c3RlZG1hdHJpeC5jb20vY2dpLWJpbi9tYWlsbWFuL2xpc3RpbmZvL3R3aXN0ZWQtd2ViCg== --===============1037650328580861884==--