Re: [keyassure] The draft and subj alt names

[Ondřej Surý <[e-mail]>]

On 1.4.2011 15:56, Martin Rex wrote:
> Jay Daley wrote:
>>
>> 6.  Add a flag into TLSA that specifies
>>      whether name matching is to be done or not
>
> I think that (6.) would be the most sensible solution.

This starts to look like overengineering.  Let's not put too many 
ingreedients into one pot please.

> Especially for self-signed X.509 certificates, it doesn't make sense
> to look at name attributes of the certificate at all, because these
> are all self-asserted attributes, not certified attributes.  The
> only thing that really matters is the public key.

On the other hand it's not that hard to issue a self-signed CA issued 
cert which matches the domain name, isn't it?

The other option would be use the bare keys (see Paul W. proposal in TLS 
WG).  E.g. if you use X.509 do match, if you use bare key, don't match.

> TLSv1.2  1. Introduction, last sentence
>
>    http://tools.ietf.org/html/rfc5246#page-5
>
>                                    the decisions on how to initiate TLS
>     handshaking and how to interpret the authentication certificates
>     exchanged are left to the judgment of the designers and implementors
>     of protocols that run on top of TLS.
>
> HTTP over TLS, 3.1 Server Endpoint Indentification, 2nd paragraph
>
>    http://tools.ietf.org/html/rfc2818#section-3.1
>
>     If the client has external information as to the expected identity of
>     the server, the hostname check MAY be omitted. (For instance, a
>     client may be connecting to a machine whose address and hostname are
>     dynamic but the client knows the certificate that the server will
>     present.)
>
>
> or the new RFC-6125
>
>    http://tools.ietf.org/html/rfc6125#page-8
>
>     o  Keys or certificates employed outside the context of PKIX-based
>        systems.
>
>        Some deployed application technologies use a web of trust model
>        based on or similar to OpenPGP [OPENPGP], or use self-signed
>        certificates, or are deployed on networks that are not directly
>        connected to the public Internet and therefore cannot depend on
>        Certificate Revocation Lists (CRLs) or the Online Certificate
>        Status Protocol [OCSP] to check CA-issued certificates.  However,
>        the method for binding a public key to an identifier in OpenPGP
>        differs essentially from the method in X.509, the data in self-
>        signed certificates has not been certified by a third party in any
>        way, [...]

I think that those paragraphs are exactly the reason why the option 
"Leave it alone - it's up to the application" is most appropriate for 
the DANE WG.  And there will be interest I think that it could be solved 
elsewhere or here as BCP RFC.

O.
-- 
  Ondřej Surý
  vedoucí výzkumu/Head of R&D department
  -------------------------------------------
  CZ.NIC, z.s.p.o.    --    Laboratoře CZ.NIC
  Americka 23, 120 00 Praha 2, Czech Republic
  mailto:[e-mail]    http://nic.cz/
  tel:[phone]       fax:[phone]
  -------------------------------------------