You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
<pid="section-6.3-9">ISO mdoc <span>[<ahref="#ISO.mdoc" class="cite xref">ISO.mdoc</a>]</span> may utilize the Status List mechanism by introducing the <code>status</code> parameter in the Mobile Security Object (MSO) as specified in Section 9.1.2. The <code>status</code> parameter uses the same encoding as a CWT as defined in <ahref="#referenced-token-cose" class="auto internal xref">Section 6.3</a>.<ahref="#section-6.3-9" class="pilcrow">¶</a></p>
<ahref="#section-11.5" class="section-number selfRef">11.5. </a><ahref="#name-exiration-and-caching" class="section-name selfRef">Exiration and Caching</a>
2714
+
<h3id="name-expiration-and-caching">
2715
+
<ahref="#section-11.5" class="section-number selfRef">11.5. </a><ahref="#name-expiration-and-caching" class="section-name selfRef">Expiration and Caching</a>
2716
2716
</h3>
2717
-
<pid="section-11.5-1">Expiration and Caching information is conveyed via the <code>exp</code> and <code>ttl</code> claims as explained in <ahref="#expiry-and-caching" class="auto internal xref">Section 13.7</a>. Clients should check that both values are within reasonable ranges before requesting new Status List Tokens based on these values to prevent accidentally creating unreasonable amounts of requests for a specific URL. Status Issuers could accidentally or maliciously use this mechanism to effectively DDoS the contained URL of the Status Provider.<ahref="#section-11.5-1" class="pilcrow">¶</a></p>
2718
-
<pid="section-11.5-2">Concrete values for both claims heavily depend on the use-case requirements and clients should be configured with lower/upper bounds for these values that fit their respective use-cases.<ahref="#section-11.5-2" class="pilcrow">¶</a></p>
2717
+
<pid="section-11.5-1">Expiration and caching information is conveyed via the <code>exp</code> and <code>ttl</code> claims as explained in <ahref="#expiry-and-caching" class="auto internal xref">Section 13.7</a>. Clients should check that both values are within reasonable ranges before requesting new Status List Tokens based on these values to prevent accidentally creating unreasonable amounts of requests for a specific URL. Status Issuers could accidentally or maliciously use this mechanism to effectively DDoS the contained URL of the Status Provider.<ahref="#section-11.5-1" class="pilcrow">¶</a></p>
2718
+
<pid="section-11.5-2">Concrete values for both claims highly depend on the use-case requirements and clients should be configured with lower/upper bounds for these values that fit their respective use-cases.<ahref="#section-11.5-2" class="pilcrow">¶</a></p>
2719
2719
</section>
2720
2720
</div>
2721
2721
<divid="security-mac">
2722
2722
<sectionid="section-11.6">
2723
2723
<h3id="name-status-list-token-protectio">
2724
2724
<ahref="#section-11.6" class="section-number selfRef">11.6. </a><ahref="#name-status-list-token-protectio" class="section-name selfRef">Status List Token Protection</a>
2725
2725
</h3>
2726
-
<pid="section-11.6-1">This specification allows both, cryptographic signatures, and Message Authentication Codes (MAC) to be used to protect Status List Tokens. Implementers should only use MACs to secure the integrity of Status List Tokens if they fully understand the risks of MACs when compared to digital signatures and especially the requirements of their use-case scenarios. MAC should only be used to secure Status List Tokens for deployments where Status Issuer and Relying Party have a trust relationship and possibility to scurely communicate the MAC out of band or are the same entity and no other entity needs to verify the Status List Token. We expect most deployments to use digital signatures for the prorection of Status List Tokens and impelementers should default to digital signatures if they are unsure.<ahref="#section-11.6-1" class="pilcrow">¶</a></p>
2726
+
<pid="section-11.6-1">This specification allows both, cryptographic signatures, and Message Authentication Codes (MAC) to be used to protect Status List Tokens. Implementers should only use MACs to secure the integrity of Status List Tokens if they fully understand the risks of MACs when compared to digital signatures and especially the requirements of their use-case scenarios. These use-cases typically represent deployments where Status Issuer and Relying Party have a trust relationship and the possibility to securely exchange keys out of band or are the same entity and no other entity needs to verify the Status List Token. We expect most deployments to use digital signatures for the protection of Status List Tokens and implementers should default to digital signatures if they are unsure.<ahref="#section-11.6-1" class="pilcrow">¶</a></p>
0 commit comments