Re: httpd/libtls: TLS client certificate revocation checking

[Joerg Sonnenberger]

On Fri, Mar 31, 2017 at 01:03:44PM -0700, William Ahern wrote:
> Basically, anything short of passing through the entire certificate is going
> to be severely limiting and frustrating, to the point of uselessness.

Passing down the common name is normally enough, but not doing that
makes it nearly useless. Speaking from the perspective of using them in
the wild.

Joerg

Re: httpd/libtls: TLS client certificate revocation checking

[William Ahern]

On Thu, Mar 30, 2017 at 10:31:06PM +1030, Jack Burton wrote:

> Personally, I'm leaning towards either local CRL file checking in
> httpd (with minimal changes to libtls), or passing through enough data
> to the let the fastcgi responders take whichever approach they want.

In all my experience with client certificates (whether with browsers, IPSec,
or custom applications), I've usually relied on the ability to embed data in
the client certificate, such as domains, e-mail addresses, UUIDs, etc. That
often entirely removed the need to do database queries from application code
or to maintain and expose any centralized data store (except the CRL, of
course) to network-facing nodes.

In other words, client certificates not only solve the authentication
problem, but can also help solve the authorization problem, and in many
cases solve it completely.

My $0.02: client certificates aren't particularly useful unless the
certificate itself is made available to the application. Knowing that a
certificate has a valid signature is only part of the equation, and not even
the most useful part. Unlike server certificates, however, there's no single
authorization check (i.e. matching the embedded domain name to the queried
URL) that can be implemented by middle-ware. The semantics of embedded data
are specific to a service and often ad hoc.

Basically, anything short of passing through the entire certificate is going
to be severely limiting and frustrating, to the point of uselessness. And as
a practical matter, parsing out and passing through a subset of certificate
data is likely going to require more complex code than just passing the
entire certificate to the application.

umass: Enable KASSERTs

[Christian Ludwig]

Since the dawn of umass(4) in OpenBSD, KASSERTs have been disabled in
the driver. These were ported from NetBSD, but never enabled. I think
it is a good idea to have them to spot potential coding mistakes.

While there, convert some KASSERTs to CTASSERTs that can be catched
during compile-time. This also avoids fixing format-string errors in
their messages.

Since these assertions have never been enabled before, please test that
patch extensively. I have not had any issues with it, but I was doing
some light testing only.
---
 sys/dev/usb/umass.c | 21 +++--
 1 file changed, 7 insertions(+), 14 deletions(-)

diff --git a/sys/dev/usb/umass.c b/sys/dev/usb/umass.c
index 0fc1782..e158e70 100644
--- a/sys/dev/usb/umass.c
+++ b/sys/dev/usb/umass.c
@@ -131,8 +131,6 @@
 #include 
 #include 
 #include 
-#undef KASSERT
-#define KASSERT(cond, msg)
 #include 
 
 #include 
@@ -146,6 +144,10 @@
 #include 
 #include 
 
+#ifdef DIAGNOSTIC
+#undef KASSERT
+#define KASSERT(cond, complaint) if (!(cond)) panic complaint
+#endif
 
 #ifdef UMASS_DEBUG
 int umassdebug = 0;
