On 03/30/2014 03:39 PM, Viktor Dukhovni wrote:
On Sun, Mar 30, 2014 at 11:20:51AM +0200, Steffen Ullrich via RT wrote:
- probably useful: while no RFC currently forbids something like *.com you
have a check to disallow wildcards in the two rightmost suffixes. I think
it makes sense to
I, for one, would not want OpenSSL to employ such a complex and fragile
mechanism.
Yeah, it's kinda gross and clunky. On the other hand, it's really all we have
right now, and rejecting a cert with a SAN name of *.com is a good security
thing to do. Perhaps a configure option, or a
Viktor Dukhovni openssl-users at dukhovni.org writes:
On Tue, Apr 01, 2014 at 12:36:18PM -0400, Daniel Kahn Gillmor wrote:
I think the current best approach to this is the public suffix
list, http://publicsuffix.org/ it's a horrible kludge (a
fully-enumerated list of all zones that are
On Tue, Apr 01, 2014 at 05:03:32PM -0400, Salz, Rich wrote:
I, for one, would not want OpenSSL to employ such a complex
and fragile mechanism.
Yeah, it's kinda gross and clunky. On the other hand, it's really
all we have right now, and rejecting a cert with a SAN name of
*.com is a good
Note that the implementation in master (some day 1.1.0) already rejects
*.com, what it fails to reject is *.co.uk
Yes, I understand; my example was wrong, sorry.
I think the onus is on the trusted CA ( that wants to remain trusted) to not
issue such certificates.
And mistake-free?
I am
On Tue, Apr 01, 2014, Viktor Dukhovni wrote:
On Tue, Apr 01, 2014 at 05:03:32PM -0400, Salz, Rich wrote:
I, for one, would not want OpenSSL to employ such a complex
and fragile mechanism.
Yeah, it's kinda gross and clunky. On the other hand, it's really
all we have right now, and
On Wed, Apr 02, 2014 at 12:57:28AM +0200, Dr. Stephen Henson wrote:
I am far from sure the callback is worth the trouble.
The initial aim of X509_check_host was to support minimal host name matching
which until then wasn't in OpenSSL at all. It wasn't intended to cover every
case but to be
On Tue, Apr 01, 2014, Viktor Dukhovni wrote:
What were your plans for X509_VERIFY_PARAM_ID_st for DANE? That's
where the TLSA records were going to be right?
If you post a note about the approach you want to take with extending
X509_VERIFY_PARAM_ID_st I can provide a more complete patch.
Viktor Dukhovni wrote:
I can contribute a patch, that addresses many of the issues. Things
that I'm not immediately planning to address are:
- Separate flag for wildcards in CN vs. wildcards in SAN dnsName.
(LDAP case in RFC 6125).
Just to add context - the LDAP RFCs always
On Tue, Apr 01, 2014 at 07:07:10PM -0700, Howard Chu wrote:
Viktor Dukhovni wrote:
I can contribute a patch, that addresses many of the issues. Things
that I'm not immediately planning to address are:
- Separate flag for wildcards in CN vs. wildcards in SAN dnsName.
(LDAP case
Viktor Dukhovni wrote:
On Tue, Apr 01, 2014 at 07:07:10PM -0700, Howard Chu wrote:
Viktor Dukhovni wrote:
I can contribute a patch, that addresses many of the issues. Things
that I'm not immediately planning to address are:
- Separate flag for wildcards in CN vs. wildcards in SAN
11 matches
Mail list logo
