Constrained Voucher Artifacts for Bootstrapping ProtocolsSandelman Software Worksmcr+ietf@sandelman.cavanderstok consultancyconsultancy@vanderstok.orgCisco Systemspkampana@cisco.comIoTconsultancy.nlesko.dijk@iotconsultancy.nl
Internet
anima Working GroupInternet-DraftThis document defines a protocol to securely assign a Pledge to an
owner and to enroll it into the owner's network.
The protocol uses an artifact that is signed by the Pledge's manufacturer.
This artifact is known as a "voucher".This document builds upon the work in and [BRSKI], but defines an encoding of
the voucher in CBOR rather than JSON, and enables the Pledge to perform its transactions using CoAP rather than HTTPS.The use of Raw Public Keys instead of X.509 certificates for security operations is also explained.IntroductionSecure enrollment of new nodes into constrained networks with constrained nodes
presents unique challenges. There are network bandwidth and code size issues to contend with.
A solution for autonomous enrollment such as may be too large in terms of
code size or bandwidth required.Therefore, this document defines a constrained version of the voucher artifact , along with a constrained version of BRSKI that makes use of the constrained CoAP-based version of EST, EST-coaps rather than EST over HTTPS .While the voucher is by default serialized to JSON with a signature in CMS,
this document defines a new voucher serialization to CBOR () with a signature in COSE .
This COSE-signed CBOR-encoded voucher can be transported using secured CoAP or HTTP.
The CoAP connection (between Pledge and Registrar) is to be protected by either OSCORE+EDHOC, or DTLS (CoAPS). The HTTP connection
(between Registrar and MASA) is to be protected using TLS (HTTPS).This document specifies a constrained voucher-request artifact based on Section 3 of , and
voucher(-request) transport over CoAP based on Section 3 of and on .The CBOR definitions for the constrained voucher format are defined using the mechanism described in using the SID mechanism explained in .
As the tooling to convert YANG documents into a 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.There is additional work when the voucher is integrated into the key-exchange, described in .
This work is not in scope for this document.TerminologyThe following terms are defined in , and are used identically as in that document:
artifact, domain, imprint, Join Registrar/Coordinator (JRC), Manufacturer Authorized Signing Authority
(MASA), Pledge, Registrar, Trust of First Use (TOFU), and Voucher.The following terms from are used identically as in that document:
Domain CA, enrollment, IDevID, Join Proxy, LDevID, manufacturer, nonced, nonceless, PKIX.Requirements LanguageThe 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.Overview of Protocol provides for vouchers that assert proximity, that authenticate the Registrar and that can offer varying levels of anti-replay protection.This document does not make any extensions to the semantic meaning of vouchers, only the encoding has been changed to optimize for constrained devices and networks.
The two main parts of the BRSKI protocol are named separately in this document: BRSKI-EST for the protocol between Pledge and Registrar, and BRSKI-MASA for the
protocol between the Registrar and the MASA.Time-based vouchers are supported in this definition, but given that constrained devices are extremely unlikely to have accurate time, their use will be uncommon.
Most Pledges using these constrained vouchers will be online during enrollment and will use live nonces to provide anti-replay protection rather than expiry times. defines the voucher artifact, while the Voucher Request artifact 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 order that they occur in the protocol.The constrained voucher request MUST be signed by the Pledge.
It signs using the private key associated with its IDevID X.509 certificate, or if an IDevID is not available, then the private key associated with its manufacturer-installed raw public key (RPK).
provides additional details on PKIX-less operations.The constrained voucher MUST be signed by the MASA.For the constrained voucher request this document defines two distinct methods for the Pledge to identify the Registrar: using either the Registrar's X.509 certificate, or using a raw public key (RPK) of the Registrar.For the constrained voucher also these two methods are supported to indicate (pin) a trusted domain identity: using either a pinned domain X.509 certificate, or a pinned raw public key (RPK).The BRSKI architectures mandates that the MASA be aware of the capabilities of the pledge.
This is not a hardship as the pledges are constructed by a manufacturer who also arranges for the MASA to be aware of the inventory of devices.The MASA therefore knows if the pledge supports PKIX operations, PKIX format certificates, or if the pledge is limited to Raw Public Keys (RPK).
Based upon this, the MASA can select which attributes to use in the voucher for certain operations, like the pinning of the Registrar identity.
This is described in more detail in , and (for RPK specifically).BRSKI-EST ProtocolThis section describes the constrained BRSKI extensions to EST-coaps to transport the voucher between Registrar and Pledge (optionally via a Join Proxy) over CoAP.
The extensions are targeting low-resource networks with small packets.The constrained BRSKI-EST protocol described in this section is between the Pledge and the Registrar only.Discovery, URIs and Content FormatsSaving header space is important and this is the reason that the EST-coaps and constrained-BRSKI URIs are shorter than the respective EST and BRSKI URIs.The EST-coaps server URIs differ from the EST URIs by replacing the scheme https by coaps and by specifying shorter resource path names. Below are some examples;
the first two using a discovered short path name and the last one using the well-known URI of EST which requires no discovery.
coaps://server.example.com/e/
coaps://server.example.com/.well-known/est/
]]>Similarly the constrained BRSKI server URIs differ from the BRSKI URIs by replacing the scheme https by coaps and by specifying shorter resource path names. Below are some examples;
the first two using a discovered short path name and the last one using the well-known URI prefix which requires no discovery.
This is the same "/.well-known/brski" prefix as defined in Section 5.
coaps://server.example.com/b/
coaps://server.example.com/.well-known/brski/
]]>Figure 5 in section 3.2.2 of enumerates the operations supported by EST, for which Table 1 in Section 5.1 of enumerates the corresponding
EST-coaps short path names. Similarly, provides the mapping from the supported BRSKI extension URI paths to the constrained-BRSKI URI paths.
BRSKI URI paths mapping to constrained BRSKI URI paths
BRSKI resource
constrained-BRSKI resource
/requestvoucher
/rv
/voucher_status
/vs
/enrollstatus
/es
Note that /requestvoucher indicated above occurs between the Pledge and Registrar (in scope of the BRSKI-EST protocol), but it also occurs between Registrar and MASA. However,
as described in , this section and above table addresses only the BRSKI-EST protocol.Pledges that wish to discover the available BRSKI bootstrap options/formats, or reduce the size of the CoAP headers by eliminating the "/.well-known/brski" path, can do a discovery operation using Section 4 by sending a discovery query to the Registrar.For example, if the Registrar supports a short BRSKI URL (/b) and supports the voucher format "application/voucher-cose+cbor" (TBD3), and status reporting in both CBOR and JSON formats:;rt=brski,
;rt=brski.rv;ct=TBD3,
;rt=brski.vs;ct="50 60",
;rt=brski.es;ct="50 60"
]]>The Registrar is under no obligation to provide shorter URLs, and MAY respond to this query with only the "/.well-known/brski/<short-name>" end points for the short names as defined in .Registrars that have implemented shorter URLs MUST also respond in equivalent ways to the corresponding "/.well-known/brski/<short-name>" URLs, and MUST NOT distinguish between them.
In particular, a Pledge MAY use the longer and shorter URLs in combination.When responding to a discovery request for BRSKI resources, the server MAY in addition return
the full resource paths and the content types which are supported at those end-points as shown in above example.
This is useful when multiple content types are specified for a particular resource on the server.
The server responds with only the root path for the BRSKI resource (rt=brski, resource /b in above example) and no others in case the client queries for only rt=brski type resources.
(So, a query for rt=brski, without the wildcard character.)The return of multiple content-types in the "ct" attribute allows the Pledge to choose the most appropriate one.
Note that Content-Format TBD3 ("application/voucher-cose+cbor") is defined in this document.The Content-Format 50 ("application/json") MAY be supported and 60 ("application/cbor") MUST be supported by the Registrar for the /vs and /es resources.
Content-Format TBD3 MUST be supported by the Registrar for the /rv resource.
If the "ct" attribute is not indicated for the /rv resource in the link format description, this implies that at least TBD3 is supported.The Pledge and MASA need to support one or more formats (at least TBD3) for the voucher and for the voucher request.
The MASA needs to support all formats that the Pledge, produced by that manufacturer, supports.Extensions to BRSKIA Pledge that only supports the BRSKI bootstrap method and already knows the IP address and port of a Registrar or Join Proxy to use SHOULD NOT use discovery.
In such case it is more efficient to just try its supported bootstrap method (e.g. /rv) via the well-known BRSKI resource on the known address and port. This avoids
the Pledge having to unnecessarily implement CoRE Link Format parsing. The method via which the Pledge learns the address/port of a Registrar or Join Proxy to use
is out of scope of this document.A Registrar SHOULD host any discoverable BRSKI resources on the same (UDP) server port that the Pledge's initial DTLS connection is using.
This avoids the overhead of the Pledge having to reconnect using DTLS, in order to access discovered resource(s).Extensions to EST-coapsA Pledge that already is DTLS-connected to either a Join Proxy or Registrar, and which only supports the EST-coaps enrollment method, SHOULD NOT use discovery for EST-coaps resources.
This is because it is more efficient to just try its supported enrollment method (e.g. /sen) via the well-known EST resource on the current DTLS connection.
This avoids an additional round-trip of packets and avoids the Pledge having to unnecessarily implement CoRE Link Format parsing.A Registrar SHOULD host any discoverable EST-coaps resources on the same (UDP) server port that the Pledge's DTLS initial connection is using.
This avoids the Pledge having to reconnect using DTLS, in order to proceed with EST enrollment after the BRSKI bootstrap.
[TBD EDNOTE: a Registrar that does host EST resources on another port won't be able to onboard Pledges that skip the discovery, so not interoperable. Should we fix this?]Pledge ExtensionsA constrained Pledge SHOULD NOT support the optional EST "CSR attributes request" (/att) to minimize network traffic and reduce code size.When creating the CSR, the Pledge selects which attributes to include. One or more Subject Distinguished Name fields MUST be included.
If the Pledge has no specific information on what attributes/fields are desired in the CSR, it MUST use the Subject Distinguished Name fields from its IDevID unmodified.
The Pledge can receive such information via the voucher (encoded in a vendor-specific way) or some other, out-of-band means.A constrained Pledge MAY use the following optimized EST-coaps procedure to minimize both network traffic and code size:
if the voucher, that validates the current Registrar, contains a single pinned domain CA certificate, the Pledge provisionally considers this certificate as the EST trust anchor, in other words,
it provisionally accepts this CA certificate as if it were the result of "CA certificates request" (/crts) to the Registrar.
Using this CA certificate as trust anchor it proceeds with EST simple enrollment (/sen) to obtain its provisionally trusted LDevID.
If the Pledge validates that the trust anchor CA was used to sign its LDevID, the Pledge accepts the pinned domain CA certificate as the legitimate trust anchor CA for the Registrar's domain and accepts the associated LDevID.
If the trust anchor CA was NOT used to sign its LDevID, the Pledge MUST perform an actual "CA certificates request" (/crts) to the EST server to obtain the EST CA trust anchor(s) since these differ from the (temporary) pinned domain CA.
When doing this /crts request, the Pledge MAY use a CoAP Accept Option with value TBD287 ("application/pkix-cert") to limit the number of returned EST CA trust anchors to only one.
If the Pledge cannot obtain the single CA certificate or the finally validated CA certificate cannot be chained to the LDevID, then the Pledge MUST abort the enrollment process and report the error using the enrollment status telemetry (/es).
Registrar ExtensionsThe Content-Format 50 MAY be supported and 60 MUST be supported by the Registrar for the /vs and /es resources.
Content-Format TBD3 MUST be supported by the Registrar for the /rv resource.When a Registrar receives a "CA certificates request" (/crts) request with a CoAP Accept Option with value TBD287 ("application/pkix-cert") it SHOULD return only the
single CA certificate that is the envisioned or actual authority for the current, authenticated Pledge making the request. The only exception case
is when the Registrar is configured to not support a request for a single CA certificate for operational or security reasons, e.g. because every device
enrolled into the domain needs to use at least multiple CAs. In such exception case the Registrar returns the CoAP response 4.06 Not Acceptable to indicate
that only the default Content-Format of 281 "application/pkcs7-mime;smime-type=certs-only" which supports multiple certificates is available.BRSKI-MASA Protocol section 5.4 describes a connection between the Registrar and the MASA as being a normal TLS connection using HTTPS.
This document does not change that. The Registrar MAY use the new format "application/voucher-cose+cbor" in its voucher request to MASA, or the existing BRSKI
format "application/voucher-cms+json" defined by . The MASA MUST support both formats. The Registrar indicates the voucher
format it wants to receive from MASA using the HTTP Accept header.At the moment of writing the creation of coaps based MASAs is deemed unrealistic.
The use of CoAP for the BRSKI-MASA connection can be the subject of another document.
Some consideration was made to specify CoAP support for consistency, but:
the Registrar is not expected to be so constrained that it cannot support HTTPS client connections.
the technology and experience to build Internet-scale HTTPS responders (which the MASA is) is common, while the experience doing the same for CoAP is much less common.
in many Enterprise networks, outgoing UDP connections are often treated as suspicious, and there seems to be no advantage to using CoAP in that environment.
a Registrar is likely to provide onboarding services to both constrained and non-constrained devices. Such a Registrar would need to speak HTTPS anyway.
similarly, a manufacturer is likely to offer both constrained and non-constrained devices, so there may in practice be no situation in which the MASA could be CoAP-only. Additionally, as the MASA is intended to be a function that can easily be oursourced to a third-party service provider, reducing the complexity would also seem to reduce the cost of that function.
Pinning in Voucher ArtifactsThe voucher is a statement from the MASA to the Pledge indicating the owner of the Pledge.
This section describes how the owner's identity is determined and how it is encoded within the voucher.Registrar Identity Selection and EncodingSection 5.5 of describes BRSKI policies for selection of the owner identity. It indicates some of the flexibility that is possible for the Registrar.
The recommendation made there is for the Registrar to include only certificates in the voucher request (CMS) signing structure which participate in the certificate chain that is to be pinned.The MASA is expected to evaluate the certificates included by the Registrar in its voucher request, forming them into a chain with the Registrar's (signing) identity on one end. Then, it pins a certificate selected from the chain.
For instance, for a domain with a two-level certification authority (see ), where the voucher-request has been signed by "Registrar", its signing structure includes two additional CA certificates:When the Registrar is using a COSE-signed constrained voucher request towards MASA, instead of a regular CMS-signed voucher request, the COSE_Sign1 object contains a protected and an unprotected header, and according to ,
would carry all the certificates of the chain in an "x5bag" or "x5chain" attribute placed in the unprotected header.MASA Pinning PolicyThe MASA, having assembled and verified the chain in the signing structure of the voucher request, will now need to select a certificate to pin in the voucher in case there are multiple available.
(For the case that only the Registrar's End-Entity certificate is included, only this certificate can be selected and this section does not apply.)
The BRSKI policy for pinning by the MASA as described in Section 5.5.2 of leaves much flexibility to the manufacturer. The present
document adds the following rules to the MASA pinning policy to reduce the network load:
for a voucher containing a nonce, it SHOULD select the most specific (lowest-level) CA certificate in the chain.
for a nonceless voucher, it SHOULD select the least-specific (highest-level) CA certificate in the chain that is allowed under the MASA's policy for this specific domain.
The rationale for 1. is that in case of a voucher with nonce, the voucher is valid only in scope of the present DTLS connection between Pledge and Registrar anyway, so it would have no
benefit to pin a higher-level CA. By pinning the most specific CA the constrained Pledge can validate its DTLS connection using less crypto operations. The
rationale for pinning a CA instead of the Registrar's End-Entity certificate directly is the following benefit on constrained networks: the pinned certificate in the voucher
can in common cases be re-used as a Domain CA trust anchor during the EST enrollment and during the operational phase that follows after EST enrollment, as explained in .The rationale for 2. follows from the flexible BRSKI trust model for, and purpose of, nonceless vouchers (Sections 5.5.* and 7.4.1 of ).Using the previous example of a domain with a two-level certification authority, the most specific CA ("Sub-CA") is the identity that is pinned by MASA in a nonced voucher.
A Registrar that wished to have only the Registrar's End-Entity certificate pinned would omit the "domain CA" and "Sub-CA" certificates from the voucher-request.In case of a nonceless voucher, the MASA would depending on trust level pin only "Registrar" certificate (low trust in customer), or the "Sub-CA" certificate (in case of
medium trust, implying that any Registrar of that sub-domain is acceptable), or even the "domain CA" certificate (in case of high trust in the customer, and possibly a pre-agreed need of the
customer to obtain flexible long-lived vouchers).Pinning of Raw Public KeysSpecifically for constrained use cases, the pinning of the raw public key (RPK) of the Registrar is also supported in the constrained voucher, instead of an X.509 certificate.
If an RPK is pinned it MUST be the RPK of the Registrar.When the Pledge is known by MASA to support RPK but not X.509 certificates, the voucher produced by the MASA pins the RPK of the Registrar in either the "pinned-domain-pubk"
or "pinned-domain-pubk-sha256" field of a voucher.
This is described in more detail in . A Pledge that does not support X.509 certificates cannot use EST to enroll; it has to use
another method for certificate-less enrollment and the Registrar has to support this method also.
It is possible that the Pledge will not enroll, but instead only a network join operation will occur, such as described in .
How the Pledge discovers this method and details of the enrollment method are out of scope of this document.When the Pledge is known by MASA to support PKIX format certificates, the "pinned-domain-cert" field present in a voucher typically pins a domain certificate.
That can be either the End-Entity certificate of the Registrar, or the certificate of a domain CA of the Registrar's domain as specified in .
However, if the Pledge is known to also support RPK pinning and the MASA intends to pin the Registrar's identity (not a CA), then MASA SHOULD pin the RPK (RPK3 in ) of the Registrar instead of the Registrar's End-Entity certificate to save space in the voucher.ArtifactsThis section describes for both the voucher request and
the voucher first the abstract (tree) definition as explained
in . 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.Voucher Request artifactTree DiagramThe following diagram is largely a duplicate of the contents of ,
with the addition of the fields proximity-registrar-pubk, proximity-registrar-pubk-sha256,
proximity-registrar-cert, and prior-signed-voucher-request.prior-signed-voucher-request is only used between the Registrar and the MASA.
proximity-registrar-pubk or proximity-registrar-pubk-sha256 optionally replaces proximity-registrar-cert
for the most constrained cases where RPK is used by the Pledge.SID valuesYANG ModuleIn 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 attributes. Two attributes of the voucher are "refined" to be optional.
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 its 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
{{I-D.ietf-anima-bootstrap-keyinfra}}
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 either a pinned Raw Public Key of the Registrar, or by a
pinned X.509 certificate of the Registrar or domain CA.
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 "2021-04-15" {
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-pubk {
type binary;
description
"The proximity-registrar-pubk replaces
the proximity-registrar-cert in constrained uses of
the voucher-request.
The proximity-registrar-pubk 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, but due to
size is discouraged.";
}
leaf proximity-registrar-pubk-sha256 {
type binary;
description
"The proximity-registrar-pubk-sha256
is an alternative to both
proximity-registrar-pubk 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
specification which may define a new leaf for another
hash type.";
}
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 field or one of its
alternatives 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.";
}
}
}
}
}
]]>Example voucher request artifactBelow is a CBOR serialization of an example constrained voucher request from a Pledge to a Registrar, shown in CBOR diagnostic notation. The enum value of the assertion field is calculated to be 2 by following the algorithm described in section 9.6.4.2 of .
Four dots ("....") in a CBOR byte string denotes a sequence of bytes that are not shown for brevity.
]]>Voucher artifactThe 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.Tree DiagramThe following diagram is largely a duplicate of the contents of ,
with only the addition of the fields pinned-domain-pubk and pinned-domain-pubk-sha256.
]]>SID values
]]>YANG ModuleIn 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 attributes.
Two attributes of the voucher are "refined" to be optional.
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 its delegate
(MASA) to securely assign one or more pledges to an 'owner',
so that a pledge may establish 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 either a pinned Raw Public Key of the Registrar, or by a
pinned X.509 certificate of the Registrar or domain CA.
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 "2021-04-15" {
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-pubk {
type binary;
description
"The pinned-domain-pubk may replace the
pinned-domain-cert in constrained uses of
the voucher. The pinned-domain-pubk
is the Raw Public Key of the Registrar.
This field is encoded as a Subject Public Key Info block
as specified in RFC7250, in 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-domain-pubk-sha256 {
type binary;
description
"The pinned-domain-pubk-sha256 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
specification which can define a new leaf for another
hash type.";
}
}
}
}
}
]]>Example voucher artifactsBelow the CBOR serialization of an example constrained voucher is shown in CBOR diagnostic 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 .
Four dots ("....") in a CBOR byte string denotes a sequence of bytes that are not shown for brevity.
]]>Signing voucher and voucher-request artifacts with COSEThe 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 REQUIRED.
Support for EdDSA is encouraged. [TBD EDNOTE: Expand and add a reference why. ]An example of the supported COSE-sign1 object structure is shown in .The specifies the integers that replace the strings and the mnemonics in .
The value of the key identifier "kid" parameter is an example value.
Usually a hash of the public key is used to identify the public key. The choice of key identifier method is
vendor-specific.
The public key and its hash are derived from the relevant certificate (Pledge, Registrar or MASA certificate).
[TBD EDNOTE: how can MASA know which kid method the Registrar has used/supports? Does it matter?]In a binary cose-sign1 object is shown based on the voucher-request example of .Design ConsiderationsThe design considerations for the CBOR encoding of vouchers are much the same as for JSON vouchers in .
One key difference is that the names of the leaves in the YANG definition do not affect the size of the resulting CBOR, as the SID translation process assigns integers to the names.Any POST request to the Registrar with resource /vs or /es returns a 2.04 Changed response with empty payload. The client should be aware that the server may use a piggybacked CoAP response (ACK, 2.04) but may also respond with a separate CoAP response, i.e. first an (ACK, 0.0) that is an acknowledgement of the request reception followed by a (CON, 2.04) response in a separate CoAP message.Raw Public Key Use ConsiderationsThis section explains techniques to reduce the number of bytes that are sent over the wire during the BRSKI bootstrap.
The use of a raw public key (RPK) in the pinning process can significantly reduce the number of bytes and round trips, but it comes with a few significant operational limitations.The Registrar Trust AnchorWhen the Pledge first connects to the Registrar, the connection to the Registrar is provisional, as explained in section 5.6.2 of .
The Registrar provides its public key in a TLSServerCertificate, and the Pledge uses that to validate that integrity of the (D)TLS connection, but it does not validate the identity of
the provided certificate.As the TLSServerCertificate object is never verified directly by the pledge, sending it can be considered superfluous.
Instead of using a (TLSServer)Certificate of type X509 (see section 4.4.2 of ),
a RawPublicKey object is used.A Registrar operating in a mixed environment can determine whether to send a Certificate or a Raw Public key: this is determined by the pledge including the server_certificate_type of RawPublicKey.
This is shown in section 5 of .The Pledge continues to send a client_certificate_type of X509, so that the Registrar can properly identify the pledge and distill the MASA URI information from its certificate.The Pledge Voucher RequestThe Pledge puts the Registrar's public key into the proximity-registrar-pubk
field of the voucher-request.
(The proximity-registrar-pubk-sha256 can also be used if the 32-bytes of a SHA256 hash turns out to be smaller than a typical ECDSA key.)As the format of the pubk field is identical to the TLS Certificate RawPublicKey, no manipulation at all is needed to insert this into a voucher-request.The Voucher ResponseA returned voucher will have a pinned-domain-subk field with the identical key as was found in the proximity-registrar-pubk field above, as well as in the TLS connection.
Validation of this key by the pledge is what takes the DTLS connection out of the provisional state (see section 5.6.2).The voucher needs to be validated first.
The Pledge needs to have a public key to validate the signature from the MASA on the voucher.In certain cases, the MASA's public key counterpart of the (private) signing key is already installed in the Pledge at manufacturing time.
In other cases, if the MASA signing key is based upon a PKI (see Section 2.3), then a certificate chain may need to be included with the voucher in order for the pledge to validate the signature.
In CMS signed artifacts, the CMS structure has a place for such certificates.
In the COSE-signed Constrained Vouchers described in this document, the x5bag attribute from is to be used for this.Security ConsiderationsClock SensitivityTBD.Protect Voucher PKI in HSMTBD.Test Domain Certificate Validity when SigningTBD.IANA ConsiderationsResource Type RegistryAdditions to the sub-registry "Resource Type Link Target Attribute Values", within the "CoRE parameters" IANA registry are specified below.The IETF XML RegistryThis document registers two URIs in the IETF XML registry .
Following the format in , the following registration is requested:The YANG Module Names RegistryThis document registers two YANG modules in the YANG Module Names registry . Following the format defined in , the the following registration is requested:The RFC SID range assignment sub-registryWarning: These SID values are defined in , not as an Early Allocation.Media Types RegistryThis section registers the 'application/voucher-cose+cbor' in the IANA "Media Types" registry.
This media type is used to indicate that the content is a CBOR voucher or voucher request
signed with a COSE_Sign1 structure .application/voucher-cose+cborCoAP Content-Format RegistryAdditions 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).AcknowledgementsWe are very grateful to Jim Schaad for explaining COSE and CMS choices.
Also thanks to Jim Schaad for correcting 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 its first uses.Changelog-10
Design considerations extended
Examples made consistent-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-01ReferencesNormative ReferencesConcise Binary Object Representation (CBOR)The Concise Binary Object Representation (CBOR) is a data format whose design goals include the possibility of extremely small code size, fairly small message size, and extensibility without the need for version negotiation. These design goals make it different from earlier binary serializations such as ASN.1 and MessagePack.CBOR Encoding of Data Modeled with YANGTrilliant Networks Inc.Google Switzerland GmbHAcklio This document defines encoding rules for serializing configuration
data, state data, RPC input and RPC output, action input, action
output, notifications and yang-data extension defined within YANG
modules using the Concise Binary Object Representation (CBOR, RFC
8949).
YANG Schema Item iDentifier (YANG SID)Trilliant Networks Inc.AcklioAcklio YANG Schema Item iDentifiers (YANG SID) are globally unique 63-bit
unsigned integers used to identify YANG items. This document defines
the semantics, the registration, and assignment processes of YANG
SIDs. To enable the implementation of these processes, this document
also defines a file format used to persist and publish assigned YANG
SIDs.
Using Raw Public Keys in Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)This document specifies a new certificate type and two TLS extensions for exchanging raw public keys in Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS). The new certificate type allows raw public keys to be used for authentication.The Transport Layer Security (TLS) Protocol Version 1.3This document specifies version 1.3 of the Transport Layer Security (TLS) protocol. TLS allows client/server applications to communicate over the Internet in a way that is designed to prevent eavesdropping, tampering, and message forgery.This document updates RFCs 5705 and 6066, and obsoletes RFCs 5077, 5246, and 6961. This document also specifies new requirements for TLS 1.2 implementations.The YANG 1.1 Data Modeling LanguageYANG is a data modeling language used to model configuration data, state data, Remote Procedure Calls, and notifications for network management protocols. This document describes the syntax and semantics of version 1.1 of the YANG language. YANG version 1.1 is a maintenance release of the YANG language, addressing ambiguities and defects in the original specification. There are a small number of backward incompatibilities from YANG version 1. This document also specifies the YANG mappings to the Network Configuration Protocol (NETCONF).Cryptographic Message Syntax (CMS)This document describes the Cryptographic Message Syntax (CMS). This syntax is used to digitally sign, digest, authenticate, or encrypt arbitrary message content. [STANDARDS-TRACK]A Voucher Artifact for Bootstrapping ProtocolsThis 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 defines an artifact format as a YANG-defined JSON document that has been signed using a Cryptographic Message Syntax (CMS) structure. Other YANG-derived formats are possible. The voucher artifact is normally generated by the pledge's manufacturer (i.e., the Manufacturer Authorized Signing Authority (MASA)).This document only defines the voucher artifact, leaving it to other documents to describe specialized protocols for accessing it.The IETF XML RegistryThis document describes an IANA maintained registry for IETF standards which use Extensible Markup Language (XML) related items such as Namespaces, Document Type Declarations (DTDs), Schemas, and Resource Description Framework (RDF) Schemas.YANG - A Data Modeling Language for the Network Configuration Protocol (NETCONF)YANG is a data modeling language used to model configuration and state data manipulated by the Network Configuration Protocol (NETCONF), NETCONF remote procedure calls, and NETCONF notifications. [STANDARDS-TRACK]CBOR Object Signing and Encryption (COSE): Structures and ProcessAugust Cellars Concise Binary Object Representation (CBOR) is a data format designed
for small code size and small message size. There is a need for the
ability to have basic security services defined for this data format.
This document defines the CBOR Object Signing and Encryption (COSE)
protocol. This specification describes how to create and process
signatures, message authentication codes, and encryption using CBOR
for serialization. This specification additionally describes how to
represent cryptographic keys using CBOR.
This document along with [I-D.ietf-cose-rfc8152bis-algs] obsoletes
RFC8152.
Bootstrapping Remote Secure Key Infrastructure (BRSKI)CiscoSandelman Software WorksFuturewei Technologies Inc. USAWatsen NetworksThis document specifies automated bootstrapping of an Autonomic Control Plane. To do this, a Secure Key Infrastructure is bootstrapped. This is done using manufacturer-installed X.509 certificates, in combination with a manufacturer's authorizing service, both online and offline. We call this process the Bootstrapping Remote Secure Key Infrastructure (BRSKI) protocol. Bootstrapping a new device can occur when using a routable address and a cloud service, only link-local connectivity, or limited/disconnected networks. Support for deployment models with less stringent security requirements is included. Bootstrapping is complete when the cryptographic identity of the new key infrastructure is successfully deployed to the device. The established secure connection can be used to deploy a locally issued certificate to the device as well.
EST over secure CoAP (EST-coaps)ConsultantCisco SystemsSandelman Software WorksRISE SICS Enrollment over Secure Transport (EST) is used as a certificate
provisioning protocol over HTTPS. Low-resource devices often use the
lightweight Constrained Application Protocol (CoAP) for message
exchanges. This document defines how to transport EST payloads over
secure CoAP (EST-coaps), which allows constrained devices to use
existing EST functionality for provisioning certificates.
CBOR Object Signing and Encryption (COSE): Header parameters for carrying and referencing X.509 certificatesAugust Cellars The CBOR Signing And Encrypted Message (COSE) structure uses
references to keys in general. For some algorithms, additional
properties are defined which carry parameters relating to keys as
needed. The COSE Key structure is used for transporting keys outside
of COSE messages. This document extends the way that keys can be
identified and transported by providing attributes that refer to or
contain X.509 certificates.
IEEE 802.1AR Secure Device IdentifierLightweight Authorization for Authenticated Key Exchange.Ericsson ABEricsson ABINRIASandelman Software WorksInstitute of Embedded Systems, ZHAW This document describes a procedure for augmenting the authenticated
Diffie-Hellman key exchange EDHOC with third party assisted
authorization targeting constrained IoT deployments (RFC 7228).
Key words for use in RFCs to Indicate Requirement LevelsIn many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.Ambiguity of Uppercase vs Lowercase in RFC 2119 Key WordsRFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings.Constrained Join Protocol (CoJP) for 6TiSCHInriaAnalog DevicesUniversity of California BerkeleySandelman Software WorksThis document describes the minimal framework required for a new device, called a "pledge", to securely join a 6TiSCH (IPv6 over the Time-Slotted Channel Hopping mode of IEEE 802.15.4) network. The framework requires that the pledge and the JRC (Join Registrar/Coordinator, a central entity), share a symmetric key. How this key is provisioned is out of scope of this document. Through a single CoAP (Constrained Application Protocol) request-response exchange secured by OSCORE (Object Security for Constrained RESTful Environments), the pledge requests admission into the network, and the JRC configures it with link-layer keying material and other parameters. The JRC may at any time update the parameters through another request-response exchange secured by OSCORE. This specification defines the Constrained Join Protocol and its CBOR (Concise Binary Object Representation) data structures, and it describes how to configure the rest of the 6TiSCH communication stack for this join process to occur in a secure manner. Additional security mechanisms may be added on top of this minimal framework.
Informative ReferencesYANG Tree DiagramsTail-f SystemsLabN Consulting, L.L.C.This document captures the current syntax used in YANG module tree diagrams. The purpose of this document is to provide a single location for this definition. This syntax may be updated from time to time based on the evolution of the YANG language.
CBOR Object Signing and Encryption (COSE) registryOperatonal Considerations for Voucher infrastructure for BRSKI MASASandelman Software WorksHuawei Technologies Co., Ltd. This document describes a number of operational modes that a BRSKI
Manufacturer Authorized Signing Authority (MASA) may take on.
Each mode is defined, and then each mode is given a relevance within
an over applicability of what kind of organization the MASA is
deployed into. This document does not change any protocol
mechanisms.
Constrained RESTful Environments (CoRE) Link FormatThis specification defines Web Linking using a link format for use by constrained web servers to describe hosted resources, their attributes, and other relationships between links. Based on the HTTP Link Header field defined in RFC 5988, the Constrained RESTful Environments (CoRE) Link Format is carried as a payload and is assigned an Internet media type. "RESTful" refers to the Representational State Transfer (REST) architecture. A well-known URI is defined as a default entry point for requesting the links hosted by a server. [STANDARDS-TRACK]Enrollment over Secure TransportThis document profiles certificate enrollment for clients using Certificate Management over CMS (CMC) messages over a secure transport. This profile, called Enrollment over Secure Transport (EST), describes a simple, yet functional, certificate management protocol targeting Public Key Infrastructure (PKI) clients that need to acquire client certificates and associated Certification Authority (CA) certificates. It also supports client-generated public/private key pairs as well as key pairs generated by the CA.Library support for BRSKIFor the implementation of BRSKI, the use of a software library to manipulate certificates and use crypto algorithms is often beneficial. Two C-based examples are OPENSSL and mbedtls. Others more targeted to specific platforms or languages exist. It is important to realize that the library interfaces differ significantly between libraries.Libraries do not support all known crypto algorithms. Before deciding on a library, it is important to look at their supported crypto algorithms and the roadmap for future support. Apart from availability, the library footprint, and the required execution cycles should be investigated beforehand.The handling of certificates usually includes the checking of a certificate chain. In some libraries, chains are constructed and verified on the basis of a set of certificates, the trust anchor (usually self signed root CA), and the target certificate. In other libraries, the chain must be constructed beforehand and obey order criteria. Verification always includes the checking of the signatures. Less frequent is the checking the validity of the dates or checking the existence of a revoked certificate in the chain against a set of revoked certificates. Checking the chain on the consistency of the certificate extensions which specify the use of the certificate usually needs to be programmed explicitly.A libary can be used to construct a (D)TLS connection. It is useful to realize that differences beetween (D)TLS implementations will occur due to the differences in the certicate checks supported by the library. On top of that, checks between client and server certificates enforced by (D)TLS are not always helpful for a BRSKI implementation. For example, the certificates of Pledge and Registrar are usually not related when the BRSKI protocol is started. It must be verified that checks on the relation between client and server certificates do not hamper a succeful DTLS connection establishment.OpensSSLfrom openssl's apps/verify.c
]]>mbedTLSwolfSSLTo be added (TBD).Constrained BRSKI-EST messagesThis section extends the examples from Appendix A of with the constrained BRSKI requests. The CoAP headers are only worked out for the enrollstatus example.enrollstatusA 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.04 Changed response will then be:With CoAP fields:TBD - remove this payload or modify example to be the request payload of the POST. // The binary payload is:The binary payload disassembles to the above CBOR diagnostic code.voucher_statusA coaps voucher_status message can be:A 2.04 Changed response will then be:TBD modify this example to let Pledge POST status to Registrar - direction change. Change 2.05 to 2.04.
]]>The payload above is represented in hexadecimal.
]]>COSE examplesThese 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 sha 256 key"
$OPENSSL_BIN ecparam -name prime256v1 -genkey \
-noout -out $cadir/private/ca-regis.key
$OPENSSL_BIN req -new -x509 \
-config $cnfdir/openssl-regis.cnf \
-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_BIN 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_BIN 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_BIN 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_BIN ecparam -name prime256v1 -genkey -noout \
-out $cadir/private/ca-masa.key
$OPENSSL_BIN req -new -x509 \
-config $cnfdir/openssl-masa.cnf \
-days 1000 -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_BIN 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_BIN 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_BIN 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 sha 256 key"
$OPENSSL_BIN ecparam -name prime256v1 -genkey -noout \
-out $dir/private/pledge.key
echo "create pledge certificate request"
$OPENSSL_BIN 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_BIN 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 derived pledge key and derived pledge \
certificate to pkcs12 file"
$OPENSSL_BIN 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_BIN 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_BIN x509 -in $dir/certs/pledge-comb.crt -text
#show private key in pledge-comb.crt
$OPENSSL_BIN 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.Pledge, Registrar and MASA keysThis 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.Pledge private key
]]>Registrar private key
]]>MASA private key
]]>Pledge, Registrar and MASA certificatesBelow the certificates that accompany the keys. The certificate description is followed by the hexadecimal DER of the certificatePledge IDevID certificate
]]>This is the hexadecimal representation in (request-)voucher examples referred to as pledge-cert-hex.
]]>Registrar Certificate
]]>This the hexadecimal representation, in (request-)voucher examples referred to as regis-cert-hex
]]>MASA Certificate
]]>This is the hexadecimal representation, in (request-)voucher examples referred to as masa-cert-hex.
]]>COSE signed voucher request from Pledge to RegistrarIn this example the voucher request has been signed by the Pledge, and has been sent to the JRC over CoAPS.
The Pledge uses the proximity assertion together with an included proximity-registrar-cert field to inform
MASA about its proximity to the specific 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:
]]>COSE signed voucher request from Registrar to MASATBD - modify example to use full paths to MASA, not short-names.
Also not use CoAP but HTTP protocol.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:
]]>COSE signed voucher from MASA to Pledge via RegistrarThe 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:
]]>