Here's a set of obvious questions:
-- What is the current design?
Is there a concise-and-complete statement somewhere?
-- What are the design constraints?
What is it that openssl MUST do?
What is it that openssl MUST NOT do?
-- What information is available?
-- What critical information is not available,
and why not?
I mention this because I read things like "deprecated"
and "working as designed" ... referring to the same
features AFAICT. Also I read "the best one can do,
absent additional information" and it makes me wonder.
In particular, at some point one could consider
changing the design to obtain additional info. For
starters, one could imagine an interface that says
in effect:
int isOK = this_site_sent_me_this_webPKI_cert(sitename, cert, ...);
The point is that when this interface is used, we don't
need to worry about CN="Joe Bloggs" s/mime issues. We
know it's supposed to be a webPKI cert and anything else
MUST be rejected.
-- For that matter, in this context, nowadays the CN
SHOULD be ignored completely in favor of SANs.
-- Especially when there are nameConstraints or other
v3 features in the cert, I would suggest the CN MUST
be ignored in favor of SANs.
++ More generally, the interface should demand whatever
information is needed in order to make an intelligent
decision.
==================
As a sidelight, not important but amusing, one might wonder:
What is it supposed to mean when a name-constrained CA issues
a CN="Joe Bloggs" certificate? Why would anyone want to rely
on such a cert? Before we decide this is working as designed,
it might be nice to take a close look at the design.
In any case, I would suggest that the s/mime tail should not
be allowed to wag the webPKI dog.
--
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=3502
Please log in as guest with password guest if prompted
--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
