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
The benefit is that User is un-aware of the Cose_Sign1 Message, but just supplies the needed inputs.
Also, it is less prone to errors on the user side.
The obvious drawback, the interface is simple (not richer), which may be needed for some applications?
In my view the benefits outweigh the disadvantages, so should be adapted however, a careful impact analysis on dependencies/users of go-cose Veraison library needs to be evaluated.
The text was updated successfully, but these errors were encountered:
yogeshbdeshpande
changed the title
Consider Interface simplicity and safer usage of Sign1 and
Consider Interface simplicity and safer usage of Sign1
May 19, 2022
The useability drawback of sole Sign1() function is that it is not possible to modify the unprotected headers after signing. Scenarios like counter signatures and timestamps are not achievable with Sign1() only.
Here's an example flow:
User Instantiates m *Sign1Message Message
User sets all the elements of the structure (like payload, protected headers etc.)
User calls m.Sign()
User gets the Signature set in the m field due to this API invocation.
User constructs a timestamping request based on m.Signature.
User sends the timestamping request and obtains a timestamping signature.
User adds the timestamping signature to m.Headers.Unprotected.
This issue is an extension of Issue #64. Issue #64 modified the external Interface for API Sign1 to return Encoded CBOR signed Sign1 message.
However the mis-use is still possible via the Interface API Method:
'func (m *Sign1Message) Sign() '
Example:
Step 1: User Instantiates (m *Sign1Message) Message
Step 2: User sets all the elements of the structure(like payload, protected headers etc.)
Step 3: User calls m.Sign()
Step 4: User gets the signature set in the m field due to this API invocation.
Step 5: User then modifies m.Signature field ?
One possible solution to this problem is to make the API Method Sign() as local function sign() and let the users only provide:
Generic API Function:
func Sign1(rand io.Reader, signer Signer, protected ProtectedHeader, payload, external []byte) (cbor_msg []byte, err error)
The benefit is that User is un-aware of the Cose_Sign1 Message, but just supplies the needed inputs.
Also, it is less prone to errors on the user side.
The obvious drawback, the interface is simple (not richer), which may be needed for some applications?
In my view the benefits outweigh the disadvantages, so should be adapted however, a careful impact analysis on dependencies/users of go-cose Veraison library needs to be evaluated.
The text was updated successfully, but these errors were encountered: