]> Sandelman Software Works

mcr+ietf@sandelman.ca

vanderstok consultancy

consultancy@vanderstok.org

Cisco Systems

pkampana@cisco.com

Internet anima Working Group Internet-Draft This document defines a strategy to securely assign a pledge to an owner, using an artifact signed, directly or indirectly, by the pledge’s manufacturer. This artifact is known as a “voucher”. This document builds upon the work in , encoding the resulting artifact in CBOR. Use with two signature technologies are described. Additionally, this document explains how constrained vouchers may be transported as an extension to the protocol.

Enrollment of new nodes into constrained networks with constrained nodes present unique challenges. There are bandwidth and code space issues to contend. A solution such as may be too large in terms of code space or bandwidth required. This document defines a constrained version of . Rather than serializing the YANG definition in JSON, it is serialized into CBOR (). This document follows a similar, but not identical structure as and supplements the brski part to . There are three constrained situations described in this document: 1. CMS signed CBOR encoded vouchers transported using CoAP, protected by DTLS (coaps). 2. COSE signed CBOR encoded vouchers transported using CoAP, protected by EDHOC or DTLS. 3. COSE signed CBOR encoded vouchers, integrated into the key exchange as described by Additional sections have been added concerning: Addition of voucher-request specification as defined in , Addition to of voucher transport requests over CoAP. The CBOR definitions for this constrained voucher format are defined using the mechanism describe in using the SID mechanism explained in . As the tooling to convert YANG documents into an list of SID keys is still in its infancy, the table of SID values presented here should be considered normative rather than the output of the pyang tool. Two methods of signing the resulting CBOR object are described in this document: One is CMS . The other is COSE_Sign1 objects.

The following terms are defined in , and are used identically as in that document: artifact, imprint, domain, Join Registrar/Coordinator (JRC), Manufacturer Authorized Signing Authority (MASA), pledge, Trust of First Use (TOFU), and Voucher.

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.

provides for vouchers that assert proximity, that authenticate the registrar and that include different amounts of anti-replay protection. This document does not make any extensions to the types of vouchers. Time based vouchers are included in this definition, but given that constrained devices are extremely unlikely to have accurate time, their use is very unlikely. Most users of these constrained vouchers will be online and will use live nonces to provide anti-replay protection. defined only the voucher artifact, and not the Voucher Request artifact, which was defined in . This document defines both a constrained voucher and a constrained voucher-request. They are presented in the order “voucher-request”, followed by a “voucher” response as this is the time order that they occur. This document defines both CMS-signed voucher requests and responses, and COSE signed voucher requests and responses. The use of CMS signatures implies the use of PKIX format certificates. The pinned-domain-cert present in a voucher, is the certificate of the Registrar. The constrained voucher and constrained voucher request MUST be signed. The use of the two signing formats permit the use of both PKIX format certificates, and raw public keys (RPK). When RPKs are used, the voucher produced by the MASA pins the raw public key of the Registrar: the pinned-domain-subject-public-key-info in a voucher, is the raw public key of the Registrar. This is described in the YANG definition for the constrained voucher.

This section describes the BRSKI extensions to EST-coaps to transport the voucher between registrar, proxy and pledge over CoAP. The extensions are targeted to low-resource networks with small packets. Saving header space is important and the EST-coaps URI is shorter than the EST URI. The presence and location of (path to) the management data are discovered by sending a GET request to “/.well-known/core” including a resource type (RT) parameter with the value “ace.est” . Upon success, the return payload will contain the root resource of the EST resources. It is up to the implementation to choose its root resource; throughout this document the example root resource /est is used. The EST-coaps server URIs differ from the EST URI by replacing the scheme https by coaps and by specifying shorter resource path names:

Figure 5 in section 3.2.2 of enumerates the operations and corresponding paths which are supported by EST. provides the mapping from the BRSKI extension URI path to the EST-coaps URI path. BRSKI EST-coaps /requestvoucher /rv /voucher_status /vs /enrollstatus /es /requestauditlog /ra /requestvoucher, /voucher_status and /enrollstatus are needed between pledge and Registrar. When discovering the root path for the EST resources, the server MAY return the full resource paths and the used content types. This is useful when multiple content types are specified for EST-coaps server. For example, the following more complete response is possible. [ EDNOTE: spell out where voucher artifacts are used in BRSKI flows since the APIs ] [ EDNOTE: The /requestauditlog and /voucher-status are exchanged by the Registrar and MASA. The JRC will likely talk to MASA over a normal (not constrained) medium. Do we need /ra and /vs? Do we need to remove them from the example too? Also what happens to the voucher-request and response in this case? Is MASA supposed to support contrained vouchers? ]

; rt="brski" ; rt="brski.rv";ct=TBD2 TBD3 ; rt="brski.vs";ct=50 60 ; rt="brski.es";ct=50 60 ]]>

The return of the content-types allows the client to choose the most appropriate one from multiple content types. ct=TBD2 stands for Content-Format “application/voucher-cms+cbor, and ct=TBD3 stands for Content-Format “application/voucher-cose+cbor”. Content-Formats TBD2 and TBD3 are defined in this document. The Content-Format (“application/json”) 50 MAY be supported. Content-Formats (“application/cbor”) 60, TBD2, and TBD3 MUST be supported by the Registrar. The Pledge and MASA need to support one or more formats for the voucher. The MASA needds to support whatever formats that the pledge’s produced by that manufacturer supports.

This section describes the abstract (tree) definition as explained in first. This provides a high-level view of the contents of each artifact. Then the assigned SID values are presented. These have been assigned using the rules in , with an allocation that was made via the http://comi.space service.

The following diagram is largely a duplicate of the contents of , with the addition of proximity-registrar-subject-public-key-info, proximity-registrar-cert, and prior-signed-voucher-request. prior-signed-voucher-request is only used between the Registrar and the MASA. proximity-registrar-subject-public-key-info replaces proximity-registrar-cert for the extremely constrained cases.

In the constrained-voucher-request YANG module, the voucher is “augmented” within the “used” grouping statement such that one continuous set of SID values is generated for the constrained-voucher-request module name, all voucher attributes, and the constrained-voucher-request attribute. Two attributes of the voucher are “refined” to be optional.

