terminology clarification (by rigo)

[vgalindo]

1.1 Terminology
"Secure Service" definition sounds strange in security terminology. A system is secure (along the lines of FIPS and E4 specs) if it behaves as defined and expected.

"Relying party". An application can never be a "party". The use of the word here is misleading

"Issuing authority" needs a better explanation. HB-SEC assumes a system where end-users are authenticated by the system. The use of the term X509 is limiting and could be avoided.

Definition of Origin: -> well done, but the use of the term is ambiguous throughout the document, especially key origins and web origins are meshed up into a very confusing mix with high potential of misunderstanding. (e.g.
problem statement: "Suppose that a domain foo.com issues a key.") In fact some entity releases a key that I want to use in the context of bar.com. And this special use in the context of bar.com should be done such that the context leaves traces in the cryptographic result of the secure operation (e.g.
signature). This is also an actual weakness of WebCrypto as it assumes a key per domain/origin or has those keys unscoped. Which in turn leave Ryan's comments on eIDAS in an even more opinionated light. (see security considerations of WebCryptoAPI)

"Secure element": I don't think we should call this "device" but rather "element".

The definition of "user agent" is circular and does not fit my understanding that we talk about browsers.

"User verification method": It says identity management is out of scope and than says: "ensures that only the genuine user". I think this needs some rewording as we make sure that only a natural person with possession and knowledge can put the secure element in action.

"Identity": I don't think we should link the key to a person. I could also imagine that we can link a key to a function or role or simply a card.
(possession based credential like door-key)

"Trusted user Interface": I think this can be in the browser-chrome. Thus the use of the term "direct browser scope" can be misunderstood.

[sbahloul]

I propose the following improvements :

• "Secure Service" : Secure Service: any web site that manages sensitive operations and would benefit from/depend upon the use of an hardware based security solution to give the security proof of the user confirmation integrity and non repudiation
• "Relying party": The term party is commonly used in Identity and Access Management. But we can restrict the document to use "Secure Service"
• "Issuing authority": The term X509 is used to illustrate the concept of issuing authority because it is currently the only well known issuing scheme. May I kindly ask why we should avoid to use it ? It is de facto the standard for HTTPS server certificates and well accepted from my point of vue. I proposed to switch to : Issuing authority: the issuing authority is in charge of issuing an associated key/identity pair to a known identity and to maintain its lifecycle. The end-user identification is out-of-scope of this document but is clearly mandatory to associate a key to a genuine identity. As an example, in the well known in X509 certificates scheme, the issuing authority is the certificate authority
• "Secure element": not anymore applicable => it has been switched to Secure Credential Storage
• "User agent": as mentionned it was pasted from Wikipedia. May I kindly ask you to propose an better definition ?
• "User verification method": I propose the following update: "This is the way the Secure Credential Storage ensures that only the natural and genuine person with possession and knowledge is authorized to use the keys. For example, this method could be knowledge of a PIN code or biometric verification."
• "Identity": I propose to remove it from the terminology section
• "Trusted user Interface": You mean that it can be implemented as a browser capability ? From my point of vue, it was clearly defined that it should rely upon an external capability (OS, middleware, TEE, ...) to enforce a higher security linked to the device. Having a browser implementation would limit the security trust chain because it would run as a user program whereas the OS, the TEE run in a privileged environment. The existing desktop middleware is considered as an exception to that security model, but is already a piece of the trust chain.

[vgalindo]

@rigow can you check that this proposal adresses your concerns ? Thxs

[sbahloul]

Regarding "Definition of Origin": I confirm that the definition matches both the key origin and the secure service origin because the document deals with the various use cases (same origin between the keys and the requested web site or different origins). I propose to mention the origins (web site vs key origin) explicitely

[mark-orz]

Cross-referencing issue #103, I find the use of "Secure Credential Storage" to refer to both the hardware and the use-case confusing. I would prefer to use "Secure Element" for the hardware.

"Trusted user interface": I don't think we should exclude browsers (the present phrasing "User interface component outside the direct browser scope" appears to exclude browsers) but should acknowledge that an additional level of security beyond that normally provided by the browser may be required. I think it is important that processes running with user-level privileges cannot interfere with either the display of information, or the user input method.

"User Verification Method": I propose "This is the way that the Hardware Secure Device ensures that only a natural and genuine person with possession and knowledge is able to access the keys stored in the Secure Element. For example, this method could be knowledge of a PIN code or biometric verification."

[sbahloul]

Regarding the Trusted UI, I don't know how an implementer could manage such additional level of security directly inside the browser implementation, but I understand your comment and integrate it.

[sbahloul]

I propose the following definition: Trusted User Interface: User interface component that provides an additional level of security to the existing browser capabilities in regards to the transaction confirmation message presented to the end-user to acquire its acknowledgment. It covers both the display of the information and the input of the user verification method.