This is the second and final set of review feedbacks for draft-ietf-anima-brski-prm-06, sorry for the long time it took.
I am continuing after where i stopped in the first review. [major] I am worried about the non-support for the mechanisms of CSRattr in this spec and would like to see that functionality for this gets added. In BRSKI, support for CSRattr, and hence the inclusion of Registrar determined attributes into the CSR of the pledge is mandatory to support, and just because pledges are in PRM does not seem to be a good enough reason for me to suspect that we could be successful in the same breaths of flexible secure domain deployments without similar support. I would like to request/propose to solve this issue through two complementary options: a) CSR attr in PER trigger Do: The PER trigger messages agent-signed data should be extended to include an optional field that can be filled with a Content-Transfer-Encoding of "base64" [RFC2045] encoded CsrAttr structure according to RFC7030 and clarified by I-D.ietf-lamps-rfc7030-csrattrs. Unfortunately, i think the inclusion of this data may make it prudent to also sign the PER trigger then in the same fashion as the PVR trigger is signed. So maybe this means to define the following into section 6.1.3: # The PER in General JWS Serialization syntax { "payload": "BASE64URL(ietf-pledge-enrolment-request:prm")", "signatures": [ { "protected": "BASE64URL(UTF8(JWS Protected Header))", "signature": "base64encodedvalue==" } ] } # Decoded Payload "ietf-pledge-enrolment-request:prm" Representation in JSON syntax "ietf-pledge-enrolment-request:prm": { "enroll-type" : "enroll-generic-cert", "csr-attributes": "base64encodedvalue==", } # Decoded "JWS Protected Header" Representation in JSON syntax { "alg": "ES256", "x5c": [ "base64encodedvalue==", "base64encodedvalue==" ], "typ": "per-trigger-jws+json" } Write: The optional "cs-attributes" field of the PER trigger message is intended to include those CSR attributes according to [EST] as clarified by I-D.ietf-lamps-rfc7030-csrattrs, that can be known by the registrar-agent before authenticating the pledge. This can includes attributes which are common across the domain such as, such as allowed type(s) and length(s) of the public key of the pledge. Attributes depending on the pledge or its identity can be included as well, as long as the registrar-agent can be made to know them. Mechanisms for how the registrar-agent can learn these attributes are out-of-scope in this document but expected to use the same or derived mechanisms to those by which the registrar-agent may learn the list of pledges serial-number to attempt to enroll. And in 6.1.4 write: Thes "csr-attributes" of the PER trigger MUST be handled by the pledge in forming the PER CSR ("p10-csr") according to [EST], Section 4.5.2 and clarified by I-D.ietf-lamps.rfc7030-csrattrs. b) Overriding and extending CSR attributes The following text should go in an appropriate section, not clear which one: When using BRSKI-PRM, additional protocol roundtrips between pledge, registrar-agent and registrar beyond the two specified in this document are prohibitive because BRSKI-PRM is optimized for the case where the registrar agent needs to physically move between connectivity to the pledge and connectivity to the registar. In BRSKI, pledge specific CSR attributes can be determined after successful mutual authentication between pledge and registar - including the existance/creation of a voucher for the pledge through the MASA. For example, in [RFC8994], the registrar (or a backend server that is consulted by the registar) can determine the exact details of the AcpNodeName attribute after authentication of the pledge and applying policy against the type (derived from the serial-number) and location of the pledge. This AcpNodeName incurs allocation of an IPv6 address for the pledge which if done before acceptance of the pledge into the domain (in conjunction with issuance of a a voucher) could at best be tentative and might need to be undone later, and at worsti it could be a new undesirable attack vector. If CSR attributes such as these are needed to be included in the pledges LDevID when using BRSKI-PRM, then the registrar SHOULD add/override the attributes provided by the pledge in its PER and use a protocol such as full Certificate Management over CMS (CMC) towards the CA, which provides mechanisms to override CSR Attributes. See also [BRSKI], Section 5.9.2. --- overlooked fixes in first part: 1280 IDevID, proof of identity is provided. Here, a JOSE object is being 1281 created in which the body utilizes the YANG module ietf-ztp-types 1282 with the grouping for csr-grouping for the CSR as defined in 1283 [I-D.ietf-netconf-sztp-csr]. 1343 The body of the pledge enrollment-request SHOULD contain a P10 1344 parameter (for PKCS#10) as defined for ietf-ztp-types:p10-csr in 1345 [I-D.ietf-netconf-sztp-csr]: 1347 * P10: contains the base64-encoded PKCS#10 of the pledge. 1343 The body of the pledge enrollment-request SHOULD contain a P10 1344 parameter (for PKCS#10) as defined for ietf-ztp-types:p10-csr in 1345 [I-D.ietf-netconf-sztp-csr]: 1347 * P10: contains the base64-encoded PKCS#10 of the pledge. [major] I find the text sections referring to I-D.ietf-netconf-sztp-csr confusing and i fear it is misleading: The use of "ietf-ztp-types" in the PER JSON format, and the text saying this is from I-D.ietf-netconf-sztp-csr makes it sound as if one could or should be allowed to also form a PER JSON using any of the other options defined in the I-D.ietf-netconf-sztp-csr YANG module. But its not clear whether that is actually intended. It is also not clear how would format the JSON, because the netconf draft does not specify any JSON, and as far as i can tell, there is no well defined mapping from YANG to JSON that would ensure that two independent implementations trying to do this would be interoperable - or am i wrong ? Aka: If two implementation (pledge, registrar/-agent) tried to use "cmp-csr" instead of "p10-csr". I also fear that by claiming to inherit/refer to the netconf drafts specification, we do incur more formal spec requirements (i may easily be wrong). In any case, i think this document would be a lot easier if formal must/YANG references to the netconf draft would be removed, and this draft would just specify what is in the "p10-csr" JSON element standalone. Which i think it already does mostly. One can still add a sentence that this definition is in "the spirit" of what is also defined in the netconf draft (with reference). Aka: The introduction and use of "ietf-ztp-types" on line 1364 does not seem to be related to any registry, so it seems we do not need to do any reference work to any registry or any netconf draft section, aka: this is all about removing unnecessary text about the netconf text to make what the draft specifies standaline, even if it is cloning ideas from the network draft (like that string name). Aka: no spec changes needed here. I would like to see the text avoid rhe abbreviation P10 though, and just refer to PKCS#10 and "p10-csr" to avoid introducing redundant terms/abbreviations. [major - or not?] I find the use or non-use of the media-types confusing. For example, there is no "typ" field in the PER JWS header, and the media-types that this draft does suggest/use feel like being all over the place. I think PRM messages would be less confusing if they all used JWS (i am making a point below to also do this for the PER trigger), and all had media-types that would allow to identify each message, and where all consistent. something like application/brski-<message-type>-jose+json where message-type could be pvrt (pledge voucher request trigger), pvr (pledge-voucher-request), rpvr (registrar pledge-voucher-request) - and so on, for all of them. Yes, i can not make a real strong functional argument for this except maybe that at some point there would be a benefit that all these messages would much better self-identify if they'd be on disk even without HTTP header. --- Following are inline comments/discusses. --- 1842 The Content-Type header of PER is: application/jose+json. As top posted [major] discusses, i would suggest something like "application/prm+jose+json" 1844 This is a deviation from the Content-Type header values used in 1845 [RFC7030] and results in additional processing at the domain 1846 registrar (as EST server). 1846 Note, the registrar is already aware that 1847 the bootstrapping is performed in a pledge-responder-mode due to the 1848 use of the LDevID(RegAgt) certificate for TLS and the provided PVR as 1849 JSON-in-JWS object. As mentioned in before, i would like to remove the reliance on the certificate used to authenticate the pledge, because it is unnecessary. Like in EST and BRSKI, the purpose of a request should always only be deduced from operation path and if necessary by media-type. So pls. remove. 1851 * If the registrar receives a PER with Content-Type header: 1852 application/jose+json, it MUST verify the wrapping signature using ^prm+ 1853 the certificate indicated in the JOSE header. Please specify which cert is used (pledge or agent). 1855 * The registrar verifies that the pledge's certificate (here 1856 IDevID), carried in "x5c" header field, is accepted to join the 1857 domain s/is accepted/is authorized/ 1857 after successful validation of the PVR. I would suggest to remove this. This is confusing, because it can be interpreted to imply that the PVR/voucher have some impact on whether or not the domain authorizes the pledge. Which it logically does not have (that would just be an internal implementation optimization on the registrar, and would be an additionals security issue). 1859 * If both succeed, the registrar utilizes the PKCS#10 request s/both succeed/this succeeds/ 1860 contained in the JWS object body as "P10" parameter of "ietf-sztp- ^ the s/"P10"/the "p10-csr"/ 1861 csr:csr" for further processing of the enrollment request with the 1862 corresponding domain CA. It creates a registrar-enrollment- 1863 request (RER) by utilizing the protocol expected by the domain CA. 1864 The domain registrar may either directly forward the provided 1865 PKCS#10 request to the CA or provide additional information about 1866 attributes to be included by the CA into the requested LDevID 1867 certificate. The approach of sending this information to the CA 1868 depends on the utilized certificate management protocol between 1869 the RA and the CA and is out of scope for this document. This text from 1864-1869 would be good to replace with the proposed text for "Overriding and extending CSR attributes" i wrote earlier, except that it is probably better to have here just a forward pointer and write this in a later section about registrar behavior. 1871 The registrar-agent SHALL send the PER to the registrar by HTTP POST 1872 to the endpoint: "/.well-known/brski/requestenroll" 1874 The registrar SHOULD respond with an HTTP 200 OK in the success case 1875 or fail with HTTP 4xx/5xx status codes as defined by the HTTP 1876 standard. replace "HTTP standard" with appropriate RFC reference. 1878 A successful interaction with the domain CA will result in a pledge 1879 LDevID certificate, which is then forwarded by the registrar to the s/forwarded/returned/ 1880 registrar-agent using the Content-Type header: application/ 1881 pkcs7-mime. ^ in response to the PER. [major] If retrieval of the CA certs is optional, then care must be taken that the pkcs7-mime pledge certificate can be authenticated against the pinned domain certificate from the voucher alone. This may not be the case, for example if the pinned-domain cert is just the registrar cert. This would be good to write down, unless: In general, i would prefer if the cert repsonse is also signed via JWS+JSON with the registrar-cert. This would also better mimic BRSKI where the pledge does trust the cert because of the voucher authenticated TLS connection. This wold make delivery of CA-certs completely optional to get successfully an initial cert. [major] This step involves actual authorization of the pledge to be enrolled (remember the voucher is really just to make the pledge trust the domain and some initial invitation, but not a finalized invite for the certificate - for example the actual issuance of a certificate could incur additional checks, such as whether the device was encountered in the correct location in the network designated for it. Long story short: This enrolment / reply may take some time. I think in BRSKI, we have some text about HTTP "come back later" or similar replies instead of "fail". It would be helpfull if we would also be able to make BRSKI-PRM work in a way where the registrar-agent would be able to repeat requests and specify whatever is easy to say about these "wait" or "come back later" HTTP replies (ENOTIME to find this text right now in BRSKI). 1883 6.2.7. Request Wrapped-CA-certificate(s) (Registrar-Agent to Registrar) ^ pick upper or lower, but make it consistent troughout the document. 1885 As the pledge will verify it own certificate LDevID certificate when ^s 1886 received, it also needs the corresponding CA certificates. This is Confusing - this makes it sound as if the corresponding CA certificates are required so the pledge can verify the LDevID. But this is not really necessary. The pledge simply trusts the LDevID in BRSKI/EST because it is received over the TLS connection that was authenticated by the voucher. The CA certificates are only needed so the pledge can authenticate peers. One can create use-cases where the pledge for example only needs to originate signed messages but not authenticate peers, and in which it would therefore not need to receive CA certificates. 1886 This is 1887 done in EST [RFC7030] using the "/.well-known/est/cacerts" endpoint, 1888 which provides the CA certificates over a TLS protected connection. 1889 BRSKI-PRM requires a signature wrapped CA certificate object, to 1890 avoid that the pledge can be provided with arbitrary CA certificates 1891 in an authorized way. The registrar signed CA certificate object 1892 will allow the pledge to verify the authorization to install the 1893 received CA certificate(s). As the CA certificate(s) are provided to 1894 the pledge after the voucher, the pledge has the required information 1895 (the domain certificate) to verify the wrapped CA certificate object. Note: it may be useful to create the reference to RFC7030 so it will read [EST], that way one avoids duplication like "EST [RFC7030]". Same for other commonly used words in the draft, like [HTTP]. Suggest to replace 1885 - 1895 with: In [EST], CA certificate(s) returned by the registrar to the pledge via the /cacerts operation path are authenticated via the TLS connection to the pledge which is authenticated by the pledge through the voucheer. In BRSKI-PRM, this is achieved by the registar-agent retrieving the CA certificates from the registrar wrapped with a registrar signature. 1897 To support registrar-agents requesting a signature wrapped CA 1898 certificate(s) object, a new endpoint for BRSKI-PRM is defined on the 1899 registrar: "/.well-known/brski/wrappedcacerts" 1901 The registrar-agent SHALL requests the EST CA trust anchor database 1902 information (in form of CA certificates) by HTTP GET. This section so far has no context. Suggest to write that the registrar-agent will request the wrapped CA certificates after the certificate request/reply with the registrar. And i guess we can say "successful" (aka: only when registrar has given registrar-agent a cert for the pledge). [major - but weird] there is a weird set of use cases i can imagine, where the pledge might not (yet) receive a certificate, but just the trust-anchors. I don't think we ever fully considered this in BRSKI explicitly (but it could work there), but in BRSKI-PRM it may be more useful, because the trust-anchors may suffice for a pledge to do all or part of its job, such as listenening and trusting other messages from the domain. And avoid having to rely/cache the voucher if/when it is instructed to take a certificate from the domain later. but if you don't immediately see value in it, then ignore this thought. 1904 The Content-Type header of the response SHALL be: application/ 1905 jose+json. 1907 This is a deviation from the Content-Type header values used in EST 1908 [RFC7030] and results in additional processing at the domain ^ Section 4.1.3 1909 registrar (as EST server). The additional processing is to sign the 1910 CA certificate(s) information using the registrar EE credentials. ... and encode it as JSON+JWS. Also: why does this need to say "EE credentials" ? And is this not also wrong ? Aka: Lets assume the voucher had just one (root) CA certificate, but the registrar itself is enrolled via an intermediate CA. In this case the signature would not only be the EE certicate of the registrar, but would also need to include the intermediate CA certificate - otherwise the pledge could not authenticate the CA certs. Something like "The registrar certificate information included in the JWS header needs to suffice to be authenticated against the pinned certificate in the voucher for the pledge to authenticate the message. For example, it is not sufficient to include the registrars EE certificate if it was signed by an intermediate CA but the voucher has only the root certificate of the domain pinned. In this case, the JWS certificate information also needs to contain the intermediate certificate." 1911 This results in a signed CA certificate(s) object (JSON-in-JWS), the 1912 CA certificates are provided as base64 encoded "x5b" in the JWS 1913 payload. 1915 # The CA certificates data with additional registrar signature in 1916 General JWS Serialization syntax 1917 { 1918 "payload": "BASE64URL(certs)", 1919 "signatures": [ 1920 { 1921 "protected": "BASE64URL(UTF8(JWS Protected Header))", Curious: Why do you use some "nice" textual string here instead of what looks like a formal registered name in the other JWS+JSON headers. I would actually prefer to reuse exactly this string "JWS Protected Header" in all JWS+JSON messages in this document given how i think we never want to demultiplex/decide anything based on this field, but only based on the media-type, ... or do we ?? (that would eliminate confusion what the impact of those "looks like registered name" here is...). 1922 "signature": "base64encodedvalue==" 1923 } 1924 ] 1925 } 1927 # Decoded payload "certs" representation in JSON syntax 1928 { 1929 "x5b": [ 1930 "base64encodedvalue==", 1931 "base64encodedvalue==" 1932 ] 1933 } [major] There is no "x5b" in RFC7515 and you have no explanation what the meaning of those two base64 encoded values is. Could/should this not simply be "cert-pkcs7-mime" with just one base64 encoded value (the pkcs7-mime base64 encoded CA certificate chain ?) In any case - needs to be explained, and unless there is a good reason to use a non-descriptive "x5b" term, i'd prefer a more prescriptive name. 1935 # Decoded "JWS Protected Header" representation in JSON syntax 1936 { 1937 "alg": "ES256", 1938 "x5c": [ 1939 "base64encodedvalue==", 1940 "base64encodedvalue==" 1941 ] 1942 } 1944 Figure 13: Representation of CA certificate(s) data with 1945 additional registrar signature 1947 6.3. Response Object Supply by Registrar-Agent to Pledge Response Objects supplied by the Registrar-Agent to the Pledge 1949 It is assumed that the registrar-agent already obtained the 1950 bootstrapping response objects from the domain registrar and can 1951 supply them to the pledge: 1953 * voucher-response - Voucher (from MASA via Registrar) 1955 * wrapped-CA-certificate(s)-response - CA certificates ^(s) 1957 * enrollment-response - LDevID(Pledge) certificate (from CA via 1958 Registrar) 1960 The registrar-agent will re-connect to the pledge. To contact the To deliver these response object, the registrar-agent will ... 1961 pledge, it may either discover the pledge as described in 1962 Section 5.4.2 or use stored information from the first contact with 1963 the pledge. 1965 Preconditions in addition to Section 6.2: 1967 * Registrar-agent: possesses voucher and LDevID certificate and s/possesses/has obtained/ (we have this special meaning for posesession such as for proof of possession, so i'd avoid it unless it's used in the context of something where you can create proof of possession). 1968 optionally CA certificates. Its nice that you reconfirm "optionally" here, but from the text leading here, i have seen no description as to who or how determines whether or not the CA certificates will be made available to the plegde. Any explanation would be nice (whereever it fits best). 1970 +--------+ +-----------+ 1971 | Pledge | | Registrar-| 1972 | | | Agent | 1973 | | | (RegAgt) | 1974 +--------+ +-----------+ 1975 | [voucher and enrollment] 1976 | [responses available] 1977 | | 1978 |<------- supply voucher -----------| 1979 | | 1980 |--------- voucher status --------->| - store 1981 | | pledge voucher status 1982 |<----- supply CA certificates ----| 1983 | | 1984 |<--- supply enrollment response ---| 1985 | | 1986 |--------- enroll status ---------->| - store 1987 | | pledge enroll status 1988 |<--- supply CAcerts (optional) ----| 1989 | | 1991 Figure 14: Responses and status handling between pledge and 1992 registrar-agent Nice picture, but now i am confused what "supply CA certificates" is versus "supply CAcerts (optional)" (cold read: this concern is written without knowing whats written further down. But also the tree bullet points above in this section didn't distinguish between "CA certificates" and "CAcerts (optional)". 1994 The content of the response objects is defined by the voucher 1995 [RFC8366] and the certificate [RFC5280]. I think this sentence is misleading here given how we know from prior text in this document, that the format is much more specific, such as JWS+JSON voucher and pkcs#7-mime certificate. If this is meant as a more general excurse into how one could potentially use all type of encodings in variations of a PRM which are not specified in this document, then thats text for an appendix or something much further below, but not here. Aka: delete sentence or make references specific to the actual formats specified in this spec. 1997 The registrar-agent provides the information via distinct pledge 1998 endpoints as following. 2000 6.3.1. Pledge: Voucher Response Processing 2002 The registrar-agent SHALL send the voucher-response to the pledge by 2003 HTTP POST to the endpoint: "/.well-known/brski/sv". 2005 The registrar-agent voucher-response Content-Type header is 2006 application/voucher-jws+json and contains the voucher as provided by 2007 the MASA. An example is given in Figure 11 for a MASA signed voucher 2008 and in Figure 12 for the voucher with the additional signature of the 2009 registrar. The figure numbers 11/12 don't seem to be correct. 2011 A nonceless voucher may be accepted as in [RFC8995] and may be 2012 allowed by a manufacture's pledge implementation. Can a pledge that knows the voucher will be nonceless not include the nonce in the JWS+JSON PVR message ? In that case it would be good to mention thi earlier in the document where you specify the none message element (e.g.: add (optional)). 2014 To perform the validation of multiple signatures on the voucher s/multiple/the different/ ?? 2015 object, the pledge SHALL perform the signature verification in the 2016 following order: 2018 1. Verify MASA signature as described in section 5.6.1 in [RFC8995] ... against pre-installed vendor trust anchors. 2020 2. Install trust anchor contained in the voucher ("pinned-domain- 2021 cert") provisionally 2023 3. Verify registrar signature as described in section 5.6.1 in 2024 [RFC8995], but take the registrar certificate instead of the MASA 2025 certificate for the verification 2027 4. Validate the registrar certificate received in the agent- 2028 provided-proximity-registrar-cert in the pledge-voucher-request 2029 trigger request (in the field "agent-provided-proximity- 2030 registrar-cert"). [major] I think this is in the wrong order or miswritten. Step 3 can not verify a signature from a certificate that was not verified in before, and i do not see that the registrar certificate mentioned in step 3 was verified in before. Or is this assumed to be the pinned-domain-cert mentioned in step 2, and the text just uses different words to make it impossible to match up terms ? But be that as it may: i really don't know what steps 3 and 4 are good for. I think they are not needed, but later when pledge-certificate and CA-certs are received will those objects need to be authenticated against the signature of the registrar, and that requires to first authenticate the registrar certificate against the pinned-domain-cert from step 3. If 3 and 4 can go, that also means that step 2 is not provisional, but would per permanent, unless the pinned domain cert is later superceeded by the CA certs. 2032 If all steps stated above have been performed successfully, the 2033 pledge SHALL terminate the "PROVISIONAL accept" state for the domain 2034 trust anchor and the registrar EE certificate. 2036 If an error occurs during the verification and validation of the 2037 voucher, this SHALL be reported in the reason field of the pledge 2038 voucher status. 2040 6.3.2. Pledge: Voucher Status Telemetry 2042 After voucher verification and validation the pledge MUST reply with 2043 a status telemetry message as defined in section 5.7 of [RFC8995]. 2044 The pledge generates the voucher-status and provides it as signed 2045 JSON-in-JWS object in response to the registrar-agent. 2047 The response has the Content-Type application/jose+json and is signed 2048 using the IDevID of the pledge as shown in Figure 15. As the reason 2049 field is optional (see [RFC8995]), it MAY be omitted in case of 2050 success. 2052 # The "pledge-voucher-status" telemetry in general JWS 2053 serialization syntax 2054 { 2055 "payload": "BASE64URL(pledge-voucher-status)", 2056 "signatures": [ 2057 { 2058 "protected": "BASE64URL(UTF8(JWS Protected Header))", 2059 "signature": "base64encodedvalue==" 2060 } 2061 ] 2062 } 2064 # Decoded payload "pledge-voucher-status" representation in JSON 2065 syntax 2066 { 2067 "version": 1, 2068 "status": true, 2069 "reason": "Voucher successfully processed", 2070 "reason-context": { 2071 "additional": "JSON" 2072 } 2073 } 2075 # Decoded "JWS Protected Header" representation in JSON syntax 2076 { 2077 "alg": "ES256", 2078 "x5c": [ 2079 "base64encodedvalue==", 2080 "base64encodedvalue==" 2081 ] 2082 } 2084 Figure 15: Representation of pledge voucher status telemetry A second picture with an excerpt of a useful error message would be great. ( aka: only showing the dedodec payload.) "failed to authenticate MASA certificate because it starts in the future (1/1/2023). Current date: 1/1/1970" (typical local clock failure on pledges ;-)) [major] What happens if there is an interruption in the process, and the registrar-agent does not get to record on disk the successful enrolment ? how does it restart ? It could attempt to re-send the same voucher, but then it should also get again success status instead of some errror it can't interpret "you already gave me the voucher 5 minutes ago". Aka: would be good to ensure that the sending of voucher and status can repeated an result in the same positive status. 2086 6.3.3. Pledge: Wrapped-CA-Certificate(s) Processing 2088 The registrar-agent SHALL provide the set of CA certificates 2089 requested from the registrar to the pledge by HTTP POST to the 2090 endpoint: "/.well-known/brski/cc". 2092 As the CA certificate provisioning is crucial from a security 2093 perspective, this provisioning SHALL only be done, if the voucher- 2094 response has been successfully processed by pledge. Well.... i don't think this is good text. The registrar-agent can always try to provide CA certificates if it wants to enroll the pledge. Its the pledge that would reject this if the voucher was not previously successfully accepted by the pledge. Aka: there is no harm in the registrar-agent trying, but if you accept the consideration from my major after line 2084, then one could write that the registrar-agent SHOULD only send the CA-certificates (like the following pledge certificate) after having received a successful voucher telemetry from the pledge. 2096 The supply CA certificates message has the Content-Type application/ s/supply// s/the/a/ 2097 jose+json and is signed using the credential of the registrar pledge 2098 as shown in Figure 13. "registrar pledge" ? 2100 The CA certificates are provided as base64 encoded "x5b". The pledge 2101 SHALL install the received CA certificates as trust anchor after 2102 successful verification of the registrar's signature. [major] This i think is where to elaborate on the 5 verification steps: - first authenticat registrar certificate against the pinned-domain-cert - then authenticate the message signature. 2104 The following 4xx client error codes SHOULD be used by the pledge: 2106 * 403 Forbidden: if the validation of the wrapping signature or 2107 another security check fails. 2109 * 415 Unsupported Media Type: if the Content-Type of the request is 2110 in an unknown or unsupported format. 2112 * 400 Bad Request: if the pledge detects errors in the encoding of 2113 the payload. 2115 6.3.4. Pledge: Enrollment Response Processing 2117 The registrar-agent SHALL send the enroll-response to the pledge by 2118 HTTP POST to the endpoint: "/.well-known/brski/se". 2120 The registrar-agent enroll-response Content-Type header, when using 2121 EST [RFC7030] as enrollment protocol between the registrar-agent and 2122 the infrastructure is: application/pkcs7-mime. Note: It only 2123 contains the LDevID certificate for the pledge, not the certificate 2124 chain. I think it is factually wrong that a pkcs7-mime does not contain a certificate chain. AFAIK it can contain perfectly well not only the signing certificate but also a chain of intermediate certificate in case those need to be supplied by the owner of the certificate later knowing that the distributed trust-anchors are not the signing certificates. [major] See my above comment about this only being sufficient if there was CA certificates given to the pledge or the pinned-domain-cert of the voucher containing the certificate chain sufficient to authenticate the pledges certificate later. So if you do not want to wrap the certificate respnse into a registrar signature, then i think those conditions need to be described here. 2126 Upon reception, the pledge SHALL verify the received LDevID 2127 certificate. The pledge SHALL generate the enroll status and provide 2128 it in the response to the registrar-agent. If the verification of 2129 the LDevID certificate succeeds, the status SHALL be set to true, 2130 otherwise to FALSE. In JSON i guess it's "true" and "false", so lets not invent additional ways to write the same (TRUE, FALSE). 2132 6.3.5. Pledge: Enrollment Status Telemetry 2134 The pledge MUST reply with a status telemetry message as defined in 2135 section 5.9.4 of [RFC8995]. As for the other objects, the enroll- 2136 status is signed and results in a JSON-in-JWS object. If the pledge 2137 verified the received LDevID certificate successfully it SHALL sign 2138 the response using its new LDevID credentials as shown in Figure 16. 2139 In the failure case, the pledge SHALL use the available IDevID 2140 credentials. As the reason field is optional, it MAY be omitted in 2141 case of success. 2143 The response has the Content-Type application/jose+json. 2145 # The "pledge-enroll-status" telemetry in General JWS Serialization 2146 syntax 2147 { 2148 "payload": "BASE64URL(pledge-enroll-status)", 2149 "signatures": [ 2150 { 2151 "protected": "BASE64URL(UTF8(JWS Protected Header))", 2152 "signature": "base64encodedvalue==" 2153 } 2154 ] 2155 } 2157 # Decoded payload "pledge-enroll-status" representation in 2158 JSON syntax 2159 { 2160 "version": 1, 2161 "status": true, 2162 "reason": "Enrollment response successfully processed", 2163 "reason-context": { 2164 "additional": "JSON" 2165 } 2166 } 2168 # Decoded "JWS Protected Header" representation in JSON syntax 2169 { 2170 "alg": "ES256", 2171 "x5c": [ 2172 "base64encodedvalue==", 2173 "base64encodedvalue==" 2174 ] 2175 } 2177 Figure 16: Representation of pledge enroll status telemetry negative example (only payload) would again be a fine addition. 2179 Once the registrar-agent has collected the information, it can 2180 connect to the registrar to provide it with the status responses. 2182 6.3.6. Telemetry Voucher Status and Enroll Status Handling (Registrar- 2183 Agent to Domain Registrar) 2185 The following description requires that the registrar-agent has 2186 collected the status information from the pledge. It SHALL provide 2187 the status information to the registrar for further processing. 2189 Preconditions in addition to Section 6.2: 2191 * Registrar-agent: possesses voucher status and enroll status from 2192 pledge. 2194 +-----------+ +-----------+ +--------+ +---------+ 2195 | Registrar | | Domain | | Domain | | Vendor | 2196 | Agent | | Registrar | | CA | | Service | 2197 | RegAgt) | | (JRC) | | | | (MASA) | 2198 +-----------+ +-----------+ +--------+ +---------+ 2199 | | | Internet | 2200 [voucher + enroll ] | | | 2201 [status info available] | | | 2202 | | | | 2203 |<------- mTLS ------->| | | 2204 | | | | 2205 |--- Voucher Status -->| | | 2206 | |--- req-device audit log-->| 2207 | |<---- device audit log ----| 2208 | [verify audit log ] 2209 | | | | 2210 |--- Enroll Status --->| | | 2211 | | | | 2213 Figure 17: Bootstrapping status handling 2215 The registrar-agent MUST provide the collected pledge voucher status 2216 to the registrar. This status indicates if the pledge could process 2217 the voucher successfully or not. 2219 If the TLS connection to the registrar was closed, the registrar- closed after...(insert maybe section). 2220 agent establishes a TLS connection with the registrar as stated in establishes a new TLS connection ^^^ 2221 Section 6.2. 2223 The registrar-agent sends the pledge voucher status without 2224 modification to the registrar with an HTTP-over-TLS POST using the 2225 registrar endpoint "/.well-known/brski/voucher_status". The Content- 2226 Type header is kept as application/jose+json as described in 2227 Figure 14 and depicted in the example in Figure 15. [major] So, in the first part of the review i was trying to suggest positive spin text around all the complexity of introducing registar-agent authentication in some messages, such as being able to track on the registrar and the backend behind it, who (which registstrar-agent) was assisting he enrollment and hence also likely co-checks for the pledge. But when you simply pass through the telementry without including an identity of the registar-agent, then this benefit goes out the door, and we could rather remove all other registrar-agent signatures from the spec because they serve no purpose other than to track somewhere who was sending messages back and forth between pledge and registrar. Aka: either have a scheme where all the steps taken can be traced back to a registrar-agent (aka: put the plege-responses into a registrar-agent signed container), or get rid of all the then unnecessary registrar-agent signatures... 2229 The registrar SHALL verify the signature of the pledge voucher status 2230 and validate that it belongs to an accepted device in his domain s/an/the/ ?? 2231 based on the contained "serial-number" in the IDevID certificate 2232 referenced in the header of the voucher status. 2234 According to [RFC8995] section 5.7, the registrar SHOULD respond with 2235 an HTTP 200 OK in the success case or fail with HTTP 4xx/5xx status 2236 codes as defined by the HTTP standard. The registrar-agent may use 2237 the response to signal success / failure to the service technician 2238 operating the registrar agent. Within the server logs the server 2239 SHOULD capture this telemetry information. 2241 The registrar SHOULD proceed with collecting and logging status 2242 information by requesting the MASA audit-log from the MASA service as 2243 described in section 5.8 of [RFC8995]. 2245 The registrar-agent MUST provide the pledge's enroll status to the 2246 registrar. The status indicates the pledge could process the enroll- 2247 response (certificate) and holds the corresponding private key. 2249 The registrar-agent sends the pledge enroll status without 2250 modification to the registrar with an HTTP-over-TLS POST using the 2251 registrar endpoint "/.well-known/brski/enrollstatus". The Content- 2252 Type header is kept as application/jose+json as described in 2253 Figure 14 and depicted in the example in Figure 16. 2255 The registrar MUST verify the signature of the pledge enroll status. 2256 Also, the registrar SHALL validate that the pledge is an accepted s/an/the/ 2257 device in his domain based on the contained product-serial-number in 2258 the LDevID certificate referenced in the header of the enroll status. 2259 The registrar SHOULD log this event. In case the pledge enroll 2260 status indicates a failure, the pledge was unable to verify the 2261 received LDevID certificate and therefore signed the enroll status 2262 with its IDevID credential. Note that the verification of a 2263 signature of the status information is an addition to the described 2264 handling in section 5.9.4 of [RFC8995]. ... and is replacing the pledges IDevID TLS authentication in [RFC8995]. 2266 According to [RFC8995] section 5.9.4, the registrar SHOULD respond 2267 with an HTTP 200 OK in the success case or fail with HTTP 4xx/5xx 2268 status codes as defined by the HTTP standard. Based on the failure 2268 status codes as defined by the HTTP standard. Based on the failure 2269 case the registrar MAY decide that for security reasons the pledge is 2270 not allowed to reside in the domain. In this case the registrar MUST 2271 revoke the certificate. The registrar-agent may use the response to 2272 signal success / failure to the service technician operating the 2273 registrar agent. Within the server log the registrar SHOULD capture 2274 this telemetry information. [major] This part (2268-2274) seems to be new compared to rfc8995. If there is a reference to this revocation after enrolment in rfc8995, please add. Otherwise it would be great to add an example. For example, if the pledge failed to install the certificate because of clock messup, this does not mean that the registrar MUST revoke the certificate. it could as well end up for the technician having to replace NVram battery on the pledge or the like and re-send the voucher/certificate to the pledge. Aka: i fail to come up with an idea for the decision for the pledge not being allowed to reside in the domain after the registrar did previously happily provde a cert to the registrar-agent for the pledge. 2276 6.4. Request Pledge-Status by Registrar-Agent from Pledge 2278 The following assumes that a registrar-agent may need to query the 2279 status of a pledge. This information may be useful to solve errors, 2280 when the pledge was not able to connect to the target domain during 2281 the bootstrapping. The pledge MAY provide a dedicated endpoint to 2282 accept status-requests. 2284 Preconditions: 2286 * Registrar-agent: possesses LDevID (RegAgt), list of serial numbers 2287 of pledges to be queried and a list of corresponding manufacturer 2288 trust anchors to be able to verify signatures performed with the 2289 IDevID credential. 2291 * Pledge: may already possess domain credentials and LDevID(Pledge), 2292 or may not possess one or both of these. 2294 +--------+ +-----------+ 2295 | Pledge | | Registrar-| 2296 | | | Agent | 2297 | | | (RegAgt) | 2298 +--------+ +-----------+ 2299 | | 2300 |<--- pledge-status request -----| 2301 | | 2302 |---- pledge-status response --->| 2303 | | 2305 Figure 18: Pledge-status handling between registrar-agent and pledge 2307 6.4.1. Pledge-Status - Trigger (Registrar-Agent to Pledge) I don't think "trigger" is a good name here. It made sense when the reply are "requests", but in this case it should be called (IMHO) a Pledge Status Request, because it's answered by a response. 2309 The registrar-agent requests the pledge-status via HTTP POST on the 2310 defined pledge endpoint: "/.well-known/brski/ps" 2312 The registrar-agent Content-Type header for the pledge-status request 2313 is: application/jose+json. It contains information on the requested 2314 status-type, the time and date the request is created, and the 2315 product serial-number of the pledge contacted as shown in Figure 19. 2316 The pledge-status request is signed by registrar-agent using the 2317 LDevID(RegAgt) credential. 2319 The following Concise Data Definition Language (CDDL) [RFC8610] 2320 explains the structure of the format for the pledge-status request. 2321 It is defined following the status telemetry definitions in BRSKI 2322 [RFC8995]. Consequently, format and semantics of pledge-status 2323 requests below are for version 1. The version field is included to 2324 permit significant changes to the pledge-status request and response 2325 in the future. A pledge or a registrar-agent that receives a pledge- 2326 status request with a version larger than it knows about SHOULD log 2327 the contents and alert a human. Seems like a lot of replicated text from RFC8995. See if you can cut it down to just reference and whatever is new here. 2329 <CODE BEGINS> 2330 status-request = { 2331 "version": uint, 2332 "created-on": tdate ttime, 2333 "serial-number": text, 2334 "status-type": text 2335 } 2336 <CODE ENDS> 2338 Figure 19: CDDL for pledge-status request Its a bit weird using formal CDDL here when the whole document so far was inventing a lot of JSON/JWS+JSON messages without an equivalent CDDL specification. I don't want to ask for additional formalistic spec stuff in CDDL here, just wanted to note the inconsistency. 2340 The status-type defined for BRSKI-PRM is "bootstrap". This indicates 2341 the pledge to provide current status information regarding the 2342 bootstrapping status (voucher processing and enrollment of the pledge 2343 into the new domain). As the pledge-status request is defined 2344 generic, it may be used by other specifications to request further 2345 status information, e.g., for onboarding to get further information 2346 about enrollment of application specific LDevIDs or other parameters. 2347 This is out of scope for this specification. 2349 Figure 20 below shows an example for querying pledge-status using 2350 status-type bootstrap. 2352 # The registrar-agent request of "pledge-status" in general JWS 2353 serialization syntax 2354 { 2355 "payload": "BASE64URL(status-request)", 2356 "signatures": [ 2357 { 2358 "protected": "BASE64URL(UTF8(JWS Protected Header))", 2359 "signature": "base64encodedvalue==" 2360 } 2361 ] 2362 } 2364 # Decoded payload "status-request" representation in JSON syntax 2365 { 2366 "version": 1, 2367 "created-on": "2022-08-12T02:37:39.235Z", 2368 "serial-number": "pledge-callee4711", 2369 "status-type": "bootstrap" 2370 } 2372 # Decoded "JWS Protected Header" representation in JSON syntax 2373 { 2374 "alg": "ES256", 2375 "x5c": [ 2376 "base64encodedvalue==", 2377 "base64encodedvalue==" 2378 ] 2379 } 2381 Figure 20: Example of registrar-agent request of pledge-status 2382 using status-type bootstrap 2384 6.4.2. Pledge-Status - Response (Pledge - Registrar-Agent) 2386 If the pledge receives the pledge-status request with status-type 2387 "bootstrap" it SHALL react with a status response message based on 2388 the telemetry information described in section Section 6.3. 2390 The pledge-status response Content-Type header is application/ 2391 jose+json. 2393 The following CDDL explains the structure of the format for the 2394 status response, which is : 2396 <CODE BEGINS> 2397 status-response = { 2398 "version": uint, 2399 "status": 2400 "factory-default" / 2401 "voucher-success" / 2402 "voucher-error" / 2403 "enroll-success" / 2404 "enroll-error" / 2405 "connect-success" / 2406 "connect-error", 2407 ?"reason" : text, 2408 ?"reason-context" : { $$arbitrary-map } 2409 } 2410 <CODE ENDS> 2412 Figure 21: CDDL for pledge-status response 2414 Different cases for pledge bootstrapping status may occur, which 2415 SHOULD be reflected using the status enumeration. This document 2416 specifies the status values in the context of the bootstrapping 2417 process and credential application. Other documents may enhance the 2418 above enumeration to reflect further status information. 2420 The pledge-status response message is signed with IDevID or LDevID, 2421 depending on bootstrapping state of the pledge. I think earlier in the text in this section you said only LDevID. There is also the question as to whether or not th pledge wants to divulge the status to anybody. I remember that even as much as 5 years ago we had to limit LLDP information from network devices to prohibit unauthenticated status visibility. So it might make sense to say that pledge SHOULD by default only answer to nodes that they can authenticate (such as registrar agents), once the pledge is enrolled with CA certificates and matching domain certificate. n 2423 * "factory-default": Pledge has not been bootstrapped. Additional 2424 information may be provided in the reason or reason-context. The 2425 pledge signs the response message using its IDevID(Pledge). 2427 * "voucher-success": Pledge processed the voucher exchange 2428 successfully. Additional information may be provided in the 2429 reason or reason-context. The pledge signs the response message 2430 using its IDevID(Pledge). 2432 * "voucher-error": Pledge voucher processing terminated with error. 2433 Additional information may be provided in the reason or reason- 2434 context. The pledge signs the response message using its 2435 IDevID(Pledge). 2437 * "enroll-success": Pledge has processed the enrollment exchange 2438 successfully. Additional information may be provided in the 2439 reason or reason-context. The pledge signs the response message 2440 using its LDevID(Pledge). 2442 * "enroll-error": Pledge enrollment response processing terminated 2443 with error. Additional information may be provided in the reason 2444 or reason-context. The pledge signs the response message using 2445 its IDevID(Pledge). 2447 The reason and the reason-context SHOULD contain the telemetry 2448 information as described in section Section 6.3. 2450 As the pledge is assumed to utilize the bootstrapped credential s/the bootstrapped credential/its LDevID(Pledge)/ 2451 information in communication with other peers, additional status 2452 information is provided for the connectivity to other peers, which 2453 may be helpful in analyzing potential error cases. 2455 * "connect-success": Pledge could successfully establish a 2456 connection to another peer. Additional information may be 2457 provided in the reason or reason-context. The pledge signs the 2458 response message using its LDevID(Pledge). 2460 * "connect-error": Pledge connection establishment terminated with 2461 error. Additional information may be provided in the reason or 2462 reason-context. The pledge signs the response message using its 2463 LDevID(Pledge). 2465 The pledge-status responses are cumulative in the sense that connect- 2466 success implies enroll-success, which in turn implies voucher- 2467 success. 2469 Figure 22 provides an example for the bootstrapping-status 2470 information. 2472 # The pledge "status-response" in General JWS Serialization syntax 2473 { 2474 "payload": "BASE64URL(status-response)", 2475 "signatures": [ 2476 { 2477 "protected": "BASE64URL(UTF8(JWS Protected Header))", 2478 "signature": "base64encodedvalue==" 2479 } 2480 ] 2481 } 2483 # Decoded payload "status-response" representation in JSON syntax 2484 { 2485 "version": 1, 2486 "status": "enroll-success", 2487 "reason-context": { 2488 "additional" : "JSON" s/JSON/example text/ ?? 2489 } 2490 } 2492 # Decoded "JWS Protected Header" representation in JSON syntax 2493 { 2494 "alg": "ES256", 2495 "x5c": [ 2496 "base64encodedvalue==", 2497 "base64encodedvalue==" 2498 ], 2499 "typ": "jose+json 2500 } 2502 Figure 22: Example of pledge-status response 2504 In case "factory-default" the pledge does not possess the domain 2505 certificate resp. the domain trust-anchor. It will not be able to 2506 verify the signature of the registrar-agent in the bootstrapping- 2507 status request. and.... just provide the status reply without authentication ?! new paraagraph. 2507 In cases "vouchered" and "enrolled" the pledge 2508 already possesses the domain certificate (has domain trust-anchor) 2509 and can therefore validate the signature of the registrar-agent. If 2510 validation of the JWS signature fails, the pledge SHOULD respond with 2511 the HTTP 403 Forbidden status code. Ok. great. this is what i was suggesting earlier. new paragraph. 2511 The HTTP 406 Not Acceptable 2512 status code SHOULD be used, if the Accept header in the request 2513 indicates an unknown or unsupported format. The HTTP 415 Unsupported 2514 Media Type status code SHOULD be used, if the Content-Type of the 2515 request is an unknown or unsupported format. The HTTP 400 Bad 2516 Request status code SHOULD be used, if the Accept/Content-Type 2517 headers are correct but nevertheless the status-request cannot be 2518 correctly parsed. 2520 7. Artifacts not reviewing now, because i think this moves to rfc8366bis, right ? 2522 7.1. Voucher Request Artifact 2524 The following enhancement extends the voucher-request as defined in 2525 [RFC8995] to include additional fields necessary for handling 2526 bootstrapping in the pledge-responder-mode. 2528 7.1.1. Tree Diagram 2530 The following tree diagram is mostly a duplicate of the contents of 2531 [RFC8995], with the addition of the fields agent-signed-data, 2532 registrar-proximity-certificate, and agent-signing certificate. The 2533 tree diagram is described in [RFC8340]. Each node in the diagram is 2534 fully described by the YANG module in Section Section 7.1.2. 2536 module: ietf-voucher-request-prm 2538 grouping voucher-request-prm-grouping 2539 +-- voucher 2540 +-- created-on? yang:date-and-time 2541 +-- expires-on? yang:date-and-time 2542 +-- assertion? enumeration 2543 +-- serial-number string 2544 +-- idevid-issuer? binary 2545 +-- pinned-domain-cert? binary 2546 +-- domain-cert-revocation-checks? boolean 2547 +-- nonce? binary 2548 +-- last-renewal-date? yang:date-and-time 2549 +-- prior-signed-voucher-request? binary 2550 +-- proximity-registrar-cert? binary 2551 +-- agent-signed-data? binary 2552 +-- agent-provided-proximity-registrar-cert? binary 2553 +-- agent-sign-cert? binary 2555 7.1.2. YANG Module 2557 The following YANG module extends the [RFC8995] Voucher Request to 2558 include a signed artifact from the registrar-agent (agent-signed- 2559 data) as well as the registrar-proximity-certificate and the agent- 2560 signing certificate. 2562 <CODE BEGINS> file "ietf-voucher-request-...@2022-07-05.yang" 2563 module ietf-voucher-request-prm { 2564 yang-version 1.1; 2566 namespace "urn:ietf:params:xml:ns:yang:ietf-voucher-request-prm"; 2567 prefix vrprm; 2568 import ietf-restconf { 2569 prefix rc; 2570 description 2571 "This import statement is only present to access 2572 the yang-data extension defined in RFC 8040."; 2573 reference "RFC 8040: RESTCONF Protocol"; 2574 } 2576 import ietf-voucher-request { 2577 prefix vcr; 2578 description 2579 "This module defines the format for a voucher request, 2580 which is produced by a pledge as part of the RFC8995 2581 onboarding process."; 2582 reference 2583 "RFC 8995: Bootstrapping Remote Secure Key Infrastructure"; 2584 } 2586 organization 2587 "IETF ANIMA Working Group"; 2589 contact 2590 "WG Web: <http://tools.ietf.org/wg/anima/> 2591 WG List: <mailto:anima@ietf.org> 2592 Author: Steffen Fries 2593 <mailto:steffen.fr...@siemens.com> 2594 Author: Eliot Lear 2595 <mailto: l...@cisco.com> 2596 Author: Thomas Werner 2597 <mailto: thomas-wer...@siemens.com> 2598 Author: Michael Richardson 2599 <mailto: mcr+i...@sandelman.ca>"; 2601 description 2602 "This module defines the format for a voucher-request form the 2603 pledge in responder mode. It bases on the voucher-request 2604 defined in RFC 8995, which is a superset of the voucher itself. 2605 It provides content to the MASA for consideration 2606 during a voucher-request. 2608 The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL 2609 NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'NOT RECOMMENDED', 2610 'MAY', and 'OPTIONAL' in this document are to be interpreted as 2611 described in BCP 14 (RFC 2119) (RFC 8174) when, and only when, 2612 they appear in all capitals, as shown here. 2614 Copyright (c) 2021 IETF Trust and the persons identified as 2615 authors of the code. All rights reserved. 2617 Redistribution and use in source and binary forms, with or 2618 without modification, is permitted pursuant to, and subject 2619 to the license terms contained in, the Simplified BSD License 2620 set forth in Section 4.c of the IETF Trust's Legal Provisions 2621 Relating to IETF Documents 2622 (https://trustee.ietf.org/license-info). 2624 This version of this YANG module is part of RFC xxxx; see the 2625 RFC itself for full legal notices."; 2627 revision 2022-07-05 { 2628 description 2629 "Initial version"; 2630 reference 2631 "RFC XXXX: BRSKI for Pledge in Responder Mode"; 2632 } 2634 // Top-level statement 2635 rc:yang-data voucher-request-prm-artifact { 2636 // YANG data template for a voucher-request. 2637 uses voucher-request-prm-grouping; 2638 } 2639 // Grouping defined for future usage 2640 grouping voucher-request-prm-grouping { 2641 description 2642 "Grouping to allow reuse/extensions in future work."; 2643 uses vcr:voucher-request-grouping { 2645 augment voucher { 2646 description "Base the voucher-request-prm upon the 2647 regular one"; 2649 leaf agent-signed-data { 2650 type binary; 2651 description 2652 "The agent-signed-data field contains a JOSE [RFC7515] 2653 object provided by the Registrar-Agent to the Pledge. 2655 This artifact is signed by the Registrar-Agent 2656 and contains a copy of the pledge's serial-number."; 2657 } 2659 leaf agent-provided-proximity-registrar-cert { 2660 type binary; 2661 description 2662 "An X.509 v3 certificate structure, as specified by 2663 RFC 5280, Section 4, encoded using the ASN.1 2664 distinguished encoding rules (DER), as specified 2665 in ITU X.690. 2666 The first certificate in the registrar TLS server 2667 certificate_list sequence (the end-entity TLS 2668 certificate; see RFC 8446) presented by the 2669 registrar to the registrar-agent and provided to 2670 the pledge. 2671 This MUST be populated in a pledge's voucher-request 2672 when an agent-proximity assertion is requested."; 2673 reference 2674 "ITU X.690: Information Technology - ASN.1 encoding 2675 rules: Specification of Basic Encoding Rules (BER), 2676 Canonical Encoding Rules (CER) and Distinguished 2677 Encoding Rules (DER) 2678 RFC 5280: Internet X.509 Public Key Infrastructure 2679 Certificate and Certificate Revocation List (CRL) 2680 Profile 2681 RFC 8446: The Transport Layer Security (TLS) 2682 Protocol Version 1.3"; 2683 } 2685 leaf-list agent-sign-cert{ 2686 type binary; 2687 min-elements 1; 2688 description 2689 "An X.509 v3 certificate structure, as specified by 2690 RFC 5280, Section 4, encoded using the ASN.1 2691 distinguished encoding rules (DER), as specified 2692 in ITU X.690. 2693 This certificate can be used by the pledge, 2694 the registrar, and the MASA to verify the signature 2695 of agent-signed-data. It is an optional component 2696 for the pledge-voucher request. 2697 This MUST be populated in a registrar's 2698 voucher-request when an agent-proximity assertion 2699 is requested. 2700 It is defined as list to enable inclusion of further 2701 certificates along the certificate chain if different 2702 issuing CAs have been used for the registrar-agent 2703 and the registrar."; 2704 reference 2705 "ITU X.690: Information Technology - ASN.1 encoding 2706 rules: Specification of Basic Encoding Rules (BER), 2707 Canonical Encoding Rules (CER) and Distinguished 2708 Encoding Rules (DER) 2709 RFC 5280: Internet X.509 Public Key Infrastructure 2710 Certificate and Certificate Revocation List (CRL) 2711 Profile"; 2713 } 2714 } 2715 } 2716 } 2717 } 2718 <CODE ENDS> 2720 Examples for the PVR are provided in Section 6.2. 2722 8. IANA Considerations 2724 This document requires the following IANA actions. 2726 8.1. BRSKI .well-known Registry 2728 IANA is requested to enhance the Registry entitled: "BRSKI Well-Known 2729 URIs" with the following endpoints: 2731 URI Description Reference 2732 tv create pledge-voucher-request [THISRFC] 2733 te create pledge-enrollment-request [THISRFC] 2734 sv supply voucher response [THISRFC] 2735 se supply enrollment response [THISRFC] 2736 cc supply CA certificates to pledge [THISRFC] 2737 ps query pledge status [THISRFC] 2738 requestenroll supply PER to registrar [THISRFC] 2739 wrappedcacerts request wrapped CA certificates [THISRFC] 2741 9. Privacy Considerations 2743 In general, the privacy considerations of [RFC8995] apply for BRSKI- 2744 PRM also. Further privacy aspects need to be considered for: 2746 * the introduction of the additional component registrar-agent 2748 * no transport layer security between registrar-agent and pledge 2750 The credential used by the registrar-agent to sign the data for the 2751 pledge should not contain any personal information. Therefore, it is 2752 recommended to use an LDevID certificate associated with the 2753 commissioning device instead of an LDevID certificate associated with 2754 the service technician operating the device. This avoids revealing 2755 potentially included personal information to Registrar and MASA. Nice. I'd even try to go for SHOULD NOT (not quite clear with this couldn't be normative, but someone from IESG review should complain if its not ok.). 2757 The communication between the pledge and the registrar-agent is 2758 performed over plain HTTP. Therefore, it is subject to disclosure by 2759 a Dolev-Yao attacker (an "oppressive observer")[onpath]. Depending 2760 on the requests and responses, the following information is 2761 disclosed. This of course raises the question why we're not using https between pledge and registrar-agent to prohibit such mitm obervation (beyond other good reasons to use https that i brought up in my first part of the review). Remember that the registrar can always authenticate the IDevID of pledges, so arguably the pledge vendors trust anchors can also be provisionined onto registrar-agents (not more difficult than the serial numbers that you assume to be provisionalbe - which i find much more difficult), and the pledge simply does not even need to do any registrar-agent certificate verification, but solely because of TLS PFS, this one-side verification should suffice to prohibit passive observation. 2763 * the Pledge product-serial-number is contained in the trigger 2764 message for the PVR and in all responses from the pledge. This 2765 information reveals the identity of the devices being bootstrapped 2766 and allows deduction of which products an operator is using in 2767 their environment. As the communication between the pledge and 2768 the registrar-agent may be realized over wireless link, this 2769 information could easily be eavesdropped, if the wireless network 2770 is unencrypted. Even if the wireless network is encrypted, if it 2771 uses a network-wide key, then layer-2 attacks (ARP/ND spoofing) 2772 could insert an on-path observer into the path. 2774 * the Timestamp data could reveal the activation time of the device. 2776 * the Status data of the device could reveal information about the 2777 current state of the device in the domain network. I'll comment on whether this is complete after we have (hopefully not) concluded that we cannot/should-not use http. 2779 10. Security Considerations 2781 In general, the security considerations of [RFC8995] apply for BRSKI- 2782 PRM also. Further security aspects are considered here related to: 2784 * the introduction of the additional component registrar-agent 2786 * the reversal of the pledge communication direction (push mode, 2787 compared to BRSKI) 2789 * no transport layer security between registrar-agent and pledge 2791 10.1. Denial of Service (DoS) Attack on Pledge 2793 Disrupting the pledge behavior by a DoS attack may prevent the 2794 bootstrapping of the pledge to a new domain. 2796 A DoS attack with a faked registrar-agent may block the bootstrapping 2797 of the pledge due to state creation on the pledge (the pledge may 2798 produce a voucher-request, and refuse to produce another one). One 2799 mitigation may be that the pledge does does not limited the number of 2800 voucher requests it creates until at least one has finished, or a 2801 single onboarding state may expire after a certain time. The way i remember, the nonce is really only meant to protect against replay attack from e.g. a prior owner: Owner generates voucher, then sells box, new owner takes ownership with new voucher, then sneaky prior owner re-owns pledge (after some partial reset) with prior voucher and then gains access to some not-fully reset information about the second owner on the pledge. The way to protect against this is IMHO to simply not issue new nonce values for every voucher request thats is triggered, but only to generate a new nonce after the pledge is presented with a successful voucher for the prior nonce. and remember the prior nonce value as "do-not-reuse". For example by having a persistent (e.g.: TPM based) RNG for the nonce. Thats just one more persistent number to remember. Maybe write something like that. 2803 10.2. Misuse of acquired PVR and PER by Registrar-Agent 2805 A registrar-agent that uses previously requested PVR and PER for 2806 domain-A, may attempt to onboard the device into domain-B. This can 2807 be detected by the domain registrar while PVR processing. The domain 2808 registrar needs to verify that the "proximity-registrar-cert" field 2809 in the PVR matches its own registrar EE certificate. In addition, 2810 the domain registrar needs to verify the association of the pledge to 2811 its domain based on the product-serial-number contained in the PVR 2812 and in the IDevID certificate of the pledge. (This is just part of 2813 the supply chain integration) Moreover, the domain registrar verifies 2814 if the registrar-agent is authorized to interact with the pledge for 2815 voucher-requests and enroll-requests, based on the LDevID(RegAgt) 2816 certificate data contained in the PVR. 2818 Misbinding of a pledge by a faked domain registrar is countered as 2819 described in BRSKI security considerations [RFC8995] (section 11.4). 2821 10.3. Misuse of Registrar-Agent Credentials 2823 Concerns of misusage of a registrar-agent with a valid 2824 LDevID(RegAgt), may be addressed by utilizing short-lived 2825 certificates (e.g., valid for a day) to authenticate the registrar- 2826 agent against the domain registrar. The LDevID(RegAgt) certificate 2827 may be acquired by a prior BRSKI run for the registrar-agent, if an 2828 IDevID is available on registrar-agent. Alternatively, the LDevID 2829 may be acquired by a service technician from the domain PKI system in 2830 an authenticated way. These problems would be eliminated with the LDevID of the registrar-agent would as i suggested in part 1 of my review only be used for tracing on or behind the registrar which registrar-agent was forwarding messages, but not making any actual enrolment security decisions based on it. Which i tried to outline how. 2832 In addition it is required that the LDevID(RegAgt) certificate is 2833 valid for the complete bootstrapping phase. This avoids that a 2834 registrar-agent could be misused to create arbitrary "agent-signed- 2835 data" objects to perform an authorized bootstrapping of a rogue 2836 pledge at a later point in time. In this misuse "agent-signed-data" 2837 could be dated after the validity time of the LDevID(RegAgt) 2838 certificate, due to missing trusted timestamp in the registrar-agents 2839 signature. To address this, the registrar SHOULD verify the 2840 certificate used to create the signature on "agent-signed-data". 2841 Furthermore the registrar also verifies the LDevID(RegAgt) 2842 certificate used in the TLS handshake with the registrar-agent. If 2843 both certificates are verified successfully, the registrar-agent's 2844 signature can be considered as valid. Same. 2846 10.4. Misuse of mDNS to obtain list of pledges 2848 To discover a specific pledge a registrar-agent may request the 2849 service name in combination with the product-serial-number of a 2850 specific pledge. The pledge reacts on this if its product-serial- 2851 number is part of the request message. 2853 If the registrar-agent performs DNS-based Service Discovery without a 2854 specific product-serial-number, all pledges in the domain react if 2855 the functionality is supported. This functionality enumerates and 2856 reveals the information of devices available in the domain. The 2857 information about this is provided here as a feature to support the 2858 commissioning of devices. A manufacturer may decide to support this 2859 feature only for devices not possessing a LDevID or to not support 2860 this feature at all, to avoid an enumeration in an operative domain. 2862 10.5. YANG Module Security Considerations 2864 The enhanced voucher-request described in section Section 7.1 is 2865 bases on [RFC8995], but uses a different encoding based on 2866 [I-D.ietf-anima-jws-voucher]. Therefore similar considerations as 2867 described in [RFC8995] section 11.7 (Security Considerations) apply. 2868 The YANG module specified in this document defines the schema for 2869 data that is subsequently encapsulated by a JOSE signed-data Content- 2870 type as described in [I-D.ietf-anima-jws-voucher]. As such, all of 2871 the YANG-modeled data is protected against modification. The use of 2872 YANG to define data structures via the "yang-data" statement, is 2873 relatively new and distinct from the traditional use of YANG to 2874 define an API accessed by network management protocols such as 2875 NETCONF [RFC6241] and RESTCONF [RFC8040]. For this reason these 2876 guidelines do not follow the template described by [RFC8407] section 2877 3.7 (Security Considerations Section). 2879 11. Acknowledgments 2881 We would like to thank the various reviewers, in particular Brian E. 2882 Carpenter, Oskar Camenzind, Hendrik Brockhaus, and Ingo Wenda for 2883 their input and discussion on use cases and call flows. Further 2884 review input was provided by Jesser Bouzid, Dominik Tacke, and 2885 Christian Spindler. Special thanks to Esko Dijk for the in deep 2886 review and the improving proposals. Support in PoC implementations 2887 and comments resulting from the implementation was provided by Hong 2888 Rui Li and He Peng Jia. I'll stop here. Thanks a lot folks. Lot of good work, and a lot more security relevant changes to BRSKI than the constrained work IMHO so don't be too annoyed by the due diligence this requires. Cheers Toerless 2890 12. References 2892 12.1. Normative References 2894 [I-D.ietf-anima-jws-voucher] 2895 Werner, T. and M. Richardson, "JWS signed Voucher 2896 Artifacts for Bootstrapping Protocols", Work in Progress, 2897 Internet-Draft, draft-ietf-anima-jws-voucher-05, 24 2898 October 2022, <https://www.ietf.org/archive/id/draft-ietf- 2899 anima-jws-voucher-05.txt>. 2901 [I-D.ietf-anima-rfc8366bis] 2902 Watsen, K., Richardson, M., Pritikin, M., Eckert, T. T., 2903 and Q. Ma, "A Voucher Artifact for Bootstrapping 2904 Protocols", Work in Progress, Internet-Draft, draft-ietf- 2905 anima-rfc8366bis-00, 31 January 2022, 2906 <https://www.ietf.org/archive/id/draft-ietf-anima- 2907 rfc8366bis-00.txt>. 2909 [I-D.ietf-netconf-sztp-csr] 2910 Watsen, K., Housley, R., and S. Turner, "Conveying a 2911 Certificate Signing Request (CSR) in a Secure Zero Touch 2912 Provisioning (SZTP) Bootstrapping Request", Work in 2913 Progress, Internet-Draft, draft-ietf-netconf-sztp-csr-14, 2914 2 March 2022, <https://www.ietf.org/archive/id/draft-ietf- 2915 netconf-sztp-csr-14.txt>. 2917 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2918 Requirement Levels", BCP 14, RFC 2119, 2919 DOI 10.17487/RFC2119, March 1997, 2920 <https://www.rfc-editor.org/info/rfc2119>. 2922 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 2923 Housley, R., and W. Polk, "Internet X.509 Public Key 2924 Infrastructure Certificate and Certificate Revocation List 2925 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, 2926 <https://www.rfc-editor.org/info/rfc5280>. 2928 [RFC6762] Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762, 2929 DOI 10.17487/RFC6762, February 2013, 2930 <https://www.rfc-editor.org/info/rfc6762>. 2932 [RFC6763] Cheshire, S. and M. Krochmal, "DNS-Based Service 2933 Discovery", RFC 6763, DOI 10.17487/RFC6763, February 2013, 2934 <https://www.rfc-editor.org/info/rfc6763>. 2936 [RFC7030] Pritikin, M., Ed., Yee, P., Ed., and D. Harkins, Ed., 2937 "Enrollment over Secure Transport", RFC 7030, 2938 DOI 10.17487/RFC7030, October 2013, 2939 <https://www.rfc-editor.org/info/rfc7030>. 2941 [RFC7515] Jones, M., Bradley, J., and N. Sakimura, "JSON Web 2942 Signature (JWS)", RFC 7515, DOI 10.17487/RFC7515, May 2943 2015, <https://www.rfc-editor.org/info/rfc7515>. 2945 [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF 2946 Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, 2947 <https://www.rfc-editor.org/info/rfc8040>. 2949 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2950 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2951 May 2017, <https://www.rfc-editor.org/info/rfc8174>. 2953 [RFC8366] Watsen, K., Richardson, M., Pritikin, M., and T. Eckert, 2954 "A Voucher Artifact for Bootstrapping Protocols", 2955 RFC 8366, DOI 10.17487/RFC8366, May 2018, 2956 <https://www.rfc-editor.org/info/rfc8366>. 2958 [RFC8610] Birkholz, H., Vigano, C., and C. Bormann, "Concise Data 2959 Definition Language (CDDL): A Notational Convention to 2960 Express Concise Binary Object Representation (CBOR) and 2961 JSON Data Structures", RFC 8610, DOI 10.17487/RFC8610, 2962 June 2019, <https://www.rfc-editor.org/info/rfc8610>. 2964 [RFC8995] Pritikin, M., Richardson, M., Eckert, T., Behringer, M., 2965 and K. Watsen, "Bootstrapping Remote Secure Key 2966 Infrastructure (BRSKI)", RFC 8995, DOI 10.17487/RFC8995, 2967 May 2021, <https://www.rfc-editor.org/info/rfc8995>. 2969 12.2. Informative References 2971 [BRSKI-PRM-abstract] 2972 "Abstract BRSKI-PRM Protocol Overview", April 2022, 2973 <https://raw.githubusercontent.com/anima-wg/anima-brski- 2974 prm/main/pics/brski_prm_overview.png>. 2976 [I-D.ietf-anima-brski-ae] 2977 von Oheimb, D., Fries, S., and H. Brockhaus, "BRSKI-AE: 2978 Alternative Enrollment Protocols in BRSKI", Work in 2979 Progress, Internet-Draft, draft-ietf-anima-brski-ae-03, 24 2980 October 2022, <https://www.ietf.org/archive/id/draft-ietf- 2981 anima-brski-ae-03.txt>. 2983 [IEEE-802.1AR] 2984 Institute of Electrical and Electronics Engineers, "IEEE 2985 802.1AR Secure Device Identifier", IEEE 802.1AR, June 2986 2018. 2988 [onpath] "can an on-path attacker drop traffic?", n.d., 2989 <https://mailarchive.ietf.org/arch/msg/saag/ 2990 m1r9uo4xYznOcf85Eyk0Rhut598/>. 2992 [RFC2986] Nystrom, M. and B. Kaliski, "PKCS #10: Certification 2993 Request Syntax Specification Version 1.7", RFC 2986, 2994 DOI 10.17487/RFC2986, November 2000, 2995 <https://www.rfc-editor.org/info/rfc2986>. 2997 [RFC6125] Saint-Andre, P. and J. Hodges, "Representation and 2998 Verification of Domain-Based Application Service Identity 2999 within Internet Public Key Infrastructure Using X.509 3000 (PKIX) Certificates in the Context of Transport Layer 3001 Security (TLS)", RFC 6125, DOI 10.17487/RFC6125, March 3002 2011, <https://www.rfc-editor.org/info/rfc6125>. 3004 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 3005 and A. Bierman, Ed., "Network Configuration Protocol 3006 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 3007 <https://www.rfc-editor.org/info/rfc6241>. 3009 [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained 3010 Application Protocol (CoAP)", RFC 7252, 3011 DOI 10.17487/RFC7252, June 2014, 3012 <https://www.rfc-editor.org/info/rfc7252>. 3014 [RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams", 3015 BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018, 3016 <https://www.rfc-editor.org/info/rfc8340>. 3018 [RFC8407] Bierman, A., "Guidelines for Authors and Reviewers of 3019 Documents Containing YANG Data Models", BCP 216, RFC 8407, 3020 DOI 10.17487/RFC8407, October 2018, 3021 <https://www.rfc-editor.org/info/rfc8407>. 3023 [RFC8792] Watsen, K., Auerswald, E., Farrel, A., and Q. Wu, 3024 "Handling Long Lines in Content of Internet-Drafts and 3025 RFCs", RFC 8792, DOI 10.17487/RFC8792, June 2020, 3026 <https://www.rfc-editor.org/info/rfc8792>. 3028 [RFC9052] Schaad, J., "CBOR Object Signing and Encryption (COSE): 3029 Structures and Process", STD 96, RFC 9052, 3030 DOI 10.17487/RFC9052, August 2022, 3031 <https://www.rfc-editor.org/info/rfc9052>. 3033 [RFC9053] Schaad, J., "CBOR Object Signing and Encryption (COSE): 3034 Initial Algorithms", RFC 9053, DOI 10.17487/RFC9053, 3035 August 2022, <https://www.rfc-editor.org/info/rfc9053>. 3037 [RFC9110] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, 3038 Ed., "HTTP Semantics", STD 97, RFC 9110, 3039 DOI 10.17487/RFC9110, June 2022, 3040 <https://www.rfc-editor.org/info/rfc9110>. 3042 [RFC9238] Richardson, M., Latour, J., and H. Habibi Gharakheili, 3043 "Loading Manufacturer Usage Description (MUD) URLs from QR 3044 Codes", RFC 9238, DOI 10.17487/RFC9238, May 2022, 3045 <https://www.rfc-editor.org/info/rfc9238>. 3047 Appendix A. Examples 3049 These examples are folded according to [RFC8792] Single Backslash 3050 rule. 3052 A.1. Example Pledge Voucher Request - PVR (from Pledge to Registrar- 3053 agent) 3055 The following is an example request sent from a Pledge to the 3056 Registrar-agent, in "General JWS JSON Serialization". 3057 The message size of this PVR is: 4649 bytes 3059 =============== NOTE: '\' line wrapping per RFC 8792 ================ 3061 { 3062 "payload": 3063 "eyJpZXRmLXZvdWNoZXItcmVxdWVzdC1wcm06dm91Y2hlciI6eyJhc3NlcnRpb24\ 3064 iOiJhZ2VudC1wcm94aW1pdHkiLCJzZXJpYWwtbnVtYmVyIjoiMDEyMzQ1Njc4OSIsIm5\ 3065 vbmNlIjoiTDNJSjZocHRIQ0lRb054YWFiOUhXQT09IiwiY3JlYXRlZC1vbiI6IjIwMjI\ 3066 tMDQtMjZUMDU6MTY6MTcuNzA5WiIsImFnZW50LXByb3ZpZGVkLXByb3hpbWl0eS1yZWd\ 3067 pc3RyYXItY2VydCI6Ik1JSUI0akNDQVlpZ0F3SUJBZ0lHQVhZNzJiYlpNQW9HQ0NxR1N\ 3068 NNDlCQU1DTURVeEV6QVJCZ05WQkFvTUNrMTVRblZ6YVc1bGMzTXhEVEFMQmdOVkJBY01\ 3069 CRk5wZEdVeER6QU5CZ05WQkFNTUJsUmxjM1JEUVRBZUZ3MHlNREV5TURjd05qRTRNVEp\ 3070 hRncwek1ERXlNRGN3TmpFNE1USmFNRDR4RXpBUkJnTlZCQW9NQ2sxNVFuVnphVzVsYzN\ 3071 NeERUQUxCZ05WQkFjTUJGTnBkR1V4R0RBV0JnTlZCQU1NRDBSdmJXRnBibEpsWjJsemR\ 3072 ISmhjakJaTUJNR0J5cUdTTTQ5QWdFR0NDcUdTTTQ5QXdFSEEwSUFCQmsxNksvaTc5b1J\ 3073 rSzVZYmVQZzhVU1I4L3VzMWRQVWlaSE10b2tTZHFLVzVmbldzQmQrcVJMN1dSZmZlV2t\ 3074 5Z2Vib0pmSWxsdXJjaTI1d25oaU9WQ0dqZXpCNU1CMEdBMVVkSlFRV01CUUdDQ3NHQVF\ 3075 VRkJ3TUJCZ2dyQmdFRkJRY0RIREFPQmdOVkhROEJBZjhFQkFNQ0I0QXdTQVlEVlIwUkJ\ 3076 FRXdQNElkY21WbmFYTjBjbUZ5TFhSbGMzUXVjMmxsYldWdWN5MWlkQzV1WlhTQ0huSmx\ 3077 aMmx6ZEhKaGNpMTBaWE4wTmk1emFXVnRaVzV6TFdKMExtNWxkREFLQmdncWhrak9QUVF\ 3078 EQWdOSUFEQkZBaUJ4bGRCaFpxMEV2NUpMMlByV0N0eVM2aERZVzF5Q08vUmF1YnBDN01\ 3079 hSURnSWhBTFNKYmdMbmdoYmJBZzBkY1dGVVZvL2dHTjAvand6SlowU2wyaDR4SVhrMSI\ 3080 sImFnZW50LXNpZ25lZC1kYXRhIjoiZXlKd1lYbHNiMkZrSWpvaVpYbEtjRnBZVW0xTVd\ 3081 GcDJaRmRPYjFwWVNYUmpiVlo0WkZkV2VtUkRNWGRqYlRBMldWZGtiR0p1VVhSak1teHV\ 3082 ZbTFXYTB4WFVtaGtSMFZwVDI1emFWa3pTbXhaV0ZKc1drTXhkbUpwU1RaSmFrbDNUV3B\ 3083 KZEUxRVVYUk5hbHBWVFVSVk5rMUVZelpPUkVWMVRrUlJORmRwU1hOSmJrNXNZMjFzYUd\ 3084 KRE1YVmtWekZwV2xoSmFVOXBTWGROVkVsNlRrUlZNazU2WnpWSmJqRTVJaXdpYzJsbmJ\ 3085 tRjBkWEpsY3lJNlczc2ljSEp2ZEdWamRHVmtJam9pWlhsS2NtRlhVV2xQYVVwWlkwaHd\ 3086 jMVJWZERSaVNFSkNUbXBvYWxaVVZrZFZWVEZaVmxoYWRWTldVVEpWV0dNNVNXbDNhVmx\ 3087 YZUc1SmFtOXBVbFpOZVU1VVdXbG1VU0lzSW5OcFoyNWhkSFZ5WlNJNklrY3pWM2hHU0d\ 3088 WMFdGQTRiR3hTVmkwNWRXSnlURmxxU25aUllUWmZlUzFRYWxGWk5FNWhkMW81Y0ZKaGI\ 3089 yeE9TbTlFTm1SbFpXdHVTVjlGV0daemVWWlRZbmM0VTBONlRWcE1iakJoUVhWb2FVZFp\ 3090 UakJSSW4xZGZRPT0iLCJhZ2VudC1zaWduLWNlcnQiOlsiTUlJQjFEQ0NBWHFnQXdJQkF\ 3091 nSUVZbWQ0T1RBS0JnZ3Foa2pPUFFRREFqQStNUk13RVFZRFZRUUtEQXBOZVVKMWMybHV\ 3092 aWE56TVEwd0N3WURWUVFIREFSVGFYUmxNUmd3RmdZRFZRUUREQTlVWlhOMFVIVnphRTF\ 3093 2WkdWc1EwRXdIaGNOTWpJd05ESTJNRFEwTWpNeldoY05Nekl3TkRJMk1EUTBNak16V2p\ 3094 BOU1STXdFUVlEVlFRS0RBcE5lVUoxYzJsdVpYTnpNUTB3Q3dZRFZRUUhEQVJUYVhSbE1\ 3095 SY3dGUVlEVlFRRERBNVNaV2RwYzNSeVlYSkJaMlZ1ZERCWk1CTUdCeXFHU000OUFnRUd\ 3096 DQ3FHU000OUF3RUhBMElBQkd4bHJOZmozaVJiNy9CUW9kVys1WWlvT3poK2pJdHlxdVJ\ 3097 JTy9XejdZb1czaXdEYzNGeGV3TFZmekNyNU52RDEzWmFGYjdmcmFuK3Q5b3RZNVdMaEo\ 3098 2alp6QmxNQTRHQTFVZER3RUIvd1FFQXdJSGdEQWZCZ05WSFNNRUdEQVdnQlJ2b1QxdWR\ 3099 lMmY2TEVRaFU3SEhqK3ZKL2Q3SXpBZEJnTlZIUTRFRmdRVVhwemxNS3hscEE2OGNVNUZ\ 3100 RTVhVdm5JVDZRd3dFd1lEVlIwbEJBd3dDZ1lJS3dZQkJRVUhBd0l3Q2dZSUtvWkl6ajB\ 3101 FQXdJRFNBQXdSUUlnYzJ5NnhvT3RvUUJsSnNnbE9MMVZ4SEdvc1R5cEVxUmZ6MFF2NFp\ 3102 FUHY0d0NJUUNWeWIyRjl6VjNuOTUrb2xnZkZKZ1pUV0V6NGRTYUYzaHpSUWIzWnVCMjl\ 3103 RPT0iLCJNSUlCekRDQ0FYR2dBd0lCQWdJRVhYakhwREFLQmdncWhrak9QUVFEQWpBMU1\ 3104 STXdFUVlEVlFRS0RBcE5lVUoxYzJsdVpYTnpNUTB3Q3dZRFZRUUhEQVJUYVhSbE1ROHd\ 3105 EUVlEVlFRRERBWlVaWE4wUTBFd0hoY05NVGt3T1RFeE1UQXdPRE0yV2hjTk1qa3dPVEV\ 3106 4TVRBd09ETTJXakErTVJNd0VRWURWUVFLREFwTmVVSjFjMmx1WlhOek1RMHdDd1lEVlF\ 3107 RSERBUlRhWFJsTVJnd0ZnWURWUVFEREE5VVpYTjBVSFZ6YUUxdlpHVnNRMEV3V1RBVEJ\ 3108 nY3Foa2pPUFFJQkJnZ3Foa2pPUFFNQkJ3TkNBQVRsRzBmd1QzM29leloxdmtIUWJldGV\ 3109 ibWorQm9WK1pGc2pjZlF3MlRPa0pQaE9rT2ZBYnU5YlMxcVppOHlhRVY4b2VyS2wvNlp\ 3110 YYmZ4T21CanJScmNYbzJZd1pEQVNCZ05WSFJNQkFmOEVDREFHQVFIL0FnRUFNQTRHQTF\ 3111 VZER3RUIvd1FFQXdJQ0JEQWZCZ05WSFNNRUdEQVdnQlRvWklNelFkc0Qvai8rZ1gvN2N\ 3112 CSnVjSC9YbWpBZEJnTlZIUTRFRmdRVWI2RTliblh0bitpeEVJVk94eDQvcnlmM2V5TXd\ 3113 DZ1lJS29aSXpqMEVBd0lEU1FBd1JnSWhBUG5CMHcxTkN1cmhNeEp3d2ZqejdnRGlpeGt\ 3114 VWUxQU1o5ZU45a29oTlFVakFpRUF3NFk3bHR4V2lQd0t0MUo5bmp5ZkRObDVNdUVEQml\ 3115 teFIzQ1hvWktHUXJVPSJdfX0", 3116 "signatures":[{ 3117 "protected":"eyJ4NWMiOlsiTUlJQitUQ0NBYUNnQXdJQkFnSUdBWG5WanNVN\ 3118 U1Bb0dDQ3FHU000OUJBTUNNRDB4Q3pBSkJnTlZCQVlUQWtGUk1SVXdFd1lEVlFRS0RBe\ 3119 EthVzVuU21sdVowTnZjbkF4RnpBVkJnTlZCQU1NRGtwcGJtZEthVzVuVkdWemRFTkJNQ\ 3120 0FYRFRJeE1EWXdOREExTkRZeE5Gb1lEems1T1RreE1qTXhNak0xT1RVNVdqQlNNUXN3Q\ 3121 1FZRFZRUUdFd0pCVVRFVk1CTUdBMVVFQ2d3TVNtbHVaMHBwYm1kRGIzSndNUk13RVFZR\ 3122 FZRUUZFd293TVRJek5EVTJOemc1TVJjd0ZRWURWUVFEREE1S2FXNW5TbWx1WjBSbGRtb\ 3123 GpaVEJaTUJNR0J5cUdTTTQ5QWdFR0NDcUdTTTQ5QXdFSEEwSUFCQzc5bGlhUmNCalpjR\ 3124 UVYdzdyVWVhdnRHSkF1SDRwazRJNDJ2YUJNc1UxMWlMRENDTGtWaHRVVjIxbXZhS0N2T\ 3125 XgyWStTTWdROGZmd0wyM3ozVElWQldqZFRCek1Dc0dDQ3NHQVFVRkJ3RWdCQjhXSFcxa\ 3126 GMyRXRkR1Z6ZEM1emFXVnRaVzV6TFdKMExtNWxkRG81TkRRek1COEdBMVVkSXdRWU1CY\ 3127 UFGRlFMak56UFwvU1wva291alF3amc1RTVmdndjWWJNQk1HQTFVZEpRUU1NQW9HQ0NzR\ 3128 0FRVUZCd01DTUE0R0ExVWREd0VCXC93UUVBd0lIZ0RBS0JnZ3Foa2pPUFFRREFnTkhBR\ 3129 EJFQWlCdTN3UkJMc0pNUDVzTTA3MEgrVUZyeU5VNmdLekxPUmNGeVJST2xxcUhpZ0lnW\ 3130 ENtSkxUekVsdkQycG9LNmR4NmwxXC91eW1UbmJRRERmSmxhdHVYMlJvT0U9Il0sImFsZ\ 3131 yI6IkVTMjU2In0", 3132 "signature":"Y_ohapnmvbwjLuUicOB7NAmbGM7igBfpUlkKUuSNdG-eDI4BQ\ 3134 yuXZ2aw93zZId45R7XxAK-12YKIx6qLjiPjMw" 3135 }] 3136 } 3138 Figure 23: Example Pledge Voucher Request - PVR 3140 A.2. Example Parboiled Registrar Voucher Request - RVR (from Registrar 3141 to MASA) 3143 The term parboiled refers to food which is partially cooked. In 3144 [RFC8995], the term refers to a Pledge voucher-request (PVR) which 3145 has been received by the Registrar, and then has been processed by 3146 the Registrar ("cooked"), and is now being forwarded to the MASA. 3148 The following is an example Registrar voucher-request (RVR) sent from 3149 the Registrar to the MASA, in "General JWS JSON Serialization". Note 3150 that the previous PVR can be seen in the payload as "prior-signed- 3151 voucher-request". The message size of this RVR is: 13257 bytes 3153 =============== NOTE: '\' line wrapping per RFC 8792 ================ 3155 { 3156 "payload": 3157 "eyJpZXRmLXZvdWNoZXItcmVxdWVzdC1wcm06dm91Y2hlciI6eyJhc3NlcnRpb24\ 3158 iOiJhZ2VudC1wcm94aW1pdHkiLCJzZXJpYWwtbnVtYmVyIjoiY2FmZmUtOTg3NDUiLCJ\ 3159 ub25jZSI6ImM1VEVPb29NTE5hNEN4L1UrVExoQ3c9PSIsInByaW9yLXNpZ25lZC12b3V\ 3160 jaGVyLXJlcXVlc3QiOiJleUp3WVhsc2IyRmtJam9pWlhsS2NGcFlVbTFNV0ZwMlpGZE9\ 3161 iMXBZU1hSamJWWjRaRmRXZW1SRE1YZGpiVEEyWkcwNU1Wa3lhR3hqYVVrMlpYbEthR01\ 3162 6VG14amJsSndZakkwYVU5cFNtaGFNbFoxWkVNeGQyTnRPVFJoVnpGd1pFaHJhVXhEU25\ 3163 wYVdFcHdXVmQzZEdKdVZuUlpiVlo1U1dwdmFWa3lSbTFhYlZWMFQxUm5NMDVFVldsTVE\ 3164 wcDFZakkxYWxwVFNUWkpiVTB4VmtWV1VHSXlPVTVVUlRWb1RrVk9ORXd4VlhKV1JYaHZ\ 3165 VVE5qT1ZCVFNYTkpiVTU1V2xkR01GcFhVWFJpTWpScFQybEplVTFFU1hsTVZFRjVURlJ\ 3166 KZVZaRVFUTlBhazE2VDJwQk5FeHFSVFZPYkc5cFRFTkthRm95Vm5Wa1F6RjNZMjA1TW1\ 3167 GWFVteGFRekYzWTIwNU5HRlhNWEJrU0d0MFkyMVdibUZZVGpCamJVWjVURmRPYkdOdVV\ 3168 XbFBhVXBPVTFWc1JGSkdVa1JSTUVacFZESmtRbVF3YkVOUlYyUktVakJHV1ZkWVRuZFR\ 3169 WMVoyVkZWR2RsSXdUa1JqVldSVVZGUlJOVkZyUms1Uk1ERkhaRE5vUkdWclJrdFJiV1J\ 3170 QVm10S1FsZFdVa0poTUZwVFZGWktTbVF3VmtKWFZWSlhWVlpHVEZKRlJuTlViVlpXVkc\ 3171 1YWFWZEZTbTlaYlRWeVpVVmFWVkZXVWtOYU1EVlhVV3RHZWxSVlVrWk5WRlpXVFRGYWN\ 3172 GbDZTbk5oTWtaWVVtNXNiRlpGVmxGVVZVVjNVakJGZUZaVlZrTmtNMlJJVmtab2MxWkh\ 3173 SbGxWYlhoT1ZXdFdNMUpJWkZwU1JscFNWVlZTUlZGWGFFOWFWbHBQWTBkU1NGWnJVbEp\ 3174 XUlVac1VtNWpkMlZWTVVWU1dHeE9Va1pHTTFSdWNFcE5WVFZGWVVkR1IyUjZRalpVVlZ\ 3175 KR1pWVXhSVlZZWkU5bGEydDRWR3RTYjFsVk1VaFRXR2hFWld0R1MxRnRaRTlXYTBwQ1Y\ 3176 xWlNRbUV3V2xOVVZrcEtaREJXUWxkVlVsZFZWa1pNVWtWR2MxUnRWbFpVYmxwcFYwVkt\ 3177 iMWx0TlhKbFJWcEZVVlpPUTFvd05WZFJhMFo2VkZWTmQwMVVWbFpOTVZwd1dYcEtjMkV\ 3178 4YkZsVGFsWk9WVlJvTTFKR1JscFNSbHBTVlZWb1JWRldjRTlhVmxwUFkwZFNTRlpZYUV\ 3179 oU1JVWllVVzFrVDFaclNrSlVWVEZGVFVSRk1WWlVTbk5OUm5CWFUyMTRZVTF0ZURaYVJ\ 3180 XaExZVWRPY1ZGc2NFNVJhekZJVVc1c2VGSXhUazVPUkd4Q1dqQldTRkV3VG5oU01VNU9\ 3181 Ua1JzUW1Rd1ZrbFJWRUpLVVZWS1NsVklhRmhrVlRGSlVucG9TMVJIV2taVlJVVTFUMWh\ 3182 hZDAxdVZrbFNWVFZxVlROc2JWa3pWVE5VUjJSYVRraEJlRTVGUmtOT01GSk9XbFJGTkU\ 3183 xSVRrWmxSV1J4VkZOME0yTnJOVFJPTURVMVdWaE9lRXQ2Um5CTlJXUlVVVEZKTlU1VVV\ 3184 UTk5SRVp0VWpKV1dGUldSbWxqVjNCWVpXdEtZVlJWU1hkU01FVjRWbGRTUzFWV1JsaFV\ 3185 WVXBTVWpCT1JHTXdaRUpWVmxaSFVXNWtUbEZyU201YU0wcERXakJXUjFGc1JtcFNSV2h\ 3186 GVVZVNVExb3dOVmRUUmtVMFVXdEdiVTlGVmtOUlZURkVVV3BTUW1Rd2RFSlhWVkpYVld\ 3187 wQ1UxRnJUa1prTUdjd1UxZFNhVmRIZURaWlZtaFRZa2RPZEZadE5XaFhSVFIzV1RJeFI\ 3188 yVlZlSFJOVkZaYVRXcHNNRmt3WkVka1YxWlVUbGR3YVUxcVFqTlJNbVJhVTFWMGRsZHJ\ 3189 iRFpoYWtKR1VWaGtTbEpHVGtKUldHUlRWVlZzYjFGV1FqVlBXRnBOVTFkR01WVnJWbEp\ 3190 qYlhnMVlteGtNRlI2VmxOaVZYQXdZVmhTVW1GNlpFOVhSRkpMVlVoV2RWVklRazlVYXp\ 3191 BeFZWUnNRbUZWUm5sa1JVNTBWRVprWVZSVmJFMVdiRTEyVFZWc1JWbFhjR2xqTVU1Sll\ 3192 tNXdkbUpYYjNkV1F6a3paVmhKY21Nd2RFdGpRM1IxVFhwU1VsQlVNR2xNUTBwb1dqSld\ 3193 kV1JETVhwaFYyUjFXbGRSZEZwSFJqQlpVMGsyU1cxV05WTnVaRnBYUjNoNldXcEtSMkV\ 3194 3YkhGaU1teGhWMGQ0VEZrd1duZFhWbFowVFZVeFdGSnVRWGxYYTFwclZESkplR05HYkZ\ 3195 SWFJrcHhXV3hhWVU1R2NFZGFSbVJzWWxaS1JWUldhR3RoYlVwVlVWUktXRlp0VW5KWmE\ 3196 yUkxaRlpXV1ZWdGNFNWlXR2d4VjFjd2VGWXlSWGRsUm1oV1lsZG9jbFZxUWxkalJsRjV\ 3197 UbGh3YUZadGREWlZNakUwVjJ4a1IxTnVUbGhoTURFMFdrY3hTMk5HVGxWWGEzQm9ZVEo\ 3198 zZWxaR1pIZFNiVkpHVFZaV1UxZEdTazlXYTFwM1ZteFNWbFZyY0U5aGVrVXlWVlpTWVZ\ 3199 Sc1NrWlNha1pWVmxaS1ExcEVSbXRqUms1WlZHdHdhV0Y2Vm5wWFZFbDRZekpHU0ZOclV\ 3200 rNVhSbHB5Vm01d1IyTkdaSE5oUlhCb1ZsUnNkMVV5TVhkWGJGbDRZMGhTV0dKRk1UTlV\ 3201 iRlUxVWxac05sRnJPVlpOUnpneFYyMTRSbUZWZUVSVGJuQm9WakpTTVZkV2FGTk5WMDU\ 3202 wVm01d1NtRnVRbWxhV0d4TFpESk9kRTlVUW1GV01EUjNWMnhrVW1GVk9YQlRiWGhzVmx\ 3203 oQ2RsZFhkR3RoYlVaV1QxaENWR0V4Y0ZkYVYzUnlaVVpTZEdKRmNHcE5SM2d3V2tWb1E\ 3204 xbFdSWGRoZWtwVVZqTm9kbFZ0ZEhwbFZsWlpVMnhTYVdKclNrcFdhMVpUVVcxV2MxSnV\ 3205 VbFJpVlZwVlZXdGFjbVZzVFhwalJ6bFhUVlpHTmxkWWNFTmhiRWw1V1ROa1ZVMUdSak5\ 3206 aVm1SaFZXdHNjR1F5YkdwTmJYaDFXVzB4UjAxSFVsbFRiWGhLWVcwNWNGZEVRazlsYXp\ 3207 sV1QxWm9VMkpyY0dGWmJHTTFaV3hOZDA5WVZsSlhSMUpUVjFSR1YyRXhiM2RqUlZaWVV\ 3208 qRndUVmxzVWt0WFZUbFhVMnhXVjFJd05URlVSazE0WXpGUmQwNVdRbWxTZWxaMlZqSjB\ 3209 SazFGT1VaWGJYUlhZa2hCZDFReFVrOWhNbEY0Vld0d1YxWlVWbGRYUkVwaFYyczVWMWR\ 3210 1UWxkaVJHdzFWWHBPVDFaV1JuSmhSa3BRVmpOQ2Vsa3haSHBsVjBsNldUSnNiVlpxUlR\ 3211 WSmFYZHBXVmRrYkdKdVVYUmpNbXh1WW1reGFscFlTakJKYW5CaVNXc3hTbE5WVGt0U1J\ 3212 VNUVVVmRPZUZvd1JqTlRWVXBDV2pCc1JsZEhlSEZSTURGRlVWVjBRMW95WkhoaFIzUnh\ 3213 WREZDVWxWVlVrSmhhMHB6VkZaR2VtUXdUbEpYVlZKWFZWWkdTRkpZWkV0UmJGWlZVbFp\ 3214 PVGxGclJraFJWRVpXVWxWT2JtUXdjRlZYUjNoRldXcEplR1F4YkZoT1ZGWk9WV3hXTTF\ 3215 KWVpGcFNSbHBTVlZWNFJWRllhRTlhVmxwUFRWWnNkVlJ1UW1GU01uaHZXVEkxY21WRlV\ 3216 qWlJWVFZEV2pBMVYxRnJSbXBVVlVweVRWUldWazF0ZDNkWGJGSkdXVlV4UTFvd1pFSk5\ 3217 WbFpHVVZoa00xVnNVbGxpUmxKb1YwWktjMVpWYUZkbGJVWkdUVmhhWVZJeFducFZWRUp\ 3218 HWkRCb2Ixa3dOVTVoYTBZelZGZHdTazVGTVVWWk0zQk9aV3RGZDFZeWFHcFVhekUyVVZ\ 3219 oa1RtRnJhekJVVlZKcVpXc3hObEZVUWxoaGEwcDBWRlpHZW1Rd1RsSlhWVkpYVlZaR1N\ 3220 GSllaRXRSYkZaVlVsWk9UbEZyUmtoUlZFWldVbFZPYm1Rd2NGVlhSM2hGV1dwSmVHUXh\ 3221 iRmhPVkZaT1ZXeFdNMUpZWkZwU1JscFNWVlY0UlZGWWFFOWFWbHBQVFZac2RWUnVRbUZ\ 3222 TTW5odldUSTFjbVZGVWpaUlZUVkRXakExVjFGclJtcFVWVXB5VFZSV1ZrMXRkM2RYYkZ\ 3223 KR1dXc3hRMkV3WkVKTlZsWkdVVmhrTTFVeFVsbGlSbEpvVjBaS2MxWlZhRmRsYlVaR1R\ 3224 WaGFZVkl4V25wVlZtaERaREF4UjJFelpFWmtNV3hKVXpJNVlWTlljSEZOUlU1Q1ZWWnN\ 3225 TbE15T1dGVFdIQnhUVVZTUWxWWFRrVlZWMlJDVWxSWmQwMVZPSEppTW5CRVlUTktSVlZ\ 3226 1WXpOYU1Hd3lWMnRWTUdGVVRUQmFSMHB2VVROR2NGSjZaSEZpTWprelYyNUJNR1ZJV2p\ 3227 aU2JsSk5XbnBhVlZaNlFtOVViVkpKWkd4Q1JWVXhVbnBrVm1oVVpWWmpOV1JJU1hwUld\ 3228 HUkVZa2RhUkdJd1VsZFVia1pRWkhwc05WUldaekpVYlRWT1VqRldNMUpIWkZwU1JscFR\ 3229 UVVpDUWxWVlozWlJhMFpTVWtWR2JscFZSazVSYW1oSVVWUkdWbHBGYkROVlZteE9VVzF\ 3230 HUWxKcmJ6TlRTRkpVWkROQ1RWUklWbEJYYW1ScVlUQkdjMVZWYUZaTk1tUkNWRmRqZGx\ 3231 Ock1VTk5SV1JDVFZaV2ExSkhaRkpXTUVwRFZXMU9WVTVVVFRCaWF6RmFaR3hTYWxKdVV\ 3232 uSmFia295VGpOb1ZrNHdVbkJpVldoeFpXdEdWVkZ0WkU5V2EyaFVWbFZXUlZKRlJreFJ\ 3233 iV1J1WTJ0S2JsSlZXa05WVjA1RlVWZHdRbE13U201YU0wWnZZVEp3VUZWR1JsSlNSVVp\ 3234 1Vkd0c1FsSkZTa2RSVjJ4R1VWaENTMDR6YUhkVWJGWXlWVlZ3U0UxRk5XOVVSMGwyV2x\ 3235 oU2FVMXFRazFTUmxWNFRtMTRkMVV3YUZCT01rWnNZbnBDVjFkWVozZGxTR1JFVTFWRmN\ 3236 sUjZWWFpYVkZwRllVTjBhVkZxU1RSTmFsSXhZVmRHVUZWWFJsWlNSRnB1VVZVMWIxZFV\ 3237 iRmRTYlZGeVlXNUtlVmt3VmpKVGJsRnBURU5LVGxOVmJFUlNNVkpFVVRCR2FVc3laRUp\ 3238 rTUd4RFVWZGtTbEpXYUhOaGEwVjJaV3RHVEZGdFpHNWpWMmh5WVdzNVVWVldSa1ZSVjN\ 3239 CRFdUQXhVbU16WkVSVlZteEZWbXhHVWxJd1ZqTlRhMHBXVmtWV1ZGUlZTa0pTTUVWNFZ\ 3240 sVldSRm96WkV0V1JtaHpVa2RKZVUxWVpGcFdlbFV4VkZaS1ZtUXdWak5YVlZKWFZWWkd\ 3241 UVkpGUmpSVWJWWlhWR3BHV21Kck5YZFhhMlJ6WVVkT2RXRXphRVZsYTBaUFVXMWtUMVp\ 3242 yU2tKWk1ERkRZWHBGTVZaVVNuTk5SbkJWVWxaS1RsRlVhRWhSVkVaV1VsVkdNMlF3YkZ\ 3243 WWFIzaFZXVlpvVTJKR1JYZFNXR1JKWVVkT1QxUlhjRUprTURGeFUxUlNUbEpIVGpWVWJ\ 3244 uQldUbFprYjFrd05VNWxhMFl6VkZkd1NrNUZNVVZaTTJ4UFpXeFZNVll5Y0VOaVJURlN\ 3245 Zek5rUkZWV2JFVldiRVpTVWpCV00xTnJTbFpXUlZaVVZGVktRbEl3UlhoV1ZWWkVXak5\ 3246 rUzFaR2FITlNSMGw1VFZoa1dsWjZWVEZVVmtwV1pEQldNMWRWVWxkVlZrWk5Va1ZHTkZ\ 3247 SdFZsZFVha1phWW1zMWQxZHJaSE5oUjA1MVlUTm9SV1ZyUms5UmJXUlBWbXRLUWxrd01\ 3248 VTmhla1V4VmxSS2MwMUdjRlZTVjBaT1VXMWtTRkZVUmxaU1ZVWXpaREZLVlZkSGVGVlp\ 3249 WbWhUWWtaV1NWWnVjR2hTVkVZeVYydGtWMk14UlhkU1dHUllWa1ZHVlZGdFpHcGpWMmh\ 3250 5WVdzNVVWVlZiRU5SYldSdVkxZG9jbUZyT1ZGVlZURkRVVzVrVDFFd1JrSlZhM0JEVm0\ 3251 wNWVscEZkRE5YVlRVMFlWWkNORk5JV25CU2JrWk1aV3RTYzA5WFdqQlVTRlpPV1ZjeGQ\ 3252 xSnNSbXBYU0dONFRXcGthRlJ0T1ZOWmJrNUpUREJhVG1OdE1UWlJNRVpKVFhwak0wMTZ\ 3253 UbXBOYlRscFZVZE9jMlJzVG5sWFZVb3lUVVZPTUZZeFJqQlpWRnBvU3pKT2RrMXNiRE5\ 3254 YYTFKQ1ZUQktibFJzV2tsVmF6RkRVVmRaTkZKVlRrVlJWV1JDVlZWbmRsRlhaRVpSVlR\ 3255 GQ1RrVmtRazFXVm10U1NHUkdVV2s1TTFWVlZrSmtNR3hFVVd0U1FscHJTbTVVYkZwSlZ\ 3256 UQXhSbEl3VWtKV01tUkRWVmh3TkdWdVpIZFZia0pOWlZNNWVWUldWbHBsYlVadlRXNU5\ 3257 lRTB5VmxaUFYyUkhaV3RHYTFGdFpFOVdhMmhTVGtWV1Ixb3hSbFppYms1c1RWVjRSR0V\ 3258 6VGpGT1JGWjFaRWhzVWxFeFdrSmFSbEpzVVZWR05WSkVhSEprTUU1dVYxVnNUR0l4Y0V\ 3259 wbGJXOTNVbFZHTTFOVlVsUlJWVVl6Vld4R1NtRkZSa3BqTVd4eldsWndUR015Y0VkVWE\ 3260 wNTZVMnQwYkZWSGVFaFVWVVpOV2xoQ1YxcFViRVpVUkdSUFlqTlJNVTFVVmpObFJ6Rlh\ 3261 aRlZ3UTFGWGJFSlpNRlpPVmxaV2IxSldUbnBVUm1SUlRsaG9WRlZXVlhkWFNFWTJWbTV\ 3262 GTkZkWVduQlNha1pwVm0wNU5sSXpjRFJPV0hCUFdqSk9lbVI2TURsSmJERTVabEVpTEN\ 3263 KemFXZHVZWFIxY21WeklqcGJleUp3Y205MFpXTjBaV1FpT2lKbGVVbzBUbGROYVU5c2M\ 3264 ybFVWV3hLVVRCb2NWRXdUa0paTVU1dVVWaGtTbEZyUm01VFZXUkNWMGRvTUUxVVVucGl\ 3265 NREZDWWpCa1JGRXpSa2hWTURBd1QxVktRbFJWVGs1U1ZtdzBVVE53UWxOclNtNVViRnB\ 3266 EVVZac1ZWRlhkRTlUVlRGVFZGaGtSbFZXYkVWV2JFWlNVekJTUW1OR1VtaFdNVm93VjJ\ 3267 4ak1XVnJiRVpTYTJoT1ZWUm9NMUpHUmxwU1JscFNWVlY0UlZGV2NFUldhMDVEVWtaV1I\ 3268 xUllhRVpXUlVaUlVXMWtUMVpyU2tKVVZURkVVbXh3YzFsdE1WTmtiVTV5Vkd0S1RsRXd\ 3269 SbGxTUmxKS1pVVXhSVlJZYkU5aGEwVXhWRmR3U21WVk5WZGlNV3hGWlcxek1WUXhVbkp\ 3270 sUlRGeFZGaG9UbUZyTUhoVU1WSldUbFprY1ZGdGFFNVZXRTR6VVRGR1dsSkdXbEpWVld\ 3271 SR1pEQndSVlV3VWtaV1JURkRVbFZrUWsxV1ZrWlJNbVF6VXpGVmVXSkhlR2xXTVZveFd\ 3272 UTnNRMUZzU2paU1ZrSk9VVlJDU0ZGVVJsWlNWVTR6WkRCa1VtSkdSbTVWVkVaRFZrVXh\ 3273 VMVZZWkVaYU1XeEZWbXhHVWxKclZqTmtSM0JhVmpGd2RGZHNUWGRPVlRsRldYcENUMVp\ 3274 GVmxoVVZVcFNVakJGZUZaVlZrSmtNMlJQVmxWYWIxSkZNVFZPVlZwUFpXeFdNRlJXVWt\ 3275 Ka01VWlZVV3h3VGxGck1VaFJibXg0VWpGT1RrNUViRUphTUZaSVVUQk9lRkl4VGs1T1J\ 3276 HeENaREJXU1ZGVVFrcFJWVXBQVFVSb2NWWXdlSHBOUjBadlV6Qm9XbGR1Vm05aVZ6Rmp\ 3277 UREpqTkdScVVsaFRNR2d5VVZoU2FGcHNSazFSVTNSS1pGVXhUMkZITVc1aFZ6RllUakJ\ 3278 HVG1OdVJtOWlWMHBWVFRCc2FGVkZUalZoUnpGaFUxWk9kMVI2V20xaVUzTXlVMWhhWTB\ 3279 3eldrcGphM1J2VlZaU01WWnRPVXhoYldSYVVWaGtiV0ZyUm5aUmJXUnVZMnRLYmxKVld\ 3280 rTlZWMDVEVTFWR1Vsa3dVa05qU0ZKYVYwVTFiMVJHYUZOaVIwMTZWVmhXYWsxdGVITlp\ 3281 iR1JYWkZkT05VNVhjR2xOYWtFeVZERlNVazFGTVRaUlZsSkRXakExVjFOR1RsWlNWVkp\ 3282 GVVZWMFExb3laSGxSYldSR1VtdEtVbGt3VWtKV1JVWlFVVzFrVDFacmFGSlBSVXBDV21\ 3283 wb1JsRnJSazVSTUVrd1VWaGtUVlZXYkVWV2JFbDNWV3RLUkZkWVpFdFRWV3h3V2tWa2I\ 3284 ySkZlSFZYYlhocFlsWktNbGt5YXpGaGJHeFlUa2hXYVdKVWEzZFVSekV3WkZkSmVsa3p\ 3285 WbXRTTW1oM1dUTnJNVTFzYkZobFJFWmhWa1ZHVEZGdFpHNWpWMmh5WVdzNVVWVldSa1Z\ 3286 SVjJSUFUxVkdSVkZyV2tKaFZVazFVVzB4ZUZRemNIRlZWR2hzV1ZkamVWTnVVblprVmx\ 3287 KdlVsWm9lVm93T1VOWFZsRjNVWHBvWVdSRGREVlBWemxKVWtad1JWbHNVbEpUVjJoQ1Z\ 3288 HMXpNbVJIT1ZOaU1sWkVXVmMxYUZSWGNFNVdSWGgwWWxaV2RXSlhTbkphYWtKNldsaGF\ 3289 jbEV3YnpSTmJXc3hWbGhHY1ZWcldsZFZVMHBrVEVOS2FHSkhZMmxQYVVwR1ZYcEpNVTV\ 3290 wU2praUxDSnphV2R1WVhSMWNtVWlPaUphWTFwa1dYbzBiMUl3UjJKc09UWnFNWGxZWm5\ 3291 kdlRYZGxVVGt6VGpCdFNVUmxjVFkyVTBacWRFdG9lR1pSWjNJMGRUWkpOVEJKWldNMmE\ 3292 xWTJhSEV3YVcxdlptTlBhVGs0VW1OSVpXUmpNVzFuZHpCWVp5SjlYWDA9IiwiY3JlYXR\ 3293 lZC1vbiI6IjIwMjItMDItMjJUMDc6MzM6MjUuMDIwWiIsImFnZW50LXNpZ24tY2VydCI\ 3294 6WyJNSUlDSkRDQ0FjcWdBd0lCQWdJRVhsakNNREFLQmdncWhrak9QUVFEQWpCbE1Rc3d\ 3295 DUVlEVlFRR0V3SkJVVEVTTUJBR0ExVUVDZ3dKVFhsRGIyMXdZVzU1TVJVd0V3WURWUVF\ 3296 MREF4TmVWTjFZbk5wWkdsaGNua3hEekFOQmdOVkJBY01CazE1VTJsMFpURWFNQmdHQTF\ 3297 VRUF3d1JUWGxUYVhSbFVIVnphRTF2WkdWc1EwRXdIaGNOTWpBd01qSTRNRGN6TXpBMFd\ 3298 oY05NekF3TWpJNE1EY3pNekEwV2pCbU1Rc3dDUVlEVlFRR0V3SkJVVEVTTUJBR0ExVUV\ 3299 DZ3dKVFhsRGIyMXdZVzU1TVJVd0V3WURWUVFMREF4TmVWTjFZbk5wWkdsaGNua3hEekF\ 3300 OQmdOVkJBY01CazE1VTJsMFpURWJNQmtHQTFVRUF3d1NUWGxUYVhSbFVIVnphRTF2Wkd\ 3301 Wc1FYQndNRmt3RXdZSEtvWkl6ajBDQVFZSUtvWkl6ajBEQVFjRFFnQUU2MDFPK29qQ2t\ 3302 yRFJ3N2dJdlpFNGkzNGRiaENxaUc3am9vd1pwNHh2ekZ0TGc2VFcwaE5kSHZQRFNUc3V\ 3303 YU3lXOXRyM0F3Q2xmQ29EVk5xT3c5eU1YNk5uTUdVd0RnWURWUjBQQVFIL0JBUURBZ2V\ 3304 BTUI4R0ExVWRJd1FZTUJhQUZKN0h0U3dwTEx1T1o3Y2tBbFFIVTNnQU1nL0pNQjBHQTF\ 3305 VZERnUVdCQlJjVDUzNG5NWXZUY0Z0a2Zydjd4VTdEaW1IanpBVEJnTlZIU1VFRERBS0J\ 3306 nZ3JCZ0VGQlFjREFqQUtCZ2dxaGtqT1BRUURBZ05JQURCRkFpRUFwSjd4cE5VdlFKRzB\ 3307 OaExiL2V0YjIwTERVMTZscFNITzdhZW8wVll4MHh3Q0lBK081L1k2RGgrYkIyODI0dWl\ 3308 hT1FhVUQ2Z0FOaFk5VkZkK2pycmNFdkp0IiwiTUlJQ0dUQ0NBYitnQXdJQkFnSUVYbGp\ 3309 BL3pBS0JnZ3Foa2pPUFFRREFqQmNNUXN3Q1FZRFZRUUdFd0pCVVRFU01CQUdBMVVFQ2d\ 3310 3SlRYbERiMjF3WVc1NU1SVXdFd1lEVlFRTERBeE5lVk4xWW5OcFpHbGhjbmt4RHpBTkJ\ 3311 nTlZCQWNNQmsxNVUybDBaVEVSTUE4R0ExVUVBd3dJVFhsVGFYUmxRMEV3SGhjTk1qQXd\ 3312 Nakk0TURjeU56VTVXaGNOTXpBd01qSTRNRGN5TnpVNVdqQmxNUXN3Q1FZRFZRUUdFd0p\ 3313 CVVRFU01CQUdBMVVFQ2d3SlRYbERiMjF3WVc1NU1SVXdFd1lEVlFRTERBeE5lVk4xWW5\ 3314 OcFpHbGhjbmt4RHpBTkJnTlZCQWNNQmsxNVUybDBaVEVhTUJnR0ExVUVBd3dSVFhsVGF\ 3315 YUmxVSFZ6YUUxdlpHVnNRMEV3V1RBVEJnY3Foa2pPUFFJQkJnZ3Foa2pPUFFNQkJ3TkN\ 3316 BQVJKQlZvc2RLd1lOeGlQeEh2aUZxS3pEbDlmdEx1TWFtcEZRY1h3MTI3YU5vUmJzSC9\ 3317 GTXJtekNBSDM3NzMzYzJvYlBjbHZTcllCdjBDdFdRdGE2YStjbzJZd1pEQVNCZ05WSFJ\ 3318 NQkFmOEVDREFHQVFIL0FnRUFNQTRHQTFVZER3RUIvd1FFQXdJQ0JEQWZCZ05WSFNNRUd\ 3319 EQVdnQlF6eHp3cFJwTHkvck1VWXphaDJzMTNlVTlnRnpBZEJnTlZIUTRFRmdRVW5zZTF\ 3320 MQ2tzdTQ1bnR5UUNWQWRUZUFBeUQ4a3dDZ1lJS29aSXpqMEVBd0lEU0FBd1JRSWhBSXN\ 3321 ZbGVaS3NqRk5Dc0pLZVBsR01BTGVwVmU5RUw3Tm90NTE1d3htVnVKQkFpQWNFTVVVaEV\ 3322 Tc0xXUDV4U1FVMFhxelZxOFl2aUYxYlZvekd6eDV6Tmdjc3c9PSJdfX0", 3323 "signatures":[{ 3324 "protected":"eyJ4NWMiOlsiTUlJQjhEQ0NBWmFnQXdJQkFnSUdBWEJoTUtZSU1\ 3325 Bb0dDQ3FHU000OUJBTUNNRnd4Q3pBSkJnTlZCQVlUQWtGUk1SSXdFQVlEVlFRS0RBbE5\ 3326 lVU52YlhCaGJua3hGVEFUQmdOVkJBc01ERTE1VTNWaWMybGthV0Z5ZVRFUE1BMEdBMVV\ 3327 FQnd3R1RYbFRhWFJsTVJFd0R3WURWUVFEREFoTmVWTnBkR1ZEUVRBZUZ3MHlNREF5TWp\ 3328 Bd05qQXlNak5hRncwek1EQXlNakF3TmpBeU1qTmFNSGt4Q3pBSkJnTlZCQVlUQWtGUk1\ 3329 SSXdFQVlEVlFRS0RBbE5lVU52YlhCaGJua3hGVEFUQmdOVkJBc01ERTE1VTNWaWMybGt\ 3330 hV0Z5ZVRFUE1BMEdBMVVFQnd3R1RYbFRhWFJsTVM0d0xBWURWUVFERENWU1pXZHBjM1J\ 3331 5WVhJZ1ZtOTFZMmhsY2lCU1pYRjFaWE4wSUZOcFoyNXBibWNnUzJWNU1Ga3dFd1lIS29\ 3332 aSXpqMENBUVlJS29aSXpqMERBUWNEUWdBRUJUVFwvc1JmTDlsSnVGbVwvY24zU2pHcWp\ 3333 QXC9xdnBrNytoSTIwOE5oVkRvR2hcLzdLUCt2TXpYeVFRQStqUjZrNnJhTTI4ZlwvbHV\ 3334 FK1h1aHVwN1Vmem05Q3FNbk1DVXdFd1lEVlIwbEJBd3dDZ1lJS3dZQkJRVUhBeHd3RGd\ 3335 ZRFZSMFBBUUhcL0JBUURBZ2VBTUFvR0NDcUdTTTQ5QkFNQ0EwZ0FNRVVDSUhOK3VBbUp\ 3336 ldVhlc1wveWQxd1M0Mlo0RFhKNEptMWErZzNYa1pnZjhUaGxuQWlFQXBVdTZzZnljRWt\ 3337 veDdSWlhtZitLOHc0cDZzUldyamExUVJwWTAyNjQxSFk9IiwiTUlJQjhEQ0NBWmVnQXd\ 3338 JQkFnSUdBWEJoTUtZQk1Bb0dDQ3FHU000OUJBTUNNRnd4Q3pBSkJnTlZCQVlUQWtGUk1\ 3339 SSXdFQVlEVlFRS0RBbE5lVU52YlhCaGJua3hGVEFUQmdOVkJBc01ERTE1VTNWaWMybGt\ 3340 hV0Z5ZVRFUE1BMEdBMVVFQnd3R1RYbFRhWFJsTVJFd0R3WURWUVFEREFoTmVWTnBkR1Z\ 3341 EUVRBZUZ3MHlNREF5TWpBd05qQXlNak5hRncwek1EQXlNakF3TmpBeU1qTmFNRnd4Q3p\ 3342 BSkJnTlZCQVlUQWtGUk1SSXdFQVlEVlFRS0RBbE5lVU52YlhCaGJua3hGVEFUQmdOVkJ\ 3343 Bc01ERTE1VTNWaWMybGthV0Z5ZVRFUE1BMEdBMVVFQnd3R1RYbFRhWFJsTVJFd0R3WUR\ 3344 WUVFEREFoTmVWTnBkR1ZEUVRCWk1CTUdCeXFHU000OUFnRUdDQ3FHU000OUF3RUhBMEl\ 3345 BQkluQ3VoV1ZzZ2NONzFvWmVzMUZHXC9xZFZnTVBva01wZlMyNzFcL2V5SWNcL29EVmJ\ 3346 NRkhDYmV2SjVMTTgxOTVOYVpLTlNvSFAzS3dMeXVCaDh2MncwOVp1alJUQkRNQklHQTF\ 3347 VZEV3RUJcL3dRSU1BWUJBZjhDQVFFd0RnWURWUjBQQVFIXC9CQVFEQWdJRU1CMEdBMVV\ 3348 kRGdRV0JCUXp4endwUnBMeVwvck1VWXphaDJzMTNlVTlnRnpBS0JnZ3Foa2pPUFFRREF\ 3349 nTkhBREJFQWlCZGJIU212YW9qaDBpZWtaSUtOVzhRMGxTbGI1K0RLTlFcL05LY1I3dWx\ 3350 6dGdJZ2RwejZiUkYyREZtcGlKb3JCMkd5VmE4YVdkd2xIc0RvRVdZY0k0UEdKYmc9Il0\ 3351 sImFsZyI6IkVTMjU2In0", 3352 "signature":"67t3n8zyEek4IM2Ko3Y_UvE1hzp794QFNTqG-HzTrBQtE4_4-yS\ 3353 yyFd3kP6YCn35YYJ7yK35d3styo_yoiPfKA" 3354 }] 3355 } 3357 Figure 24: Example Registrar Voucher Request - RVR 3359 A.3. Example Voucher Response (from MASA to Pledge, via Registrar and 3360 Registrar-agent) 3362 The following is an example voucher response from MASA to Pledge via 3363 Registrar and Registrar-agent, in "General JWS JSON Serialization". 3364 The message size of this Voucher is: 1916 bytes 3365 =============== NOTE: '\' line wrapping per RFC 8792 ================ 3367 { 3368 "payload":"eyJpZXRmLXZvdWNoZXI6dm91Y2hlciI6eyJhc3NlcnRpb24iOiJhZ2V\ 3369 udC1wcm94aW1pdHkiLCJzZXJpYWwtbnVtYmVyIjoiMDEyMzQ1Njc4OSIsIm5vbmNlIjo\ 3370 iTDNJSjZocHRIQ0lRb054YWFiOUhXQT09IiwiY3JlYXRlZC1vbiI6IjIwMjItMDQtMjZ\ 3371 UMDU6MTY6MjguNzI2WiIsInBpbm5lZC1kb21haW4tY2VydCI6Ik1JSUJwRENDQVVtZ0F\ 3372 3SUJBZ0lHQVcwZUx1SCtNQW9HQ0NxR1NNNDlCQU1DTURVeEV6QVJCZ05WQkFvTUNrMTV\ 3373 RblZ6YVc1bGMzTXhEVEFMQmdOVkJBY01CRk5wZEdVeER6QU5CZ05WQkFNTUJsUmxjM1J\ 3374 EUVRBZUZ3MHhPVEE1TVRFd01qTTNNekphRncweU9UQTVNVEV3TWpNM016SmFNRFV4RXp\ 3375 BUkJnTlZCQW9NQ2sxNVFuVnphVzVsYzNNeERUQUxCZ05WQkFjTUJGTnBkR1V4RHpBTkJ\ 3376 nTlZCQU1NQmxSbGMzUkRRVEJaTUJNR0J5cUdTTTQ5QWdFR0NDcUdTTTQ5QXdFSEEwSUF\ 3377 CT2t2a1RIdThRbFQzRkhKMVVhSTcrV3NIT2IwVVMzU0FMdEc1d3VLUURqaWV4MDYvU2N\ 3378 ZNVBKaWJ2Z0hUQitGL1FUamdlbEhHeTFZS3B3Y05NY3NTeWFqUlRCRE1CSUdBMVVkRXd\ 3379 FQi93UUlNQVlCQWY4Q0FRRXdEZ1lEVlIwUEFRSC9CQVFEQWdJRU1CMEdBMVVkRGdRV0J\ 3380 CVG9aSU16UWRzRC9qLytnWC83Y0JKdWNIL1htakFLQmdncWhrak9QUVFEQWdOSkFEQkd\ 3381 BaUVBdHhRMytJTEdCUEl0U2g0YjlXWGhYTnVocVNQNkgrYi9MQy9mVllEalE2b0NJUUR\ 3382 HMnVSQ0hsVnEzeWhCNThUWE1VYnpIOCtPbGhXVXZPbFJEM1ZFcURkY1F3PT0ifX0", 3383 "signatures":[{ 3384 "protected":"eyJ4NWMiOlsiTUlJQmt6Q0NBVGlnQXdJQkFnSUdBV0ZCakNrWU1\ 3385 Bb0dDQ3FHU000OUJBTUNNRDB4Q3pBSkJnTlZCQVlUQWtGUk1SVXdFd1lEVlFRS0RBeEt\ 3386 hVzVuU21sdVowTnZjbkF4RnpBVkJnTlZCQU1NRGtwcGJtZEthVzVuVkdWemRFTkJNQjR\ 3387 YRFRFNE1ERXlPVEV3TlRJME1Gb1hEVEk0TURFeU9URXdOVEkwTUZvd1R6RUxNQWtHQTF\ 3388 VRUJoTUNRVkV4RlRBVEJnTlZCQW9NREVwcGJtZEthVzVuUTI5eWNERXBNQ2NHQTFVRUF\ 3389 3d2dTbWx1WjBwcGJtZERiM0p3SUZadmRXTm9aWElnVTJsbmJtbHVaeUJMWlhrd1dUQVR\ 3390 CZ2NxaGtqT1BRSUJCZ2dxaGtqT1BRTUJCd05DQUFTQzZiZUxBbWVxMVZ3NmlRclJzOFI\ 3391 wWlcrNGIxR1d5ZG1XczJHQU1GV3diaXRmMm5JWEgzT3FIS1Z1OHMyUnZpQkdOaXZPS0d\ 3392 CSEh0QmRpRkVaWnZiN294SXdFREFPQmdOVkhROEJBZjhFQkFNQ0I0QXdDZ1lJS29aSXp\ 3393 qMEVBd0lEU1FBd1JnSWhBSTRQWWJ4dHNzSFAyVkh4XC90elVvUVwvU3N5ZEwzMERRSU5\ 3394 FdGNOOW1DVFhQQWlFQXZJYjNvK0ZPM0JUbmNMRnNhSlpSQWtkN3pPdXNuXC9cL1pLT2F\ 3395 FS2JzVkRpVT0iXSwiYWxnIjoiRVMyNTYifQ", 3396 "signature":"0TB5lr-cs1jqka2vNbQm3bBYWfLJd8zdVKIoV53eo2YgSITnKKY\ 3397 TvHMUw0wx9wdyuNVjNoAgLysNIgEvlcltBw" 3398 }] 3399 } 3401 Figure 25: Example Voucher Response from MASA 3403 A.4. Example Voucher Response, MASA issued Voucher with additional 3404 Registrar signature (from MASA to Pledge, via Registrar and 3405 Registrar-agent) 3407 The following is an example voucher response from MASA to Pledge via 3408 Registrar and Registrar-agent, in "General JWS JSON Serialization". 3409 The message size of this Voucher is: 3006 bytes 3410 =============== NOTE: '\' line wrapping per RFC 8792 ================ 3412 { 3413 "payload":"eyJpZXRmLXZvdWNoZXI6dm91Y2hlciI6eyJhc3NlcnRpb24iOiJhZ2V\ 3414 udC1wcm94aW1pdHkiLCJzZXJpYWwtbnVtYmVyIjoiMDEyMzQ1Njc4OSIsIm5vbmNlIjo\ 3415 iUUJiSXMxNTJzbkFvVzdSeVFMWENvZz09IiwiY3JlYXRlZC1vbiI6IjIwMjItMDktMjl\ 3416 UMDM6Mzc6MjYuMzgyWiIsInBpbm5lZC1kb21haW4tY2VydCI6Ik1JSUJwRENDQVVtZ0F\ 3417 3SUJBZ0lHQVcwZUx1SCtNQW9HQ0NxR1NNNDlCQU1DTURVeEV6QVJCZ05WQkFvTUNrMTV\ 3418 RblZ6YVc1bGMzTXhEVEFMQmdOVkJBY01CRk5wZEdVeER6QU5CZ05WQkFNTUJsUmxjM1J\ 3419 EUVRBZUZ3MHhPVEE1TVRFd01qTTNNekphRncweU9UQTVNVEV3TWpNM016SmFNRFV4RXp\ 3420 BUkJnTlZCQW9NQ2sxNVFuVnphVzVsYzNNeERUQUxCZ05WQkFjTUJGTnBkR1V4RHpBTkJ\ 3421 nTlZCQU1NQmxSbGMzUkRRVEJaTUJNR0J5cUdTTTQ5QWdFR0NDcUdTTTQ5QXdFSEEwSUF\ 3422 CT2t2a1RIdThRbFQzRkhKMVVhSTcrV3NIT2IwVVMzU0FMdEc1d3VLUURqaWV4MDYvU2N\ 3423 ZNVBKaWJ2Z0hUQitGL1FUamdlbEhHeTFZS3B3Y05NY3NTeWFqUlRCRE1CSUdBMVVkRXd\ 3424 FQi93UUlNQVlCQWY4Q0FRRXdEZ1lEVlIwUEFRSC9CQVFEQWdJRU1CMEdBMVVkRGdRV0J\ 3425 CVG9aSU16UWRzRC9qLytnWC83Y0JKdWNIL1htakFLQmdncWhrak9QUVFEQWdOSkFEQkd\ 3426 BaUVBdHhRMytJTEdCUEl0U2g0YjlXWGhYTnVocVNQNkgrYi9MQy9mVllEalE2b0NJUUR\ 3427 HMnVSQ0hsVnEzeWhCNThUWE1VYnpIOCtPbGhXVXZPbFJEM1ZFcURkY1F3PT0ifX0", 3428 "signatures":[{ 3429 "protected":"eyJ4NWMiOlsiTUlJQmt6Q0NBVGlnQXdJQkFnSUdBV0ZCakNrWU1\ 3430 Bb0dDQ3FHU000OUJBTUNNRDB4Q3pBSkJnTlZCQVlUQWtGUk1SVXdFd1lEVlFRS0RBeEt\ 3431 hVzVuU21sdVowTnZjbkF4RnpBVkJnTlZCQU1NRGtwcGJtZEthVzVuVkdWemRFTkJNQjR\ 3432 YRFRFNE1ERXlPVEV3TlRJME1Gb1hEVEk0TURFeU9URXdOVEkwTUZvd1R6RUxNQWtHQTF\ 3433 VRUJoTUNRVkV4RlRBVEJnTlZCQW9NREVwcGJtZEthVzVuUTI5eWNERXBNQ2NHQTFVRUF\ 3434 3d2dTbWx1WjBwcGJtZERiM0p3SUZadmRXTm9aWElnVTJsbmJtbHVaeUJMWlhrd1dUQVR\ 3435 CZ2NxaGtqT1BRSUJCZ2dxaGtqT1BRTUJCd05DQUFTQzZiZUxBbWVxMVZ3NmlRclJzOFI\ 3436 wWlcrNGIxR1d5ZG1XczJHQU1GV3diaXRmMm5JWEgzT3FIS1Z1OHMyUnZpQkdOaXZPS0d\ 3437 CSEh0QmRpRkVaWnZiN294SXdFREFPQmdOVkhROEJBZjhFQkFNQ0I0QXdDZ1lJS29aSXp\ 3438 qMEVBd0lEU1FBd1JnSWhBSTRQWWJ4dHNzSFAyVkh4XC90elVvUVwvU3N5ZEwzMERRSU5\ 3439 FdGNOOW1DVFhQQWlFQXZJYjNvK0ZPM0JUbmNMRnNhSlpSQWtkN3pPdXNuXC9cL1pLT2F\ 3440 FS2JzVkRpVT0iXSwidHlwIjoidm91Y2hlci1qd3MranNvbiIsImFsZyI6IkVTMjU2In0\ 3441 ", 3442 "signature":"ShqW8uFRkuAXIzjAhB4bolMMndcY7GYq3Kbo94yvGtjCaxEX3Hp\ 3443 6QXZUTEJ_kulQ1G7DnaU4igDPdUGtcV9Lkw"},{ 3444 "protected":"eyJ4NWMiOlsiTUlJQjRqQ0NBWWlnQXdJQkFnSUdBWFk3MmJiWk1\ 3445 Bb0dDQ3FHU000OUJBTUNNRFV4RXpBUkJnTlZCQW9NQ2sxNVFuVnphVzVsYzNNeERUQUx\ 3446 CZ05WQkFjTUJGTnBkR1V4RHpBTkJnTlZCQU1NQmxSbGMzUkRRVEFlRncweU1ERXlNRGN\ 3447 3TmpFNE1USmFGdzB6TURFeU1EY3dOakU0TVRKYU1ENHhFekFSQmdOVkJBb01DazE1UW5\ 3448 WemFXNWxjM014RFRBTEJnTlZCQWNNQkZOcGRHVXhHREFXQmdOVkJBTU1EMFJ2YldGcGJ\ 3449 sSmxaMmx6ZEhKaGNqQlpNQk1HQnlxR1NNNDlBZ0VHQ0NxR1NNNDlBd0VIQTBJQUJCazE\ 3450 2S1wvaTc5b1JrSzVZYmVQZzhVU1I4XC91czFkUFVpWkhNdG9rU2RxS1c1Zm5Xc0JkK3F\ 3451 STDdXUmZmZVdreWdlYm9KZklsbHVyY2kyNXduaGlPVkNHamV6QjVNQjBHQTFVZEpRUVd\ 3452 NQlFHQ0NzR0FRVUZCd01CQmdnckJnRUZCUWNESERBT0JnTlZIUThCQWY4RUJBTUNCNEF\ 3453 3U0FZRFZSMFJCRUV3UDRJZGNtVm5hWE4wY21GeUxYUmxjM1F1YzJsbGJXVnVjeTFpZEM\ 3454 1dVpYU0NIbkpsWjJsemRISmhjaTEwWlhOME5pNXphV1Z0Wlc1ekxXSjBMbTVsZERBS0J\ 3455 nZ3Foa2pPUFFRREFnTklBREJGQWlCeGxkQmhacTBFdjVKTDJQcldDdHlTNmhEWVcxeUN\ 3456 PXC9SYXVicEM3TWFJRGdJaEFMU0piZ0xuZ2hiYkFnMGRjV0ZVVm9cL2dHTjBcL2p3ekp\ 3457 aMFNsMmg0eElYazEiXSwidHlwIjoidm91Y2hlci1qd3MranNvbiIsImFsZyI6IkVTMjU\ 3458 2In0", 3459 "signature":"N4oXV48V6umsHMKkhdSSmJYFtVb6agjD32uXpIlGx6qVE7Dh0-b\ 3460 qhRRyjnxp80IV_Fy1RAOXIIzs3Q8CnMgBgg" 3461 }] 3462 } 3464 Figure 26: Example Voucher Response from MASA, with additional 3465 Registrar signature 3467 Appendix B. History of Changes [RFC Editor: please delete] 3469 Proof of Concept Code available 3471 From IETF draft 05 -> IETF draft 06: 3473 * Update of list of reviewers 3475 * Issue #67, shortened the pledge endpoints to prepare for 3476 constraint deployments 3478 * Included table for new endpoints on the registrar in the overview 3479 of the registrar-agent 3481 * addressed review comments from SECDIR early review 3483 * addressed review comments from IOTDIR early review 3485 From IETF draft 04 -> IETF draft 05: 3487 * Restructured document to have a distinct section for the object 3488 flow and handling and shortened introduction, issue #72 3490 * Added security considerations for using mDNS without a specific 3491 product-serial-number, issue #75 3493 * Clarified pledge-status responses are cumulative, issue #73 3495 * Removed agent-sign-cert from trigger data to save bandwidth and 3496 remove complexity through options, issue #70 3498 * Changed terminology for LDevID(Reg) certificate to registrar EE 3499 certificate, as it does not need to be an LDevID, issue #66 3501 * Added new protected header parameter (created-on) in PER to 3502 support freshness validation, issue #63 3504 * Removed reference to CAB Forum as not needed for BRSKI-PRM 3505 specifically, issue #65 3507 * Enhanced error codes in section 5.5.1, issue #39, #64 3509 * Enhanced security considerations and privacy considerations, issue 3510 #59 3512 * Issue #50 addressed by referring to the utilized enrollment 3513 protocol 3515 * Issue #47 MASA verification of LDevID(RegAgt) to the same 3516 registrar EE certificate domain CA 3518 * Reworked terminology of "enrollment object", "certification 3519 object", "enrollment request object", etc., issue #27 3521 * Reworked all message representations to align with encoding 3523 * Added explanation of MASA requiring domain CA cert in section 3524 5.5.1 and section 5.5.2, issue #36 3526 * Defined new endpoint for pledge bootstrapping status inquiry, 3527 issue #35 in section Section 6.4, IANA considerations and section 3528 Section 5.3 3530 * Included examples for several objects in section Appendix A 3531 including message example sizes, issue #33 3533 * PoP for private key to registrar certificate included as 3534 mandatory, issues #32 and #49 3536 * Issue #31, clarified that combined pledge may act as client/server 3537 for further (re)enrollment 3539 * Issue #42, clarified that Registrar needs to verify the status 3540 responses with and ensure that they match the audit log response 3541 from the MASA, otherwise it needs drop the pledge and revoke the 3542 certificate 3544 * Issue #43, clarified that the pledge shall use the create time 3545 from the trigger message if the time has not been synchronized, 3546 yet. 3548 * Several editorial changes and enhancements to increasing 3549 readability. 3551 From IETF draft 03 -> IETF draft 04: 3553 * In deep Review by Esko Dijk lead to issues #22-#61, which are bein 3554 stepwise integrated 3556 * Simplified YANG definition by augmenting the voucher request from 3557 RFC 8995 instead of redefining it. 3559 * Added explanation for terminology "endpoint" used in this 3560 document, issue #16 3562 * Added clarification that registrar-agent may collect PVR or PER or 3563 both in one run, issue #17 3565 * Added a statement that nonceless voucher may be accepted, issue 3566 #18 3568 * Simplified structure in section Section 3.1, issue #19 3570 * Removed join proxy in Figure 1 and added explanatory text, issue 3571 #20 3573 * Added description of pledge-CAcerts endpoint plus further handling 3574 of providing a wrapped CA certs response to the pledge in section 3575 Section 6.3; also added new required registrar endpoint (section 3576 Section 6.2 and IANA considerations) for the registrar to provide 3577 a wrapped CA certs response, issue #21 3579 * utilized defined abbreviations in the document consistently, issue 3580 #22 3582 * Reworked text on discovery according to issue #23 to clarify scope 3583 and handling 3585 * Added several clarifications based on review comments 3587 From IETF draft 02 -> IETF draft 03: 3589 * Updated examples to state "base64encodedvalue==" for x5c 3590 occurrences 3592 * Include link to SVG graphic as general overview 3594 * Restructuring of section 5 to flatten hierarchy 3596 * Enhanced requirements and motivation in Section 4 3598 * Several editorial improvements based on review comments 3600 From IETF draft 01 -> IETF draft 02: 3602 * Issue #15 included additional signature on voucher from registrar 3603 in section Section 6.2 and section Section 5.2 The verification of 3604 multiple signatures is described in section Section 6.3 3606 * Included representation for General JWS JSON Serialization for 3607 examples 3609 * Included error responses from pledge if it is not able to create a 3610 pledge-voucher request or an enrollment request in section 3611 Section 6.1 3613 * Removed open issue regarding handling of multiple CSRs and 3614 enrollment responses during the bootstrapping as the initial 3615 target it the provisioning of a generic LDevID certificate. The 3616 defined endpoint on the pledge may also be used for management of 3617 further certificates. 3619 From IETF draft 00 -> IETF draft 01: 3621 * Issue #15 lead to the inclusion of an option for an additional 3622 signature of the registrar on the voucher received from the MASA 3623 before forwarding to the registrar-agent to support verification 3624 of POP of the registrars private key in section Section 6.2 and 3625 Section 6.3. 3627 * Based on issue #11, a new endpoint was defined for the registrar 3628 to enable delivery of the wrapped enrollment request from the 3629 pledge (in contrast to plain PKCS#10 in simple enroll). 3631 * Decision on issue #8 to not provide an additional signature on the 3632 enrollment-response object by the registrar. As the enrollment 3633 response will only contain the generic LDevID certificate. This 3634 credential builds the base for further configuration outside the 3635 initial enrollment. 3637 * Decision on issue #7 to not support multiple CSRs during the 3638 bootstrapping, as based on the generic LDevID certificate the 3639 pledge may enroll for further certificates. 3641 * Closed open issue #5 regarding verification of ietf-ztp-types 3642 usage as verified via a proof-of-concept in section 3643 {#exchanges_uc2_1}. 3645 * Housekeeping: Removed already addressed open issues stated in the 3646 draft directly. 3648 * Reworked text in from introduction to section pledge-responder- 3649 mode 3651 * Fixed "serial-number" encoding in PVR/RVR 3653 * Added prior-signed-voucher-request in the parameter description of 3654 the registrar-voucher-request in Section 6.2. 3656 * Note added in Section 6.2 if sub-CAs are used, that the 3657 corresponding information is to be provided to the MASA. 3659 * Inclusion of limitation section (pledge sleeps and needs to be 3660 waked up. Pledge is awake but registrar-agent is not available) 3661 (Issue #10). 3663 * Assertion-type aligned with voucher in RFC8366bis, deleted related 3664 open issues. (Issue #4) 3666 * Included table for endpoints in Section 5.3 for better 3667 readability. 3669 * Included registrar authorization check for registrar-agent during 3670 TLS handshake in section Section 6.2. Also enhanced figure 3671 Figure 9 with the authorization step on TLS level. 3673 * Enhanced description of registrar authorization check for 3674 registrar-agent based on the agent-signed-data in section 3675 Section 6.2. Also enhanced figure Figure 9 with the authorization 3676 step on pledge-voucher-request level. 3678 * Changed agent-signed-cert to an array to allow for providing 3679 further certificate information like the issuing CA cert for the 3680 LDevID(RegAgt) certificate in case the registrar and the 3681 registrar-agent have different issuing CAs in Figure 9 (issue 3682 #12). This also required changes in the YANG module in 3683 Section 7.1.2 3685 * Addressed YANG warning (issue #1) 3687 * Inclusion of examples for a trigger to create a pledge-voucher- 3688 request and an enrollment-request. 3690 From IETF draft-ietf-anima-brski-async-enroll-03 -> IETF anima-brski- 3691 prm-00: 3693 * Moved UC2 related parts defining the pledge in responder mode from 3694 draft-ietf-anima-brski-async-enroll-03 to this document This 3695 required changes and adaptations in several sections to remove the 3696 description and references to UC1. 3698 * Addressed feedback for voucher-request enhancements from YANG 3699 doctor early review in Section 7.1 as well as in the security 3700 considerations (formerly named ietf-async-voucher-request). 3702 * Renamed ietf-async-voucher-request to IETF-voucher-request-prm to 3703 to allow better listing of voucher related extensions; aligned 3704 with constraint voucher (#20) 3706 * Utilized ietf-voucher-request-async instead of ietf-voucher- 3707 request in voucher exchanges to utilize the enhanced voucher- 3708 request. 3710 * Included changes from draft-ietf-netconf-sztp-csr-06 regarding the 3711 YANG definition of csr-types into the enrollment request exchange. 3713 From IETF draft 02 -> IETF draft 03: 3715 * Housekeeping, deleted open issue regarding YANG voucher-request in 3716 Section 6.1 as voucher-request was enhanced with additional leaf. 3718 * Included open issues in YANG model in Section 5.1 regarding 3719 assertion value agent-proximity and csr encapsulation using SZTP 3720 sub module). 3722 From IETF draft 01 -> IETF draft 02: 3724 * Defined call flow and objects for interactions in UC2. Object 3725 format based on draft for JOSE signed voucher artifacts and 3726 aligned the remaining objects with this approach in Section 6 . 3728 * Terminology change: issue #2 pledge-agent -> registrar-agent to 3729 better underline agent relation. 3731 * Terminology change: issue #3 PULL/PUSH -> pledge-initiator-mode 3732 and pledge-responder-mode to better address the pledge operation. 3734 * Communication approach between pledge and registrar-agent changed 3735 by removing TLS-PSK (former section TLS establishment) and 3736 associated references to other drafts in favor of relying on 3737 higher layer exchange of signed data objects. These data objects 3738 are included also in the pledge-voucher-request and lead to an 3739 extension of the YANG module for the voucher-request (issue #12). 3741 * Details on trust relationship between registrar-agent and 3742 registrar (issue #4, #5, #9) included in Section 5.1. 3744 * Recommendation regarding short-lived certificates for registrar- 3745 agent authentication towards registrar (issue #7) in the security 3746 considerations. 3748 * Introduction of reference to agent signing certificate using SKID 3749 in agent signed data (issue #37). 3751 * Enhanced objects in exchanges between pledge and registrar-agent 3752 to allow the registrar to verify agent-proximity to the pledge 3753 (issue #1) in Section 6. 3755 * Details on trust relationship between registrar-agent and pledge 3756 (issue #5) included in Section 5.1. 3758 * Split of use case 2 call flow into sub sections in Section 6. 3760 From IETF draft 00 -> IETF draft 01: 3762 * Update of scope in Section 3.1 to include in which the pledge acts 3763 as a server. This is one main motivation for use case 2. 3765 * Rework of use case 2 in Section 5.1 to consider the transport 3766 between the pledge and the pledge-agent. Addressed is the TLS 3767 channel establishment between the pledge-agent and the pledge as 3768 well as the endpoint definition on the pledge. 3770 * First description of exchanged object types (needs more work) 3772 * Clarification in discovery options for enrollment endpoints at the 3773 domain registrar based on well-known endpoints do not result in 3774 additional /.well-known URIs. Update of the illustrative example. 3775 Note that the change to /brski for the voucher related endpoints 3776 has been taken over in the BRSKI main document. 3778 * Updated references. 3780 * Included Thomas Werner as additional author for the document. 3782 From individual version 03 -> IETF draft 00: 3784 * Inclusion of discovery options of enrollment endpoints at the 3785 domain registrar based on well-known endpoints in new section as 3786 replacement of section 5.1.3 in the individual draft. This is 3787 intended to support both use cases in the document. An 3788 illustrative example is provided. 3790 * Missing details provided for the description and call flow in 3791 pledge-agent use case Section 5.1, e.g. to accommodate 3792 distribution of CA certificates. 3794 * Updated CMP example in to use lightweight CMP instead of CMP, as 3795 the draft already provides the necessary /.well-known endpoints. 3797 * Requirements discussion moved to separate section in Section 4. 3798 Shortened description of proof of identity binding and mapping to 3799 existing protocols. 3801 * Removal of copied call flows for voucher exchange and registrar 3802 discovery flow from [RFC8995] in UC1 to avoid doubling or text or 3803 inconsistencies. 3805 * Reworked abstract and introduction to be more crisp regarding the 3806 targeted solution. Several structural changes in the document to 3807 have a better distinction between requirements, use case 3808 description, and solution description as separate sections. 3809 History moved to appendix. 3811 From individual version 02 -> 03: 3813 * Update of terminology from self-contained to authenticated self- 3814 contained object to be consistent in the wording and to underline 3815 the protection of the object with an existing credential. Note 3816 that the naming of this object may be discussed. An alternative 3817 name may be attestation object. 3819 * Simplification of the architecture approach for the initial use 3820 case having an offsite PKI. 3822 * Introduction of a new use case utilizing authenticated self- 3823 contain objects to onboard a pledge using a commissioning tool 3824 containing a pledge-agent. This requires additional changes in 3825 the BRSKI call flow sequence and led to changes in the 3826 introduction, the application example,and also in the related 3827 BRSKI-PRM call flow. 3829 From individual version 01 -> 02: 3831 * Update of introduction text to clearly relate to the usage of 3832 IDevID and LDevID. 3834 * Update of description of architecture elements and changes to 3835 BRSKI in Section 5. 3837 * Enhanced consideration of existing enrollment protocols in the 3838 context of mapping the requirements to existing solutions in 3839 Section 4. 3841 From individual version 00 -> 01: 3843 * Update of examples, specifically for building automation as well 3844 as two new application use cases in Section 3.1. 3846 * Deletion of asynchronous interaction with MASA to not complicate 3847 the use case. Note that the voucher exchange can already be 3848 handled in an asynchronous manner and is therefore not considered 3849 further. This resulted in removal of the alternative path the 3850 MASA in Figure 1 and the associated description in Section 5. 3852 * Enhancement of description of architecture elements and changes to 3853 BRSKI in Section 5. 3855 * Consideration of existing enrollment protocols in the context of 3856 mapping the requirements to existing solutions in Section 4. 3858 * New section starting with the mapping to existing enrollment 3859 protocols by collecting boundary conditions. 3861 Contributors 3863 Esko Dijk 3864 IoTconsultancy.nl 3865 Email: esko.d...@iotconsultancy.nl 3867 Authors' Addresses 3869 Steffen Fries 3870 Siemens AG 3871 Otto-Hahn-Ring 6 3872 81739 Munich 3873 Germany 3874 Email: steffen.fr...@siemens.com 3875 URI: https://www.siemens.com/ 3877 Thomas Werner 3878 Siemens AG 3879 Otto-Hahn-Ring 6 3880 81739 Munich 3881 Germany 3882 Email: thomas-wer...@siemens.com 3883 URI: https://www.siemens.com/ 3885 Eliot Lear 3886 Cisco Systems 3887 Richtistrasse 7 3888 CH-8304 Wallisellen 3889 Switzerland 3890 Phone: +41 44 878 9200 3891 Email: l...@cisco.com 3893 Michael C. Richardson 3894 Sandelman Software Works 3895 Email: mcr+i...@sandelman.ca 3896 URI: http://www.sandelman.ca/ _______________________________________________ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima