Re: Non Repudiation via WebCrypto API

Hi. Ryan.

thanks for your comment.

we will try to do our best to solve this.
and will share within this WG.

regards
mountie.

On Fri, Sep 21, 2012 at 10:34 AM, Ryan Sleevi <sleevi@google.com> wrote:

> On Thu, Sep 20, 2012 at 6:25 PM, Mountie Lee <mountie.lee@mw2.or.kr>
> wrote:
> > Hi.
> >
> > as my understanding
> > some requirements of Korea were affected webcrypto WG forming.
> >
> > Non-Repudiation is the key concept of Korea NPKI.
> > in Korea, we have Legal National Public Key Infrastructure.
> >
> > many people in here expect webcrypto API can be the replacement of
> activeX
> > used for client side technology.
> > that means people expect Non-Repudiation service with webcrypto API.
> >
> > when I see the draft API,
> > in worst words,
> > I think "I can strip my JS code with webcrypto API, I can kick off
> > jCryption"
> >
> > If the client computing environment is clean and not compromised
> > is current key generation, export, import is usable for implementing
> > non-repudiation service?
> > really I'm not clear for this.
>
> My response was trying to highlight that you're asking two very
> different questions, even though it looks like just one :-)
>
> If we assume that all other variables are equal, can the Web Crypto
> API provide the same guarantees that would otherwise be obtained using
> a native application executing on the same machine?
>
> The answer to that is "Combined with the necessary other technologies
> to ensure the correct and proper JS operating environment, the answer
> should be YES."
>
> Which is to say, there are a unique set of security considerations for
> "Web" applications that are not necessarily present with native code.
> Those considerations are broadly "implementation specific", but when
> you talk about a web browser and an arbitrary web page, there are a
> general set of concerns, such as cross-site scripting or injection.
> However, these can be mitigated through means like "Content Security
> Policy", or the user agent may provide an alternative interface that
> is more restrictive and thus presumed more secure (for example,
> extension APIs).
>
> But my response, and much to Anders' general disagreement, is that
> calling such technical solutions "non-repudiation" is a bit of a
> stretch. That's no more nor less a stretch than saying the ActiveX
> application provides non-repudiation though, so if your concern is "Is
> X (JS) as capable as Y (ActiveX)", then if we're doing things right,
> the answer should be "yes".
>
> >
> > when do we have next face to face meeting?
>
> The next face to face is at the W3C Technical Plenary (
> http://www.w3.org/2012/10/TPAC/ ) in Lyon, France. Our group is
> meeting on 1 Nov - 2 Nov. I hope you'll be able to attend!
>
> >
> >
> >
> > On Wed, Sep 19, 2012 at 3:30 PM, Anders Rundgren <
> anders.rundgren@telia.com>
> > wrote:
> >>
> >> Mountie,
> >> Sorry for repeating myself but Non-repudiation is (primarily) a legal
> >> term that has been interpreted in very different ways regarding what
> >> is needed.  In Sweden authentication with an OTP-token to a server-based
> >> signature service is considered as fully compliant!
> >>
> >> Ryan,
> >> That the state of computing is such that trustworthy signatures are
> >> not possible (or plain ridiculous) is an opinion, not an absolute fact.
> >> I doubt that there is a consensus for this opinion in the WebCrypto WG.
> >> If the platform itself is broken, WebCrypto won't fix it as we already
> >> concluded in previous discussions.
> >>
> >> So what's left IMO is simply: How do you architect trustworthy signature
> >> schemes in general-purpose computers using the WebCrypto API and leave
> >> the design of trustworthy operating systems and browsers to those who
> >> are dealing with these issues on a daily basis.
> >>
> >> Anders
> >>
> >>
> >> > On Tue, Sep 18, 2012 at 2:28 PM, Anders Rundgren
> >> > <anders.rundgren@telia.com> wrote:
> >> >> On 2012-09-18 21:59, Ryan Sleevi wrote:
> >> >>
> >> >> Ryan,
> >> >> I can't really figure out what you are trying to say here.
> >> >>
> >> >> - Signature applications are ridiculous because it is technically
> >> >> infeasible keeping computers free from malware?
> >> >> - Web intents can do this much better than existing solutions?
> >> >
> >> > Trust derived from the fact that it came from a particular signature
> >> > application, executing on a general purpose system, is ridiculous and
> >> > unrealistic.
> >> > That's not to say there isn't value in such applications for user
> >> > friendliness for whatever legally mandated scheme, but as a general
> >> > point of practice, their value as a trust-adding solution is zero.
> >> >
> >> >>
> >> >> IMO, computers should be abandoned if they can't be free from malware
> >> >> that disrupts the execution of "goodware".
> >> >
> >> > So does that mean you'll be leaving us now? :) Because that's
> >> > certainly the state of the world.
> >> >
> >> >>
> >> >> In addition, I think there is (generally) something wrong with the
> >> >> proportions:  SIGNATURES are by no means the most critical operation
> because
> >> >> signatures that are associated by some kind of promise can always be
> >> >> disputed while an AUTHENTICATION gone wrong is /fait accompli/.
> >> >>
> >> >> (That is, if you can't use your computer for signing, you shouldn't
> be
> >> >> allowed to log in either).
> >> >
> >> > I'm not sure what you're saying here, but I'm also not sure the
> >> > distinction matters at all. Any cryptographic operation shares the
> >> > same concerns. Any.
> >> >
> >> >>
> >> >> BTW, I didn't mean that user agents should provide the signature view
> >> >> or process, only that they could provide the means to create such
> views.
> >> >
> >> > Thank you for your feedback. I'm sure it will be considered.
> >> >
> >> > Web Intents is another such way to create such views.
> >> >
> >> > When we're at the point where we're specifying such things, I'm sure
> >> > we can visit the variety of pros and cons of the different solutions.
> >> > I'm by no means wed or suggesting that WI solves all of these
> >> > problems, simply pointing to it as one possible way to restrict and
> >> > constrain operation of a key to a particular "application", to support
> >> > rich views of content, and to require no special contortions by user
> >> > agents above and beyond existing standards-track work.
> >> >
> >> >>
> >> >> As shown by the write-up I supplied there could be more than one
> >> >> possible trust model for creating custom signature GUIs and
> processes.
> >> >> The write-up also addresses "Apps" which is another but related
> topic.
> >> >>
> >> >> Would it be too much asking for some kind of write-up showing your
> take
> >> >> on this subject?
> >> >> It would probably be quite interesting for the apparently pretty big
> >> >> bunch of people who are interested in casting their existing
> applications in
> >> >> a new format.
> >> >>
> >> >> Anders
> >> >>
> >> >>
> >> >>>
> >> >>>
> >> >>> On Tue, Sep 18, 2012 at 12:22 PM, Anders Rundgren
> >> >>> <anders.rundgren@telia.com <mailto:anders.rundgren@telia.com>>
> wrote:
> >> >>>
> >> >>>         Switched to the -comments list since I'm not a WG member...
> >> >>>
> >> >>>     There has been a huge bunch of messages on the public-webrypto
> >> >>> list regarding this topic.
> >> >>>     I think it is important separating issues, otherwise you get
> >> >>> stuck.
> >> >>>
> >> >>>     Non-Repudiation is a legal term which IMO doesn't fit into a
> >> >>> technical specification.
> >> >>>     However, the technical underpinnings of non-repudiation are not
> a
> >> >>> mystery,
> >> >>>     the question boils down to:
> >> >>>
> >> >>>       Can the WebCrypto API support a server-provided
> HTML5/JavaScript
> >> >>>       signature scheme where the User View, the Signature Process,
> and
> >> >>>       the associated cryptographic operations can be trusted to be
> >> >>> free
> >> >>>       from manipulation, limited only by the trustworthiness of the
> >> >>> client-
> >> >>>       platform itself?
> >> >>>
> >> >>>
> >> >>> "Can the Cryptography Next Generation/PKCS#11/CDSA API support an
> >> >>> application-supplied signature scheme where the User View, the
> Signature
> >> >>> Process, and the associated cryptographic operations can be trusted
> to be
> >> >>> free from manipulation, limited only by the trustworthiness of the
> operating
> >> >>> system itself."
> >> >>>
> >> >>> (Hint: The answer is no, not really).
> >> >>>
> >> >>> You can get a close approximation by defining custom cryptographic
> >> >>> providers, perhaps that show their own overlay windows, but those
> can be
> >> >>> subverted by malware. You could perhaps have it talk to a secure
> element,
> >> >>> where the secure element had an LCD that displayed the "To be
> Signed"
> >> >>> operation (popular in Asia, AIUI), but you're still limited to the
> >> >>> trustworthiness that the channel has not been subverted.
> >> >>>
> >> >>> There are any number of techniques you can do, and they apply as
> much
> >> >>> to the Web Crypto API as they apply to the native APIs. Your degree
> of
> >> >>> assurance you're granted is proportional to the degree of trust you
> grant.
> >> >>>
> >> >>> The question of whether or not user agents will provide some sort of
> >> >>> trusted UI is tricky. If you're wanting to implement PDF signing,
> for
> >> >>> example, does that mean a user agent MUST support PDF? If you're
> wanting to
> >> >>> support XML DSig, does the user agent need to know how to turn that
> XML
> >> >>> document into some presentable form? Can it be subverted at all?
> >> >>>
> >> >>> As a user agent, I can't really express any interest in that. I'm
> more
> >> >>> interested in providing a means for either extensions (which are,
> >> >>> admittedly, user-agent specific) or for means such as Web Intents,
> to allow
> >> >>> third-party developers to fill in the gaps, with as much or as
> little
> >> >>> security as you wish to afford them.
> >> >>>
> >> >>> That is, fundamentally, no worse than the existing state of the
> native
> >> >>> application world, but with the use of (future) standards like Web
> Intents
> >> >>> *and things like it*, it can be much better.
> >> >>>
> >> >>>
> >> >>>
> >> >>>     I'm sure some of you English-speaking folks can express this
> >> >>> better
> >> >>>     but hopefully it isn't entirely unintelligible :-|
> >> >>>
> >> >>>     On 2012-09-18 19:03, Ryan Sleevi wrote:
> >> >>>
> >> >>>     > We've equally had discussions about "high-value transactions"
> -
> >> >>> which are
> >> >>>     > a separate class with a separate set of requirements. That
> isn't
> >> >>> to say that
> >> >>>     > they're out of scope, but that, due to both political and
> >> >>> technical complexity,
> >> >>>     > have been de-prioritized for some of the reasonable and
> >> >>> attainable short-term goals.
> >> >>>
> >> >>>     This is somewhat sad to hear.  Shouldn't it be possible to
> verify
> >> >>> if the goal is
> >> >>>     achievable or not already at this stage if we bring our heads
> >> >>> together?
> >> >>>     If we stick to the technical stuff at least.  There will always
> be
> >> >>> a minority who
> >> >>>     insist of something very special but I wouldn't bother too much
> >> >>> about edge cases.
> >> >>>
> >> >>>     > ... I don't think there is much interest by browser vendors to
> >> >>> get in the
> >> >>>     > business of supporting all the esoteric signing schemes of the
> >> >>> various
> >> >>>     > national IDs. That's something best left to native
> applications
> >> >>> - or,
> >> >>>     > using this API, by specific origins (and/or extensions).
> >> >>>     > I've already suggested one way this may work, with Web
> Intents,
> >> >>>     > but I'm sure many more schemes can be imagined and
> implemented.
> >> >>>
> >> >>>     It would be very interesting to hear more how this would work!
> >> >>>
> >> >>>     Here is a write-up showing another trust model:
> >> >>>
> >> >>>     http://webpki.org/papers/PKI/pki-webcrypto.pdf
> >> >>>
> >> >>>     Regards,
> >> >>>     Anders
> >> >>>
> >> >>>     <snip>
> >> >>>
> >> >>>     >
> >> >>>     > On Tue, Sep 18, 2012 at 8:19 AM, Seetharama Rao Durbha
> >> >>> <S.Durbha@cablelabs.com <mailto:S.Durbha@cablelabs.com>
> >> >>> <mailto:S.Durbha@cablelabs.com <mailto:S.Durbha@cablelabs.com>>>
> wrote:
> >> >>>     >
> >> >>>     >     In my mind too, non-repudiation is a functional use case
> >> >>> that implementors MAY use this API for.  There are so many prisms
> through
> >> >>> which you can view non-repudiability. This API cannot in anyway
> guarantee
> >> >>> non-repudiability.
> >> >>>     >
> >> >>>     >     Having said that, please see one comment inline.
> >> >>>     >
> >> >>>     >     On 9/17/12 7:59 PM, "Ryan Sleevi" <sleevi@google.com
> >> >>> <mailto:sleevi@google.com> <mailto:sleevi@google.com
> >> >>> <mailto:sleevi@google.com>>> wrote:
> >> >>>     >
> >> >>>     >         On Mon, Sep 17, 2012 at 6:31 PM, Mountie Lee
> >> >>> <mountie.lee@mw2.or.kr <mailto:mountie.lee@mw2.or.kr>
> >> >>> <mailto:mountie.lee@mw2.or.kr <mailto:mountie.lee@mw2.or.kr>>>
> wrote:
> >> >>>     >
> >> >>>     >             Hi.
> >> >>>     >             I want to make consensus and verify that the
> current
> >> >>> WebCryptoAPI is enough for implementing non-repudiation services
> >> >>> (http://en.wikipedia.org/wiki/Non-repudiation)
> >> >>>     >             also want to know whats are undefined or missing
> >> >>> parts.
> >> >>>     >
> >> >>>     >             because
> >> >>>     >             some countries has the regulations that give
> digital
> >> >>> signature can be non-repudiable .
> >> >>>     >
> >> >>>     >
> >> >>>     >             =======================================
> >> >>>     >             PayGate Inc.
> >> >>>     >             THE STANDARD FOR ONLINE PAYMENT
> >> >>>     >             for Korea, Japan, China, and the World
> >> >>>     >
> >> >>>     >         Depends on your definition of non-repudiation.
> >> >>>     >
> >> >>>     >         While this offers an API to perform digital signatures
> >> >>> (aka the non-forgeable part of non-repudiation), it is inherent in
> the
> >> >>> operating environment that some elements of non-repudiation simply
> cannot be
> >> >>> offered.
> >> >>>     >
> >> >>>     >         For example, if a site is XSSed, a signature can be
> >> >>> fraudulently generated by a malicious third-party, and thus needs
> to be
> >> >>> repudiable.
> >> >>>     >         Likewise, if signatures can be generated with
> no/minimal
> >> >>> user interaction, then a malicious site can fraudulently generate a
> >> >>> signature that is Signature(X), while presenting to the user that
> they
> >> >>> generated Signature(Y).
> >> >>>     >
> >> >>>     >
> >> >>>     >     This is an issue. I do not want to get bogged down in
> >> >>> signatures generated using keys generated within the browser. For a
> moment,
> >> >>> let us just focus on smart cards. There definitely is no trust
> between the
> >> >>> browser and the server application – BUT, there is trust between
> the user
> >> >>> and the browser. The user is using the browser to enter their
> credentials,
> >> >>> check their sensitive data on the web sites and so on. That trust
> extends
> >> >>> when the user is giving consent to the browser to access the smart
> card.
> >> >>> Essentially, the trust translates to 'I trust the browser to use my
> smart
> >> >>> card credentials in a rightful manner'. What is the rightful manner
> for
> >> >>> signatures? In my mind, it is to guarantee that a signature
> generated using
> >> >>> those credentials are on data the browser confirmed with the user.
> If the
> >> >>> browser lets the application generate arbitrary signatures, it is a
> big
> >> >>> problem. I, as a user (not as an app developer), have huge trust
> problems
> >> >>> with the browser.
> >> >>>     >
> >> >>>     >
> >> >>>     > On a general purpose machine, there is no trust between the
> >> >>> browser and the operating system. Malware or other compromise may
> have
> >> >>> occurred.
> >> >>>     > On a general purpose machine, there is no trust between the
> >> >>> operating system and the smart card. Again, malicious drivers may
> have been
> >> >>> introduced.
> >> >>>     >
> >> >>>     > For native applications, the operating system provides no such
> >> >>> signing interface as you describe. Any native application can run
> and induce
> >> >>> signatures from the smart card. While some applications may present
> user
> >> >>> interfaces for confirmation, those are at the application layer,
> and can be
> >> >>> compromised (as I've previously provided examples of).
> >> >>>     >
> >> >>>     > We've equally had discussions about "high-value transactions"
> -
> >> >>> which are a separate class with a separate set of requirements.
> That isn't
> >> >>> to say that they're out of scope, but that, due to both political
> and
> >> >>> technical complexity, have been de-prioritized for some of the
> reasonable
> >> >>> and attainable short-term goals.
> >> >>>     >
> >> >>>     > The general goal is to uplift web applications to the same
> >> >>> degree as native applications, and in a standards-based and
> cross-browser
> >> >>> way. Within that goal, if native applications cannot do what you
> describe -
> >> >>> and they cannot - then it must be asserted that web applications
> can not
> >> >>> change that.
> >> >>>     >
> >> >>>     > As far as having the browser do it natively, I don't think
> there
> >> >>> is much interest by browser vendors to get in the business of
> supporting all
> >> >>> the esoteric signing schemes of the various national IDs. That's
> something
> >> >>> best left to native applications - or, using this API, by specific
> origins
> >> >>> (and/or extensions). I've already suggested one way this may work,
> with Web
> >> >>> Intents, but I'm sure many more schemes can be imagined and
> implemented.
> >> >>>
> >> >>>
> >> >>
> >> >>
> >> >
> >> >
> >>
> >
> > =======================================
> > PayGate Inc.
> > THE STANDARD FOR ONLINE PAYMENT
> > for Korea, Japan, China, and the World
> >
>

=======================================
PayGate Inc.
THE STANDARD FOR ONLINE PAYMENT
for Korea, Japan, China, and the World