[Cryptography] Mutually authenticated TLS

Kevin W. Wall kevin.w.wall at gmail.com
Mon Mar 5 18:50:49 EST 2018


[Moderator: Sorry if this is slightly OT. I think it is tangentially
related to cryptography, but if a moderator rejects it, I'll
understand. But people here a a lot more clueful than those on Stack
Overflow, so I'm hoping it is allowed.]

I'm working with someone who is issuing X.509 client-side certificates
used for authenticating against a REST-base web service.

That person is says that the server code for the web service is only
checking for a specific OU in the client cert's DN to do the
authentication. (There are validating the entire cert chain and have
an internal CA that has to issue the cert.) I tried to explain that
ideally, the entire client cert or at least it's public key should be
used for the authentication process, but short of that, at least use
the full, canonicalized DN.

I find it rather odd that if they are going to use only a portion of
the DN, that they wouldn't at least use the CN rather than some OU and
explained my concern about having two different DNs with the same OU
(which is supposed to represent a specific client application invoking
the web service). E.g., one DN containing OU=abc,OU=applName and the
other containing only OU=applName and otherwise the same. Because the
server is only looking if the DN contains 'OU=applName', then the
[supposedly unauthorized] cert with the DN containing
'OU=abc,OU=applName' could be used to authenticate as well, even
though only the one with a single 'OU-applName' was intended to be
allowed. (Fortunately, the intermediate CA is manually vetting all
requests and there's a very small number of clients certs issues so
they claim they would catch this by their manual vetting process, but
still it leaves me feeling a bit uneasy.)

They are telling me that what *they* are doing is "standard practice"
and what I was proposing (to minimally at least check the full,
canonicalized DN) as "an acceptable compromise under some conditions,
but should be avoided".

So I was just wondering, is anyone aware of any standards documents
such as RFCs or some widely cited "best practices" document that I can
refer them to?

Thanks,
-kevin
-
Blog: http://off-the-wall-security.blogspot.com/    | Twitter: @KevinWWall
NSA: All your crypto bit are belong to us.


More information about the cryptography mailing list