Re: [Danish] revised charter text from Tuesday morning

[Viktor Dukhovni <[e-mail]>]

> On 22 Jun 2021, at 10:40 am, Michael Richardson <[e-mail]> wrote:
> 
> The process of establishing trust in public-key-authenticated identity
> typically involves the use of a Public Key Infrastructure (PKI), and a
> shared PKI root of trust between the parties exchanging public keys. A
> Certification Authority (CA) is one example of a PKI which can be used for
> establishing trust in public keys.

I don't think it is correct to conflate a CA with a PKI.  A PKI is an ecosystem,
that consists of some mixture of:

  * Relying parties
  * Key holders
  * Certification authorities
  * Registration Authorities
  * CRL distribution services
  * OCSP services
  * CT logs?
  * ...

A CA's public key (or the associated certificate) can be a trust-anchor in a PKI,
but is not in itself a PKI.

> The DNS namespace, together with DNSSEC, forms the most widely-recognized
> namespace and authenticated discovery mechanism on the Internet.

This rather lacks context and looks poorly framed to me.  Why are we suddenly
talking about "discovery".  DNS is a distributed directly (lookup) service, it
is not a "discovery" mechanism, even if some "discovery" mechanisms happen to
leverage DNS at some point.

DNS is the largest (only) Internet-wide federated namespace.  DNSSEC provides
end-to-end integrity for DNS, obviating the need to trust intermediate caches.
DNSSEC also makes it possible to securely publish the public keys or
certificates of (DNS) named entities.

> DANE builds on this authenticated discovery mechanism to enable public key-based
> TLS authentication which is resilient to impersonation, but only for TLS
> server identities.

DNS is not a discovery mechanism.  DANE makes it possible to securely look up
the public key or certificate (in full or a digest) associated with a (DNS)
named entity.  In the case of TLS, DANE presently only defines naming for
server endpoints.

> What DANE did not define is how services can authenticate connecting clients.

There is presently no standard definition of client identity names, nor how a
client would communicate its DNS name to a server in a given protocol.

> In response to the challenges related to ambiguity between client identities issued
> by different CAs, application owners frequently choose to onboard IoT devices
> to a single private CA specific to that vertical.

All mention of "ambiguity" needs to go.  It is misleading and not the real issue
at hand.  The problem is not "ambiguity".  The relevant concerns are:

  * Need for global names.  If the relying party is not also the owner/operator
    of a private PKI, but rather relies on a global PKI, then of course the
    names being authenticated need to be global (e.g. DNS names).

  * Need to scope trust.  In many applications it is not acceptable to trust
    client identities issued by all the various CAs of the WebPKI.

Ambiguity is not relevant, and fails to capture the key issues.

-- 
	Viktor.