On 10/01/2019 18:00, Michael Wojcik wrote:
From: openssl-users [mailto:openssl-users-boun...@openssl.org] On Behalf Of
Jordan Brown
Sent: Thursday, January 10, 2019 11:15
On 1/9/2019 6:54 PM, Corey Minyard wrote:
2. Set the userid in the certificate and use client authentication to
authenticate the user logging in. Set the username in the CN field
of the certificate so it can't be changed, extract that and set the
CA before verification. This is what I'm currently trying to do,
and I keep running into roadblocks.
Why do you think you need to set the CA?
Agreed. That's an odd requirement.
Then you look at their subject name to derive the user ID (probably from its
CN).
That's one logical option, but some systems (e.g. IBM zOS) instead maintain a database
mapping client certificates to system user IDs. That has the advantage of not imposing
any particular requirement on the client certificate's subject name format, with the
disadvantage of additional administration. (For HTTPS, there's a provision for
"automatic registration" where an unrecognized but valid and trusted client
certificate will trigger HTTP Basic Authentication, and if those credentials are verified
by the OS, the certificate is added to the database.) The database may index certificates
by subject DN (for ease of administration, e.g. when certificates are renewed) or by
fingerprint (as a defense against impersonation if a CA is compromised).
If you want to be really paranoid - if you believe that Verisign can vouch for
John
and Comodo can vouch for Sam, but not vice versa, factor the issuer name into
the process.
Right. For the original "set the CA" plan to work, you would need to already
have some association between client certificates and CAs, so you can simply check that a
validated client certificate was issued by the expected CA.
But again this would be an unusual requirement; and even if it exists, the
contemporary standard mechanism for guarding against rogue or compromised CAs
is Certificate Transparency. Checking CT logs seems like overkill in this case,
and it would arguably be more useful to implement revocation checks and other
defenses first; but if restricting certificates by issuer is important for some
reason, CT might be a better approach than inventing your own mechanism.
CT does nothing of the sort, it just provides a means to ensure all
certificates are potentially subject to 3rd party audits.
And CT cannot be legally used for user certificates anyway because
CT publishes unredacted certificate content to the world.
One really should be careful with security ideas from a company whose
main source of income is to spy on the world population for profit.
Regarding Corey's original note: SSL/TLS does not have a "username" concept
because it would be redundant or inconsistent. A certificate is a peer identifier; it
takes the place of a username.
Enjoy
Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark. Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded
--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