@@ -982,14 +984,8 @@ umass_bbb_transfer(struct umass_softc *sc, int lun, void 
*cmd, int cmdlen,
KASSERT(datalen == 0 || dir != DIR_NONE,
("%s: direction is NONE while datalen is not zero\n",
sc->sc_dev.dv_xname));
-   KASSERT(sizeof(struct umass_bbb_cbw) == UMASS_BBB_CBW_SIZE,
-   ("%s: CBW struct does not have the right size (%d vs. %d)\n",
-   sc->sc_dev.dv_xname,
-   sizeof(struct umass_bbb_cbw), UMASS_BBB_CBW_SIZE));
-   KASSERT(sizeof(struct umass_bbb_csw) == UMASS_BBB_CSW_SIZE,
-   ("%s: CSW struct does not have the right size (%d vs. %d)\n",
-   sc->sc_dev.dv_xname,
-   sizeof(struct umass_bbb_csw), UMASS_BBB_CSW_SIZE));
+   CTASSERT(sizeof(struct umass_bbb_cbw) == UMASS_BBB_CBW_SIZE);
+   CTASSERT(sizeof(struct umass_bbb_csw) == UMASS_BBB_CSW_SIZE);
 
/*
 * Determine the direction of the data transfer and the length.
@@ -1409,10 +1405,7 @@ umass_cbi_reset(struct umass_softc *sc, int status)
DPRINTF(UDMASS_CBI, ("%s: CBI Reset\n",
sc->sc_dev.dv_xname));
 
-   KASSERT(sizeof(sc->cbl) >= SEND_DIAGNOSTIC_CMDLEN,
-   ("%s: CBL struct is too small (%d < %d)\n",
-   sc->sc_dev.dv_xname,
-   sizeof(sc->cbl), SEND_DIAGNOSTIC_CMDLEN));
+   CTASSERT(sizeof(sc->cbl) >= SEND_DIAGNOSTIC_CMDLEN);
 
sc->transfer_state = TSTATE_CBI_RESET1;
sc->transfer_status = status;
-- 
2.1.4

Re: sync root.mail

[Marc Espie]

On Thu, Mar 30, 2017 at 09:00:41PM +0200, Jeremie Courreges-Anglas wrote:
> Marc Espie  writes:
> 
> > On Wed, Mar 29, 2017 at 09:40:32PM +0200, Christian Weisgerber wrote:
> >> Antoine Jacoutot:
> >> 
> >> > Why not just:
> >> > 
> >> > # pkg_add -v rsync chromium emacs--no_x11
> >> > 
> >> > So we don't have to change it each release?
> >> 
> >> Because people won't let Emacs 21 die.
> >> 
> >> Ambiguous: choose package for emacs--no_x11
> >> a   0: 
> >> 1: emacs-21.4p37-no_x11
> >> 2: emacs-25.1p3-no_x11
> >> Your choice:
> >
> > pkg_add -v rsync chromium emacs--no_x11%emacs
> 
> Omitting the version, adding a flavor and specifying a branch is a bit
> verbose IMHO.  Like Antoine, I'd prefer if we stopped listing emacs
> here.

Think about it.

In one line, you explain to people how to do this kind of thing, so that
noobs get to figure out how to get to flavors and branches without specifying
version numbers.

Is that a win or a loss ?

cdce(4): replace CRC32 function with common ether_crc32_le

[Hiltjo Posthuma]

Hi,

This patch removes the CRC32 function from the driver and uses the common
function ether_crc32_le.

Maybe worth noting is that by testing in userspace using gcc -O0 the
specific cdce(4) CRC32 function is about twice as fast as ether_crc32_le.

Apart from this no functional change is intended.

Tested on amd64.

Diff below:


diff --git a/sys/dev/usb/if_cdce.c b/sys/dev/usb/if_cdce.c
index 750382d650b..1862e321e6c 100644
--- a/sys/dev/usb/if_cdce.c
+++ b/sys/dev/usb/if_cdce.c
@@ -88,7 +88,6 @@ void   cdce_init(void *);
 voidcdce_watchdog(struct ifnet *);
 voidcdce_stop(struct cdce_softc *);
 voidcdce_intr(struct usbd_xfer *, void *, usbd_status);
-static uint32_t cdce_crc32(const void *, size_t);
 
 const struct cdce_type cdce_devs[] = {
 {{ USB_VENDOR_ACERLABS, USB_PRODUCT_ACERLABS_M5632 }, 0 },
@@ -413,7 +412,7 @@ cdce_encap(struct cdce_softc *sc, struct mbuf *m, int idx)
/* Some devices want a 32-bit CRC appended to every frame */
u_int32_t crc;
 
-   crc = cdce_crc32(c->cdce_buf, m->m_pkthdr.len);
+   crc = ether_crc32_le(c->cdce_buf, m->m_pkthdr.len) ^ ~0U;
bcopy(, c->cdce_buf + m->m_pkthdr.len, 4);
extra = 4;
}
@@ -866,69 +865,3 @@ cdce_intr(struct usbd_xfer *xfer, void *addr, usbd_status 
status)
}
 #endif
 }
