Merge branch 'main' into gen_art_review

Author: paulbastian

draft-ietf-oauth-status-list.md

@@ -445,7 +445,7 @@ The following is a non-normative example of a Status List Token in JWT format:
 
 ## Status List Token in CWT Format {#status-list-token-cwt}
 
-The Status List Token MUST be encoded as a "CBOR Web Token (CWT)" according to {{RFC8392}}.
+The Status List Token MUST be encoded as a "CBOR Web Token (CWT)" according to {{RFC8392}}. The Status List Token MUST not be tagged with the tags defined in section 6 of {{RFC8392}} or in section 2 of {{RFC9052}}.
 
 The following content applies to the protected header of the CWT:
 
@@ -463,11 +463,11 @@ The following additional rules apply:
 
 1. The CWT MAY contain other claims.
 
-2. The CWT MUST be secured using a cryptographic signature or MAC algorithm. Relying Parties MUST reject CWTs with an invalid signature.
+1. The CWT MUST be secured using a cryptographic signature or MAC algorithm. Relying Parties MUST reject CWTs with an invalid signature.
 
-3. Relying Parties MUST reject CWTs that are not valid in all other respects per "CBOR Web Token (CWT)" {{RFC8392}}.
+1. Relying Parties MUST reject CWTs that are not valid in all other respects per "CBOR Web Token (CWT)" {{RFC8392}}.
 
-4. Application of additional restrictions and policies are at the discretion of the Relying Party.
+1. Application of additional restrictions and policies are at the discretion of the Relying Party.
 
 The following is a non-normative example of a Status List Token in CWT format in Hex:
 
@@ -1042,7 +1042,7 @@ This malicious behavior can be detected by Relying Parties that request large am
 
 ## Observability of Relying Parties {#privacy-relying-party}
 
-Once the Relying Party receives the Referenced Token, this enables them to request the Status List to validate its status through the provided `uri` parameter and look up the corresponding `index`. However, the Relying Party may persistently store the `uri` and `index` of the Referenced Token to request the Status List again at a later time. By doing so regularly, the Relying Party may create a profile of the Referenced Token's validity status. This behaviour may be intended as a feature, e.g. for an identity proofing (e.g. Know-Your-Customer process in finance industry) that requires regular validity checks, but might also be abused in cases where this is not intended and unknown to the Holder, e.g. profiling the suspension of a driving license or checking the employment status of an employee credential.
+Once the Relying Party receives the Referenced Token, this enables them to request the Status List to validate its status through the provided `uri` parameter and look up the corresponding `index`. However, the Relying Party may persistently store the `uri` and `index` of the Referenced Token to request the Status List again at a later time. By doing so regularly, the Relying Party may create a profile of the Referenced Token's validity status. This behaviour may be intended as a feature, e.g. for an identity proofing (e.g. Know-Your-Customer process in finance industry) that requires regular validity checks, but might also be abused in cases where this is not intended and unknown to the Holder, e.g. profiling the suspension of an employee credential.
 
 This behaviour could be mitigated by:
 
