On Fri, 31 Mar 2017 22:21:38 +0200
Joerg Sonnenberger <[email protected]> wrote:
> 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.
My initial diff passed the DN (from which you can get the CN with a
trivial regex) in TLS_PEER_SUBJECT.
That might be enough in some circumstances, but remember that RFC5280
tells us "A CA MAY issue more than one certificate with the same DN to
the same subject entity"...
One common example of that happening is when a cert gets revoked because
its private key has been lost/stolen and the user needs a new cert
associated with the same identity. An even more common example is when
a cert expires & gets renewed.
The only thing that's always required to be unique is {issuer,
serialNumber}.
So at a minimum the serialNumber & issuer are both still necessary for
unique identification (in addition to the DN plus whatever else for
authorisation)...
...unless you've *already* validated that the cert has not been revoked
(but either checking CRLs or doing non-stapled OCSP also requires
knowing the serialNumber).
In fact, your application's authorisation routines can be quite a bit
simpler if your CA adopts a policy of having a 1:1 mapping of entities
to DNs, varying only the serial number & valid date range when renewing
or revoking/reissuing certs -- but that's a matter of personal choice:
nothing wrong with a CA having a "DNs never get reused" rule, but I
don't think it's reasonable to expect *every* CA to do that, given that
RFC5280 explicitly allows DN reuse for the same entity.
I agree with you that it probably makes sense to continue passing the
DN, even if we pass the whole cert as well, so that fastcgi responders
with simple auth schemes using CAs that do implement a "DNs never get
reused" rule don't need to link against libcrypto just to get the DN,
but I don't think that's a reason to shy away from William's good
suggestion of passing the whole cert.
On the other hand the rest of the TLS_PEER_* fastcgi variables from my
initial diff can probably be left out if we're passing the whole cert
(e.g. if you have the cert it's easy enough to generate the hash
yourself).
