https://tinyurl.com/yylruorn contains an updated diff against -24.
Benjamin Kaduk via Datatracker wrote:
> Section 5.2
> application/voucher-cms+json The request is a "YANG-defined JSON
> document that has been signed using a CMS structure" as described
> in Section 3 using the JSON encoding described in [RFC7951]. This
> Section 3 does not describe any "sign[ing] using a CMS structure"
> operation.
Yes, I see, the sentence structure is wrong. I have changed it:
- application/voucher-cms+json The request is a "YANG-defined JSON
- document that has been signed using a CMS structure" as described
- in Section 3 using the JSON encoding described in [RFC7951]. This
- voucher media type is defined in [RFC8366] and is also used for
- the pledge voucher-request. The pledge SHOULD sign the request
- using the Section 2.3 credential.
+ application/voucher-cms+json [RFC8366] defines a "YANG-defined JSON
+ document that has been signed using a CMS structure", and the
+ voucher-request described in Section 3 is created in the same way.
+ The media type is the same as defined in [RFC8366]. and is also
+ used for the pledge voucher-request. The pledge MUST sign the
+ request using the Section 2.3 credential.
> To be clear, this is MUST sign, but SHOULD use IDevID (vs. some other
> credential) to sign?
It was SHOULD, because we supported unsigned voucher requests, but we removed
that option. It is now MUST.
> constrained voucher formats are expected in the future. Registrar's
> and MASA's are expected to be flexible in what they accept.
> nits: no apostrophes for plurals.
done.
> proximity-registrar-cert: In a pledge voucher-request this is the
> first certificate in the TLS server 'certificate_list' sequence
> (see [RFC5246]) presented by the registrar to the pledge. This
> MUST be populated in a pledge voucher-request if the "proximity"
> assertion is populated.
> [same comment as above about "end-entity certificate"]
done.
> The registrar validates the client identity as described in EST
> [RFC7030] section 3.3.2. The registrar confirms that the 'proximity'
> assertion and associated 'proximity-registrar-cert' are correct.
> what 'proximity' assertion?
> Does verifying proximity-registrar-cert just mean checking that it's the
> same leaf certificate that the registrar presented? What happens if the
> validation fails?
Yes, it means confirming that the pinned certificate is one's own.
If it fails, then there is a MITM, and the connection should be closed.
{I will use "MITM" until someone tells if me we are using a different term}
I've split that paragraph up, as there are two thoughts, one is about the
ClientCertificate, and the other is about the pinned certificate.
The registrar validates the client identity as described in EST
- [RFC7030] section 3.3.2. The registrar confirms that the 'proximity'
- assertion and associated 'proximity-registrar-cert' are correct.
+ [RFC7030] section 3.3.2.
+
+ The registrar confirms that the assertion is 'proximity' and that
+ pinned 'proximity-registrar-cert' is the Registrar's certificate. If
+ this validation fails, then there a On-Path Attacker (MITM), and the
+ connection MUST be closed after the returning an HTTP 401 error code.
> Section 5.3
doc> A Registrar accepts or declines a request to join the domain, based
doc> on the authenticated identity presented. Automated acceptance
doc> criteria include:
> I suggest "for different networks, examples of automated acceptance
> criteria may include".
doc> If these validations fail the registrar SHOULD respond with an
doc> appropriate HTTP error code.
> Similarly, "If validation fails".
done.
> Section 5.4
doc> The BRSKI-MASA TLS connection is a 'normal' TLS connection
doc> appropriate for HTTPS REST interfaces. The registrar initiates the
doc> connection and uses the MASA URL obtained as described in Section 2.8
doc> for [RFC6125] authentication of the MASA.
> I'd consider mentioning the implicit trust anchor database as well as
> the MASA URL.
edits for another review changed this to:
The BRSKI-MASA TLS connection is a 'normal' TLS connection
appropriate for HTTPS REST interfaces. The registrar initiates the
connection and uses the MASA URL obtained as described in
Section 2.8. The mechanisms in [RFC6125] SHOULD be used
authentication of the MASA. Some vendors will establish explicit (or
private) trust anchors for validating their MASA; this will typically
done as part of a sales channel integration. Registars SHOULD permit
trust anchors to be pre-configured on a per-vendor basis.
doc> The MASA and the registrars SHOULD be prepared to support TLS client
doc> certificate authentication and/or HTTP Basic or Digest aut