-
-
-/*  COPYRIGHT (C) 1986 Gary S. Brown.  You may use this program, or
- *  code or tables extracted from it, as desired without restriction.
- */
-
-static uint32_t cdce_crc32_tab[] = {
-   0x, 0x77073096, 0xee0e612c, 0x990951ba, 0x076dc419, 0x706af48f,
-   0xe963a535, 0x9e6495a3, 0x0edb8832, 0x79dcb8a4, 0xe0d5e91e, 0x97d2d988,
-   0x09b64c2b, 0x7eb17cbd, 0xe7b82d07, 0x90bf1d91, 0x1db71064, 0x6ab020f2,
-   0xf3b97148, 0x84be41de, 0x1adad47d, 0x6ddde4eb, 0xf4d4b551, 0x83d385c7,
-   0x136c9856, 0x646ba8c0, 0xfd62f97a, 0x8a65c9ec, 0x14015c4f, 0x63066cd9,
-   0xfa0f3d63, 0x8d080df5, 0x3b6e20c8, 0x4c69105e, 0xd56041e4, 0xa2677172,
-   0x3c03e4d1, 0x4b04d447, 0xd20d85fd, 0xa50ab56b, 0x35b5a8fa, 0x42b2986c,
-   0xdbbbc9d6, 0xacbcf940, 0x32d86ce3, 0x45df5c75, 0xdcd60dcf, 0xabd13d59,
-   0x26d930ac, 0x51de003a, 0xc8d75180, 0xbfd06116, 0x21b4f4b5, 0x56b3c423,
-   0xcfba9599, 0xb8bda50f, 0x2802b89e, 0x5f058808, 0xc60cd9b2, 0xb10be924,
-   0x2f6f7c87, 0x58684c11, 0xc1611dab, 0xb6662d3d, 0x76dc4190, 0x01db7106,
-   0x98d220bc, 0xefd5102a, 0x71b18589, 0x06b6b51f, 0x9fbfe4a5, 0xe8b8d433,
-   0x7807c9a2, 0x0f00f934, 0x9609a88e, 0xe10e9818, 0x7f6a0dbb, 0x086d3d2d,
-   0x91646c97, 0xe6635c01, 0x6b6b51f4, 0x1c6c6162, 0x856530d8, 0xf262004e,
-   0x6c0695ed, 0x1b01a57b, 0x8208f4c1, 0xf50fc457, 0x65b0d9c6, 0x12b7e950,
-   0x8bbeb8ea, 0xfcb9887c, 0x62dd1ddf, 0x15da2d49, 0x8cd37cf3, 0xfbd44c65,
-   0x4db26158, 0x3ab551ce, 0xa3bc0074, 0xd4bb30e2, 0x4adfa541, 0x3dd895d7,
-   0xa4d1c46d, 0xd3d6f4fb, 0x4369e96a, 0x346ed9fc, 0xad678846, 0xda60b8d0,
-   0x44042d73, 0x33031de5, 0xaa0a4c5f, 0xdd0d7cc9, 0x5005713c, 0x270241aa,
-   0xbe0b1010, 0xc90c2086, 0x5768b525, 0x206f85b3, 0xb966d409, 0xce61e49f,
-   0x5edef90e, 0x29d9c998, 0xb0d09822, 0xc7d7a8b4, 0x59b33d17, 0x2eb40d81,
-   0xb7bd5c3b, 0xc0ba6cad, 0xedb88320, 0x9abfb3b6, 0x03b6e20c, 0x74b1d29a,
-   0xead54739, 0x9dd277af, 0x04db2615, 0x73dc1683, 0xe3630b12, 0x94643b84,
-   0x0d6d6a3e, 0x7a6a5aa8, 0xe40ecf0b, 0x9309ff9d, 0x0a00ae27, 0x7d079eb1,
-   0xf00f9344, 0x8708a3d2, 0x1e01f268, 0x6906c2fe, 0xf762575d, 0x806567cb,
-   0x196c3671, 0x6e6b06e7, 0xfed41b76, 0x89d32be0, 0x10da7a5a, 0x67dd4acc,
-   0xf9b9df6f, 0x8ebeeff9, 0x17b7be43, 0x60b08ed5, 0xd6d6a3e8, 0xa1d1937e,
-   0x38d8c2c4, 0x4fdff252, 0xd1bb67f1, 0xa6bc5767, 0x3fb506dd, 0x48b2364b,
-   0xd80d2bda, 0xaf0a1b4c, 0x36034af6, 0x41047a60, 0xdf60efc3, 0xa867df55,
-   0x316e8eef, 0x4669be79, 0xcb61b38c, 0xbc66831a, 0x256fd2a0, 0x5268e236,
-   0xcc0c7795, 0xbb0b4703, 0x220216b9, 0x5505262f, 0xc5ba3bbe, 0xb2bd0b28,
-   0x2bb45a92, 0x5cb36a04, 0xc2d7ffa7, 0xb5d0cf31, 0x2cd99e8b, 0x5bdeae1d,
-   0x9b64c2b0, 0xec63f226, 0x756aa39c, 0x026d930a, 0x9c0906a9, 0xeb0e363f,
-   0x72076785, 0x05005713, 0x95bf4a82, 0xe2b87a14, 0x7bb12bae, 0x0cb61b38,
-   0x92d28e9b, 0xe5d5be0d, 0x7cdcefb7, 0x0bdbdf21, 0x86d3d2d4, 0xf1d4e242,
-   0x68ddb3f8, 0x1fda836e, 0x81be16cd, 0xf6b9265b, 0x6fb077e1, 0x18b74777,
-   0x88085ae6, 0xff0f6a70, 0x66063bca, 0x11010b5c, 0x8f659eff, 0xf862ae69,
-   0x616bffd3, 0x166ccf45, 0xa00ae278, 0xd70dd2ee, 0x4e048354, 0x3903b3c2,
-   0xa7672661, 0xd06016f7, 0x4969474d, 0x3e6e77db, 0xaed16a4a, 0xd9d65adc,
-   0x40df0b66, 0x37d83bf0, 0xa9bcae53, 0xdebb9ec5, 0x47b2cf7f, 0x30b5ffe9,
-   0xbdbdf21c, 0xcabac28a, 0x53b39330, 0x24b4a3a6, 0xbad03605, 0xcdd70693,
-   0x54de5729, 0x23d967bf, 0xb3667a2e, 0xc4614ab8, 0x5d681b02, 0x2a6f2b94,
-   0xb40bbe37, 0xc30c8ea1, 0x5a05df1b, 0x2d02ef8d
-};
-
-uint32_t

Re: usermod.8 patch

[Philipp Buehler]

Am 31.03.2017 15:39 schrieb Jeremie Courreges-Anglas:

I think the current wording is fine; no need for an option to set
_default_ values.


options are good - as long as they're optional --art

--
pb

Re: usermod.8 patch

[Edgar Pettijohn]

Sent from my iPhone

> On Mar 31, 2017, at 8:44 AM, Matthew Martin  wrote:
> 
>> On Fri, Mar 31, 2017 at 08:03:44AM -0500, Edgar Pettijohn wrote:
>> usermod(8) doesn't have an option for setting defaults.  Here is a patch to
>> correct the manual.
> 
> I believe it's referring to user.c read_defaults which calls setdefaults
> before reading the defaults.

I guess that's possible.

Re: usermod.8 patch

[Matthew Martin]

On Fri, Mar 31, 2017 at 08:03:44AM -0500, Edgar Pettijohn wrote:
> usermod(8) doesn't have an option for setting defaults.  Here is a patch to
> correct the manual.

I believe it's referring to user.c read_defaults which calls setdefaults
before reading the defaults.

Re: usermod.8 patch

[Jeremie Courreges-Anglas]

Edgar Pettijohn  writes:

> usermod(8) doesn't have an option for setting defaults.  Here is a patch
> to correct the manual.

