The DRIP DET public Key InfrastructureHTT ConsultingOak ParkMI48237USArgm@labs.htt-consult.comAX Enterprize, LLC4947 Commercial DriveYorkvilleNY13495USAstu.card@axenterprize.com
Internet
INTAREARFCRequest for CommentsI-DInternet-DraftDRIPPKIX
The DRIP Entity Tag (DET) public Key Infrastructure (DKI) is a
specific variant of classic Public Key Infrastructures (PKI) where
the orginization is around the DET, in place of X.520 Distinguished
Names. Further, the DKI uses DRIP Endorsements in place of X.509
certificates for establishing trust within the DKI.
There is a shadow PKI behind the DKI, with many of its X.509 fields
mirroring content in the DRIP Endorsements. This PKI can at times
be used where X.509 is expected and non-constrained communication
links are available that can handle their larger size.
Introduction
A DRIP Entity Tag (DET, )
public Key Infrastructure (DKI) is a strict hierarchy, governed by
the administrator of the DET prefix and having the authority to authorize RAAs. RAAs
in turn authorize HDAs within their domain. This authorization is
managed via a set of DETs whose sole use is to define the DKI. The
RAA Authorization DETs MUST reside in HID = RAA#|0 (Apex
Authorization DET in HID = 0|0).
There are three main classifications/types of DETs:
Authorization DETs
Used to assert the authorization of a DKI level.
Endorsing DETs
Used to assert operations within DKI level.
Operational DETs
Used by operational entities within DKI level
All DETs exist in DET-Endorsements ().
These DET-Endorsements provide the proof of registration and thus
trust. These DETs, through chained Endorsements define the DKI as
follows:
The Authorization DETs exist in a set of
DET-Authorization-Endorsements. The lifetime of these endorsements
SHOULD be no less than 1 year, recommended 5 years, and should not
exceed 10 years. Endorsements SHOULD be reissued prior to expiry
(may be for a new DET). DETs used to define this authorization are
replaced per undetermined policy (note these DETs do very little
signing, see section...).
This separation of DET type roles reduce the risk of private key
loss for the critical Authentication DETs by making them
infrequently used. It does make the chain of trust for a HDA
customers' Operational DETs to be 4 Endorsements.
Terms and DefinitionsRequirements Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED",
"MAY", and "OPTIONAL" in this document are to be interpreted as
described in BCP 14 when, and only when, they appear in all
capitals, as shown here.
Definitions
This document uses the terms defined in and in . The
following new terms are used in the document:
DKI
A DRIP Entity Tag (DET) public Key Infrastructure.
The DKI LevelsThe Apex
The Apex Authorization DET is used to endorse RAA Authorization
DETs and its own Apex Endorsing DETs; it has no other use. This is
the case for all Authorization DETs. Apex Endorsing DETs are used
to endorse DETs, with HID= 0|0, used by Apex services.
The RAAs
Each RAA use its Authorization DET (HID = RAA#|0) to endorse its
RAA Endorsing DET(s) (also HID = RAA#|0) and for endorsing its HDA
Authorization DETs (HID = RAA#|HDA#).
An RAA may have multiple Endorsing DETs (HID = RAA#|0), each for a
different use (e.g. CRL signing, RAA server signing). It is
expected that, over time, an RAA will rollover its Endorsing DETs,
thus at times there will be more than ONE Endorsing DET per role
in use.
The HDAs
Each HDA use its Authorization DET to endorse its HDA Endorsing
DETs (e.g. RAA=267, HDA=567).
An HDA Endorsing DET is used to endorse Operational DETs; those
used by the HDA for its services (e.g. USS) and for Devices (e.g.
UA, GCS, ground infrastructure) partaking in the HDA's services.
DNS view of DKI
The primary view of the DKI is within DNS. There are two main DNS
structures, one for DETs and one for DKI entities.
In the DET DNS structure, only the Apex and RAA levels MUST be
DNSSEC signed. The HDA level may be too dynamic for DNSSEC signing
(e.g. hundreds of new EE Operational DETs per hour); trust in the
EE Operational DETs within the HDA level comes through inclusion of
the HDA Endorsement of EE object. A slow-churn HDA MAY use DNSSEC.
The RAA and HDA levels MUST contain their Endorsement by higher
object; this provides the needed trust in the Endorsement of EE
objects. The Apex level Endorsement is self-signed, thus trust in
it is only possible via DNSSEC. Other RR within these levels will
vary. There may be HIP, TLSA, URI RR.
Each level needs FQDNs for its Authorization DET and Endorsing
DET(s) (e.g. PTR to DETs?). FQDNs for services offered may also be
present, or a URI for the commercial FQDN for the DKI Entity. TLSA
RR of DET SPKI may be directly included here. Same with HIP RR.
The Authorization Endorsement SHOULD be present, as SHOULD be
Endorsing Endorsements.
The Offline cache of HDA Endorsements
The Offline cache of HDA Endorsements, used to verify various EE
signed objects without needing DNS access, SHOULD consist of the
HDA Authentication DET Endorsements of the HDA Endorsement DETs.
Thus the receiver has a trusted source of the HDA Endorsement DET
Public Key (HI) in a DRIP standard object (136 bytes). If the DKI
DNS tree includes GEO location data and coverage, a receiver could
query some service for a trusted cache within some radius of its
location. Such as, please tell me of all HDAs within 100KM of...
This cache MAY contain the full chain up to the Apex. This could
be helpful in limited connectivity environments when encountering
an Endorsing HDA DET under a know Authenticated HDA or RAA. The
needed trust chain could be shorter.
RAAs set aside for Testing
The RAA range of 16376 - 16383 are reserved for testing. It test
DET DNS structure under drip-testing.org will use these. RAAs
16376 - 16389 are preallocated in this test DNS with 16390 - 16383
available for testing setting up RAAs. Within RAAs 16376 - 16383,
HDAs 16376 - 16383 will be preset for testing of Operational DETs.
Other HDAs within RAAs 16376 - 16383 additional HDAs can be made
available for testing of HDA setup and running said HDAs.
It is anticipated that once a production DNS is established, these
test RAAs and HDAs will carry forward. The migration could be as
simple as the production Apex Endorsing the test RAA Authorization
DETs and moving the various test DNS structures to the production
structure.
The DKI's Shadow PKI
TBD
In development is an X.509 PKI to shadow the DKI. The X.509
certificates are minimalistic (less than 400 bytes for DER). Any
DRIP specific OIDs should come from the ICAO arc (e.g.
1.3.27.16.2). Important X.509 fields like issuerKeyIdentifier will
have DETs rather than public key hashes, so software will need to
specifically handle them.
Distiguished Names will follow DET hierarchy and not map well into
traditional PKI usage.
This is a work in progress.
IANA Considerations
TBD
Security Considerations
TBD
Needs description of risk to Authorization DET private keys for
broad trees (e.g. lots of RAAs).
ReferencesIANA IPv6 Special-Purpose Address RegistryIANAAcknowledgments
TBD