Hi Malcolm,
Thanks for your detailed review about this, I had not idea those RFC's
and the Mozilla bug were there...
Anyway, you logic and analysis clearly shows that that the current
behavior is well accepted by the standards and that Firefox will change
their behavior in line with this.
I guess the consensus is to follow RFC specified behavior, however, if
there are any thoughts on deviations from this in the future, I hope
someone considers making SSL more broadly applicable as
I think that it would really help the Internet considerably (note: my
thoughts only!) in reducing the cost of SSL certificates, whilst still
providing the same level of encryption. I can't see how it could be less
secure but perhaps there is something that I may have overlooked.
Best regards,
Matt
Malcolm Rowe wrote:
> On Fri, Sep 07, 2007 at 09:35:32AM +1200, Matt Bodley wrote:
>
>> It is widely accepted that *.domain.com means xxx.domain.com, but not so
>> clear that this also means yyy.xxx.domain.com, but in my view, this is the
>> same as it follows DNS delegation in both instances (of the implied/inherent
>> trust that is dictated by DNS).
>>
>>
>
> RFC 2595 (which deals with TLS for IMAP and POP3, and was, I believe one
> of the first RFCs to deal with wildcards) simply reads (in 2.4):
>
> - A "*" wildcard character MAY be used as the left-most name
> component in the certificate. For example, *.example.com would
> match a.example.com, foo.example.com, etc. but would not match
> example.com.
>
> So that's not clear either way. RFC 2818 (which deals with TLS for
> HTTP) reads (in 3.1):
>
> ... Names may contain the wildcard
> character * which is considered to match any single domain name
> component or component fragment. E.g., *.a.com matches foo.a.com but
> not bar.foo.a.com. f*.com matches foo.com but not bar.com.
>
> Which is pretty clear as _not_ allowing this behaviour. I understand
> that RFC 4513 also mandates this approach for LDAP.
>
> It also appears that the current Firefox behaviour is considered a bug:
> https://bugzilla.mozilla.org/show_bug.cgi?id=159483
>
> So, while it _might_ arguably make things more complex to keep with the
> current behaviour (but perhaps no more than the widely-understood case
> where a certificate for *.example.com doesn't match http://example.com),
> it seems like it would be a mistake to make a change away from the
> current RFC-compliant behaviour.
>
> Regards,
> Malcolm
>
--
Best Regards,
Matt Bodley
Received on Fri Sep 7 22:46:56 2007