Draft: draft-ietf-anima-brski-prm

Commentary: Related to issue 
 Thank you  . We may then 
 Section 5.5.1 mentions the Pledge responds 406 when it can not produce the enrollment request or voucher request . This seems inappropriate , see and also for use of 406 by MASA . The use of 406 is thus for the case that the  receives another media type than " application / json " . E.g. responses that would be applicable are : 400   - if there 's some error in the format of the request , e.g. missing field , wrong data types , etc . Or it 's not valid JSON even though the media type says application / json . 403 Forbidden - see for example , or . For example if the Pledge performs some initial verification as described in 5.5.1 below figure 5 and finds that the Registrar cert is actually not from a Registrar ( missing " RA " flag ) . Or it 's a chain which does n't correctly validate . It would be useful to include possible error cases on the  side and what it should do then ( e.g. respond 4xx errors as in the examples above ) . 
 okay , good point . Included the following : For PVR If the pledge is unable to construct the PVR it SHOULD respond with a HTTP error code to the registrar - agent to indicate that it is not able to create the PVR . Error codes MAY be used : 400 : if the pledge detected an error in the format of the request , e.g .. missing field , wrong data types , etc . or it 's not valid JSON even though the PVR media type was set to . 403 : if the pledge detected that parameter from the trigger message to create the PVR were not valid , e.g. , the LDevID ( Reg ) certificate . For the PER I include a little deviating text , as the trigger may be empty : If the pledge is unable to construct the PER it SHOULD respond with a HTTP error code to the registrar - agent to indicate that it is not able to create the PER . Error codes MAY be used : 400 : if the pledge detected an error in the format of the request or it 's not valid JSON even though the PER media type was set to . 403 : if the pledge detected that parameter ( if provided ) from the trigger message to create the PER were not valid . could be closed ? 
 Changes included in section 5.5.1 below Figure 6 and Figure 8 . please check and provide your feedback . 
 I 'd like to provide an additional pass on the text with the following : terminology : " HTTP status code " is the right name 415 should be used if an unsupported or unknown media type is being pushed into a resource ( 406 only if the requested media type as listed in an Accep theader is not acceptable ) Add names of HTTP error codes for readability ( hope that 's ok - saves a lot of lookups ! ) fix typos I 'll create a PR which makes the reviewing of changes easier . 
 Merged the proposed changes and closing issue
it may also respond with a suitable 4xx or 5xx error HTTP response
code as described in section 5.6 of RFC8995.
it may also respond with a suitable 4xx or 5xx status code as
described in section 5.6 of RFC8995.
400: if the pledge detected an error in the format of the request,
e.g. missing field, wrong data types, etc. or it's not valid JSON
even though the PVR media type was set to "application/json".
403: if the pledge detected that parameter from the trigger
message to create the PVR were not valid, e.g., the LDevID (Reg)
certificate.
Upon receiving the voucher-request trigger, the pledge SHALL
construct the body of the PVR as defined in RFC8995.  It will contain
additional information provided by the registrar-agent as specified
in the following.  This PVR becomes a JSON-in-JWS object as defined
in I-D.ietf-anima-jws-voucher.  If the pledge is unable to construct
the PVR it SHOULD respond with a HTTP error status code to the
registrar-agent to indicate that it is not able to create the PVR.
400 Bad Request: if the pledge detected an error in the format of
the request, e.g. missing field, wrong data types, etc. or it's
not valid JSON even though the PVR media type was set to
"application/json".
403 Forbidden: if the pledge detected that one or more security
parameters from the trigger message to create the PVR were not
valid, e.g., the LDevID (Reg) certificate.
The registrar-agent PER trigger Content-Type header is: "application/
json" with an empty body.  Note that using HTTP POST allows for an
empty body, but also to provide additional data, like CSR attributes
or information about the enroll type: "enroll-generic-cert" or
"reenroll-generic-cert".  The "enroll-generic-cert" case is shown in
raer.
The registrar-agent PER trigger Content-Type header is: "application/
json" with an empty body by default.  Note that using HTTP POST
allows for an empty body, but also to provide additional data, like
CSR attributes or information about the enroll type: "enroll-generic-
cert" or "reenroll-generic-cert".  The "enroll-generic-cert" case is
shown in raer.
400: if the pledge detected an error in the format of the request
or it's not valid JSON even though the PER media type was set to
"application/json".
403: if the pledge detected that parameter (if provided) from the
trigger message to create the PER were not valid.
If the pledge is unable to construct the PER it SHOULD respond with a
HTTP 4xx/5xx status code to the registrar-agent to indicate that it
is not able to create the PER.
400 Bad Request: if the pledge detected an error in the format of
the request or detected invalid JSON even though the PER media
type was set to "application/json".
403 Forbidden: if the pledge detected that one or more security
parameters (if provided) from the trigger message to create the
PER are not valid.
406 Not Acceptable: if the request's Accept header indicates a
type that is unknown or unsupported.  For example, a type other
than "application/jose+json".
415 Unsupported Media Type: if the request's Content-Type header
indicates a type that is unknown or unsupported.  For example, a
type other than 'application/json'.
If the validation fails the registrar SHOULD respond with HTTP 404
error code to the registrar-agent.  HTTP 406 error code SHOULD be
used if the format of PVR is unknown.
If the validation fails the registrar SHOULD respond with HTTP 404
Not Found status code to the registrar-agent.  HTTP 406 Not
Acceptable status code SHOULD be used if the Content-Type indicated
by the Accept header is unknown or unsupported.
If validation fails, the MASA SHOULD respond with an HTTP error code
to the registrar.  The HTTP error codes are kept the same as defined
in section 5.6 of RFC8995, and comprise the codes: 403, 404, 406, and
415.
The expected voucher-response format for the pledge-responder-mode
the "application/voucher-jws+json" as defined in I-D.ietf-anima-jws-
voucher is applied.  If the MASA detects that the Accept header of
the PVR does not match the "application/voucher-jws+json" it SHOULD
respond with the HTTP error code 406 as the pledge will not be able
to parse the response.  The voucher syntax is described in detail by
RFC8366.  MASA-vr shows an example of the contents of a voucher.
If validation fails, the MASA SHOULD respond with an HTTP 4xx client
error status code to the registrar.  The HTTP error status codes are
kept the same as defined in section 5.6 of RFC8995, and comprise the
codes: 403, 404, 406, and 415.
The expected voucher-response format for the pledge-responder-mode
the "application/voucher-jws+json" as defined in I-D.ietf-anima-jws-
voucher is applied.  If the MASA detects that the Accept header of
the PVR does not match the "application/voucher-jws+json" it SHOULD
respond with the HTTP status code 406 Not Acceptable as the pledge
will not be able to parse the response.  The voucher syntax is
described in detail by RFC8366.  MASA-vr shows an example of the
contents of a voucher.
The registrar SHOULD respond with an HTTP 200 in the success case or
fail with HTTP 4xx/5xx codes as defined by the HTTP standard.
The registrar SHOULD respond with an HTTP 200 OK in the success case
or fail with HTTP 4xx/5xx status codes as defined by the HTTP
standard.
If validation of the wrapping signature fails, the pledge SHOULD
respond with the HTTP 403 error code.  The HTTP 406 error code SHOULD
be used, if the response is in an unknown format.
If validation of the wrapping signature or another security check
fails, the pledge SHOULD respond with the HTTP 403 Forbidden status
code.  The HTTP 415 Unsupported Media Type status code SHOULD be
used, if the Content-Type of the request is in an unknown or
unsupported format.  The HTTP 400 Bad Request status code SHOULD be
used, if the pledge detects errors in the encoding of the payload.
According to RFC8995 section 5.7, the registrar SHOULD respond with
an HTTP 200 in the success case or fail with HTTP 4xx/5xx codes as
defined by the HTTP standard.  The registrar-agent may use the
response to signal success / failure to the service technician
operating the registrar agent.  Within the server logs the server
SHOULD capture this telemetry information.
According to RFC8995 section 5.7, the registrar SHOULD respond with
an HTTP 200 OK in the success case or fail with HTTP 4xx/5xx status
codes as defined by the HTTP standard.  The registrar-agent may use
the response to signal success / failure to the service technician
operating the registrar agent.  Within the server logs the server
SHOULD capture this telemetry information.
According to RFC8995 section 5.9.4, the registrar SHOULD respond with
an HTTP 200 in the success case or fail with HTTP 4xx/5xx codes as
defined by the HTTP standard.  Based on the failure case the
registrar MAY decide that for security reasons the pledge is not
allowed to reside in the domain.  In this case the registrar MUST
revoke the certificate.  The registrar-agent may use the response to
signal success / failure to the service technician operating the
registrar agent.  Within the server log the registrar SHOULD capture
this telemetry information.
According to RFC8995 section 5.9.4, the registrar SHOULD respond with
an HTTP 200 OK in the success case or fail with HTTP 4xx/5xx status
codes as defined by the HTTP standard.  Based on the failure case the
registrar MAY decide that for security reasons the pledge is not
allowed to reside in the domain.  In this case the registrar MUST
revoke the certificate.  The registrar-agent may use the response to
signal success / failure to the service technician operating the
registrar agent.  Within the server log the registrar SHOULD capture
this telemetry information.
The following assumes that a registrar-agent may need to query the
status of a pledge.  This information may be useful to solve errors,
when the pledge was not able to connect to the target domain during
the bootstrapping.  The pledge MAY provide a dedicated endpoint to
supply status-requests.
The following assumes that a registrar-agent may need to query the
status of a pledge.  This information may be useful to solve errors,
when the pledge was not able to connect to the target domain during
the bootstrapping.  The pledge MAY provide a dedicated endpoint to
accept status-requests.
Pledge: may already possess domain credentials and LDevID(Pledge).
Pledge: may already possess domain credentials and LDevID(Pledge),
or may not possess one or both of these.
In case "factory-default" the pledge does not possess the domain
certificate resp. the domain trust-anchor.  It will not be able to
verify the signature of the registrar-agent in the bootstrapping-
status request.  In cases "vouchered" and "enrolled" the pledge
already possesses the domain certificate (has domain trust-anchore)
and can therefore validate the signature of the registrar-agent.  If
validation of the JWS signature fails, the pledge SHOULD respond with
the HTTP 403 error code.  The HTTP 406 error code SHOULD be used, if
the response is in an unknown format.
In case "factory-default" the pledge does not possess the domain
certificate resp. the domain trust-anchor.  It will not be able to
verify the signature of the registrar-agent in the bootstrapping-
status request.  In cases "vouchered" and "enrolled" the pledge
already possesses the domain certificate (has domain trust-anchore)
and can therefore validate the signature of the registrar-agent.  If
validation of the JWS signature fails, the pledge SHOULD respond with
the HTTP 403 Forbidden status code.  The HTTP 406 Not Acceptable
status code SHOULD be used, if the Accept header in the request
indicates an unknown or unsupported format.  The HTTP 415 Unsupported
Media Type status code SHOULD be used, if the Content-Type of the
request is an unknown or unsupported format.  The HTTP 400 Bad
Request status code SHOULD be used, if the Accept/Content-Type
headers are correct but nevertheless the status-request cannot be
correctly parsed.