Re: Question regarding custom contextFactory for twisted.web.client.Agent

--===============3500276795187737124==
Content-Type: multipart/alternative; boundary="f4030435b7fc1b3764055367c95c"

--f4030435b7fc1b3764055367c95c
Content-Type: text/plain; charset="UTF-8"

On Mon, Jul 3, 2017 at 12:58 AM, Jason Litzinger <[email protected]>
wrote:

> > 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:
> >
> >
> > https://github.com/LeastAuthority/txkube/blob/
> faa0374fcef6d089af39a98310f1bd798eb54b08/src/txkube/test/
> test_authentication.py#L17-L29
> >
> > https://github.com/LeastAuthority/txkube/blob/
> faa0374fcef6d089af39a98310f1bd798eb54b08/src/txkube/test/
> test_authentication.py#L276-L309
>
> 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?
>
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:
>
>     a signs a
>     a signs b
>     b signs c
>
> If so, do you want me to send you a PR for this change?
>
>
Heya Jason,

Thanks for pointing this out.  Yes, it's a bug.  Also, it turns out
re-using serial numbers is a bad idea too.  I don't think their mistake
*currently* hurts the tests but it would be great to get them both fixed.
So a PR would be quite welcome.

Regarding Glyph's comments about where the chain is verified - that's still
handled by the TLS library.  The Chain invariant in _authentication.py is
just a superficial sanity check to catch the common problem of "a-b-c" vs
"c-b-a" chain certificate order.

Thanks!
Jean-Paul

--f4030435b7fc1b3764055367c95c
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On M=
on, Jul 3, 2017 at 12:58 AM, Jason Litzinger <span dir=3D"ltr">&lt;<a href=
=3D"mailto:[email protected]" target=3D"_blank">[email protected]=
om</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"marg=
in:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1e=
x"><span class=3D"gmail-">&gt; The cryptography APIs for making certs are p=
retty straightforward and well<br>
&gt; documented.=C2=A0 But if another example helps, here&#39;s some code t=
hat creates a<br>
&gt; self-signed ca cert and a client cert with an intermediate cert in bet=
ween:<br>
&gt;<br>
&gt;<br>
&gt; <a href=3D"https://github.com/LeastAuthority/txkube/blob/faa0374fcef6d=
089af39a98310f1bd798eb54b08/src/txkube/test/test_authentication.py#L17-L29"=
 rel=3D"noreferrer" target=3D"_blank">https://github.com/<wbr>LeastAuthorit=
y/txkube/blob/<wbr>faa0374fcef6d089af39a98310f1bd<wbr>798eb54b08/src/txkube=
/test/<wbr>test_authentication.py#L17-L29</a><br>
&gt;<br>
&gt; <a href=3D"https://github.com/LeastAuthority/txkube/blob/faa0374fcef6d=
089af39a98310f1bd798eb54b08/src/txkube/test/test_authentication.py#L276-L30=
9" rel=3D"noreferrer" target=3D"_blank">https://github.com/<wbr>LeastAuthor=
ity/txkube/blob/<wbr>faa0374fcef6d089af39a98310f1bd<wbr>798eb54b08/src/txku=
be/test/<wbr>test_authentication.py#L276-<wbr>L309</a><br>
<br>
</span>I&#39;m diving into adding benchmarks for testing HTTPS and this has=
 been<br>
very helpful.=C2=A0 I did have one question, in the cert function<br>
neither the pubkey or privkey parameters are used, rather, a_key is<br>
always used as both the public and the signing key.=C2=A0 Is that<br>
intentional?=C2=A0<br></blockquote><blockquote class=3D"gmail_quote" style=
=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding=
-left:1ex">
Or, should the public key be the pubkey value and the signing key the<br>
privkey value?=C2=A0 Meaning, each cert uses the supplied public key and th=
e<br>
signing order is:<br>
<br>
=C2=A0 =C2=A0 a signs a<br>
=C2=A0 =C2=A0 a signs b<br>
=C2=A0 =C2=A0 b signs c<br>
<br>
If so, do you want me to send you a PR for this change?<br>
<br><div></div></blockquote><div>=C2=A0</div><div>Heya Jason,</div><div><br=
></div><div>Thanks for pointing this out.=C2=A0 Yes, it&#39;s a bug.=C2=A0 =
Also, it turns out re-using serial numbers is a bad idea too.=C2=A0 I don&#=
39;t think their mistake=C2=A0<i>currently</i>=C2=A0hurts the tests but it =
would be great to get them both fixed.=C2=A0 So a PR would be quite welcome=
.</div><div>=C2=A0</div><div>Regarding Glyph&#39;s comments about where the=
 chain is verified - that&#39;s still handled by the TLS library.=C2=A0 The=
 Chain invariant in _authentication.py is just a superficial sanity check t=
o catch the common problem of &quot;a-b-c&quot; vs &quot;c-b-a&quot; chain =
certificate order.</div><div><br></div><div>Thanks!</div><div>Jean-Paul</di=
v><div><br></div></div></div></div>

--f4030435b7fc1b3764055367c95c--


--===============3500276795187737124==
Content-Type: text/plain; charset="utf-8"
MIME-Version: 1.0
Content-Transfer-Encoding: base64
Content-Disposition: inline

X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KVHdpc3RlZC13
ZWIgbWFpbGluZyBsaXN0ClR3aXN0ZWQtd2ViQHR3aXN0ZWRtYXRyaXguY29tCmh0dHBzOi8vdHdp
c3RlZG1hdHJpeC5jb20vY2dpLWJpbi9tYWlsbWFuL2xpc3RpbmZvL3R3aXN0ZWQtd2ViCg==

--===============3500276795187737124==--