@@ -1094,8 +1094,6 @@ There are strong privacy concerns that have to be carefully taken into considera
 
 As previously explained, there is the potential risk of observability by Relying Parties (see [](#privacy-relying-party)) and Outsiders (see [](#privacy-outsider)). That means that any Status Type that transports special information about a Referenced Token can leak information to other parties. This document defines one additional Status Type with "SUSPENDED" that conveys such additional information.
 
-A concrete example for "SUSPENDED" would be a driver's license, where the digital driver's license might still be useful to prove other information about its holder, but suspended could signal that it should not be considered valid in the scope of being allowed to drive a car. This case could be solved by either introducing a special status type, or by revoking the Referenced Token and re-issuing with changed attributes. For such a case, the status type suspended might be dangerous as it would leak the information of a suspended driver's license even if the driver's license is used as a mean of identification and not in the context of driving a car. This could also allow for the unwanted collection of statistical data on the status of driver's licenses.
-
 Ecosystems that want to use other Status Types than "VALID" and "INVALID" should consider the possible leakage of data and profiling possibilities before doing so and evaluate if revocation and re-issuance might a better fit for their use-case.
 
 # Implementation Considerations {#implementation}
@@ -1502,41 +1500,7 @@ IANA is requested to register the following OID "1.3.6.1.5.5.7.3.TBD" in the "SM
 
 IANA is requested to register the following OID "1.3.6.1.5.5.7.0.TBD" in the "SMI Security for PKIX Module Identifier" registry (1.3.6.1.5.5.7.0), this OID is defined in section [](#asn1-module).
 
-# Appendix A. ASN.1 Module {#asn1-module}
-{:numbered="false"}
-
-The following module adheres to ASN.1 specifications {{X.680}} and {{X.690}}.
-
-~~~
-<CODE BEGINS>
-
-  OauthStatusSigning-EKU
-    { iso(1) identified-organization(3) dod(6) internet(1)
-      security(5) mechanisms(5) pkix(7) id-mod(0)
-      id-mod-oauth-status-signing-eku (TBD) }
-
-  DEFINITIONS IMPLICIT TAGS ::=
-  BEGIN
-
-  -- OID Arc
-
-  id-kp OBJECT IDENTIFIER ::=
-    { iso(1) identified-organization(3) dod(6) internet(1)
-      security(5) mechanisms(5) pkix(7) kp(3) }
-
-  -- OAuth Extended Key Usage
-
-  id-kp-oauthStatusSigning OBJECT IDENTIFIER ::= { id-kp TBD }
-
-  END
-
-<CODE ENDS>
-~~~
-
---- back
-
 # Acknowledgments
-{:numbered="false"}
 
 We would like to thank
 Andrii Deinega,
@@ -1565,13 +1529,43 @@ Torsten Lodderstedt
 
 for their valuable contributions, discussions and feedback to this specification.
 
+--- back
+
+# ASN.1 Module {#asn1-module}
+
+The following module adheres to ASN.1 specifications {{X.680}} and {{X.690}}.
+
+~~~
+<CODE BEGINS>
+
+  OauthStatusSigning-EKU
+    { iso(1) identified-organization(3) dod(6) internet(1)
+      security(5) mechanisms(5) pkix(7) id-mod(0)
+      id-mod-oauth-status-signing-eku (TBD) }
+
+  DEFINITIONS IMPLICIT TAGS ::=
+  BEGIN
+
+  -- OID Arc
+
+  id-kp OBJECT IDENTIFIER ::=
+    { iso(1) identified-organization(3) dod(6) internet(1)
+      security(5) mechanisms(5) pkix(7) kp(3) }
+
+  -- OAuth Extended Key Usage
+
+  id-kp-oauthStatusSigning OBJECT IDENTIFIER ::= { id-kp TBD }
+
+  END
+
+<CODE ENDS>
+~~~
+
 # Size comparison {#size-comparison}
-{:unnumbered}
 
 The following tables show a size comparison for a Status List (compressed byte array as defined in [](#status-list-byte-array) and a compressed Byte Array of UUIDs (as an approximation for a Certificate Revocation List). Readers must be aware that these are not sizes for complete Status List Tokens in JSON/CBOR nor Certificate Revocation Lists (CRLs), as they don't contain metadata, certificates and signatures.
 
 ## Status List size for varying sizes and revocation rates
-{:unnumbered}
 
 | Size | 0.01%   | 0.1%     | 1%       | 2%       | 5%       | 10%      | 25%       | 50%      | 75%       | 100%    |
 | 100k | 81 B    | 252 B    | 1.4 KB   | 2.3 KB   | 4.5 KB   | 6.9 KB   | 10.2 KB   | 12.2 KB  | 10.2 KB   | 35 B    |
@@ -1581,7 +1575,6 @@ The following tables show a size comparison for a Status List (compressed byte a
 {: title="Status List Size examples for varying sizes and revocation rates"}
 
 ## Compressed array of UUIDv4 (128 bit UUIDs) for varying sizes and revocation rates
-{:unnumbered}
 
 This is a simple approximation of a Certificate Revocation List using an array of UUIDs without any additional metadata (128 bit UUID per revoked entry).
 
@@ -1593,14 +1586,12 @@ This is a simple approximation of a Certificate Revocation List using an array o
 {: title="Size examples for 128 bit UUIDs for varying sizes and revocation rates"}
 
 # Test vectors for Status List encoding {#test-vectors}
-{:unnumbered}
 
 All examples here are given in the form of JSON or CBOR payloads. The examples are encoded according to [](#status-list-json) for JSON and [](#status-list-cbor) for CBOR. The CBOR examples are displayed as hex values.
 
 All values that are not mentioned for the examples below can be assumed to be 0 (VALID). All examples are initialized with a size of 2^20 entries.
 
 ## 1 bit Status List
-{:unnumbered}
 
 The following example uses a 1 bit Status List (2 possible values):
 
@@ -1631,7 +1622,6 @@ CBOR encoding:
 ~~~~~~~~~~
 
 ## 2 bit Status List
-{:unnumbered}
 
 The following example uses a 2 bit Status List (4 possible values):
 
@@ -1662,7 +1652,6 @@ CBOR encoding:
 ~~~~~~~~~~
 
 ## 4 bit Status List
-{:unnumbered}
 
 The following example uses a 4 bit Status List (16 possible values):
 
@@ -1697,7 +1686,6 @@ CBOR encoding:
 ~~~~~~~~~~
 
 ## 8 bit Status List
-{:unnumbered}
 
 The following example uses a 8 bit Status List (256 possible values):
 
@@ -1985,6 +1973,10 @@ CBOR encoding:
 * slightly restructure/clarify referenced token cose section
 * Add ASN.1 module
 * many nits and improvements from genart review
+* remove cose_sign1 tag from statuslist in cwt form examples
+* slightly restructure/clarify referenced token cose section
+* Add ASN.1 module
+* removed DL suspension example
 
 -13
 

src/requirements.txt

@@ -2,6 +2,6 @@
 git+https://github.com/wbond/oscrypto.git@1547f535001ba568b239b8797465536759c742a3
 # Normal dependencies
 jwcrypto==1.5.6
-cbor2==5.6.2
-cwt==2.7.4
+cbor2==5.7.1
+cwt==3.2.0
 py_markdown_table==1.3.0

src/status_token.py

@@ -1,8 +1,8 @@
 import json
-from datetime import datetime, timedelta
+from datetime import UTC, datetime, timedelta
 from typing import Dict
 
-from cbor2 import dumps
+from cbor2 import CBORTag, dumps
 from cwt import COSE, COSEHeaders, COSEKey, CWTClaims
 from jwcrypto import jwk, jwt
 
@@ -77,7 +77,7 @@ def get(self, pos: int) -> int:
 
     def buildJWT(
         self,
-        iat: datetime = datetime.utcnow(),
+        iat: datetime = datetime.now(UTC),
         exp: datetime | None = None,
         ttl: timedelta | None = None,
         optional_claims: Dict | None = None,
@@ -115,7 +115,7 @@ def buildJWT(
 
     def buildCWT(
         self,
-        iat: datetime = datetime.utcnow(),
+        iat: datetime = datetime.now(UTC),
         exp: datetime | None = None,
         ttl: timedelta | None = None,
         optional_claims: Dict | None = None,
@@ -158,10 +158,12 @@ def buildCWT(
         # The sender side:
         sender = COSE.new()
         encoded = sender.encode(
-            dumps(claims),
-            key,
+            payload=dumps(claims),
+            key=key,
             protected=protected_header,
             unprotected=unprotected_header,
         )
 
+        # removes cose_sign1 tag (only 1 byte long for tag 18)
+        encoded = encoded[1:]
         return encoded