Orie Steele has entered the following ballot position for draft-ietf-anima-brski-prm-18: No Objection
When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ for more information about how to handle DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-anima-brski-prm/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- # Orie Steele, ART AD, comments for draft-ietf-anima-brski-prm-18 CC @OR13 * line numbers: - https://author-tools.ietf.org/api/idnits?url=https://www.ietf.org/archive/id/draft-ietf-anima-brski-prm-18.txt&submitcheck=True * comment syntax: - https://github.com/mnot/ietf-comments/blob/main/format.md * "Handling Ballot Positions": - https://ietf.org/about/groups/iesg/statements/handling-ballot-positions/ ## Comments ### RFC 3339 or RFC 9557? ``` 1500 The created-on member SHALL contain the current date and time at tPVR 1501 creation as standard date/time string as defined in Section 5.6 of 1502 [RFC3339]. ``` See https://datatracker.ietf.org/doc/html/rfc9557#inconsistent ### Attacker controlled time? ``` 1580 * created-on: SHALL contain the current date and time at PVR 1581 creation as standard date/time string as defined in Section 5.6 of 1582 [RFC3339]; if the pledge does not have synchronized time, it SHALL 1583 use the created-on value from the JSON Agent-Signed Data received 1584 with the tPVR artifact and SHOULD advance that value based on its 1585 local clock to reflect the PVR creation time ``` Is there any risk of this section interacting with the provisional status? See https://datatracker.ietf.org/doc/html/rfc8995#section-5.1-6 ### nonce ``` 1587 * nonce: SHALL contain a cryptographically strong pseudo-random 1588 number ``` Do you mean a single number? or do you mean a sequence of byte of some length derived from some PRNG? Consider language like https://datatracker.ietf.org/doc/html/draft-ietf-oauth-selective-disclosure-jwt-17#section-9.3 ### "created-on" vs "iat" ``` 1826 { 1827 "alg": "ES256", 1828 "x5c": [ 1829 "base64encodedvalue==", 1830 "base64encodedvalue==" 1831 ], 1832 "crit": ["created-on"], 1833 "created-on": "2022-09-13T00:00:02.000Z" 1834 } ``` Per https://datatracker.ietf.org/doc/html/rfc7519#section-5.3 it is possible to replicate claims in headers. I wonder why the existing `iat` claim is not sufficient for this use case, aside from being an integer. It also seems like an integer based creation time would be easier and safer to use. ### application/pkcs7-mime ``` 2407 A successful interaction with the Key Infrastructure will result in a 2408 pledge EE certificate signed by the domain owner (e.g., LDevID 2409 certificate). The registrar MUST reply to the Registrar-Agent with 2410 the Enroll-Response (Enroll-Resp) as defined in Section 7.4.2 in the 2411 body of an HTTP 200 OK response. In the response header, the 2412 Content-Type field MUST be set to application/pkcs7-mime. ``` https://datatracker.ietf.org/doc/html/rfc2311#section-3.2 I don't think you want the optional "smime-type" parameter, but you might want to comment on envelopedData vs signedData here. ### application/voucher-jws+json vs application/jose+json ``` 2662 defined in Section 7.3.6. In the request header, the Content-Type 2663 field MUST be set to application/voucher-jws+json as defined in 2664 [I-D.ietf-anima-jws-voucher] and the Accept field SHOULD be set to 2665 application/jose+json. ``` I found myself wondering which objects use `application/voucher-jws+json` and which use `application/jose+json`. A simple table might help explain this once upfront. Are there cases where `application/jose+json` is used for encryption? ### reason-context ``` 2771 * reason-context: contains a JSON object that provides additional 2772 information specific to a failure; in contrast to Section 5.7 of 2773 [RFC8995], MUST be provided; SHOULD NOT provide information 2774 beneficial to an attacker ``` Consider giving this more structure, like: https://datatracker.ietf.org/doc/html/rfc7807#section-3 Also, seems potentially conflicting definitions exist: ``` 3474 "reason-context": { * $$arbitrary-map } ``` Yet there are map keys defined with very specific semantics, consider gathering them in a table. ## Nits ### Consider clarifying not base64url-encoded ``` 2567 format. For JSON syntax, the octet-based certificates MUST be 2568 base64-encoded. It SHALL contain one or more domain CA (root or 2569 issuing) certificates. ``` Since this is a common point of confusion, and you are using base64url nearby. You might highlight this once for both `x5c` and `x5bag`. ### Registrar Endpoints ``` 1071 +================+=========================+========================+ 1072 | Endpoint | Operation | Exchange and Artifacts | 1073 +================+=========================+========================+ 1074 | requestenroll | Supply PER | Section 7.4 | 1075 | | to Registrar | | 1076 +----------------+-------------------------+------------------------+ 1077 | wrappedcacerts | Obtain CA | Section 7.5 | 1078 | | Certificates | | 1079 +----------------+-------------------------+------------------------+ 1081 Table 2: Additional Well-Known Endpoints on a BRSKI-PRM Registrar ``` Some `-` / `_` could improve readability of these... later in the document I see `voucher_status` and `enrollstatus`... _______________________________________________ Anima mailing list -- [email protected] To unsubscribe send an email to [email protected]