file "ietf-constrained-voucher-request@2019-09-01.yang" module ietf-constrained-voucher-request { yang-version 1.1; namespace "urn:ietf:params:xml:ns:yang:ietf-constrained-voucher-request"; prefix "constrained"; import ietf-restconf { prefix rc; description "This import statement is only present to access the yang-data extension defined in RFC 8040."; reference "RFC 8040: RESTCONF Protocol"; } import ietf-voucher { prefix "v"; } organization "IETF ANIMA Working Group"; contact "WG Web: WG List: Author: Michael Richardson Author: Peter van der Stok Author: Panos Kampanakis "; description "This module defines the format for a voucher request, which is produced by a pledge to request a voucher. The voucher-request is sent to the potential owner's Registrar, which in turn sends the voucher request to the manufacturer or delegate (MASA). A voucher is then returned to the pledge, binding the pledge to the owner. This is a constrained version of the voucher-request present in draft-ietf-anima-bootstrap-keyinfra.txt. This version provides a very restricted subset appropriate for very constrained devices. In particular, it assumes that nonce-ful operation is always required, that expiration dates are rather weak, as no clocks can be assumed, and that the Registrar is identified by a pinned Raw Public Key. The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'MAY', and 'OPTIONAL' in the module text are to be interpreted as described in RFC 2119."; revision "2019-09-01" { description "Initial version"; reference "RFC XXXX: Voucher Profile for Constrained Devices"; } rc:yang-data voucher-request-constrained-artifact { // YANG data template for a voucher. uses voucher-request-constrained-grouping; } // Grouping defined for future usage grouping voucher-request-constrained-grouping { description "Grouping to allow reuse/extensions in future work."; uses v:voucher-artifact-grouping { refine voucher/created-on { mandatory false; } refine voucher/pinned-domain-cert { mandatory false; } augment "voucher" { description "Base the constrained voucher-request upon the regular one"; leaf proximity-registrar-subject-public-key-info { type binary; description "The proximity-registrar-subject-public-key-info replaces the proximit-registrar-cert in constrained uses of the voucher-request. The proximity-registrar-subject-public-key-info is the Raw Public Key of the Registrar. This field is encoded as specified in RFC7250, section 3. The ECDSA algorithm MUST be supported. The EdDSA algorithm as specified in draft-ietf-tls-rfc4492bis-17 SHOULD be supported. Support for the DSA algorithm is not recommended. Support for the RSA algorithm is MAY, but due to size is discouraged."; } leaf proximity-registrar-sha256-of-subject-public-key-info { type binary; description "The proximity-registrar-sha256-of-subject-public-key-info is an alternative to proximity-registrar-subject-public-key-info. and pinned-domain-cert. In many cases the public key of the domain has already been transmitted during the key agreement protocol, and it is wasteful to transmit the public key another two times. The use of a hash of public key info, at 32-bytes for sha256 is a significant savings compared to an RSA public key, but is only a minor savings compared to a 256-bit ECDSA public-key. Algorithm agility is provided by extensions to this specifications which define new leaf for other hash types."; } leaf proximity-registrar-cert { type binary; description "An X.509 v3 certificate structure as specified by RFC 5280, Section 4 encoded using the ASN.1 distinguished encoding rules (DER), as specified in ITU-T X.690. The first certificate in the Registrar TLS server certificate_list sequence (see [RFC5246]) presented by the Registrar to the Pledge. This MUST be populated in a Pledge's voucher request if the proximity assertion is populated."; } leaf prior-signed-voucher-request { type binary; description "If it is necessary to change a voucher, or re-sign and forward a voucher that was previously provided along a protocol path, then the previously signed voucher SHOULD be included in this field. For example, a pledge might sign a proximity voucher, which an intermediate registrar then re-signs to make its own proximity assertion. This is a simple mechanism for a chain of trusted parties to change a voucher, while maintaining the prior signature information. The pledge MUST ignore all prior voucher information when accepting a voucher for imprinting. Other parties MAY examine the prior signed voucher information for the purposes of policy decisions. For example this information could be useful to a MASA to determine that both pledge and registrar agree on proximity assertions. The MASA SHOULD remove all prior-signed-voucher-request information when signing a voucher for imprinting so as to minimize the final voucher size."; } } } } } ]]>

Below is a CBOR serialization of the constrained-voucher-request is shown in diagnostic CBOR notation. The enum value of the assertion field is calculated to be zero by following the algorithm described in section 9.6.4.2 of .

The voucher’s primary purpose is to securely assign a pledge to an owner. The voucher informs the pledge which entity it should consider to be its owner. This document defines a voucher that is a CBOR encoded instance of the YANG module defined in Section 5.3 that has been signed with CMS or with COSE.

The following diagram is largely a duplicate of the contents of , with only the addition of pinned-domain-subject-public-key-info.

In the constrained-voucher YANG module, the voucher is “augmented” within the “used” grouping statement such that one continuous set of SID values is generated for the constrained-voucher module name, all voucher attributes, and the constrained-voucher attribute. Two attributes of the voucher are “refined” to be optional.

file "ietf-constrained-voucher@2019-09-01.yang" module ietf-constrained-voucher { yang-version 1.1; namespace "urn:ietf:params:xml:ns:yang:ietf-constrained-voucher"; prefix "constrained"; import ietf-restconf { prefix rc; description "This import statement is only present to access the yang-data extension defined in RFC 8040."; reference "RFC 8040: RESTCONF Protocol"; } import ietf-voucher { prefix "v"; } organization "IETF ANIMA Working Group"; contact "WG Web: WG List: Author: Michael Richardson Author: Peter van der Stok Author: Panos Kampanakis "; description "This module defines the format for a voucher, which is produced by a pledge's manufacturer or delegate (MASA) to securely assign one or more pledges to an 'owner', so that the pledges may establis a secure connection to the owner's network infrastructure. This version provides a very restricted subset appropriate for very constrained devices. In particular, it assumes that nonce-ful operation is always required, that expiration dates are rather weak, as no clocks can be assumed, and that the Registrar is identified by a pinned Raw Public Key. The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'MAY', and 'OPTIONAL' in the module text are to be interpreted as described in RFC 2119."; revision "2019-09-01" { description "Initial version"; reference "RFC XXXX: Voucher Profile for Constrained Devices"; } rc:yang-data voucher-constrained-artifact { // YANG data template for a voucher. uses voucher-constrained-grouping; } // Grouping defined for future usage grouping voucher-constrained-grouping { description "Grouping to allow reuse/extensions in future work."; uses v:voucher-artifact-grouping { refine voucher/created-on { mandatory false; } refine voucher/pinned-domain-cert { mandatory false; } augment "voucher" { description "Base the constrained voucher upon the regular one"; leaf pinned-domain-subject-public-key-info { type binary; description "The pinned-domain-subject-public-key-info replaces the pinned-domain-cert in constrained uses of the voucher. The pinned-domain-subject-public-key-info is the Raw Public Key of the Registrar. This field is encoded as specified in RFC7250, section 3. The ECDSA algorithm MUST be supported. The EdDSA algorithm as specified in draft-ietf-tls-rfc4492bis-17 SHOULD be supported. Support for the DSA algorithm is not recommended. Support for the RSA algorithm is a MAY."; } leaf pinned-sha256-of-subject-public-key-info { type binary; description "The pinned-hash-subject-public-key-info is a second alternative to pinned-domain-cert. In many cases the public key of the domain has already been transmitted during the key agreement process, and it is wasteful to transmit the public key another two times. The use of a hash of public key info, at 32-bytes for sha256 is a significant savings compared to an RSA public key, but is only a minor savings compared to a 256-bit ECDSA public-key. Algorithm agility is provided by extensions to this specifications which define new leaf for other hash types"; } } } } } ]]>

Below a the CBOR serialization of the constrained-voucher is shown in diagnostic CBOR notation. The enum value of the assertion field is calculated to be zero by following the algorithm described in section 9.6.4.2 of .

The signing of the example is shown in .

The IETF evolution of PKCS#7 is CMS . The CMS signed voucher is much like the equivalent voucher defined in . A different eContentType of TBD1 is used to indicate that the contents are in a different format than in . The id-ct-animaJSONVoucher allocated by indicates a voucher and voucher-request encoded in JSON, and the new value TBD1 indicates that the voucher and voucher-request are encoded in CBOR. The ContentInfo structure contains a payload consisting of the CBOR encoded voucher. The use of delta encoding creates a canonical ordering for the keys on the wire. This canonical ordering is not important as there is no expectation that the content will be reproduced during the validation process. Normally the recipient is the pledge and the signer is the MASA. supports both signed and unsigned voucher requests from the pledge to the JRC. In this specification, voucher-request artifact is not signed from the pledge to the registrar. [EDNOTE: Confirm that voucher requests do not need to be signed ] From the JRC to the MASA, the voucher-request artifact MUST be signed by the domain owner key which is requesting ownership. The considerations of section 5.1, concerning validating CMS objects which are really PKCS7 objects (cmsVersion=1) applies. The CMS structure SHOULD also contain all the certificates leading up to and including the signer’s trust anchor certificate known to the recipient. The inclusion of the trust anchor is unusual in many applications, but without it third parties can not accurately audit the transaction. The CMS structure MAY also contain revocation objects for any intermediate certificate authorities (CAs) between the voucher-issuer and the trust anchor known to the recipient. However, the use of CRLs and other validity mechanisms is discouraged, as the pledge is unlikely to be able to perform online checks, and is unlikely to have a trusted clock source. As described below, the use of short-lived vouchers and/or pledge provided nonce provides a freshness guarantee.

The COSE-Sign1 structure is discussed in section 4.2 of . The CBOR object that carries the body, the signature, and the information about the body and signature is called the COSE_Sign1 structure. It is used when only one signature is used on the body. Support for ECDSA with sha256 (secp256k1 and prime256v1 curves) is compulsory. The supported COSE-sign1 object stucture is shown in . Support for EdDSA is encouraged. [EDNOTE: Expand and add a reference why. ]

The specifies the integers that replace the strings and the mnemonics in . The value of the “kid” parameter is an example value. Usually a hash of the public key is used to idientify the public key. The public key and its hash are derived from the relevant certificate (Pledge, Registrar or MASA certificate). In a binary cose-sign1 object is shown based on the voucher-request example of .

The design considerations for the CBOR encoding of vouchers is much the same as for . One key difference is that the names of the leaves in the YANG does not have a material effect on the size of the resulting CBOR, as the SID translation process assigns integers to the names.

TBD.

TBD.

TBD.

Additions to the sub-registry “CoAP Resource Type”, within the “CoRE parameters” registry are specified below. These can be registered either in the Expert Review range (0-255) or IETF Review range (256-9999).

This document registers two URIs in the IETF XML registry . Following the format in , the following registration is requested:

This document registers two YANG modules in the YANG Module Names registry . Following the format defined in , the the following registration is requested:

Warning: These SID values are defined in , not as an Early Allocation.

This document registers an OID in the “SMI Security for S/MIME CMS Content Type” registry (1.2.840.113549.1.9.16.1), with the value:

This section registers the ‘application/voucher-cms+cbor’ media type and the ‘application/voucher-cose+cbor’ in the “Media Types” registry. These media types are used to indicate that the content is a CBOR voucher either signed with a cms structure or a COSE_Sign1 structure .

Additions to the sub-registry “CoAP Content-Formats”, within the “CoRE Parameters” registry are needed for two media types. These can be registered either in the Expert Review range (0-255) or IETF Review range (256-9999).

We are very grateful to Jim Schaad for explaining COSE and CMS choices. Also thanks to Jim Schaad for correctinging earlier version of the COSE Sign1 objects. Michel Veillette did extensive work on pyang to extend it to support the SID allocation process, and this document was among the first users. We are grateful for the suggestions done by Esko Dijk.

-08 Examples for cose_sign1 are completed and improved. -06 New SID values assigned; regenerated examples -04 voucher and request-voucher MUST be signed examples for signed request are added in appendix IANA SID registration is updated SID values in examples are aligned signed cms examples aligned with new SIDs -03

-02

-01

&RFC7049; &I-D.ietf-core-yang-cbor; &I-D.ietf-core-sid; &RFC7950; &RFC5652; &RFC8152; &RFC8366; &RFC3688; &RFC6020; &I-D.ietf-anima-bootstrapping-keyinfra; &I-D.ietf-ace-coap-est; &I-D.selander-ace-ake-authz; &RFC2119; &RFC8174; &I-D.ietf-netmod-yang-tree-diagrams; &RFC6690; &RFC7030;

This section extends the examples from Appendix A of . The CoAP headers are only worked out for the enrollstatus example.

A coaps enrollstatus message can be :

The corresponding coap header fields are shown below.

The Uri-Host and Uri-Port Options are omitted because they coincide with the transport protocol destination address and port respectively. A 2.05 Content response with an unsigned voucher status (ct=60) will then be:

With CoAP fields and payload:

The binary payload is:

The binary payload disassembles to the above CBOR diagnostic code.

A coaps voucher_status message can be:

A 2.05 Content response with a non signed CBOR voucher status (ct=60) will then be:

Signed request-voucher-request payloads are sent from pledge to Registrar, as explained in Section 5.2 of .

A CMS signed requestvoucher message from JRC to MASA is shown below. It would be CoAP POSTED to /est/rv.

The payload would be in binary, but is presented in base64 in this document.

A 2.04 Changed response returning CBOR voucher signed with a cms structure(ct=TBD2) will then be:

A coaps requestauditing message contains the signed CBOR voucher :

A 2.05 Content response returning a log of the voucher (ct=60) will then be:

", "domainID":"", "nonce":"" "assertion":"" "truncated":"" }, { "date":"", "domainID":"", "nonce":"" "assertion":"" } ], "truncation": { "nonced duplicates": "", "nonceless duplicates": "", "arbitrary": "" } } [EDNOTE: Change JSON to CBOR; Serialize CBOR payload to binary] ]]>

The voucher-request example, visualized in CBOR diagnostic notation in is shown as a hexadecimal dump of the binary file.

The voucher-request example has been signed by using the WT1234 certificate and key pair shown in Appendix C of . The CMS signing of the binary voucher-request leads to a binary signed voucher-request, shown with a hexadecimal representation shown in the payload of the request part of and . The breakdown of the CMS signed binary voucher-request file is visualized below:

encapContentInfo: eContentType: pkcs7-data (1.2.840.113549.1.7.1) eContent: certificates: d.certificate: cert_info: version: 2 serialNumber: 9112578475118446130 signature: algorithm: ecdsa-with-SHA256 (1.2.840.10045.4.3.2) parameter: issuer: C=US, ST=CA, O=Example Inc, OU=certification, CN=802.1AR CA validity: notBefore: Jan 31 11:29:16 2019 GMT notAfter: Dec 31 23:59:59 9999 GMT subject: C=US, ST=CA, L=LA, O=example Inc, OU=IoT/serialNumber=Wt1234 key: algor: algorithm: id-ecPublicKey (1.2.840.10045.2.1) parameter: OBJECT:prime256v1 (1.2.840.10045.3.1.7) public_key: (0 unused bits) 0000 - 04 c8 b4 21 f1 1c 25 e4-7e 3a c5 71 23 bf 000e - 2d 9f dc 49 4f 02 8b c3-51 cc 80 c0 3f 15 001c - 0b f5 0c ff 95 8d 75 41-9d 81 a6 a2 45 df 002a - fa e7 90 be 95 cf 75 f6-02 f9 15 26 18 f8 0038 - 16 a2 b2 3b 56 38 e5 9f-d9 issuerUID: subjectUID: extensions: object: X509v3 Basic Constraints (2.5.29.19) critical: BOOL ABSENT value: 0000 - 30 0002 - object: X509v3 Subject Key Identifier (2.5.29.14) critical: BOOL ABSENT value: 0000 - 04 14 96 60 0d 87 16 bf-7f d0 e7 52 d0 000d - ac 76 07 77 ad 66 5d 02-a0 object: X509v3 Authority Key Identifier (2.5.29.35) critical: BOOL ABSENT value: 0000 - 30 16 80 14 68 d1 65 51-f9 51 bf c8 2a 000d - 43 1d 0d 9f 08 bc 2d 20-5b 11 60 object: X509v3 Key Usage (2.5.29.15) critical: TRUE value: 0000 - 03 02 05 a0 object: X509v3 Subject Alternative Name (2.5.29.17) critical: BOOL ABSENT value: 0000 - 30 21 a0 1f 06 08 2b 06-01 05 05 07 08 000d - 04 a0 13 30 11 06 09 2b-06 01 04 01 b4 001a - 3b 0a 01 04 04 01 02 03-04 sig_alg: algorithm: ecdsa-with-SHA256 (1.2.840.10045.4.3.2) parameter: signature: (0 unused bits) 0000 - 30 46 02 21 00 c0 d8 19-96 d2 50 7d 69 3f 3c 000f - 48 ea a5 ee 94 91 bd a6-db 21 40 99 d9 81 17 001e - c6 3b 36 13 74 cd 86 02-21 00 a7 74 98 9f 4c 002d - 32 1a 5c f2 5d 83 2a 4d-33 6a 08 ad 67 df 20 003c - f1 50 64 21 18 8a 0a de-6d 34 92 36 crls: signerInfos: version: 1 d.issuerAndSerialNumber: issuer: C=US, ST=CA, O=Example Inc, OU=certification, CN=802.1AR CA serialNumber: 9112578475118446130 digestAlgorithm: algorithm: sha256 (2.16.840.1.101.3.4.2.1) parameter: signedAttrs: object: contentType (1.2.840.113549.1.9.3) value.set: OBJECT:pkcs7-data (1.2.840.113549.1.7.1) object: signingTime (1.2.840.113549.1.9.5) value.set: UTCTIME:Jul 3 08:53:30 2019 GMT object: messageDigest (1.2.840.113549.1.9.4) value.set: OCTET STRING: 0000 - d4 b0 5c dd c8 b4 91 28-4a 18 ca 25 9d 000d - be d0 60 23 cf ad a0 aa-c2 95 ac e9 3f 001a - 0b 4f 44 9e 25 0020 - signatureAlgorithm: algorithm: ecdsa-with-SHA256 (1.2.840.10045.4.3.2) parameter: signature: 0000 - 30 46 02 21 00 e5 e1 7f-23 c3 aa 14 9f 35 64 000f - 1e c4 4a 0f 68 fe b0 16-3b e6 7c 06 51 af bf 001e - 5a a0 99 59 e0 28 1f 02-21 00 b4 07 2f 7c c4 002d - f9 26 0c 6d 47 a7 93 56-de b8 da f7 23 f0 af 003c - 2b 59 16 cc 36 63 e7 91-89 39 df df unsignedAttrs: ]]>

These examples are generated on a pie 4 and a PC running BASH. Keys and Certificates have been generated with openssl with the following shell script:

serial echo 1000 > crlnumber # intermediate level mkdir intermediate cd intermediate mkdir certs crl csr newcerts private chmod 700 private touch index.txt echo 11223344556600 >serial echo 1000 > crlnumber cd ../.. # file structure is cleaned start filling echo "#############################" echo "create registrar keys and certificates " echo "#############################" echo "create root registrar certificate using ecdsa with sha256" openssl ecparam -name prime256v1 -genkey \ -noout -out $cadir/private/ca-regis.key openssl req -new -x509 \ -key $cadir/private/ca-regis.key \ -out $cadir/certs/ca-regis.crt \ -extensions v3_ca\ -days 365 \ -subj "/C=NL/ST=NB/L=Helmond/O=vanderstok\ "/OU=consultancy/CN=registrar.stok.nl" # Combine authority certificate and key echo "Combine authority certificate and key" openssl pkcs12 -passin pass:watnietweet \ -passout pass:watnietweet \ -inkey $cadir/private/ca-regis.key \ -in $cadir/certs/ca-regis.crt -export \ -out $cadir/certs/ca-regis-comb.pfx # converteer authority pkcs12 file to pem echo "converteer authority pkcs12 file to pem" openssl pkcs12 -passin pass:watnietweet -passout pass:watnietweet\ -in $cadir/certs/ca-regis-comb.pfx \\ -out $cadir/certs/ca-regis-comb.crt -nodes #show certificate in registrar combined certificate openssl x509 -in $cadir/certs/ca-regis-comb.crt -text # # Certificate Authority for MASA # echo "#############################" echo "create MASA keys and certificates " echo "#############################" echo "create root MASA certificate using ecdsa with sha 256 key" openssl ecparam -name prime256v1 -genkey -noout \ -out $cadir/private/ca-masa.key openssl req -new -x509 \ -days 365 -key $cadir/private/ca-masa.key \ -out $cadir/certs/ca-masa.crt \ -extensions v3_ca\ -subj "/C=NL/ST=NB/L=Helmond/O=vanderstok/\ OU=manufacturer/CN=masa.stok.nl" # Combine authority certificate and key echo "Combine authority certificate and key for masa" openssl pkcs12 -passin pass:watnietweet \ -passout pass:watnietweet\ -inkey $cadir/private/ca-masa.key \ -in $cadir/certs/ca-masa.crt -export \ -out $cadir/certs/ca-masa-comb.pfx # converteer authority pkcs12 file to pem for masa echo "converteer authority pkcs12 file to pem for masa" openssl pkcs12 -passin pass:watnietweet \ -passout pass:watnietweet\ -in $cadir/certs/ca-masa-comb.pfx \ -out $cadir/certs/ca-masa-comb.crt -nodes #show certificate in pledge combined certificate openssl x509 -in $cadir/certs/ca-masa-comb.crt -text # # Certificate for Pledge derived from MASA certificate # echo "#############################" echo "create pledge keys and certificates " echo "#############################" # Pledge derived Certificate echo "create pledge derived certificate using ecdsa with sha256" openssl ecparam -name prime256v1 -genkey \ -noout -out $dir/private/pledge.key echo "create pledge certificate request" openssl req -nodes -new -sha256 \ -key $dir/private/pledge.key -out $dir/csr/pledge.csr \ -subj \ "/C=NL/ST=NB/L=Helmond/O=vanderstok/OU=manufacturing\ /CN=uuid:$DevID/$serialNumber" # Sign pledge derived Certificate echo "sign pledge derived certificate " openssl ca -config $cnfdir/openssl-pledge.cnf \ -extensions 8021ar_idevid\ -days 365 -in $dir/csr/pledge.csr -out $dir/certs/pledge.crt # Add pledge key and pledge certificate to pkcs12 file echo "Add pledge key and pledge certificate to pkcs12 file" openssl pkcs12 -passin pass:watnietweet\ -passout pass:watnietweet\ -inkey $dir/private/pledge.key \ -in $dir/certs/pledge.crt -export \ -out $dir/certs/pledge-comb.pfx # converteer pledge pkcs12 file to pem echo "converteer pledge pkcs12 file to pem" openssl pkcs12 -passin pass:watnietweet \ -passout pass:watnietweet\ -in $dir/certs/pledge-comb.pfx \ -out $dir/certs/pledge-comb.crt -nodes #show certificate in pledge-comb.crt openssl x509 -in $dir/certs/pledge-comb.crt -text #show private key in pledge-comb.crt openssl ecparam -name prime256v1 \ -in $dir/certs/pledge-comb.crt -text ]]>

The xxxx-comb certificates have been generated as required by libcoap for the DTLS connection generation.

This first section documents the public and private keys used in the subsequent test vectors below. These keys come from test code and are not used in any production system, and should only be used only to validate implementations.

Below the certificates that accompany the keys. The certificate description is followed by the hexadecimal DER of the certificate

This is the hexadecimal representation in (request-)voucher examples referred to as pledge-cert-hex.

This the hexadecimal representation, in (request-)voucher examples referred to as regis-cert-hex

This is the hexadecimal representation, in (request-)voucher examples referred to as masa-cert-hex.

In this example the voucher request has been signed by the pledge, and has been sent to the JRC over CoAPS. This example uses the proximity-registrar-cert mechanism to request a voucher that pins the certificate of the registrar.

The payload signed_request_voucher is shown as hexadecimal dump (with lf added):

The representiation of signed_voucher_request in CBOR diagnostic format is:

In this example the voucher request has been signed by the JRC using the private key from . Contained within this voucher request is the voucher request from the pledge to JRC.

The payload signed_masa_voucher_request is shown as hexadecimal dump (with lf added):

The representiation of signed_masa_voucher_request in CBOR diagnostic format is:

The resulting voucher is created by the MASA and returned via the JRC to the Pledge. It is signed by the MASA’s private key and can be verified by the pledge using the MASA’s public key contained within the MASA certificate. This is the raw binary signed_voucher, encoded in hexadecimal (with lf added):

The representiation of signed_voucher in CBOR diagnostic format is: