﻿<?xml version='1.0' encoding='utf-8'?>
<?rfc toc="yes" ?>
<?rfc symrefs="yes" ?>
<?rfc sortrefs="yes"?>
<?rfc compact="yes" ?>
<?rfc subcompact="no" ?>
<?rfc iprnotified="no" ?>
<?rfc strict="no" ?>
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" consensus="true" docName="draft-ietf-drip-dki-05"
	category="info" ipr="trust200902" obsoletes="" submissionType="IETF" tocDepth="4"
	xml:lang="en" tocInclude="true" symRefs="true" sortRefs="true" version="3">

<front> <title abbrev="DRIP DKI">The DRIP DET public Key Infrastructure</title>
    <seriesInfo name="Internet-Draft" value="draft-ietf-drip-dki-05"/>
	<author fullname="Robert Moskowitz" initials="R" surname="Moskowitz">
    <organization>HTT Consulting</organization>
    <address>
      <postal>
	    <street></street>
        <city>Oak Park</city>
        <region>MI</region>
        <code>48237</code>
        <country>USA</country>
      </postal>
      <email>rgm@labs.htt-consult.com</email>
	</address>
	</author>
	<author fullname="Stuart W. Card" initials="S." surname="Card">
	<organization>AX Enterprize, LLC</organization>
	<address>
	  <postal>
	    <street>4947 Commercial Drive</street>
	    <city>Yorkville</city>
	    <region>NY</region>
	    <code>13495</code>
	    <country>USA</country>
	  </postal>
	  <email>stu.card@axenterprize.com</email>
	</address>
	</author>
<date year="2025" />
   <area>Internet</area>
   <workgroup>INTAREA</workgroup>
    <keyword>RFC</keyword>
     <keyword>Request for Comments</keyword>
     <keyword>I-D</keyword>
     <keyword>Internet-Draft</keyword>
     <keyword>DRIP</keyword>
     <keyword>PKIX</keyword>
<abstract>
<t>
	The DRIP Entity Tag (DET) public Key Infrastructure (DKI) is a 
	specific variant of classic Public Key Infrastructures (PKI) where 
	the organization 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.
</t>
<t>
	There are two X.509 profiles for shadow PKI behind the DKI, with 
	many of their X.509 fields mirroring content in the DRIP 
	Endorsements.  These PKIs can at times be used where X.509 is 
	expected and non-constrained communication links are available that 
	can handle their larger size.  It is recommended that a DRIP 
	deployment implement both of these along side the Endorsement trees.
</t>
<t>
	C509 (CBOR) encoding of all X.509 certificates are also provided as 
	an alternative for where there are gains in reduced object size.
</t>
<t>
	Author's note: This draft is a partial update of all the additions 
	needed for the PKIX-like PKI to be ICAO ACCP compliant.
</t>
</abstract>
</front>
<middle>
<section numbered="true" toc="default"> <name>Introduction</name>
<t>
	A DRIP Entity Tag (DET, <xref target="RFC9374" format="default"/>) 
	public Key Infrastructure (DKI) is designed as a strict hierarchy, 
	governed by the administrator of the DET prefix <xref 
	target="IPv6-SPECIAL" format="default"/> 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).
</t>
<t>
	There are three main classifications/types of DETs:
</t>
<ul empty="true">
	<li>
	<dl newline="true" spacing="normal">
		<dt>Authorization DETs</dt>
		<dd>
			Used to assert the authorization of a DKI level.
		</dd>
		<dt>Issuing DETs</dt>
		<dd>
			Used to assert operations within DKI level.
		</dd>
        <dt>Operational DETs</dt>
        <dd>
			Used by operational entities within DKI level
		</dd>
 	</dl>
 	</li>
</ul>
<t>
	All DETs exist in DET-Endorsements (<xref 
	target="I-D.ietf-drip-registries" section="B" format="default"/>). 
	These DET-Endorsements provide the proof of registration and thus 
	trust.  These DETs, through chained Endorsements define the DKI as 
	follows:
</t>
<figure anchor="reg-class-fig"> <name>The DKI Endorsements</name>
	<artwork align="center" name="" type="" alt="">
<![CDATA[
                +----------+
                |   Auth   | 
                +-o------o-+
                  |      |
                  |    +-o-----+
 Apex             |   +--o----+|
                  |   | Issue |+
                  |   +---o---+
                  |      |
                  |    +-o-----+
                  |   +--o----+|
                  |   |CRL,Srv|+
                  |   +-------+
                  |      
******************|************************************
                +-o--------+
               +-o--------+|
               |   Auth   |+
               +--o-----o-+
                  |     |
                  |   +-o-----+
 RAAs             |  +--o----+|
                  |  | Issue |+
                  |  +---o---+
                  |     |
                  |   +-o--------+
                  |  +--o-------+|
                  |  |  CRL,Srv ||
                  |  |Oper,Pilot|+
                  |  +----------+
                  |      
******************|************************************
                +-o--------+
               +-o--------+|
               |   Auth   |+
               +----o-----+
                    |
                  +-o-------+
 HDAs            +--o------+|
                 |   Issue |+
                 +---o-----+
                     |    |
                     |   +-o--------+
                     |  +--o-------+|
                     |  |  CRL,Srv ||
                     |  |Oper,Pilot||
                     |  |   UAS    |+
                     |  +----------+
                   
*******************************************************
]]>
	</artwork>
</figure>
<t>
	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 <xref target="offline_keys" />).
</t>
<t>
	This separation of DET type roles reduce the risk of private key 
	loss for the critical Authentication DETs by making them 
	infrequently used and only used in offline operations.  It does 
	make the chain of trust for a HDA customers' Operational DETs to be 
	4 Endorsements.
</t>
<section anchor="no-apex" numbered="true" toc="default"> <name>The DKI without an Apex Entity</name>
<t>
	The hierarchical design of the DKI is the most efficient possible 
	with the least data transmission overhead.  But it requires the 
	participation of an Entity, in the role of the Apex, trusted by all 
	the RAAs.  The logical Entity for this role is the International 
	Civil Aviation Authority (ICAO), but the processes for ICAO to take 
	on this role are complex.  Work is ongoing with the ICAO, but 
	timing is indeterminate and immediately implementable alternatives 
	are needed.
</t>
<t>
	The DKI can work by the RAAs establishing mutual trust within a 
	geographic region.  It is envisioned that the initial RAA 
	assignments will follow <xref target="I-D.ietf-drip-registries" 
	section="6.2.1" format="default"/>, Table 1.  Without an Apex, each 
	RAA self-endorses its Authentication DET, acting as its own apex. 
	However, RAAs issued DETs (via their HDAs) will not exist in the 
	air by themselves (except perhaps for some small island nations), 
	thus a geographic regional consortium of RAAs will need to deploy 
	some mechanism for mutual trust for their End Entities to fly 
	together.
</t>
<t>
	There are three reasonable approaches for RAAs to manage their 
	mutual trust and it is likely that all will occur:
</t>
<ul empty="true">
	<li>
		<ol>
			<li>
				RAA Trust lists
			</li>
			<li>
				RAA Cross-endorsements
			</li>
			<li>
				Bridge RAA with cross-endorsements to RAAs
			</li>
		</ol>
 	</li>
</ul>
<t>
	It is recommended that the RAA Trust List be used during initial 
	DKI testing.  The cross-endorsing options will need their own 
	testing to work out how best to deploy them.
</t>
<section anchor="raa_trust_list" numbered="true" toc="default"> <name>RAA Trust lists</name>
<t>
	A consortium of RAAs MAY choose to maintain a list of RAAs they 
	trust.  It is recommended that this list consist of the RAA's 
	Authentication DET and HI.  Each RAA in the consortium SHOULD 
	maintain its own list, signed with its Authentication DET.
</t>
<t>
	This Trust List MAY contain each RAA's Authentication DET 
	self-endorsement validity dates.  If a trusted RAA has more than 
	one self-endorsement (most likely to support key rollover), 
	including these dates makes it easier to have an RAA duplicated in 
	the list.
</t>
<t>
	How the RAAs communicate between themselves to maintain these lists 
	is out of scope here.  Each RAA SHOULD include validity dates in 
	its Trust List.  Frequency of Trust List updates is also out of 
	scope here.
</t>
<t>
	Trust Lists is the simplest method to implement, but may not be the 
	simplest to maintain over time.
</t>
<t>
	There is a natural Trust List of ALL RAAs, based on what is 
	allocated in the DRIP DNS tree.
</t>
</section>
<section anchor="raa_cross_endorse" numbered="true" toc="default"> <name>RAA Cross-endorsements</name>
<t>
	A consortium of RAAs MAY choose to cross-endorse each's 
	Authentication DET.  This is done by one RAA endorsing for its 
	community, an other's Authentication DET.  This establishes one-way 
	trust; thus, in practice, each RAA needs to cross-endorse each 
	RAA's Authentication DET within the consortium.
</t>
<t>
	RAA Cross-endorsements definitely has a scaling (n^2) problem.  It 
	works for a starting point or for a very small group of RAAs.
</t>
<t>
	How these RAA Cross-endorsements are discovered has not been 
	defined at this point.  One potential is via a to-be-defined DNS 
	HHIT RR within the endorsing RAA's zone.  This information would 
	need to be cached by any potential offline entity.
</t>
</section>
<section anchor="raa_bridge_endorse" numbered="true" toc="default"> <name>Bridge RAA with cross-endorsements to RAAs</name>
<t>
	A consortium of RAAs MAY select one RAA to function as a "Bridge" 
	between all members of the consortium.  In this approach, the 
	"Bridge RAA" does not authorize any sub-HDAs.  Its sole purpose is 
	the cross-endorse to member RAAs.  The Bridge and each RAA cross 
	endorse as in <xref target="raa_cross_endorse" />.
</t>
<t>
	Bridge RAA Cross-endorsementing reduces the scaling challenge to 
	only the number of RAAs in the consortium.  Plus there is little 
	need to communicate any changes in the cross-endorsementing to the 
	various parties within the consortium.  Thus this option scales the 
	best out of the three alternatives to DKI Apex hierarchy.
</t>
<t>
	How these RAA Cross-endorsements are discovered has not been 
	defined at this point.  The Bridge RAA will have to be known to all 
	parties within the consortium.  One potential, as above, is via a 
	to-be-defined DNS HHIT RR (<xref target="I-D.ietf-drip-registries" 
	section="A" format="default"/>) within the endorsing RAA's zone.  
	This information would need to be cached by any potential offline 
	entity.
</t>
</section>
</section>
<section anchor="x509" numbered="true" toc="default"> <name>Value add to DKI in X.509 Certificates</name>
<t>
	The <xref target="RFC9434" format="default">Drip 
	Architecture</xref> does not use or need X.509 certificates or the 
	associated Certificate Authories.  However, there is considerable 
	value for the Apex, RAAs, and HDAs to deploy the CAs described 
	herein.  Of considerable note is the inclusion of the ICAO Level of 
	Assurance (LOA) policy OIDs, <xref target="CA_Servers_LOA" />, that 
	inform trust behind the DRIP Endorsement tree and the associated 
	CAs.
</t>
<t>
	A signing entity MUST follow the same LOA for all 3 objects:  
	Endorsements, DRIP-Lite, and DRIP-PKIX certificates.
</t>
<t>
	There may be other UAS applications that will just work with X.509 
	certificates, but would have to be customized to use DIRP 
	Endorsements.
</t>
</section>
<section anchor="c509" numbered="true" toc="default"> <name>The C509 encoding of X.509 Certificates</name>
<t>
	A price in object size is paid in the ASN.1 encoding of X.509 
	certificates.  This is often a barrier for use over constrained 
	links and even storage demands on constrained processing platforms. 
	The <xref target="I-D.ietf-cose-cbor-encoded-cert" 
	format="default"/> provides an alternative encoding in two 
	different manners:
</t>
<ul empty="true">
	<li>
		<ol>
			<li>
				An invertible CBOR re-encoding of DER encoded X.509 
				certificates <xref target="RFC5280"/>, which can be 
				reversed to obtain the original DER encoded X.509 
				certificate.
			</li>
			<li>
				Natively signed C509 certificates, where the signature 
				is calculated over the CBOR encoding instead of over 
				the DER encoding as in 1. This removes the need for 
				ASN.1 and DER parsing and the associated complexity but 
				they are not backwards compatible with implementations 
				requiring DER encoded X.509.
			</li>
		</ol>
 	</li>
</ul>
<t>
	The invertible CBOR encoding is recommended for use here.  This can 
	be readily implemented through libraries that do the translation, 
	as needed, between X.509 and c509.
</t>
</section>
</section>
<section anchor="terms" numbered="true" toc="default"> <name>Terms and Definitions</name>
<section numbered="true" toc="default"> <name>Requirements Terminology</name>
	<t>
		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 <xref target="RFC2119" /> <xref
		target="RFC8174" /> when, and only when, they appear in all
		capitals, as shown here.
	</t>
</section>
<section numbered="true" toc="default"> <name>Definitions</name>
<t>
	This document uses the terms defined in <xref target="RFC9153" 
	section="2.2" format="default">Drip Requirements and 
	Terminology</xref> and in <xref target="RFC9434" section="2" 
	format="default">Drip Architecture</xref>.  The following new terms 
	are used in the document:
</t>
	<dl newline="true" spacing="normal">
		<dt>Authorization DETs</dt>
		<dd>
			DETs whose use is to define a hierarchy level and endorse 
			lower hierarchy level Authorization DETs and finally 
			Issuing DETs at this hierarchy level.  They the DETs in the 
			Authentication Endorsements and X.509 certificates.
		</dd>
		<dt>DKI</dt>
		<dd>
			A DRIP Entity Tag (DET) public Key Infrastructure.  Similar 
			to an X.509 PKI, but built on the DRIP Endorsements.
		</dd>
		<dt>IAL (Identity Assurance Level)</dt>
		<dd>
			ICAO:  "The confidence in the identity verification 
			processes used to establish the identity of an entity 
			associated with a certificate. The robustness of identity 
			proofing and the certainty with which the identity is bound 
			to the certificate."
		</dd>
		<dt>International Aviation Trust Framework (IATF)</dt>
		<dd>
			The ICAO IATF is comprised of a set of policies, 
			requirements, and best practices that will enable resilient 
			and secured ground-ground, air-ground, and air-air exchange 
			of digital information, and among both traditional and 
			newly-emerging system stakeholders.
		</dd>
		<dt>Issuing DETs</dt>
		<dd>
			DETs whose use is to sign Endorsements and X.509 
			certificates for Operational DETs that are at the same 
			hierarchy level as the Issuing DET.
		</dd>
		<dt>LOA (Level of Assurance)</dt>
		<dd>
			ICAO:  "The confidence in the security 
			measures that protect the private key and manage the 
			certificate lifecycle."
		</dd>
		<dt>Operational DETs</dt>
		<dd>
			DETs used by various entities in DRIP protocols and as 
			non-routable IPv6 addresses.  A partial list of such 
			entities includes: GCS, Infrastructure (e.g. wireless tower 
			systems), UAS Operators, Pilots-in-command, Servers, UA.
		</dd>
		<dt>​System Wide Information Management (SWIM)</dt>
		<dd>
			The ICAO SWIM consists of Standards, Infrastructure and 
			Governance enabling the management of Air Navigation 
			Systems (ANS) related information and its exchange between 
			qualified parties via interoperable services.
		</dd>
 	</dl>
</section>
</section>
<section anchor="DKI" numbered="true" toc="default"> <name>The DET public Key Infrastructure (DKI)</name>
<section anchor="DKI_Levels" numbered="true" toc="default"> <name>The DKI Levels</name>
<section anchor="DKI_apex" numbered="true" toc="default"> <name>The Apex</name>
<t>
	The Apex Authorization DET is used to endorse RAA Authorization 
	DETs and its own Apex Issuing DETs; it has no other use.  This is 
	the case for all Authorization DETs.  Apex Issuing DETs are used 
	to endorse DETs, with HID= 0|0, used by Apex services.
</t>
<t>
	The DET Apex may be only theoretical if no Entity steps forward to 
	provide this role.
</t>
</section>
<section anchor="DKI_raas" numbered="true" toc="default"> <name>The RAAs</name>
<t>
	Each RAA use its Authorization DET (HID = RAA#|0) to endorse its 
	RAA Issuing DET(s) (also HID = RAA#|0) and for signing its HDA 
	Authorization DETs (HID = RAA#|HDA#).
</t>
<t>
	An RAA may have multiple Issuing 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 Issuing DETs, 
	thus at times there will be more than ONE Issuing DET per role in 
	use.
</t>
<t>
	These Issuing DETs, like those at the Apex level, constitute an 
	implicit HDA.  There is no Authorization DET for this implicit HDA, 
	but other than only signing for entities like servers needed by the 
	RAA, it should be considered as an HDA in terms of policies.
</t>
<t>
	An RAA may directly issue DETs for Operators/Pilots, but it is 
	recommended that if the RAA has this responsiblity, it runs an HDA 
	specifically for this function.  This allows separation of the RAA 
	role from the HDA.  It is recommended that the RAA only offer 
	Endorsing/Signing services for the functions of running the RAA.
</t>
<t>
	The initial RAA range assignments are defined in <xref 
	target="I-D.ietf-drip-registries" section="6.2.1" 
	format="default"/>, Table 1.  It is anticipated that DRIP usage 
	will expand to use into General/Civil Aviation.  Thus at some point 
	a block of RAAs will be set aside much like for the CTA-2063A <xref 
	target="CTA2063A" format="default"/> range.
</t>
</section>
<section anchor="DKI_hdas" numbered="true" toc="default"> <name>The HDAs</name>
<t>
	Each HDA use its Authorization DET to endorse its HDA Issuing 
	DETs (e.g. RAA=267, HDA=567).
</t>
<t>
	An HDA Issuing 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.
</t>
<t>
	If the Operational DET is a Manufacturer DET, the "valid not after" 
	date (vna) MUST be 99991231235959Z.
</t>
<t>
	An HDA may directly issue DETs for Operators/Pilots.  It is 
	recommended that different Issuing HDAs be used for devices and 
	people.  They may be under the same Authentication HDA.  Of 
	importance is that there are different LOAs for CAs for people and 
	devices per <xref target="CA_Servers_LOA"/>.
</t>
</section>
</section>
<section anchor="Offline_Auth" numbered="true" toc="default"> <name>The Offline Requirement for Authentication DETs</name>
<t>
	The Authentication DETs private keys MUST NEVER be on a system with 
	any network connectivity.  Also efforts MUST be taken to limit any 
	external digital media connections to these offline systems.  
	Compromise of an Authentication DET compromises its and all lower 
	hierarchy levels. Such a compromise could result in a major 
	re-signing effort with a new Authentication DET.  Also, during the 
	time of compromise, fraudulent additions to the DKI could have 
	occurred.
</t>
<t>
	This means that the process whereby the Authentication DET is used 
	to sign the Endorsement/X.509 certificate of its level's Issuing 
	DET(s) and lower level Authentication DETs MUST be conducted in an 
	offline manner (e.g. <xref target="CA_Servers" format="default"/>).
</t>
<t>
	This offline process need not be onerous.  For example, QR codes 
	could be used to pass CSR objects to the offline Authentication DET 
	system, and this system could produce QR codes containing the 
	Endorsements and X.509 certificates it signed  (<xref 
	target="CA_X.509_QR_Exhg" format="default"/>).
</t>
<t>
	A video conference between the parties could have one side show its 
	QR code and the other copy and print it to move between the video 
	conferencing system and the offline system.  This is a 
	simplification of a larger signing operation, but shows how such a 
	signing need not require travel and expensive hand-off methodologies.
</t>
<t>
	It should be noted that the endorsement of Issuing DETs follow the 
	same restriction, as it is done with the Authentication DET.  It 
	MUST be conducted in an offline manner.
</t>
</section>
<section anchor="DKI_dns" numbered="true" toc="default"> <name>DNS view of DKI</name>
<t>
	The primary view of the DKI is within DNS.  This is in the 
	3.0.0.1.0.0.2.ip6.arpa zone (Apex level of the DRIP IPv6 DET 
	format).
</t>
<t>
	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.
</t>
<t>
	Endorsements are stored in the DNS BRID RR (<xref 
	target="I-D.ietf-drip-registries" section="5.2" 
	format="default"/>). X.509 certificates in the DNS HHIT RR (<xref 
	target="I-D.ietf-drip-registries" section="5.1" 
	format="default"/>).
</t>
<t>
	Authors note:  These RR will only be available once <xref 
	target="I-D.ietf-drip-registries" format="default"/> is published. 
	Until then, <xref target="RFC3597" format="default"/> will be used 
	to encode these RR Types.
</t>
<t>
	Other RR within these levels will vary.  There also 
	may be HIP, TLSA, and/or URI RR.
</t>
<t>
	Each level continues on down the 3.0.0.1.0.0.2.ip6.arpa zone for 
	its Authorization DET and Issuing DET(s). RR with FQDNs for 
	services offered may also be present in various forms (e.g. 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 Issuing Endorsements.
</t>
</section>
<section anchor="DET_revok" numbered="true" toc="default"> <name>Managing DET Revocation</name>
<t>
	For Operational DETs, there is no direct concept of DET revocation. 
	Operational DETs are either discoverable via DNS or not valid 
	despite being in a non-expired Endorsement signed an Issuing DET. 
	Thus if an Issuing Entity needs to "revoke" an Operational DET it 
	removes all entries for it from DNS, so a short TTL on those 
	records is recommended.
</t>
<t>
	Authorization and Issuing DETs are not so easily "revoked"; 
	something akin to an X.509 CRL mechanism is needed.  This could 
	best be dealt with by Endorsements managed in the new DET RR that 
	includes revocation status.  Thus <xref 
	target="I-D.ietf-drip-registries" section="5.2" format="default"/> 
	defines the specific RR for Endorsements that will be used here.  
	Minimally, at least the revocation status and revocation date(s) 
	need to be in this RR.  Until this RR is available, there is no 
	mechanism, other than removal for Authorization and Issuing DET 
	revocations.
</t>
</section>
<section anchor="Offline_cache" numbered="true" toc="default"> <name>The Offline cache of HDA Issuing Endorsements</name>
<t>
	The Offline cache of HDA Issuing Endorsements, used to verify 
	various EE signed objects without needing DNS access, SHOULD 
	consist of the HDA Authentication DET Endorsements of the HDA 
	Issuing DETs. Thus the receiver has a trusted source of the HDA 
	Issuing 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...
</t>
<t>
	This cache MAY contain the full chain up to the Apex.  This could 
	be helpful in limited connectivity environments when encountering 
	an HDA Issuing DET under a unknown Authenticated HDA or RAA.  The 
	needed trust chain could be shorter.
</t>
<section anchor="trust_cache" numbered="true" toc="default"> <name>HDA Offline Trust cache</name>
<t>
	There are situations where a list of specific HDAs for an entity to 
	trust for some application is needed.  This can best be met by 
	maintaining a cache as above but only of the trusted HDA Issuing 
	Endorsements.  How a list of this limited trust is maintain and 
	distributed is out of scope of this document and is left to those 
	needing this specific feature.
</t>
</section>
</section>
</section>
<section anchor="Shadow_PKI" numbered="true" toc="default"> <name>The DKI's Shadow PKI</name>
<t>
	The following defines the components of a DKI's shadow PKI built 
	from X.509 certificates with content that mirrors that in the DKI 
	Endorsements.  There are two profiles provided; both may be used, 
	or the community may select one for deployment.  In both cases, the 
	PKI tree mirrors that of the DKI levels (<xref target="DKI_Levels" 
	format="default"/>).
</t>
<t>
	It is recommended that at least the PKIX-like <xref 
	target="Shadow_reg_PKI" format="default"/> be deployed, as its CA 
	certificates contain ICAO policy OIDs the reflect on the whole DKI 
	deployment.
</t>
<t>
	At this point in defining the shadow PKIs, alternatives to a strict 
	hierarchy is still an open work item.  This work will follow the 
	pattern set in <xref target="no-apex" format="default"/>.
</t>
<section anchor="Shadow_lite_PKI" numbered="true" toc="default"> <name>Shadow Lite-PKI with minimal content Certificates</name>
<t>
	The Lite-PKI is designed to fully mirror the DKI in the smallest 
	reasonable X.509 certificates (e.g. 240 bytes for DER), but still 
	adhere to <xref target="RFC5280" format="default"/> MUST field 
	usage.
</t>
<section anchor="Lite_cert_content" numbered="true" toc="default"> <name>DRIP Lite X.509 certificate profile</name>
<t>
	The following is the profile for the DRIP X.509 Lite certificates
</t>
<figure anchor="x509-lite-profile-fig"> <name>The X.509 Lite Profile</name>
	<artwork anchor="x509-lite-profile" name="" type="" alt="">
<![CDATA[
Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number: 
        Signature Algorithm: ED25519
        Issuer: CN = 
        Validity
            Not Before: 
            Not After : 
        Subject: {CN = or Empty}
        Subject Public Key Info:
            Public Key Algorithm: ED25519
                ED25519 Public-Key:
                pub:
        X509v3 extensions: {Operation Certs ONLY}
            X509v3 Subject Alternative Name: critical
                IP Address:
    Signature Algorithm: ED25519
    Signature Value:
]]>
	</artwork>
</figure>
</section>
<section anchor="Mandatory" numbered="true" toc="default"> <name>DRIP Lite Mandatory Certificate Content</name>
<t>
	The following detail the Mandatory to include content in all DRIP 
	Lite certificates.
</t>
<section anchor="Lite_Serial_Number" numbered="true" toc="default"> <name>Serial Number</name>
<t>
	The Serial Number is a MUST field, but it has no usage in this 
	Lite-PKI.  It is 1-byte in size and thus duplicates are guaranteed.  
	To drop this field could make many X.509 parsing libraries fail.
</t>
<t>
	However, CA certificate's Serial Number MAY be the common 20 bytes. 
	This is to avoid possible issues with general software expecting 
	this size Serial Numbers for CAs.
</t>
<t>
	If Serial Numbers are incrementally assigned, 31 bits are 
	sufficient for an Issuing CA with 2B DETs active.  A CA should 
	determine its best-used Serial Number field size to limit the 
	impact of this field on the certificate size.
</t>
</section>
<section anchor="Lite_Subject" numbered="true" toc="default"> <name>Subject</name>
<t>
	The Subject field is only used in Authentication and Issuing 
	Certificates.  For Entity Certificates, the Subject is Empty and 
	the DET will be in Subject Alternative Name (SAN).  In the SAN, the 
	DET can be properly encoded as an IPv6 address.
</t>
<t>
	The Subject field in Authentication and Issuing 
	Certificates uses the following format:
</t>
<figure anchor="Lite-CA-subj-fig"> <name>Lite CA Certificate Subject Name Format</name>
	<artwork align="center" name="" type="" alt="">
<![CDATA[
DRIP-{APEX|RAA|HDA}-{A|I}[-RAA#][-HDA#]

Examples:

    DRIP-RAA-A-16376
    DRIP-HDA-I-16376-16376

]]>
	</artwork>
</figure>
<t>
	The CA Subject Name serves a duo purpose: foremostly, to place the 
	CA within the DKI tree, but secondly for outside of DRIP usage to 
	tag that this CA's function is to serve DRIP Entities.
</t>
</section>
<section anchor="Lite_SAN" numbered="true" toc="default"> <name>Subject Alternative Name</name>
<t>
	Subject Alternative Name is only used in Operational (End Entity) 
	certificates.  It is used to provide the DET as an IP address with 
	an Empty Subject (SAN MUST be flagged as Critical).
</t>
<t>
	The Subject Alternative Name is also used in Manufacturer DET 
	certificates.  These may contain the hardwareModuleName as 
	described in <xref target="DOI_10.1109_IEEESTD.2018.8423794" 
	format="default"/> that references <xref target="RFC4108" 
	format="default"/>.
</t>
<t>
	Per <xref target="RFC5280" format="default"/> and <xref 
	target="DOI_10.1109_IEEESTD.2018.8423794" format="default"/>, 
	Manufacturer DET certificates with hardwareModuleName MUST have the 
	notAfter date as 99991231235959Z.
</t>
</section>
<section anchor="Lite_Issuer" numbered="true" toc="default"> <name>Issuer</name>
<t>
	The Issuer MUST be the higher level's DET.
</t>
<t>
	The Issuer for the Apex Authentication certificate MUST be its 
	DET (indicating self-signed).  If the RAA Authentication 
	certificate is self-signed (i.e., no Apex), its Issuer is its 
	DET.
</t>
<t>
	The Issuer content of its DET assists in finding this specific 
	Issuer in the DRIP ip6.arpa. DNS tree and any additional 
	information.
</t>
</section>
</section>
<section anchor="Mandatory_CA_cert_content" numbered="true" toc="default"> <name>DRIP Lite Mandatory CA Certificate Content</name>
<t>
	The following detail the Mandatory content for DRIP Lite CA 
	certificates.
</t>
<section anchor="Lite_CA_Basic_Const" numbered="true" toc="default"> <name>Basic Constraints</name>
<t>
	CA certificates MUST contain the CA=True object, flagged Critical 
	as a Basic Constraint.
</t>
</section>
</section>
<section anchor="Optional_CA_cert_content" numbered="true" toc="default"> <name>DRIP Lite Optional CA Certificate Content</name>
<t>
	The following detail the Optional content for DRIP Lite CA 
	certificates.  Inclusion of these objects are based on the policies 
	of the CA using them and CAs higher in the trust chain.
</t>
<section anchor="Lite_CA_SAN_URI" numbered="true" toc="default"> <name>CA Subject Alternative Name URI</name>
<t>
	This is the one exception to <xref target="Lite_SAN" 
	format="default"/>.  A CA certificate MAY have a SAN URI, 
	containing a pointer where additional information on the CA and 
	certificates under its control.  For example, an authorized 
	authority may access EE PII like an Operator phone number through 
	this URI link.
</t>
</section>
<section anchor="Lite_CA_Key_Usage" numbered="true" toc="default"> <name>Key Usage</name>
<t>
	The CA certificate MAY contain the keyUsage extension.  For 
	example, it may assert Certificate Signing and flag this as 
	Critical.
</t>
</section>
<section anchor="Lite_CA_Policy_OIDs" numbered="true" toc="default"> <name>CA Policy OIDs</name>
<t>
	The CA MAY have policy OIDs defining rules for EEs within its 
	domain.  The OIDs used here will tend to be within ICAO's arc of 
	1.3.27.16.
</t>
</section>
</section>
<section anchor="test_Lite_PKI" numbered="true" toc="default"> <name>The test DKI and Lite PKI</name>
<t>
	The test DKI and Lite PKI, (<xref target="test_dki" 
	format="default"/>/<xref target="test_pki_certs" format="default"/>), 
	were created using the python scripts at <xref 
	target="drip_scripts" format="default"/>.  First csr-gen.py is used 
	to create an X.509 CSR (and optionally the EdDSA keypair).  This 
	CSR is minimal in content.  For example, a UA might only have 
	knowledge of its Manufacturer Serial Number and can generate its 
	keypair.  Per <xref 
	target="I-D.wiethuechter-drip-det-registration-coap-cwt" 
	format="default"/>, this CSR may be sent to the CA with additional 
	information provided by the Operator, for example desired 
	validityDates.  The raa-endorse.py and hda-endorse.py scripts are 
	provided to produce the DRIP Endorsements and X.509 certificates.
</t>
<t>
	At this time, with no Apex level, each RAA Authorization CA is 
	self-signed.  These are created using the RAA's CSR and its own 
	keypair as input to the raa-endorse.py script.  Normally, the 
	raa-endorse.py script is used to create the HDA's Authorization and 
	Issuing CAs and the hda-endorse.py script for the End Entity 
	certificates.
</t>
</section>
</section>
<section anchor="Shadow_reg_PKI" numbered="true" toc="default"> <name>Shadow PKI with PKIX-like Certificates</name>
<t>
	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.1).
</t>
<section anchor="Cert_content" numbered="true" toc="default"> <name>DRIP PKIX X.509 certificate profile</name>
<t>
	The following is the profile for the DRIP X.509 certificates
</t>
<figure anchor="x509-profile-fig"> <name>DRIP X.509 certificate profile</name>
	<artwork anchor="x509-profile" name="" type="" alt="">
<![CDATA[
Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number: 
        Signature Algorithm: ED25519
        Issuer: CN = 
        Validity
            Not Before: 
            Not After : 
        Subject: {CN = or Empty}
        Subject Public Key Info:
            Public Key Algorithm: ED25519
                ED25519 Public-Key:
                pub:
        X509v3 extensions:
             X509v3 Subject Alternative Name: critical {in EE}
                IP Address:
           X509v3 Subject Key Identifier: {not in EE}
            X509v3 Authority Key Identifier: 
            X509v3 Basic Constraints: critical
            X509v3 Key Usage: critical
    Signature Algorithm: ED25519
    Signature Value:
]]>
	</artwork>
</figure>
</section>
<section anchor="PKIX_Mandatory_cert_content" numbered="true" toc="default"> <name>DRIP PKIX Mandatory Certificate Content</name>
<t>
	The following detail the Mandatory to include content in all DRIP 
	Lite certificates.
</t>
<section anchor="Serial_Number" numbered="true" toc="default"> <name>Serial Number</name>
<t>
	The certificates will contain a 20-byte randomly generated Serial 
	Number, compliant with CABForum recommendations.  Serial Numbers 
	are included for CRL functionality.
</t>
</section>
<section anchor="Subject" numbered="true" toc="default"> <name>Subject</name>
<t>
	The Subject field is only used in Authentication and Issuing 
	Certificates.  For Entity Certificates, the Subject is Empty and 
	the DET will be in Subject Alternative Name (SAN).  In the SAN, the 
	DET can be properly encoded as an IPv6 address.
</t>
<t>
	The Subject field in Authentication and Issuing 
	Certificates uses the following format:
</t>
<figure anchor="CA-subj-fig"> <name>CA Certificate Subject Name Format</name>
	<artwork align="center" name="" type="" alt="">
<![CDATA[
DRIP-{APEX|RAA|HDA}-{A|I}[-RAA#][-HDA#]

Examples:

    DRIP-RAA-A-16376
    DRIP-HDA-I-16376-16376

]]>
	</artwork>
</figure>
<t>
	The CA Subject Name serves a duo purpose: foremostly, to place the 
	CA within the DKI tree, but secondly for outside of DRIP usage to 
	tag that this CA's function is to serve DRIP Entities.
</t>
</section>
<section anchor="SAN" numbered="true" toc="default"> <name>Subject Alternative Name</name>
<t>
	Subject Alternative Name is only used in Operational (End Entity) 
	certificates.  It is used to provide the DET as an IP address with 
	an Empty Subject (SAN MUST be flagged as Critical).
</t>
<t>
	The Subject Alternative Name is also used in Manufacturer DET 
	certificates.  These may contain the hardwareModuleName as 
	described in <xref target="DOI_10.1109_IEEESTD.2018.8423794" 
	format="default"/> that references <xref target="RFC4108" 
	format="default"/>.
</t>
<t>
	Per <xref target="RFC5280" format="default"/> and <xref 
	target="DOI_10.1109_IEEESTD.2018.8423794" format="default"/>, 
	Manufacturer DET certificates with hardwareModuleName MUST have the 
	notAfter date as 99991231235959Z.
</t>
</section>
<section anchor="Issuer" numbered="true" toc="default"> <name>Issuer</name>
<t>
	The Issuer MUST be the higher level's DET.
</t>
<t>
	The Issuer for the Apex Authentication certificate MUST be its DET 
	(indicating self-signed).  If the RAA Authentication certificate is 
	self-signed (i.e., no Apex), its Issuer is its DET.
</t>
<t>
	The Issuer content of its DET assists in finding this specific 
	Issuer in the DRIP ip6.arpa. DNS tree and any additional 
	information.
</t>
</section>
<section anchor="SKI" numbered="true" toc="default"> <name>Subject Key Identifier</name>
<t>
	The Subject Key Identifier MUST be the DET.  This is a major 
	deviation from "standard" X.509 certificates that hash (normally 
	with SHA2) the Public Key to fill the Subject Key Identifier.
</t>
<t>
	The Subject Key Identifier is NOT included in EE certificates.  If 
	needed by some application, it is identical with SAN.
</t>
</section>
<section anchor="AKI" numbered="true" toc="default"> <name>Authority Key Identifier</name>
<t>
	The Authority Key Identifier MUST be the higher level's Subject Key 
	Identifier (i.e. DET).  This partially follows standard practice to 
	chain up the Authority Key Identifier' from the Subject Key 
	Identifier, except for how the Subject Key Identifiers are populated.
</t>
<t>
	The Authority Key Identifier for the Apex Authentication (or 
	self-signed RAA Authentication ) certificate MUST be the Subject 
	Key Identifier (indicating self-signed).
</t>
</section>
</section>
<section anchor="Mandatory_PKIX_CA_cert_content" numbered="true" toc="default"> <name>DRIP PKIX Mandatory CA Certificate Content</name>
<t>
	The following detail the Mandatory content for DRIP PKIX CA 
	certificates.
</t>
<section anchor="PKIX_CA_Basic_Const" numbered="true" toc="default"> <name>Basic Constraints</name>
<t>
	CA certificates MUST contain the CA=True object, flagged Critical 
	as a Basic Constraint.
</t>
</section>
</section>
<section anchor="Optional_PKIX_CA_cert_content" numbered="true" toc="default"> <name>DRIP PKIX Optional CA Certificate Content</name>
<t>
	The following detail the Optional content for DRIP PKIX CA 
	certificates.  Inclusion of these objects are based on the policies 
	of the CA using them and CAs higher in the trust chain.
</t>
<section anchor="PKIX_CA_SAN_URI" numbered="true" toc="default"> <name>CA Subject Alternative Name URI</name>
<t>
	This is the one exception to <xref target="SAN" 
	format="default"/>.  A CA certificate MAY have a SAN URI, 
	containing a pointer where additional information on the CA and 
	certificates under its control.  For example, an authorized 
	authority may access EE PII like an Operator phone number through 
	this URI link.
</t>
</section>
<section anchor="PKIX_CA_Key_Usage" numbered="true" toc="default"> <name>Key Usage</name>
<t>
	The CA certificate SHOULD contain the keyUsage extension.  For 
	example, it may assert Certificate Signing and flag this as 
	Critical.
</t>
</section>
<section anchor="PKIX_CA_Policy_OIDs" numbered="true" toc="default"> <name>CA Policy OIDs</name>
<t>
	It is recommended that a CA have policy OIDs defining rules for EEs 
	within its domain.  The OIDs used here will tend to be within 
	ICAO's arc of 1.3.27.16.
</t>
<t>
	If the CA certificate has policy OIDs, it MUST include an ICAO LOA 
	OID defining "the confidence in the security measures that protect 
	the private key and manage the certificate lifecycle".  Currently 
	defined OIDs <xref target="ICAO-Doc-10169" format="default"/> in 
	ICAO's LOA arc of 1.3.27.16.1.1.0:
</t>
<table anchor="table_hit_suites" align="center"> <name>ICAO LOA OID Assignments under 1.3.27.16.1.1.0</name>
	<thead>
		<tr>
			<th align="right">OID</th>
			<th align="center">Description</th>
			<th align="center">Applicability</th>
		</tr>
	</thead>
	<tbody>
		<tr>
			<td align="right">1</td>
			<td align="center">Low</td>
			<td align="left"><t>This level is relevant to environments 
			where Risks and consequences of data Compromise are 
			low.</t> <t>Subscriber Private Keys shall be stored in 
			software at this Identity Assurance Level (IAL).</t></td>
		</tr>
		<tr>
			<td align="right">2</td>
			<td align="center">LowDevice</td>
			<td align="left">TBD</td>
		</tr>
		<tr>
			<td align="right">3</td>
			<td align="center">Low-TSP Mediated Signature</td>
			<td align="left">This policy is identical to that defined 
			for the Low Assurance policy (above) with the exception 
			that the Private key is not in the possession of the user, 
			but rather by a Trust Service Provider.</td>
		</tr>
		<tr>
			<td align="right">4</td>
			<td align="center">Medium</td>
			<td align="left"><t>This level is relevant to environments 
			where Risks and consequences of data Compromise are 
			moderate. This may include transactions having substantial 
			monetary value or Risk of fraud or involving access to 
			private information where the likelihood of malicious 
			access is substantial.</t>
			<t>Subscriber Private Keys shall be stored in software at 
			this IAL.</t></td>
		</tr>
		<tr>
			<td align="right">5</td> <td 
			align="center">MediumDevice</td>
			<td align="left">This policy is identical to that defined 
			for the Medium Assurance policy (above) with the exception 
			of identity proofing, re-key, and Activation Data.</td>
		</tr>
		<tr>
			<td align="right">6</td>
			<td align="center">Medium-TSP Mediated Signature</td>
			<td align="left">This policy is identical to that defined 
			for the Medium Assurance policy (above) with the exception 
			that the Private key is not in the possession of the user, 
			but rather by a Trust Service Provider.</td>
		</tr>
		<tr>
			<td align="right">7</td>
			<td align="center">MediumHardware</td>
			<td align="left">This policy is identical to that defined 
			for the Medium Assurance policy (above) with the exception 
			of Subscriber Cryptographic Module requirements described 
			in <xref target="ICAO-Doc-10169"/>.</td>
		</tr>
		<tr>
			<td align="right">8</td>
			<td align="center">MediumDeviceHardware</td>
			<td align="left">This policy is identical to that defined 
			for the Medium Hardware Assurance policy (above) with the 
			exception of identity proofing, re-key, and Activation 
			Data.</td>
		</tr>
		<tr>
			<td align="right">9</td>
			<td align="center">High</td>
			<td align="left"><t>This level is relevant to environments 
			where Risks and consequences of data Compromise are high.</t>
			<t>Certificates issued at the High-cardAuth IAL shall only 
			be issued for Card Authentication, as defined by NIST SP 
			800-73 or equivalent standard.</t>
			<t>Further, this policy is identical to that defined for 
			the identical to the MediumHardware IAL except where 
			specifically noted in <xref target="ICAO-Doc-10169"/>.</t></td>
		</tr>
		<tr>
			<td align="right">10</td>
			<td align="center">High-CardAuth</td>
			<td align="left"><t>This level is relevant to environments 
			where Risks and consequences of data Compromise are high.</t>
			<t>Certificates issued at the High-cardAuth IAL shall only 
			be issued for Card Authentication, as defined by NIST SP 
			800-73 or equivalent standard.</t></td>
		</tr>
		<tr>
			<td align="right">11</td>
			<td align="center">High-ContentSigning</td>
			<td align="left"><t>This level is relevant to environments 
			where Risks and consequences of data Compromise are High. 
			This may include transactions having substantial monetary 
			value or Risk of fraud or involving access to private 
			information where the likelihood of malicious access is 
			substantial.</t>
			<t>Certificates issued at the High IAL shall only be issued 
			to human Subscribers.</t>
			<t>Certificates issued at the High-contentSigning IAL shall 
			only be issued to the CMS for signing the HIGH card 
			security objects (e.g. Certificates, CRLs, OCSP 
			responses).</t>
			<t>Further, this policy is identical to that defined for 
			the identical to the MediumHardware IAL except where 
			specifically noted in <xref target="ICAO-Doc-10169"/>.</t></td>
		</tr>
	</tbody>
</table>
<t>
	In this document, the term “Device” is defined as a Non-Person 
	Entity, i.e., an entity with a digital identity that acts in 
	cyberspace but is not a human actor. This can include 
	Organizations, hardware devices (e.g. a UA), software applications, 
	and information artifacts.
</t>
<t>
	End Entity Certificates issued to Devices shall assert policies 
	mapped to LowDevice, MediumDevice, MediumDeviceHardware, or High 
	Content Signing policies. All other policies defined here should be 
	reserved for human Subscribers when used in End Entity 
	Certificates.  Thus it is recommended that Issuing CAs/HDAs should 
	be segregated by device and human subscribers so policy can be 
	stated at the CA level rather in individual certificates.
</t>
<t>
	Author's note:  The applicability statement for LowDevice is not 
	yet defined in 10169.  This is still an open item.  The Author has 
	commented to IACO that this should be the similar to MediumDevice.  
	That is as MediumDevice is to Medium, LowDevice is to Device.
</t>
</section>
</section>
<section anchor="test_PKI" numbered="true" toc="default"> <name>The PKIX-like test PKI</name>
<t>
	Author's Note:  At this time, the following PKIX-like test PKI and 
	<xref target="test_pki_reg_certs" format="default"/> is is a 
	work-in-progress.  The content has not been updated from prior 
	work, and may not reflect current needs.
</t>
<t>
	The PKIX-like test PKI, following the test DKI, was built with 
	openSSL using the "req" command to create a CSR and the "ca" 
	command to sign the CSR, making the certificate.  A guide for using 
	openSSL as here can be found in <xref target="I-D.moskowitz-ec-pki" 
	format="default"/>.
</t>
<t>
	It should be noted that these CSRs have all the content, less the 
	validityDates, for making a DRIP Endorsement, such that a registrar 
	may prefer to receive CSRs and use it to make both structures.  The 
	registrar, per CA practices will provide the validityDates per its 
	policy.
</t>
<t>
	The self-signed certificates created by "req -x509" does not allow 
	selection of the validity dates, only the number of days from NOW. 
	The hack used around this limitation is to create a throw-away 
	self-signed certificate as above with the Apex's (or RAA's) DET.  
	Then create a CSR with that DET and sign it with the throw-away 
	certificate, setting the validity dates as desired.  This now 
	becomes the actual Apex (or RAA's) self-signed Authentication 
	certificate and the throw-away certificate can now be thrown away.
</t>
</section>
</section>
</section>
<section anchor="IAC" numbered="true" toc="default"> <name>The DKI and the ICAO SWIM PKI</name>
<t>
	ICAO advocates for a federated implementation model of individual 
	PKIs based on common standards, the total of which can be 
	considered an international aviation trust framework.  This is 
	embodied in Aviation Common Certificate Policy (ACCP) <xref 
	target="ICAO-Doc-10169"/>.  A test of a compliant PKI is rolling 
	out for testing the Aviation System Wide Information Management 
	(SWIM) environment.
</t>
<t>
	Currently, this PKI is using ECDSA P-256 in its certificates.  This 
	is equivalent to DET SuiteID of "3".  The subjectNames in use can 
	readily by mapped to RAAs (<xref target="I-D.ietf-drip-registries" 
	section="6.2.1" format="default"/>, Table 1) and HDAs. Thus it is a 
	potential straight-forward technical work item to add DET support 
	into the PKI.
</t>
<t>
	The DETs can readily be stored in subjectAltName or more 
	interestingly in subjectKeyIdentifier (and thus 
	authorityKeyIdentifier).
</t>
<t>
	There are a number of advantages for SWIM to have DETs and the 
	matching DNS available.  For example, the "cost" of adding DETs to 
	these certificates could result in moving much of their content 
	into DNS SRV RR and potentially reduce their size by 1/3rd. DETs as 
	the authorityKeyIdentifier would enable DNS for Trust Chain 
	discovery.
</t>
<t>
	Another approach is direct inclusion in this PKI of the DET "Lite" 
	EE certificates for constrained A2A communications.
</t>
<t>
	Discussions are ongoing with those involved with the ACCP and this 
	could open up DET usage into General/Civil Aviation.
</t>
</section>
<section anchor="CA_Servers" numbered="true" toc="default"> <name>DRIP Tamper Evident CA Servers and Protocols</name>
<t>
	The DRIP architecture <xref target="RFC9434" format="default"/> 
	anticipates thousands of CAs for the thousands of administrative 
	entities involved in the DRIP ecosystem.  Current business models 
	for deploying public-facing CAs are just not practical or 
	affordable at this volume.  Yet these DRIP CAs need to provide an 
	acceptable LOA (<xref target="PKIX_CA_Policy_OIDs" 
	format="default"/>).
</t>
<t>
	In-depth analysis of the CA needs for the DKI have resulted in a 
	Tamper Evident CA design as described here.  This Tamper Evident 
	design SHOULD meet the Medium and MediumDevice LOAs in <xref 
	target="PKIX_CA_Policy_OIDs" format="default"/>.
</t>
<t>
	If all data into and out from the DRIP CAs are strictly controlled, 
	the sole hard-to-detect risk is are the keypairs for the CA really 
	generated by the CA and not an artifact of corrupted code.
</t>
<t>
	For the Apex, RAA Auth, and HDA Auth CAs they need to have as input 
	the next level down CSR and associated data and output the 
	resultant DRIP Endorsements and X.509 certificates.  These CAs are 
	basically kept locked away except during these occasional signing 
	operations.  A CA with all data ports sealed and only the camera to 
	read QR encoded data and the screen to display similarly QR encoded 
	data can provide this Tamper Evident CA design.
</t>
<t>
	The HDA Issuing CA (and any other Issuing CA) will be too heavily 
	used to be locked away.  But if it is connected via USB to a USS 
	provider server and ONLY the same data objects as above are 
	processed via that USB connection, almost the same assurance level 
	can be shown.
</t>
<section anchor="CA_Servers_LOA" numbered="true" toc="default"> <name>CA servers LOA</name>
<t>
	Apex and RAA CA servers SHOULD meet at least the Medium LOA.  They 
	MAY meet the High LOA.
</t>
<t>
	HDA Authentication CA servers SHOULD also meet at least the Medium 
	LOA.  They MAY meet the High LOA.  If they only support Devices, 
	they MAY assert the appropriate Device LOA.
</t>
<t>
	HDA Issuing CA servers SHOULD also meet at least the Medium LOA.  
	They MAY meet the High LOA.  It is recommended that CAs separately 
	service Devices and People and assert the appropriate LOA.
</t>
</section>
<section anchor="CA_Servers_Tmp_Evid" numbered="true" toc="default"> <name>What Tamper Evident means</name>
<t>
	Here, Tamper Evident means that any unofficial access to the CA is 
	recorded and steps can be taken to mitigate any damages.
</t>
<t>
	Start with a system with a known software build and all needed 
	applications.  This part of the setup MUST be done without any 
	Internet connectivity.  Perhaps from known CD/DVD images.  During 
	this setup, all data ports, other than that used for the CD/DVD 
	reader are sealed with security tape.  After the build, that port 
	is also so sealed.
</t>
<t>
	The only remaining input devices to the system is its camera and 
	keyboard.  The only output device is the integral display.
</t>
<t>
	A notebook is best for this purpose, as once closed, security tape 
	can seal it closed thus any attempt to access the keyboard will be 
	evident.  Any use of this CA is videoed and the time from the 
	security seal broken to a new one attached is logged.
</t>
<t>
	Thus any tampering with the system can be detected, as security 
	seals will have been removed to gain access.
</t>
<section anchor="Issue_Servers_Tmp_Evid" numbered="true" toc="default"> <name>Issuing CA special case</name>
<t>
	Issuing CAs present a special case and a serious challenge.  These 
	servers could be signing thousands of DETs per day; their use MUST 
	be an automated, always accessible service to the USS.
</t>
<t>
	One approach would be these CAs are hardwired to a USS server via a 
	USB null-modem cable that has security tape on both end connectors.  The 
	application controlling this USB port on the CA ONLY accepts, and 
	outputs, a set of expected X.509 and related objects.  Any other 
	data sent over this USB to the server will return an error.  Any 
	attempt to attach a different device other than the USS server will 
	cause a fault.
</t>
<t>
	By using a serial interface, there are significant limitations on 
	what the OS can be tricked to do.  Since this cable has security 
	tape on the connectors, any changing of the cable should be 
	evident.  There might be other approaches to using a serial 
	interface.
</t>
</section>
</section>
<section anchor="CA_cwt_Exhg" numbered="true" toc="default"> <name>The Data Exchange</name>
<t>
	The full extent of this exchange is a work-in-progress.  It will be 
	modeled after the exchanges covered in <xref 
	target="I-D.wiethuechter-drip-det-registration-coap-cwt" 
	format="default"/>.
</t>
<t>
	The data used by the CA can be grouped into three catagories:
</t>
<ul empty="true">
	<li>
	<dl newline="true" spacing="normal">
		<dt>What the CA knows</dt>
		<dd>
			<t>Its keypair</t>
			<t>Its DET, including the RRA, HDA, and SuiteID</t>
			<t>Its ICAO LOA</t>
			<t>Its serialNumber length in bits</t>
			<t>Does it sign CAs or Entities</t>
		</dd>
		<dt>Data from USS/Operator</dt>
		<dd>
			<t>Signee CSR file</t>
			<t>Validity dates</t>
		</dd>
        <dt>Data returned to USS/Operator</dt>
		<dd>
			<t>Endorsements and Certificates</t>
		</dd>
 	</dl>
 	</li>
</ul>
<t>
	This breakdown will advise the development of the CA operation.  
	Still missing, and needing work, is signing a trust list.
</t>
</section>
<section anchor="CA_X.509_QR_Exhg" numbered="true" toc="default"> <name>QR Codes for the Exchange Protocol</name>
<t>
	QR codes can encode up to 3KB of data.  There are programs that can 
	monitor the server's camera (e.g. zbarcam), producing a data file 
	that can then be reviewed for correctness and processed.
</t>
<t>
	Likewise, there are programs (e.g. qrencode) that can accept a data 
	file to create a QR code.  If the data file is larger than 3KB, it 
	SHOULD be fragmented and then generate multiple QR codes.
</t>
<t>
	These QR codes can be passed between DRIP administrators in a 
	verifiable manner (to mitigate fraudulent activities) so that there 
	may not be a need for in-person key signing.  The HDA operator can 
	express a paper with the CSR QR code.  So proofing by the RAA 
	operator can validate this paper and the code really came from the 
	HDA operator.  After using this CSR, the RAA operator takes 
	pictures of the generated output QR codes and gets those to the HDA 
	operator who inputs them to their server as needed.
</t>
</section>
<section anchor="CA_X.509_USB_Exhg" numbered="true" toc="default"> <name>USB for the Exchange Protocol</name>
<t>
	The USB exchange applications are both simpler and more demanding 
	than the QR code approach.  There are standard libraries for 
	accepting data over USB and many ways to build this.  The 
	application monitors data coming in over USB and sends back data as 
	appropriate.
</t>
<t>
	The challenge comes in ensuring that any attempts to alter the USB 
	connection, as in unplugging the USS server and attaching a 
	bootable USB drive, are detected and blocked.  Only the exchange 
	program has access, at the system level, to the USB port, and only 
	expected data is accepted and returned.
</t>
<t>
	Using a serial null-modem inline on the USB connection may be the 
	simplest way to enforce the USB behavior so that an attack on the 
	USS side could not get the CA side to accept accepting attack code. 
	It would take a physical cable change that would be visibly 
	evident.
</t>
</section>
</section>
<section anchor="IANA" numbered="true" toc="default"> <name>IANA Considerations</name>
<t>
	TBD
</t>
</section>
<section anchor="security-considerations" numbered="true" toc="default"> <name>Security Considerations</name>
<t>
	Risks in the DKI are similar to those in any X.509 PKI.  The 
	methodologies to mitigate risk in PKI management should be 
	considered and implemented as appropriate.
</t>
<t>
	The DKI presents a tree-breath problem that is rarely seen in PKIs 
	and needs practical solutions to minimize cost of operations and 
	not introduce risks needlessly.  Consider that there can be 16,384 
	RAAs.  Assume only 10,000 RAAs, each of which Authentication DET 
	Endorsement has a 10 year validity period.  This means that, on 
	average, 1,000 RAAs per year need to rekey their Authentication DET 
	Endorsement, or on average, 3 per day.  Current witnessed key 
	signing processes will not scale to this volume.  Some virtual 
	method (like in <xref target="Offline_Auth" />) is needed.
</t>
<section anchor="offline_keys" numbered="true" toc="default"> <name>Protecting against DKI/PKI compromise</name>
<t>
	There is always a risk of key compromise that could be a major 
	setback to the operation of a PKI and likewise the DRIP DKI.  To 
	mitigate this risk, the Authentication DETs MUST only be used in 
	offline signing operations.  They MUST NEVER be used on connected 
	systems.  The information needed to create the Endorsements and 
	X.509 certificates are brought to them on media that cannot 
	transfer code, for example in a QR code.  The objects that are 
	created are then transferred away from the offline system to be used 
	where needed.
</t>
<t>
	It should be noted that this offline process MUST be followed down 
	the DKI/PKI tree.  That is, the Apex has offline operations that 
	include signing the RAA Authentication DET that will be used in the 
	RAA's set up.
</t>
</section>
</section>
</middle>
<back>
<displayreference target="I-D.ietf-cose-cbor-encoded-cert" to="C509-Certificates"/>
<displayreference target="I-D.ietf-drip-registries" to="drip-registries"/>
<displayreference target="I-D.moskowitz-ec-pki" to="ec-pki-guidance"/>
<displayreference target="I-D.wiethuechter-drip-det-registration-coap-cwt" to="drip-registration-cwt"/>
<displayreference target="DOI_10.1109_IEEESTD.2018.8423794" to="IEEE 802.1AR"/>
<references> <name>References</name>
<references title="Normative References">
	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"/>
	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"/>
</references>
<references title="Informative References">
	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3597.xml"/>
	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4108.xml"/>
	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5280.xml"/>
	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9153.xml"/>
	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9374.xml"/>
<!--	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9380.xml"/> -->
	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9434.xml"/>
	<xi:include href="https://datatracker.ietf.org/doc/bibxml3/draft-ietf-cose-cbor-encoded-cert.xml"/>
	<xi:include href="https://datatracker.ietf.org/doc/bibxml3/draft-ietf-drip-registries.xml"/>
	<xi:include href="https://datatracker.ietf.org/doc/bibxml3/draft-moskowitz-ec-pki.xml"/>
	<xi:include href="https://datatracker.ietf.org/doc/bibxml3/draft-wiethuechter-drip-det-registration-coap-cwt.xml"/>
	<xi:include href="https://bib.ietf.org/public/rfc/bibxml7/reference.DOI.10.1109/IEEESTD.2018.8423794.xml"/>
	<reference anchor="IPv6-SPECIAL"  target="https://www.iana.org/assignments/iana-ipv6-special-registry/">
		<front>
			<title>IANA IPv6 Special-Purpose Address Registry</title>
			<author><organization>IANA</organization></author>
		</front>
	</reference>
	<reference anchor="CTA2063A" target="https://shop.cta.tech/products/small-unmanned-aerial-systems-serial-numbers">
	<front>
		<title>ANSI/CTA 2063-A Small Unmanned Aerial Systems Numbers</title>
		<author>
			<organization>ANSI/CTA</organization>
		</author>
		<date month="09" year="2019"/>
	</front>
	</reference>
	<reference anchor="ICAO-Doc-10169">
	<front>
		<title>ICAO Aviation Common Certificate Policy, Doc 10169</title>
		<author>
			<organization>ICAO</organization>
		</author>
	</front>
	<refcontent>To be available by Q2, 2025</refcontent>
	</reference>
<!--	<reference anchor="ISO-3166"  target="https://www.iso.org/iso-3166-country-codes.html">
		<front>
			<title>ISO 3166 Country Codes</title>
			<author><organization>ISO</organization></author>
		</front>
	</reference> -->
	<reference anchor="drip_scripts" target="https://github.com/ietf-wg-drip/drip-scripts">
	<front>
	<title>Python scripts to generate DETs and Endorsements</title>
    <author/>
		<date month="4" year="2023"/>
	</front>
	</reference>
</references>
</references>
<section anchor="test_dki" numbered="true" toc="default"> <name>Test DETs and Endorsements</name>
<t>
	The following are test DETs and Endorsements for the test DKI. This 
	testing environment is open to all.  There are 4 RAAs available for 
	others to build out.  HDAs under the 4 preset RAAs, or under any 
	of the 4, built out by others, are available.  Finally the test 
	HDA is available for setting up a handful of entities.  Any 
	tester wanting more than a few DETs for entities should plan on 
	doing that under their own HDA.
</t>
<t>
	The following are the test values and objects.  They were generated 
	using the csr-gen.py, raa-endorse.py, and hda-endorse.py scripts 
	available at <xref target="drip_scripts" format="default"/>.
</t>
<t>
	Note, that as there is no APEX level at this time, the RAA 
	Endorsement is self-signed.
</t>
<figure anchor="DKI_DET_Endorse-fig"> <name>Test DKI DETs and Endorsements</name>
<artwork anchor="test_dki_val-1" name="" type="" alt="">
<![CDATA[
raa16376
    Authorizing DET  (HID=16376|0)

# SN is there just because script needs it.
python csr-gen.py --keyname=raa16376 --serialnumber=0 --raa=16376/
 --hda=0
python raa-endorse.py --commandfile=raa16376

    HI: 9229539f2ae6a961d1c24977455da98162e53efc98df9eb30f72537699
        3a7275
    DET: 2001003ffe3ff8050911d10e29d8478e
    DET: 2001:003f:fe3f:f805:0911:d10e:29d8:478e
    vnb="03/01/2025"
    vna="03/01/2026"
    Endorsement(136 bytes): 67c2945069a3c7d02001003ffe3ff8050911d1
    0e29d8478e9229539f2ae6a961d1c24977455da98162e53efc98df9eb30f72
    5376993a72752001003ffe3ff8050911d10e29d8478e8455dcc5051fe724e6
    93ff951d44ccd20bcddc031833e810f9ce0e5b4ead5295a2e47f97d0a8f152
    8b27afbd0a5c01c76ac047a409db65e8a887b483b54b3000

]]>
</artwork>
<artwork anchor="test_dki_val-2" name="" type="" alt="">
<![CDATA[
hda16376-16376
    Authorizing DET  (HID=16376|16376)
# SN is there just because script needs it.
python csr-gen.py --keyname=hda16376-16376A --serialnumber=0
python raa-endorse.py --commandfile=hda16376-16376A

    HI: b82b27f86b013468fe48d85b54f01bf65385f302ab2e136dc51a3b929c
        88ce5a
    DET: 2001003ffe3ff805e805a98f9df15e2d
    DET: 2001:003f:fe3f:f805:e805:a98f:9df1:5e2d
    DETofRAA=2001003ffe3ff8050911d10e29d8478e
    vnb="03/02/2025"
    vna="02/28/2026"

    Endorsement(136 bytes): 67c3e5d069a276502001003ffe3ff805e805a9
    8f9df15e2db82b27f86b013468fe48d85b54f01bf65385f302ab2e136dc51a
    3b929c88ce5a2001003ffe3ff8050911d10e29d8478e1e3d4e8fc23568ecbd
    695b67d874172ca22793bfbea25c6ced095a69f3a518a53d56a1bc53508ee2
    7449dd5d088cb4d8641a86b3b04394c0e118a40663075d0e

]]>
</artwork>
<artwork anchor="test_dki_val-3" name="" type="" alt="">
<![CDATA[
    Issuing DET  (HID=16376|16376)

# SN is there just because script needs it.
python csr-gen.py --keyname=hda16376-16376I --serialnumber=0
python raa-endorse.py --commandfile=hda16376-16376I --certsign=Y

    HI: cc75d75df778734d2e5b682f6ff938abf10a1026f788dca99945cbddac
        f3d723
    DET: 2001003ffe3ff805aa16ed2392f6f0cb
    DET: 2001:003f:fe3f:f805:aa16:ed23:92f6:f0cb
    DETofHDA=0x2001003ffe3ff805e805a98f9df15e2d
    vnb="03/02/2025"
    vna="02/27/2026"

    Endorsement(136 bytes): 67c3e5d069a124d02001003ffe3ff805aa16ed
    2392f6f0cbcc75d75df778734d2e5b682f6ff938abf10a1026f788dca99945
    cbddacf3d7232001003ffe3ff805e805a98f9df15e2df6bb7c846c8da369d2
    ce114d5458ea47a2ca7675193170c0bb94824544f68b237cd190295d957610
    2adb56422c762c8630bf749306c7f606afbb3a6a996d7807
]]>
</artwork>
<artwork anchor="test_dki_val-4" name="" type="" alt="">
<![CDATA[
    UA DET in 16376.16376
    
python csr-gen.py --keyname=ua1-16376-16376/
 --serialnumber=x1224AABBCCDDEE56789
python hda-endorse.py --commandfile=ua1-16376-16376

    DET: 2001003ffe3ff805aa28cd1ae2a3dae3
    DET: 2001:003f:fe3f:f805:aa28:cd1a:e2a3:dae3
    HI: 26fd3a734b3366ffe4ab68dbd2230812fd0b197090ba1eaa7eb34ffa38
    ffb78f
    DETofHDA=0x2001003ffe3ff8059f5514beac58f8db
    vnb="03/04/2025"
    vna="02/25/2026"
    Endorsement(136 bytes): 67c688d0699e81d02001003ffe3ff805aa28cd
    1ae2a3dae326fd3a734b3366ffe4ab68dbd2230812fd0b197090ba1eaa7eb3
    4ffa38ffb78f2001003ffe3ff805aa16ed2392f6f0cbef965cac46990bec69
    580dd96ff471bc2bfc221adf0c93920341406806f1f00b6b9bec65879aa8bf
    db551a8be16ec7ee4b32c32e95f7d85bc9643b09eb94a102

]]>
</artwork>
</figure>
<section anchor="test_dns" numbered="true" toc="default"> <name>Test DNS</name>
<t>
	The DNS tree(s) for the above test data is still in limbo and will 
	be added in a later version of this draft with the proposed DET RR 
	from <xref target="I-D.ietf-drip-registries" format="default"/>.  
</t>
</section>
</section>
<section anchor="test_pki_certs" numbered="true" toc="default"> <name>Test X.509 certificates</name>
<section anchor="test_pki_lite_certs" numbered="true" toc="default"> <name>Test Lite X.509 certificates</name>
<t>
	The following the test DRIP X.509 certificates that mirror the test 
	Endorsements.
</t>
<figure anchor="Lite_x509-fig"> <name>Test Lite X.509 certificates</name>
<artwork anchor="x509-Lite-raa16376-cert" name="" type="" alt="">
<![CDATA[
  raa16376.pem (der is 300 bytes)
  
-----BEGIN CERTIFICATE-----
MIIBKDCB26ADAgECAgJYGjAFBgMrZXAwKzEpMCcGA1UEAwwgMjAwMTAwM2ZmZTNm
ZjgwNTA5MTFkMTBlMjlkODQ3OGUwHhcNMjUwMzAxMDAwMTAwWhcNMjYwMzAxMjM1
OTAwWjAbMRkwFwYDVQQDDBBEUklQLVJBQS1BLTE2Mzc2MCowBQYDK2VwAyEAkilT
nyrmqWHRwkl3RV2pgWLlPvyY356zD3JTdpk6cnWjMzAxMB4GA1UdEQEB/wQUMBKH
ECABAD/+P/gFCRHRDinYR44wDwYDVR0TAQH/BAUwAwEB/zAFBgMrZXADQQAnexSf
Co2Q6cbhe4olvF8meRh40OdooIqO7ZW75aipE9wTHPA+OxKt/fq3SYcRdRZ+qbo3
sNcB+0XMxNZvsgsH
-----END CERTIFICATE-----

Certificate: 461 bytes
    Data:
        Version: 3 (0x2)
        Serial Number: 22554 (0x581a)
        Signature Algorithm: ED25519
        Issuer: CN=2001003ffe3ff8050911d10e29d8478e
        Validity
            Not Before: Mar  1 00:01:00 2025 GMT
            Not After : Mar  1 23:59:00 2026 GMT
        Subject: CN=DRIP-RAA-A-16376
        Subject Public Key Info:
            Public Key Algorithm: ED25519
                ED25519 Public-Key:
                pub:
                    92:29:53:9f:2a:e6:a9:61:d1:c2:49:77:45:5d:a9:
                    81:62:e5:3e:fc:98:df:9e:b3:0f:72:53:76:99:3a:
                    72:75
        X509v3 extensions:
            X509v3 Subject Alternative Name: critical
                IP Address:2001:3F:FE3F:F805:911:D10E:29D8:478E
            X509v3 Basic Constraints: critical
                CA:TRUE
    Signature Algorithm: ED25519
    Signature Value:
        27:7b:14:9f:0a:8d:90:e9:c6:e1:7b:8a:25:bc:5f:26:79:18:
        78:d0:e7:68:a0:8a:8e:ed:95:bb:e5:a8:a9:13:dc:13:1c:f0:
        3e:3b:12:ad:fd:fa:b7:49:87:11:75:16:7e:a9:ba:37:b0:d7:
        01:fb:45:cc:c4:d6:6f:b2:0b:07
]]>
</artwork>
<artwork anchor="x509-Lite-Ahda16376-16376-cert" name="" type="" alt="">
<![CDATA[
  Authentication hda16376-16376A.pem (der is 306 bytes)

-----BEGIN CERTIFICATE-----
MIIBLjCB4aADAgECAgIQRzAFBgMrZXAwKzEpMCcGA1UEAwwgMjAwMTAwM2ZmZTNm
ZjgwNTA5MTFkMTBlMjlkODQ3OGUwHhcNMjUwMzAyMDAwMTAwWhcNMjYwMjI4MjM1
OTAwWjAhMR8wHQYDVQQDDBZEUklQLUhEQS1BLTE2Mzc2LTE2Mzc2MCowBQYDK2Vw
AyEAuCsn+GsBNGj+SNhbVPAb9lOF8wKrLhNtxRo7kpyIzlqjMzAxMB4GA1UdEQEB
/wQUMBKHECABAD/+P/gF6AWpj53xXi0wDwYDVR0TAQH/BAUwAwEB/zAFBgMrZXAD
QQDi3VQl7w4i5FbnlnIyJnRHzNaPGMQkI4nq30mJTiyw2YtjBsBHtVYAzDoSzFT1
tXQ+L3LtwkwYgNDykSi/QyUN
-----END CERTIFICATE-----
  
Certificate:   469 bytes
    Data:
        Version: 3 (0x2)
        Serial Number: 4167 (0x1047)
        Signature Algorithm: ED25519
        Issuer: CN=2001003ffe3ff8050911d10e29d8478e
        Validity
            Not Before: Mar  2 00:01:00 2025 GMT
            Not After : Feb 28 23:59:00 2026 GMT
        Subject: CN=DRIP-HDA-A-16376-16376
        Subject Public Key Info:
            Public Key Algorithm: ED25519
                ED25519 Public-Key:
                pub:
                    b8:2b:27:f8:6b:01:34:68:fe:48:d8:5b:54:f0:1b:
                    f6:53:85:f3:02:ab:2e:13:6d:c5:1a:3b:92:9c:88:
                    ce:5a
        X509v3 extensions:
            X509v3 Subject Alternative Name: critical
                IP Address:2001:3F:FE3F:F805:E805:A98F:9DF1:5E2D
            X509v3 Basic Constraints: critical
                CA:TRUE
    Signature Algorithm: ED25519
    Signature Value:
        e2:dd:54:25:ef:0e:22:e4:56:e7:96:72:32:26:74:47:cc:d6:
        8f:18:c4:24:23:89:ea:df:49:89:4e:2c:b0:d9:8b:63:06:c0:
        47:b5:56:00:cc:3a:12:cc:54:f5:b5:74:3e:2f:72:ed:c2:4c:
        18:80:d0:f2:91:28:bf:43:25:0d
]]>
</artwork>
<artwork anchor="x509-Lite-Ihda16376-16376-cert" name="" type="" alt="">
<![CDATA[
  Issuing hda16376-16376I.pem (der is 322 bytes)

-----BEGIN CERTIFICATE-----
MIIBPjCB8aADAgECAgIbIDAFBgMrZXAwKzEpMCcGA1UEAwwgMjAwMTAwM2ZmZTNm
ZjgwNWU4MDVhOThmOWRmMTVlMmQwHhcNMjUwMzAyMDAwMTAwWhcNMjYwMjI3MjM1
OTAwWjAhMR8wHQYDVQQDDBZEUklQLUhEQS1JLTE2Mzc2LTE2Mzc2MCowBQYDK2Vw
AyEAzHXXXfd4c00uW2gvb/k4q/EKECb3iNypmUXL3azz1yOjQzBBMB4GA1UdEQEB
/wQUMBKHECABAD/+P/gFqhbtI5L28MswDwYDVR0TAQH/BAUwAwEB/zAOBgNVHQ8B
Af8EBAMCAgQwBQYDK2VwA0EACXNFWKbsWuKUF0ZltNzOGz2YIFXr9m+0GrFsuo/6
0ycoh1obOk6O3uRsd4AhP8xiChjxf7j+Nd11mzBhZIKkAA==
-----END CERTIFICATE-----

Certificate:    493 bytes
    Data:
        Version: 3 (0x2)
        Serial Number: 6944 (0x1b20)
        Signature Algorithm: ED25519
        Issuer: CN=2001003ffe3ff805e805a98f9df15e2d
        Validity
            Not Before: Mar  2 00:01:00 2025 GMT
            Not After : Feb 27 23:59:00 2026 GMT
        Subject: CN=DRIP-HDA-I-16376-16376
        Subject Public Key Info:
            Public Key Algorithm: ED25519
                ED25519 Public-Key:
                pub:
                    cc:75:d7:5d:f7:78:73:4d:2e:5b:68:2f:6f:f9:38:
                    ab:f1:0a:10:26:f7:88:dc:a9:99:45:cb:dd:ac:f3:
                    d7:23
        X509v3 extensions:
            X509v3 Subject Alternative Name: critical
                IP Address:2001:3F:FE3F:F805:AA16:ED23:92F6:F0CB
            X509v3 Basic Constraints: critical
                CA:TRUE
            X509v3 Key Usage: critical
                Certificate Sign
    Signature Algorithm: ED25519
    Signature Value:
        09:73:45:58:a6:ec:5a:e2:94:17:46:65:b4:dc:ce:1b:3d:98:
        20:55:eb:f6:6f:b4:1a:b1:6c:ba:8f:fa:d3:27:28:87:5a:1b:
        3a:4e:8e:de:e4:6c:77:80:21:3f:cc:62:0a:18:f1:7f:b8:fe:
        35:dd:75:9b:30:61:64:82:a4:00
]]>
</artwork>
<artwork anchor="x509-Lite-UA1-hda16376-16376-cert" name="" type="" alt="">
<![CDATA[

  ua1-16376-16376csr.pem  290 bytes

Certificate Request:
    Data:
        Version: 1 (0x0)
        Subject: serialNumber=x1224AABBCCDDEE56789
        Subject Public Key Info:
            Public Key Algorithm: ED25519
                ED25519 Public-Key:
                pub:
                    8a:7a:47:db:44:c6:58:2f:0e:1f:99:5d:55:fe:5e:
                    dd:ff:0b:97:12:44:5b:63:68:e1:a5:5f:60:38:1b:
                    4c:b7
        Attributes:
            (none)
            Requested Extensions:
    Signature Algorithm: ED25519
    Signature Value:
        2b:73:a9:6a:e7:07:3c:95:b4:71:95:06:43:ee:fc:3d:27:88:
        54:46:68:42:76:c7:7b:e9:1b:4b:6e:e1:4a:37:be:5f:79:e2:
        b8:6d:60:75:ea:49:13:54:75:e6:47:6a:14:8d:90:52:e1:32:
        58:f1:06:29:f6:b1:7d:24:d7:05

  ua1-16376-16376.pem (der is 256 bytes)

-----BEGIN CERTIFICATE-----
MIH9MIGwoAMCAQICA0glVDAFBgMrZXAwKzEpMCcGA1UEAwwgMjAwMTAwM2ZmZTNm
ZjgwNWFhMTZlZDIzOTJmNmYwY2IwHhcNMjUwMzA0MDAwMTAwWhcNMjYwMjI1MjM1
OTAwWjAAMCowBQYDK2VwAyEAJv06c0szZv/kq2jb0iMIEv0LGXCQuh6qfrNP+jj/
t4+jIjAgMB4GA1UdEQEB/wQUMBKHECABAD/+P/gFqijNGuKj2uMwBQYDK2VwA0EA
jnOvDNmjNbzPCdz8VV6IsO/JctmzJGbYF1EyR5jkyeSP0152tz1TMQnPBx8ibpe0
JeDXJU2CNiiHGcA5utZmDA==
-----END CERTIFICATE-----

Certificate Request:  404 bytes
    Data:
        Version: 1 (0x0)
        Serial Number: 4728148 (0x482554)
        Signature Algorithm: ED25519
        Issuer: CN=2001003ffe3ff805aa16ed2392f6f0cb
        Validity
            Not Before: Mar  4 00:01:00 2025 GMT
            Not After : Feb 25 23:59:00 2026 GMT
        Subject: 
        Subject Public Key Info:
            Public Key Algorithm: ED25519
                ED25519 Public-Key:
                pub:
                    26:fd:3a:73:4b:33:66:ff:e4:ab:68:db:d2:23:08:
                    12:fd:0b:19:70:90:ba:1e:aa:7e:b3:4f:fa:38:ff:
                    b7:8f
        X509v3 extensions:
            X509v3 Subject Alternative Name: critical
                IP Address:2001:3F:FE3F:F805:AA28:CD1A:E2A3:DAE3
    Signature Algorithm: ED25519
    Signature Value:
        8e:73:af:0c:d9:a3:35:bc:cf:09:dc:fc:55:5e:88:b0:ef:c9:
        72:d9:b3:24:66:d8:17:51:32:47:98:e4:c9:e4:8f:d3:5e:76:
        b7:3d:53:31:09:cf:07:1f:22:6e:97:b4:25:e0:d7:25:4d:82:
        36:28:87:19:c0:39:ba:d6:66:0c

]]>
</artwork>
</figure>
</section>
<section anchor="test_pki_reg_certs" numbered="true" toc="default"> <name>Test PKIX-like X.509 certificates</name>
<t>
	This section follows an earlier certificate design and needs updates.
</t>
<t>
	The following the test DRIP PKIX-like X.509 certificates that 
	mirror the test Endorsements of prior drafts.  Note that this 
	section is unchanged from prior work and needs updates to bring to 
	the current design.
</t>
<t>
	Further, the actual commands used to produce these certificates 
	needs to be included.  The commands used generate these "old" 
	results are available on request.  A later update will have new 
	test results and will include the openSSL commands used.
</t>
<figure anchor="PKIX_x509-fig"> <name>Test PKIX-like X.509 certificates</name>
<artwork anchor="x509-raa16376-cert" name="" type="" alt="">
<![CDATA[
  raa16376.cert.pem (der is 331 bytes)
  
  -----BEGIN CERTIFICATE-----
  MIIBRzCB+qADAgECAgkAtub1kRGFxHgwBQYDK2VwMBsxGTAXBgNVBAMMEDIwMDEw
  MDMwMDAwMDAwMDUwHhcNMjMwNTE1MDAwMDAwWhcNMjQwNTI0MDAwMDAwWjAbMRkw
  FwYDVQQDDBAyMDAxMDAzZmZlMDAwMDA1MCowBQYDK2VwAyEA335kzBv9y2WDVDez
  e2EQ1W/tuBRD9Y1T34CU4OKCjSOjWzBZMBkGA1UdDgQSBBAgAQA//gAABflwpNf9
  DhSlMBsGA1UdIwQUMBKAECABADAAAAAFKuua3BzosewwDwYDVR0TAQH/BAUwAwEB
  /zAOBgNVHQ8BAf8EBAMCAgQwBQYDK2VwA0EAqw9AheCVGyvi3/qp9QOdV+xQcKFM
  7jRX1+3uWR7FUoVZez2QX/dueYELScLqbHE7bK1KfAgavrD1YZZE2gJRCw==
  -----END CERTIFICATE-----
  
  Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number:
            b6:e6:f5:91:11:85:c4:78
        Signature Algorithm: ED25519
        Issuer: CN = 2001003000000005
        Validity
            Not Before: May 15 00:00:00 2023 GMT
            Not After : May 24 00:00:00 2024 GMT
        Subject: CN = 2001003ffe000005
        Subject Public Key Info:
            Public Key Algorithm: ED25519
                ED25519 Public-Key:
                pub:
                    df:7e:64:cc:1b:fd:cb:65:83:54:37:b3:7b:61:10:
                    d5:6f:ed:b8:14:43:f5:8d:53:df:80:94:e0:e2:82:
                    8d:23
        X509v3 extensions:
            X509v3 Subject Key Identifier: 
                20:01:00:3F:FE:00:00:05:F9:70:A4:D7:FD:0E:14:A5
            X509v3 Authority Key Identifier: 
                20:01:00:30:00:00:00:05:2A:EB:9A:DC:1C:E8:B1:EC
            X509v3 Basic Constraints: critical
                CA:TRUE
            X509v3 Key Usage: critical
                Certificate Sign
    Signature Algorithm: ED25519
    Signature Value:
        ab:0f:40:85:e0:95:1b:2b:e2:df:fa:a9:f5:03:9d:57:ec:50:
        70:a1:4c:ee:34:57:d7:ed:ee:59:1e:c5:52:85:59:7b:3d:90:
        5f:f7:6e:79:81:0b:49:c2:ea:6c:71:3b:6c:ad:4a:7c:08:1a:
        be:b0:f5:61:96:44:da:02:51:0b
]]>
</artwork>
<artwork anchor="x509-Ahda16376-16376-cert" name="" type="" alt="">
<![CDATA[
  Authentication hda16376-16376.cert.pem (der is 331 bytes)
  
  -----BEGIN CERTIFICATE-----
  MIIBRzCB+qADAgECAgkAvmZjQZW1SFcwBQYDK2VwMBsxGTAXBgNVBAMMEDIwMDEw
  MDNmZmUwMDAwMDUwHhcNMjMwNTIxMDAwMDAwWhcNMjQwNTIxMDAwMDAwWjAbMRkw
  FwYDVQQDDBAyMDAxMDAzZmZlM2ZmODA1MCowBQYDK2VwAyEA6PbZH31TUUhUcUIK
  nH1d8YDHox24bMk3WB7oEG8Y5OujWzBZMBkGA1UdDgQSBBAgAQA//j/4BegFqY+d
  8V4tMBsGA1UdIwQUMBKAECABAD/+AAAF+XCk1/0OFKUwDwYDVR0TAQH/BAUwAwEB
  /zAOBgNVHQ8BAf8EBAMCAgQwBQYDK2VwA0EAGUPOy6K8XxT6QaguvdTVxhHba2Ws
  MEzF/oeyi8V1DNaH5wrLDgQLng7RrQfXpkUbI9l7GBq8+nr4jKkqcIxvDA==
  -----END CERTIFICATE-----

  Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number:
            be:66:63:41:95:b5:48:57
        Signature Algorithm: ED25519
        Issuer: CN = 2001003ffe000005
        Validity
            Not Before: May 21 00:00:00 2023 GMT
            Not After : May 21 00:00:00 2024 GMT
        Subject: CN = 2001003ffe3ff805
        Subject Public Key Info:
            Public Key Algorithm: ED25519
                ED25519 Public-Key:
                pub:
                    e8:f6:d9:1f:7d:53:51:48:54:71:42:0a:9c:7d:5d:
                    f1:80:c7:a3:1d:b8:6c:c9:37:58:1e:e8:10:6f:18:
                    e4:eb
        X509v3 extensions:
            X509v3 Subject Key Identifier: 
                20:01:00:3F:FE:3F:F8:05:E8:05:A9:8F:9D:F1:5E:2D
            X509v3 Authority Key Identifier: 
                20:01:00:3F:FE:00:00:05:F9:70:A4:D7:FD:0E:14:A5
            X509v3 Basic Constraints: critical
                CA:TRUE
            X509v3 Key Usage: critical
                Certificate Sign
    Signature Algorithm: ED25519
    Signature Value:
        19:43:ce:cb:a2:bc:5f:14:fa:41:a8:2e:bd:d4:d5:c6:11:db:
        6b:65:ac:30:4c:c5:fe:87:b2:8b:c5:75:0c:d6:87:e7:0a:cb:
        0e:04:0b:9e:0e:d1:ad:07:d7:a6:45:1b:23:d9:7b:18:1a:bc:
        fa:7a:f8:8c:a9:2a:70:8c:6f:0c
]]>
</artwork>
<artwork anchor="x509-Ehda16376-16376-cert" name="" type="" alt="">
<![CDATA[
  Issuing hda16376-16376.cert.pem (der is 332 bytes)
  
  -----BEGIN CERTIFICATE-----
  MIIBSDCB+6ADAgECAgkAtkOsgzdFgMwwBQYDK2VwMBsxGTAXBgNVBAMMEDIwMDEw
  MDNmZmUzZmY4MDUwHhcNMjMwNTE0MDAwMDAwWhcNMjQwNTE0MDAwMDAwWjAcMRow
  GAYDVQQDDBEyMDAxMDAzZmZlM2ZmODA1STAqMAUGAytlcAMhAGXya8AbiTmPeHxH
  heTn9uAfKZMTd1mZXXuqcnkaRKxdo1swWTAZBgNVHQ4EEgQQIAEAP/4/+AWbDihg
  6wus3jAbBgNVHSMEFDASgBAgAQA//j/4BegFqY+d8V4tMA8GA1UdEwEB/wQFMAMB
  Af8wDgYDVR0PAQH/BAQDAgIEMAUGAytlcANBAJo6Va29k8nYIUvHqnQJlwGHHz0u
  gXgvaQuAt6f66T4eTX5zqG/ARy2MzDVlO0H/ojzWi3qiyAHjATcYRxMqzw8=
  -----END CERTIFICATE-----

  Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number:
            b6:43:ac:83:37:45:80:cc
        Signature Algorithm: ED25519
        Issuer: CN = 2001003ffe3ff805
        Validity
            Not Before: May 14 00:00:00 2023 GMT
            Not After : May 14 00:00:00 2024 GMT
        Subject: CN = 2001003ffe3ff805I
        Subject Public Key Info:
            Public Key Algorithm: ED25519
                ED25519 Public-Key:
                pub:
                    65:f2:6b:c0:1b:89:39:8f:78:7c:47:85:e4:e7:f6:
                    e0:1f:29:93:13:77:59:99:5d:7b:aa:72:79:1a:44:
                    ac:5d
        X509v3 extensions:
            X509v3 Subject Key Identifier: 
                20:01:00:3F:FE:3F:F8:05:9B:0E:28:60:EB:0B:AC:DE
            X509v3 Authority Key Identifier: 
                20:01:00:3F:FE:3F:F8:05:E8:05:A9:8F:9D:F1:5E:2D
            X509v3 Basic Constraints: critical
                CA:TRUE
            X509v3 Key Usage: critical
                Certificate Sign
    Signature Algorithm: ED25519
    Signature Value:
        9a:3a:55:ad:bd:93:c9:d8:21:4b:c7:aa:74:09:97:01:87:1f:
        3d:2e:81:78:2f:69:0b:80:b7:a7:fa:e9:3e:1e:4d:7e:73:a8:
        6f:c0:47:2d:8c:cc:35:65:3b:41:ff:a2:3c:d6:8b:7a:a2:c8:
        01:e3:01:37:18:47:13:2a:cf:0f
]]>
</artwork>
<artwork anchor="x509-UA1-hda16376-16376-cert" name="" type="" alt="">
<![CDATA[

  UA1-16376-16376 CSR

    Data:
        Version: 1 (0x0)
        Subject: 
        Subject Public Key Info:
            Public Key Algorithm: ED25519
                ED25519 Public-Key:
                pub:
                    bf:04:53:a0:11:20:ed:8e:65:1a:e9:f6:95:1a:82:
                    78:3d:a8:20:29:6a:33:8e:ff:d5:4a:0b:a8:46:a9:
                    98:75
        Attributes:
            Requested Extensions:
                X509v3 Subject Alternative Name: critical
                    IP Address:2001:3F:FE3F:F805:A93E:53B7:2709:E0BA
    Signature Algorithm: ED25519
    Signature Value:
        e5:36:03:fa:3c:7b:c7:a8:03:4e:6e:37:37:de:79:7d:c3:d4:
        01:43:a4:62:4d:91:ec:e5:20:0e:7f:6e:2f:f2:44:02:3a:b8:
        b8:3f:1f:60:a8:e9:02:40:cc:e0:73:70:1c:2c:c5:1a:12:21:
        ff:a8:f8:d0:07:a8:47:29:fd:05

  UA1-16376-16376.cert.pem (der is 335 bytes)
  
  -----BEGIN CERTIFICATE-----
  MIIBSzCB/qADAgECAgkAnwfIckSSf74wBQYDK2VwMBwxGjAYBgNVBAMMETIwMDEw
  MDNmZmUzZmY4MDVJMB4XDTIzMDUyMTAwMDAwMFoXDTIzMDUyNDAwMDAwMFowADAq
  MAUGAytlcAMhAL8EU6ARIO2OZRrp9pUagng9qCApajOO/9VKC6hGqZh1o3kwdzAJ
  BgNVHRMEAjAAMA4GA1UdDwEB/wQEAwIDyDAdBgNVHSUEFjAUBggrBgEFBQcDAgYI
  KwYBBQUHAwQwHgYDVR0RAQH/BBQwEocQIAEAP/4/+AWpPlO3JwngujAbBgNVHSME
  FDASgBAgAQA//j/4BZsOKGDrC6zeMAUGAytlcANBAL0ztu4wCQZFH7V/gfKnK5fP
  HqUXxYzA4stvb4k1DMEHgum8NesVnlOhZ3OPpUet6GrnjIKd8SksbADW1h+hcwI=
  -----END CERTIFICATE-----

Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number:
            9f:07:c8:72:44:92:7f:be
        Signature Algorithm: ED25519
        Issuer: CN = 2001003ffe3ff805I
        Validity
            Not Before: May 21 00:00:00 2023 GMT
            Not After : May 24 00:00:00 2023 GMT
        Subject: 
        Subject Public Key Info:
            Public Key Algorithm: ED25519
                ED25519 Public-Key:
                pub:
                    bf:04:53:a0:11:20:ed:8e:65:1a:e9:f6:95:1a:82:
                    78:3d:a8:20:29:6a:33:8e:ff:d5:4a:0b:a8:46:a9:
                    98:75
        X509v3 extensions:
            X509v3 Basic Constraints: 
                CA:FALSE
            X509v3 Key Usage: critical
                Digital Signature, Non Repudiation, Key Agreement
            X509v3 Extended Key Usage: 
                TLS Web Client Authentication, E-mail Protection
            X509v3 Subject Alternative Name: critical
                IP Address:2001:3F:FE3F:F805:A93E:53B7:2709:E0BA
            X509v3 Authority Key Identifier: 
                20:01:00:3F:FE:3F:F8:05:9B:0E:28:60:EB:0B:AC:DE
    Signature Algorithm: ED25519
    Signature Value:
        bd:33:b6:ee:30:09:06:45:1f:b5:7f:81:f2:a7:2b:97:cf:1e:
        a5:17:c5:8c:c0:e2:cb:6f:6f:89:35:0c:c1:07:82:e9:bc:35:
        eb:15:9e:53:a1:67:73:8f:a5:47:ad:e8:6a:e7:8c:82:9d:f1:
        29:2c:6c:00:d6:d6:1f:a1:73:02
]]>
</artwork>
</figure>
<section anchor="conf" numbered="true" toc="default"> <name>openSSL config file</name>
<t>
	The following openssl-conf file was used to create the above 
	certificates; as such it needs updates.  It is dependent on a 
	number of environment variables to make each unique certificate.  
	The conf file is a bit of a hack of multiple conf files and some 
	sections are really not used.  It is included here as a guide.
</t>
<figure anchor="PKIX_conf-fig"> <name>Test PKIX-like OpenSSL Config File</name>
<artwork anchor="openssl-conf-cert" name="" type="" alt="">
<![CDATA[
# OpenSSL DRIP X.509 configuration file.
# Copy to `$dir/openssl-root.cnf`.

[ ca ]
# `man ca`
default_ca = CA_default

[ CA_default ]
# Directory and file locations.
dir               = $ENV::dir
cadir             = $ENV::cadir
format            = $ENV::format
signcert          = $ENV::signcert
certkeyusage      = $ENV::certkeyusage
certextkeyusage   = $ENV::certextkeyusage
basicConstraints  = $ENV::basicConstraints

certs             = $dir/certs
crl_dir           = $dir/crl
new_certs_dir     = $dir/newcerts
database          = $dir/index.txt
serial            = $dir/serial
RANDFILE          = $dir/private/.rand

# The signing key and signing certificate.
private_key       = $cadir/private/$signcert.key.$format
certificate       = $cadir/certs/$signcert.cert.$format

# For certificate revocation lists.
crlnumber         = $dir/crlnumber
crl               = $dir/crl/ca.crl.pem
crl_extensions    = crl_ext
default_crl_days  = 30

# SHA-1 is deprecated, so use SHA-2 instead.
default_md        = sha256

name_opt          = ca_default
cert_opt          = ca_default
default_startdate = $ENV::startdate
default_enddate   = $ENV::enddate
preserve          = no
policy            = policy_loose
copy_extensions   = copy

[ policy_loose ]
# Allow the intermediate CA to sign a more
#   diverse range of certificates.
# See the POLICY FORMAT section of the `ca` man page.
countryName             = optional
stateOrProvinceName     = optional
localityName            = optional
organizationName        = optional
organizationalUnitName  = optional
commonName              = optional

[ req ]
# Options for the `req` tool (`man req`).
distinguished_name  = req_distinguished_name
string_mask         = utf8only
req_extensions      = req_ext
default_crl_days  = 30

# SHA-1 is deprecated, so use SHA-2 instead.
default_md          = sha256

# Extension to add when the -x509 option is used.
x509_extensions     = v3_ca

[ req_distinguished_name ]
# See <https://en.wikipedia.org/wiki/Certificate_signing_request>.
#countryName                     = Country Name (2 letter code)
#stateOrProvinceName             = State or Province Name
#localityName                    = Locality Name
#0.organizationName              = Organization Name
#organizationalUnitName          = Organizational Unit Name
commonName                      = Common Name

[ req_ext ]
basicConstraints = $ENV::basicConstraints
keyUsage = $ENV::certkeyusage

[ v3_ca ]
# Extensions for a typical CA (`man x509v3_config`).
subjectKeyIdentifier = $ENV::DET
authorityKeyIdentifier = keyid:always
basicConstraints = critical, CA:true
keyUsage = $ENV::certkeyusage

[ usr_cert ]
# Extensions for client certificates (`man x509v3_config`).
basicConstraints = $ENV::basicConstraints
authorityKeyIdentifier = keyid:always
keyUsage = $ENV::certkeyusage
extendedKeyUsage = $ENV::certextkeyusage
# uncomment the following if the ENV variables set
# crlDistributionPoints = $ENV::crlDP
# authorityInfoAccess = $ENV::ocspIAI

[ usr_req ]
# Extensions for client certificates (`man x509v3_config`).
subjectAltName = critical, $ENV::subjectAltName

[ crl_ext ]
# Extension for CRLs (`man x509v3_config`).
authorityKeyIdentifier=keyid:always

[ ocsp ]
# Extension for OCSP signing certificates (`man ocsp`).
basicConstraints = CA:FALSE
subjectKeyIdentifier = hash
authorityKeyIdentifier = keyid,issuer
# keyUsage = critical, digitalSignature
keyUsage = $ENV::certkeyusage
# extendedKeyUsage = critical, OCSPSigning
extendedkeyUsage = $ENV::certextkeyusage
]]>
</artwork>
</figure>
</section>
</section>
<section anchor="c509_certs" numbered="true" toc="default"> <name>Test Lite C509 certificates</name>
<t>
	The CBOR Encoded X.509 Certificates (C509 Certificates) <xref 
	target="I-D.ietf-cose-cbor-encoded-cert" format="default"/> 
	provides a standards-based approach to reduce the size of X.509 
	certificates both on-the-wire and in storage.
</t>
<t>
	These C509 certificates MAY be stored in the DET RR, but are more 
	likely to by used in over-the-air protocols and exist only for 
	transmission, being converted from/to their source X.509 
	certificates.
</t>
<t>
	Author's Note:  This section is still a Work in Progress.  The CBOR 
	diagnostic tool is currently not working, and that content should 
	be added back in on a later revision.  Further note that we think 
	there is a bug in the c509 code, making the certificate version = 
	1, not 3.
</t>
<t>
	The following are examples of a C509 cert.
</t>
<figure anchor="Lite_c509-fig"> <name>Test Lite C.509 certificates</name>
<artwork anchor="x509-raa16376-c509-cert" name="" type="" alt="">
<![CDATA[
  raa16376.cert CBOR:
  
COSE_X509 (212 bytes)
8B 01 54 77 87 D8 A9 EB 72 E4 19 90 AF DB 94 CA 79 54 82 CB 93 D2 C5
78 20 32 30 30 31 30 30 33 66 66 65 30 30 30 30 30 35 30 36 61 62 35
38 37 35 34 66 36 38 65 36 62 33 1A 66 D3 AE BC 1A 6A 96 15 44 70 44
52 49 50 2D 52 41 41 2D 41 2D 31 36 33 37 36 0A 58 20 32 52 8C 1C 11
5D 00 4D 1F 00 8D 07 AC 50 7A 2D 83 BB AB 74 60 40 52 2E A6 CD C7 86
FA BC 80 57 86 22 82 07 50 20 01 00 3F FE 00 00 05 06 AB 58 75 4F 68
E6 B3 23 20 21 18 20 0C 58 40 EF E9 BB 74 75 FF 32 FF 72 2E CC CB B9
67 C1 6B 69 0E 99 00 84 87 1C AE E3 23 CA 69 13 C4 77 3C D3 1A C6 EA
F0 40 85 F8 21 83 06 25 B0 B7 68 E2 38 82 B9 DB 1E 93 1A DB D4 6E 60
69 99 F6 E1 0F
]]>
</artwork>
<artwork anchor="x509-UA1-16376-16376-c509-cert-diag" name="" type="" alt="">
<![CDATA[
  ua1-16376-16376.cert CBOR:

COSE_X509 (173 bytes)
8B 01 42 22 0E 78 20 32 30 30 31 30 30 33 66 66 65 33 66 66 38 30 35
39 66 35 35 31 34 62 65 61 63 35 38 66 38 64 62 1A 66 EB 69 BC 1A 68
CF 3F C4 80 0A 58 20 88 F5 E2 D5 C7 16 1B 5B 15 A5 90 B4 A5 6C 47 59
FE 46 CB 1B BA D1 1F 07 0E B3 EC 7B DD 28 A9 69 82 22 82 07 50 20 01
00 3F FE 3F F8 05 78 CC 48 8C 41 B5 2B 28 0C 58 40 75 83 86 30 FD 17
AB F6 12 12 54 B5 54 BD A7 7C 74 A2 52 7B 68 22 01 A3 4E 65 B0 ED 7B
17 96 86 C6 44 5C C5 8D 5A E8 46 90 47 9F 2A 4E 48 6C 03 3D 72 CF 62
B2 55 91 D5 B5 FE A3 DD 47 31 77 01
]]>
</artwork>
</figure>
</section>
</section>
<section numbered="false" toc="default"> <name>Acknowledgments</name>
<t>
	Many people assisted in creating the python scripts for making DETs 
	and DRIP Endorsements. Any roughness in the scripts is all my 
	doing.
</t>
<t>
	The openssl-user mailing list provided needed help in getting 
	openssl command line to do what was needed to build the test PKI.
</t>
<t>
	The COSE C509 authors are providing active help in creating the 
	C509 equivalent objects.
</t>
</section>
</back>
</rfc>
