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
§4 of lamps-nonce suggests using EST's "CSR Attributes" resource to convey the nonce from the CA/RA to the EE. However, nonce would need to be generated afresh for each GET and that is not ideal because state on the CA/RA regardless of the intention of the requestor to actually start an "attested enrolment".
It probably makes sense to add an explicit protocol signal that the requestor can use to trigger nonce generation on the CA/RA side.
Two options:
add another EST API endpoint (e.g., /nonce, /attested-enrolment, ...)
extend the /csrattrs endpoint with a query parameter
In both cases, it makes sense to allow the caller to also specify the size of the nonce. This is because attesters' APIs may have constraints in terms of the challenges they allow (e.g., PSA API.
The text was updated successfully, but these errors were encountered:
@hannestschofenig, @HBrock
§4 of lamps-nonce suggests using EST's "CSR Attributes" resource to convey the nonce from the CA/RA to the EE. However, nonce would need to be generated afresh for each GET and that is not ideal because state on the CA/RA regardless of the intention of the requestor to actually start an "attested enrolment".
It probably makes sense to add an explicit protocol signal that the requestor can use to trigger nonce generation on the CA/RA side.
Two options:
/nonce
,/attested-enrolment
, ...)/csrattrs
endpoint with a query parameterIn both cases, it makes sense to allow the caller to also specify the size of the nonce. This is because attesters' APIs may have constraints in terms of the challenges they allow (e.g., PSA API.
The text was updated successfully, but these errors were encountered: