Hi Orie, thanks a lot for your feedback, see my comments inline [TW] Changes to the draft are on anima-wg/anima-brski-prm repo: https://github.com/anima-wg/anima-brski-prm/commit/884e7387fa6b880d13eff1cfcb885df68056254b and will be included in the next version to IETF.
Best regards Thomas Von: Orie Steele via Datatracker <nore...@ietf.org> Datum: Montag, 14. April 2025 um 23:46 An: The IESG <i...@ietf.org> Cc: draft-ietf-anima-brski-...@ietf.org <draft-ietf-anima-brski-...@ietf.org>, anima-cha...@ietf.org <anima-cha...@ietf.org>, anima@ietf.org <anima@ietf.org>, i...@kovatsch.net <i...@kovatsch.net>, t...@cs.fau.de <t...@cs.fau.de>, i...@kovatsch.net <i...@kovatsch.net> Betreff: Orie Steele's No Objection on draft-ietf-anima-brski-prm-18: (with COMMENT) 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://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fabout%2Fgroups%2Fiesg%2Fstatements%2Fhandling-ballot-positions%2F&data=05%7C02%7Cthomas-werner%40siemens.com%7C948802c8ed30420e759408dd7b9dcfe9%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C638802639947028986%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=79Sing5bJ2I3X5jx3MdD0kPSBrGHdjFyGMs6yl%2BPl%2Fg%3D&reserved=0<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://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-ietf-anima-brski-prm%2F&data=05%7C02%7Cthomas-werner%40siemens.com%7C948802c8ed30420e759408dd7b9dcfe9%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C638802639947056525%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=i45wQOczTxkHRa%2B%2BjA6CRU%2Bao%2FRUy6sCjh0JG02m1O4%3D&reserved=0<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://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fauthor-tools.ietf.org%2Fapi%2Fidnits%3Furl%3Dhttps%3A%2F%2Fwww.ietf.org%2Farchive%2Fid%2Fdraft-ietf-anima-brski-prm-18.txt%26submitcheck%3DTrue&data=05%7C02%7Cthomas-werner%40siemens.com%7C948802c8ed30420e759408dd7b9dcfe9%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C638802639947073120%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=NVPkNf3pkjWnpTVUTQC9nhf%2B5O%2B8maD423ab%2FSz6HQ8%3D&reserved=0<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://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fmnot%2Fietf-comments%2Fblob%2Fmain%2Fformat.md&data=05%7C02%7Cthomas-werner%40siemens.com%7C948802c8ed30420e759408dd7b9dcfe9%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C638802639947088338%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=tnaxCmbzKMm0c8%2BWcFiN6rra6NPtG2tkK1xMHTgq2gA%3D&reserved=0<https://github.com/mnot/ietf-comments/blob/main/format.md> * "Handling Ballot Positions": - https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fietf.org%2Fabout%2Fgroups%2Fiesg%2Fstatements%2Fhandling-ballot-positions%2F&data=05%7C02%7Cthomas-werner%40siemens.com%7C948802c8ed30420e759408dd7b9dcfe9%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C638802639947105031%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=HS3WD71%2FAT27sgZvicXK%2FjiotoWD7V1thx34X1i7T%2Bw%3D&reserved=0<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]. ``` • [TW] BRSKI-PRM relies on BRSKI RFC 8995, this does not use extensions as defined in RFC 9557, so we would stay with RFC 3339. See https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Frfc9557%23inconsistent&data=05%7C02%7Cthomas-werner%40siemens.com%7C948802c8ed30420e759408dd7b9dcfe9%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C638802639947123087%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=7dmiIzvHXZDdfnqJYqPfwLNNriXKMuehv3gUic29L5s%3D&reserved=0<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://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Frfc8995%23section-5.1-6&data=05%7C02%7Cthomas-werner%40siemens.com%7C948802c8ed30420e759408dd7b9dcfe9%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C638802639947140892%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=FveZBbpJ9LISYlwjbHcTnSAY4QE0pCaDBpoffqg%2Bc2Y%3D&reserved=0<https://datatracker.ietf.org/doc/html/rfc8995#section-5.1-6> • [TW] In BRSKI-PRM we have no relation between the signed objects and the provisional-accept of TLS in BRSKI. ### 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://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-ietf-oauth-selective-disclosure-jwt-17%23section-9.3&data=05%7C02%7Cthomas-werner%40siemens.com%7C948802c8ed30420e759408dd7b9dcfe9%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C638802639947155249%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=YJ54IDh%2FbGopFqbMOQyGH98Sw1gZZ8ONMkEQgYvWh0A%3D&reserved=0<https://datatracker.ietf.org/doc/html/draft-ietf-oauth-selective-disclosure-jwt-17#section-9.3> • [TW] Proposal to enhance: OLD: * nonce: SHALL contain a cryptographically strong pseudo-random number NEW: * `nonce`: SHALL contain a cryptographically strong random or pseudo-random number nonce (see {{Section 6.2 of !RFC4086}}). ### "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://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Frfc7519%23section-5.3&data=05%7C02%7Cthomas-werner%40siemens.com%7C948802c8ed30420e759408dd7b9dcfe9%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C638802639947168883%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=JMFMf3aZiHzFUrvib6W3EqIWWTLeXWqWQUKfRgqinH8%3D&reserved=0<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. •[TW] The reusage of "created-on“ originates from Voucher RFC 8366 and BRSKI RFC 8995, both are not using „iat“ claim. BRSKI-PRM is intended to be constistent with Voucher and BRSKI specifications. The "created-on" is combined with "crit" in the PER header to enforce the registrar to validate the timely correlation between the PER and previous exchanges. ### 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://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Frfc2311%23section-3.2&data=05%7C02%7Cthomas-werner%40siemens.com%7C948802c8ed30420e759408dd7b9dcfe9%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C638802639947182743%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=OJG45gk3eZJmBq6QhO4YXafjDzfgNCNaGrIi8AADDDo%3D&reserved=0<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. • [TW] The text is enhanced as follows, as the behaviour is defined in RFC 7030 and we are not changing it. OLD: Content-Type field MUST be set to application/pkcs7-mime. NEW: Content-Type field MUST be set to `application/pkcs7-mime` with an smime-type parameter `certs-only`, as specified in {{!RFC7030}} and {{!RFC5273}}. ### 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? •[TW] following enhancement to clarify the response encoding OLD: In the request header, the Content-Type field MUST be set to application/voucher-jws+json as defined in [I-D.ietf-anima-jws-voucher] and the Accept field SHOULD be set to application/jose+json. NEW: In the request header, the Content-Type field MUST be set to „application/voucher-jws+json“ as defined in [I-D.ietf-anima-jws-voucher] and the Accept field SHOULD be set to `application/jose+json`, to indicate the encoding of the vStatus response object status telemetry message. ### 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 ``` •[TW] Proposal to change from: OLD: reason-context: contains a JSON object that provides additional information specific to a failure; in contrast to Section 5.7 of [RFC8995], MUST be provided; SHOULD NOT provide information beneficial to an attacker NEW: reason-context: contains a JSON object that provides additional information specific to a failure; in contrast to Section 5.7 of [RFC8995], MUST be provided Consider giving this more structure, like: https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Frfc7807%23section-3&data=05%7C02%7Cthomas-werner%40siemens.com%7C948802c8ed30420e759408dd7b9dcfe9%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C638802639947196375%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=beL%2Bs5t1dW5gVAxEbI4%2BISHfxSgCnACI3YsCRdbe5RI%3D&reserved=0<https://datatracker.ietf.org/doc/html/rfc7807#section-3> • [TW] Proposal to provide more structure: OLD: { 2786 "version": 1, 2787 "status": true, 2788 "reason": "Voucher successfully processed.", 2789 "reason-context": { 2790 "pvs-details": "Current date 5/23/2024" 2791 } 2792 } 2793 Figure 32: JSON Voucher Status Data Success Example 2795 { 2796 "version": 1, 2797 "status": false, 2798 "reason": "Failed to authenticate MASA certificate.", 2799 "reason-context": { 2800 "pvs-details": "Current date 1/1/1970 < valid from 1/1/2023" 2801 } 2802 } 2804 Figure 33: JSON Voucher Status Data Failure Example NEW: HTTP/1.1 200 OK Content-Type: application/jose+json Content-Language: en { "version": 1, "status": true, "reason": "Voucher successfully processed.", "reason-context": { "pvs-details": "Current date 5/23/2024" } } Figure 32: JSON Voucher Status Data Success Example HTTP/1.1 400 Bad Request Content-Type: application/jose+json Content-Language: en { "version": 1, "status": false, "reason": "Failed to authenticate MASA certificate.", "reason-context": { "pvs-details": "Current date 1/1/1970 < valid from 1/1/2023" } } Figure 33: JSON Voucher Status Data Failure Example 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. •[TW] Created an issue to double check conflicting definitions and consider gathering them in a table: https://github.com/anima-wg/anima-brski-prm/issues/147 ## 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`. •[TW] Thanks, this would be added: OLD 339 This document includes many examples that would contain many long 340 sequences of base64-encoded objects with no content directly 341 comprehensible to a human reader. In order to keep those examples 342 short, they use the token base64encodedvalue== as a placeholder for 343 base64 data. The full base64 data is included in the appendices of 344 this document. NEW This document includes many examples that would contain many long sequences of base64-encoded objects with no content directly comprehensible to a human reader. In order to keep those examples short, they use the token `base64encodedvalue==` as a placeholder for base64 data. The full base64 data is included in the appendices of this document. Note, base64-encoded values are mainly used for fields related to certificates like: x5bag, x5c, agent-provided-proximity-registrar-cert, p10-csr ### 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`... • [TW] Table 2 defines the Additional Well-Known Endpoints on a BRSKI-PRM Registrar, `voucher_status` and `enrollstatus` endpoints are reused from BRSKI RFC 8995. We would like to keep the them as is.
_______________________________________________ Anima mailing list -- anima@ietf.org To unsubscribe send an email to anima-le...@ietf.org
