Re: [keyassure] CN/SAN matching (was: End entity certificate

[Martin Rex <[e-mail]>]

Eric Rescorla wrote:
> 
> Jay Daley <[e-mail]> wrote:
> >
> > Richard L. Barnes wrote:
> > >
> > > Nope, it's up to applications.  If you want SN/CAN *not* to be
> > > checked for HTTPS, then you need to go revise RFC 2818; for SMTP,
> > > RFC 3207; for IMAP/POP3, RFC 2595.
> >
> > Indeed.
> >
> > I assumed we were updating RFC 2818.
> 
> In that case, this document will need to be dual last called in the
> TLS WG, since 2818 was a TLS product.

While it doesn't call itself an update to rfc2818 by its document header,
I always assumed it wanted to be this update.

  http://tools.ietf.org/html/rfc6125


The question is more about "if the creator of the certificate placed
attributes in that certificates that are traditionally considered
"constraints" or "usage restrictions", should these be still be honoured,
even if there is no PKIX cert path validation performed on the certificate.

This is why personally, I have a preference to use X.509v1 certs as
self-signed TLS server certs -- there are significantly less attributes
to get wrong by accident.


But the real issue is more about determining intent.
Maybe the DANE TLSA record should also carry a hint whether or not
the cert attributes (anything besides the public key) should
be ignored (= not checked, not seen as usage limitations).

There may be clients in the installed base that have certain
checks or assumptions about presence of specific attributes in
a certificate hardcoded, and the TLS server admin may want to
provide the attributes only/specifically for those old clients
in the installed base -- not for DANE-aware new clients.


-Martin