I think the current wording is fine; no need for an option to set
_default_ values.

> Index: usermod.8
> ===
> RCS file: /cvs/src/usr.sbin/user/usermod.8,v
> retrieving revision 1.35
> diff -u -p -u -r1.35 usermod.8
> --- usermod.8 30 Nov 2016 20:26:37 -  1.35
> +++ usermod.8 31 Mar 2017 13:00:42 -
> @@ -60,7 +60,7 @@ Default values are taken from the inform
>  file, which, if running as root, is created using the built-in defaults if
>  it does not exist.
>  .Pp
> -After setting any defaults, and then reading values from
> +After reading values from
>  .Pa /etc/usermgmt.conf ,
>  the following command line options are processed:
>  .Bl -tag -width Ds
>

-- 
jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF  DDCC 0DFA 74AE 1524 E7EE

usermod.8 patch

[Edgar Pettijohn]

usermod(8) doesn't have an option for setting defaults.  Here is a patch 
to correct the manual.


Index: usermod.8
===
RCS file: /cvs/src/usr.sbin/user/usermod.8,v
retrieving revision 1.35
diff -u -p -u -r1.35 usermod.8
--- usermod.8	30 Nov 2016 20:26:37 -	1.35
+++ usermod.8	31 Mar 2017 13:00:42 -
@@ -60,7 +60,7 @@ Default values are taken from the inform
 file, which, if running as root, is created using the built-in defaults if
 it does not exist.
 .Pp
-After setting any defaults, and then reading values from
+After reading values from
 .Pa /etc/usermgmt.conf ,
 the following command line options are processed:
 .Bl -tag -width Ds

Another arm64 pmap cleanup diff

[Mark Kettenis]

On ARMv8, the translation table walk is fully coherent so there is no
reason to explicitly flush the cache before invalidating the TLB.  The
barrier that is included in out TLB flushing code should be enough to
guarantee that the TLB walking hardware sees the updated page table
contents, so the explicit barriers can go as well.  Diff also
sanitizes the code immediately around the removed bits of code to drop
redundant curly braces, avoid C++ style comments and removes some
blank lines that aren't particular useful.

Can somebody give this a spin on hardware with a Cortex-A57 and verify
that this doesn't make things more unstable?

Index: arch/arm64/arm64/pmap.c
===
RCS file: /cvs/src/sys/arch/arm64/arm64/pmap.c,v
retrieving revision 1.29
diff -u -p -r1.29 pmap.c
--- arch/arm64/arm64/pmap.c 28 Mar 2017 18:23:53 -  1.29
+++ arch/arm64/arm64/pmap.c 31 Mar 2017 11:49:19 -
@@ -1304,24 +1304,21 @@ pmap_set_l1(struct pmap *pm, uint64_t va
int idx0;
 
if (l1_pa == 0) {
-   // if this is called from pmap_vp_enter, this is a normally
-   // mapped page, call pmap_extract to get pa
+   /*
+* if this is called from pmap_vp_enter, this is a
+* normally mapped page, call pmap_extract to get pa
+*/
pmap_extract(pmap_kernel(), (vaddr_t)l1_va, _pa);
}
 
-   if (l1_pa & (Lx_TABLE_ALIGN-1)) {
+   if (l1_pa & (Lx_TABLE_ALIGN-1))
panic("misaligned L2 table\n");
-   }
 
pg_entry = VP_Lx(l1_pa);
 
idx0 = VP_IDX0(va);
pm->pm_vp.l0->vp[idx0] = l1_va;
-
pm->pm_vp.l0->l0[idx0] = pg_entry;
-   __asm __volatile("dsb sy");
-
-   cpu_dcache_wb_range((vaddr_t)>pm_vp.l0->l0[idx0], 8);
 
ttlb_flush_range(pm, va & ~PAGE_MASK, 1<have_4_level_pt) {
+   if (pm->have_4_level_pt)
vp1 = pm->pm_vp.l0->vp[idx0];
-   } else {
+   else
vp1 = pm->pm_vp.l1;
-   }
vp1->vp[idx1] = l2_va;
vp1->l1[idx1] = pg_entry;
 
-   __asm __volatile("dsb sy");
-   cpu_dcache_wb_range((vaddr_t)>l1[idx1], 8);
-
ttlb_flush_range(pm, va & ~PAGE_MASK, 1<have_4_level_pt) {
+   if (pm->have_4_level_pt)
vp1 = pm->pm_vp.l0->vp[idx0];
-   } else {
+   else
vp1 = pm->pm_vp.l1;
-   }
vp2 = vp1->vp[idx1];
-
vp2->vp[idx2] = l3_va;
vp2->l2[idx2] = pg_entry;
-   __asm __volatile("dsb sy");
-   cpu_dcache_wb_range((vaddr_t)>l2[idx2], 8);
 
ttlb_flush_range(pm, va & ~PAGE_MASK, 1<pted_pmap;
uint64_t attr = 0;
 
-   // see mair in locore.S
+   /* see mair in locore.S */
switch (pted->pted_va & PMAP_CACHE_BITS) {
case PMAP_CACHE_WB:
-   attr |= ATTR_IDX(PTE_ATTR_WB); // inner and outer writeback
+   /* inner and outer writeback */
+   attr |= ATTR_IDX(PTE_ATTR_WB);
attr |= ATTR_SH(SH_INNER);
break;
case PMAP_CACHE_WT:
-   attr |= ATTR_IDX(PTE_ATTR_WT); // inner and outer writethrough
+/* inner and outer writethrough */
+   attr |= 

usage() in chpass(1)

[Michael W. Bombardieri]

Hi,

The following patch makes chpass(1) fail even faster when
the wrong options are provided and usage() would be printed.
In other words, no point accessing environment variables
before checking result of getopt().

- Michael


Index: chpass.c
===
RCS file: /cvs/src/usr.bin/chpass/chpass.c,v
retrieving revision 1.43
diff -u -p -u -r1.43 chpass.c
--- chpass.c26 Nov 2015 19:01:47 -  1.43
+++ chpass.c31 Mar 2017 08:03:37 -
@@ -66,13 +66,6 @@ main(int argc, char *argv[])
char *tz, *arg = NULL;
sigset_t fullset;
 
-   /* We need to use the system timezone for date conversions. */
-   if ((tz = getenv("TZ")) != NULL) {
-   unsetenv("TZ");
-   tzset();
-   setenv("TZ", tz, 1);
-   }
-
op = EDITENTRY;
while ((ch = getopt(argc, argv, "a:s:")) != -1)
switch(ch) {
@@ -90,6 +83,13 @@ main(int argc, char *argv[])
}
argc -= optind;
argv += optind;
+
+   /* We need to use the system timezone for date conversions. */
+   if ((tz = getenv("TZ")) != NULL) {
+   unsetenv("TZ");
+   tzset();
+   setenv("TZ", tz, 1);
+   }
 
uid = getuid();
 

Re: httpd: proposed patch to add TLS client certificate support

[Jack Burton]

On Thu, 30 Mar 2017 21:47:34 +0200
Jan Klemkow  wrote:
> I'm not a developer (just a contributor), but I worked on httpd client
> certs a year ago, too.  (https://marc.info/?t=14528592613=1=2)

Interesting. Thanks Jan, I hadn't seen your earlier diffs before (my
fault -- I guess I should have searched further back in the list
archives to begin with)

> I got a private response from a developer, who had an own similar diff
> in preparation.  He told me that is better to name configuration
> option "client ca " instead of "ca ".

I just went with single words for consistency: apart from "ticket
lifetime", all the other tls options were single words. It's just
semantics though: "client ca " sounds fine to me too, happy to
use that instead.

What's more interesting is learning now that there were two of you
working on this a year ago. I'm curious as to why that didn't proceed --
strategic decision not to go down that path, or waiting for OCSP
support in libtls (which arrived more recently), or the project just had
other priorities?

> You could adapt my regression test to make sure the feature does not
> break in future development:
> https://marc.info/?l=openbsd-tech=146289968117988=2

Good idea. Can do. My only comment on tests/args-tls.pl in your diff is
that it might be better to test client TLS connections both with &
without client TLS certs (I haven't tried your diff, but a quick read
show that it just modified an existing TLS test to use a client cert).

> I had not time to test your diff, but I like it.  I also need this
> feature in httpd.

Thanks. Your diff & mine have quite a bit in common, but there's a few
points of difference worth noting:

I think passing through TLS_PEER_* to fastcgi (as my diff did) is
pretty much essential (even if we end up checking revocation status
in httpd itself or in libtls, instead of leaving it to the fastcgi
responders), as authentication usually goes hand-in-hand with
authorisation, so fastcgi responders need some way (ideally issuer, DN
& serial number, but issuer, DN & cert hash is at least a start) of
knowing *which* certificate was used for authentication.

Your diff defined tls options for both mandatory (request & require) and
optional (request but do not require) client cert checking. Mine only
defined a tls option for mandatory checking -- mainly because I've never
yet seen a real world use case for optional client cert checking that
couldn't be implemented more coherently (not to mention more safely)
some other way... but perhaps I was wrong. Is the optional mode worth
having? If so, why?

Your diff used chunked transfers for config_{get,set}tls(), to avoid
the hard limit of imsg transfers. In my local tests I had only two
certs (for root & subordinate CAs) in the client CA file (and they
were only throwaway certs for testing, with relatively small moduli),
so I didn't run into the imsg size limit. But if the chain or the certs
in it were any longer, then yes the size limit would cause problems.
Having seen your code now, I think your chunked transfer approach makes
good sense.

Is it worth putting forward another diff with those changes now, or
should I wait to hear whether the feature would be considered welcome
or not first?

> In response of your second mail:
> I prefer the Idea to handle revocations by a CRL which is checked by
> libtls in case of client certificates.

Thanks. Yes, I agree that CRLs are *probably* the way to go here
(OCSP being a bit problematic for client certs in most, but not all,
circumstances).

I can also see the benefit of handling local CRL file checking in
libtls (reusable beyond just httpd), but wonder if that needs to be
balanced against the flexibility of delegating revocation checks to the
fastcgi responders (as some sites -- e.g. where there are no WAN links
involved -- might be better served by doing online OCSP, whereas most
others will likely prefer local CRL files -- so passing through both
URIs from the cert, plus the serial number would allow greater choice).

That's probably the matter I'd like some guidance from the devs on
the most -- as it's almost more about policy than about the code.

> btw: As far as I know, there is a source tree lock at the moment.
> Thus, it may take some time to integrate you diff.

Thanks. Yes, I've heard that and am definitely NOT trying to get this
into 6.1!

But I still think it's worth having these discussions now, so that by
the time the 6.1 release is done & dusted we might have something to add
that's actually worth committing, rather than just my first cut diff and
a few initial thoughts...