Re: [Danish] Charter Text and the Problem Statement

[Viktor Dukhovni <[e-mail]>]

On Wed, Jun 16, 2021 at 02:27:48PM -0700, Ash Wilson wrote:

> CAs guarantee the uniqueness of an entity's name within the scope of the
> CA, but have no method for enforcing name uniqueness across other CAs.

Uniqueness is not the property you're looking for.  It doesn't matter
how many keys a CA binds the same name to, so long as all those keys are
legitimately associated with the same entity.  Overlap is perfectly
normal, e.g. across renewals CAs don't typically revoke the (soon(ish) to
expire) previous certificate.

Nor does it matter if more CAs assign the same name to some subset of
the same keys, provided they're expected/authorised to do so.

All that matters is whether the verifier is willing to trust a given CA
to for names in a given namespace, and it is here that it is quite
reasonable to not place trust in every CA on the planet when
provisioning cameras, electronic locks, uranium isotope centrifuges, ...

This is not about "uniqueness", rather it is about assurance, sometimes
you need to run your own CA, because the CA/B forum CAs don't provide
the required assurance levels and sometimes are presumed actively
hostile.

> For instance, CA1 and CA2 may both sign certificates for entities with
> the same name. If CA1 and CA2 are both trusted by the RADIUS server,
> and two entities named "medicaldevice123" exist, one per CA, then the
> resulting ambiguity makes it difficult to appropriately apply access
> controls.

No, the problem only happens when the two are not the same, but CAs
issuing certificates from publically trusted keys should only sign
assertions about globally valid names, so there are no "collisions",
there is only authorised or unauthorised issuance.

> This ambiguity is mitigated by operating a single organizational PKI,
> and requiring identities issued by that single organizational PKI for
> EAP-TLS authentication.

There is no ambiguity or uniqueness problem.  There is only a trust /
authorisation problem.

> Oftentimes some sort of skilled labor and/or dedicated infrastructure for
> automating the onboarding process is involved. DANE allows us to bind a DNS
> name to a public key, and mitigates the ambiguities introduced by the use
> of multiple CAs.

No, rather DANE gives a natural global namespace, with natural name
constraints, so that only the signing keys of the authoritative zone
(and potentially its parent zones if compelled to transfer domain
control, or hypotheticall, but much less likely forge non-delegated
responses) can be used to sign TLSA RRsets for a given name.

So with DANE there is a natural single naming authority, that is absent
with WebPKI.

> An organization can only issue working identities within its own
> namespace in DNS. Since naming ambiguity can be mitigated using DANE,
> we may now choose to use manufacturer-issued PKI, represented in DNS,
> for authenticating entities.

We're converging to the same observations, but your terminology is sadly
misleading and regrettable.  Please remove all referce to uniqueness and
ambiguity, and instead clarify the actual desire for a single naming
authority trusted by the verifier.  It can be the device manufacturer
(if not trusted, why use the device), but in some environments, the user
may elect to reconfigure the device with their own keys and DNS name and
avoid reliance on outside parties.

> From the hospital's standpoint, the IT staff no longer needs to manage
> the process of onboarding devices to organizational PKI. The device
> arrives on-site with an identity which can be immediately used for
> network authentication.

Perhaps so, though some equipment is sufficiently critical that it will
need to remain working even if the outside vendor is no longer reachable
or even in business.  In which case one would want to use one's own
internal DNS servers proximate to the devices in question.

> If a supplier issues a trustworthy identity for a device, and DNS prevents
> another PKI from issuing working credentials under the same name,

DNSSEC provides natural name constraints.  It is then up to the user
whether to trust the device vendor for authenticity and availability
during or beyond the initial device onboarding.

> then issuing another identity via organizational PKI becomes
> superfluous. This is where we think that time and effort can be saved,
> because the skills required for onboarding do not need to include the
> management and issuance of identities under organizational PKI.

You might also simplify onboarding, but the device is then promptly
reconfigured with an internal name and keys.  It suffices to wipe the
TLSA RRs from DNS when the device is deprovisioned, the keys are then no
longer sensitive (after the TLSA RRSIGs expire), but wiping those too
is generally prudent.

-- 
    Viktor.