Re: Request from WebRTC

OK, thanks, this was not detailed until recently, typo in the spec: 
14.3.10 step1 "passed to the exportKey method" not importKey

Regards

Aymeric

Le 17/03/2014 15:59, Ryan Sleevi a écrit :
>
>
> On Mar 17, 2014 5:29 AM, "Aymeric Vitte" <vitteaymeric@gmail.com 
> <mailto:vitteaymeric@gmail.com>> wrote:
> >
> > Reopening this one, the project mentioned below is moving to WebRTC, 
> the draft specs are there [2]
> >
> > What was the conclusion of this thread?
> >
>
> Exactly what is written on this thread.
>
> I still oppose integration as being wrong on a both technical and 
> conceptual grounds.
>
> > I have read it several time and still didn't get exactly what was 
> the difficulty to handle the keys for DTLS à la WebCrypto.
> >
> > I  could not read the latest draft due to the mail I just sent, but 
> [2] does raise some questions and I don't think it's currently 
> possible with the WebCrypto API, using generatKey with RSA:
> >
> > - how can I get the public key fingerprint?
>
> exportKey(spki)+digest()
>
> > - how can I get the public key modulus?
> >
>
> RsaKeyAlgorithm object that hangs off Key.algorithm
>
> > Regards
> >
> > Aymeric
> >
> > [2] 
> https://github.com/Ayms/node-Tor#anonymous-serverless-p2p-inside-browsers---peersm-specs
> >
> > Le 14/11/2013 10:14, Richard L. Barnes a écrit :
> >>
> >>
> >> On Thursday, November 14, 2013 at 1:06 AM, Aymeric Vitte wrote:
> >>>
> >>> Interesting, I was wondering how WebRTC was handling DTLS between 
> peers, so despite of all security concepts that are opposed to me each 
> time I mention self-signed certificates, all of a sudden, a Web API, 
> WebRTC, is allowed to use them (to switch later to CA-issued 
> certificates... for peers???)
> >>
> >> Obviously, if you’re using self-signed certificates, you need some 
> other mechanism for authentication.  WebRTC uses an “Identity 
> Provider” system to layer authentication on top of any certificates in 
> DTLS, including self-signed.
> >>
> >> 
> <http://tools.ietf.org/html/draft-ietf-rtcweb-security-arch-07#section-5.6>
> >>
> >>>
> >>> It seems like we are back to certificates, expose certificates and 
> TLS subjects.
> >>>
> >>> Maybe what is needed finally is to use the WebCrypto Key interface 
> and a "secondary feature" TLS/DTLS secure implementation.
> >>>
> >>> More generally, I have not looked at the WebRTC ideas to "avoid 
> tracking", but I put together a study case (see at the end of [1]) how 
> WebRTC could potentially be used and insure privacy at the same time, 
> the conclusion is that the whole world knows what you are doing so 
> WebRTC can certainly not be used if you care about privacy, and I 
> don't see any reliable means to encrypt things between peers not 
> involving them sharing a secret (ie know each other, so impossible in 
> practice), that's not the concern of this group but if the conclusion 
> is wrong or limited then please advise separately.
> >>
> >> The tracking risk arises when an app use the same public key 
> repeatedly, either across several different peers or multiple times 
> with the same peer.  This is different from the usual fingerprinting, 
> since it’s peer-to-peer fingerprinting instead of server-based.
> >>
> >> --Richard
> >>
> >>
> >>>
> >>>
> >>> [1]: http://www.peersm.com
> >>>
> >>> Regards,
> >>>
> >>> Aymeric
> >>>
> >>> Le 14/11/2013 04:35, Richard L. Barnes a écrit :
> >>>>
> >>>> The current concept is to focus on keys and self-signed 
> certificates (as current WebRTC implementations are doing), with 
> CA-issued certificates as future work.
> >>>>
> >>>> --Richard
> >>>>
> >>>>
> >>>> On Wednesday, November 13, 2013 at 7:32 PM, Mountie Lee wrote:
> >>>>>
> >>>>> DTLS is based on Certificate which is not yet fully discussed in 
> WebCrypto WG
> >>>>>
> >>>>>
> >>>>> On Thu, Nov 14, 2013 at 11:24 AM, Ryan Sleevi <sleevi@google.com 
> <mailto:sleevi@google.com>> wrote:
> >>>>>>
> >>>>>> On Wed, Nov 13, 2013 at 5:53 PM, Richard L. Barnes 
> <rbarnes@bbn.com <mailto:rbarnes@bbn.com>> wrote:
> >>>>>> > For those who might not have been following WebRTC, they are 
> enabling
> >>>>>> > browser-to-browser real time communications, using JavaScript.
> >>>>>> >
> >>>>>> > The good news is that all WebRTC communications are encrypted 
> with keys
> >>>>>> > negotiated using DTLS (using either SRTP or the DTLS for 
> encryption).  These
> >>>>>> > keys are bound to user identities by way of identity 
> assertions passed in
> >>>>>> > SDP [draft-ietf-rtcweb-security-arch].  The challenge is that 
> WebRTC apps
> >>>>>> > want to be able to control what keys are used in the DTLS 
> negotiation.
> >>>>>> >
> >>>>>> > The overall concept is that the app will be able to impose a 
> key on the DTLS
> >>>>>> > session, using something like a setDtlsKey() method.  The 
> question is: Can
> >>>>>> > WebRTC use WebCrypto Key objects to represent keys used for DTLS?
> >>>>>> >
> >>>>>> > It appears that the answer to this question is “yes”.  The 
> app/key
> >>>>>> > separation provided by the WebCrypto API provides the layer 
> of separation
> >>>>>> > that is needed.  However, the WebRTC layer needs some 
> additional metadata
> >>>>>> > about the key:
> >>>>>> > -- Whether the key was ever accessible to JS
> >>>>>> > -- Limitation of the key to usage with DTLS
> >>>>>>
> >>>>>> These two statements make me think that WebCrypto is not the 
> right fit for them.
> >>>>>>
> >>>>>> It is, in essence, stating "Were these keys ever Web Crypto keys"
> >>>>>>
> >>>>>> >
> >>>>>> > The proposal is to add information to the WebCrypto Key 
> object to encode
> >>>>>> > these metadata.
> >>>>>> >
> >>>>>> > This email is intended to be a summary, with more detail to 
> be provided in
> >>>>>> > discussion tomorrow.  The main question for now is whether 
> this seems like a
> >>>>>> > current-API thing or a future-API thing.
> >>>>>> >
> >>>>>> > I would suggest that it is an issue for the current API, 
> because (1) the
> >>>>>> > proposed changes are small, and (2) if this is punted to a 
> future version,
> >>>>>> > then WebRTC will likely come up with an alternative solution.
> >>>>>> >
> >>>>>> > Thanks,
> >>>>>> > --Richard
> >>>>>>
> >>>>>> Seems like a never-API to me, based on your summary, but 
> perhaps I'm
> >>>>>> missing important context.
> >>>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>> --
> >>>>> Mountie Lee
> >>>>>
> >>>>> PayGate
> >>>>> CTO, CISSP
> >>>>> Tel : +82 2 2140 2700
> >>>>> E-Mail : mountie@paygate.net <mailto:mountie@paygate.net>
> >>>>>
> >>>>> =======================================
> >>>>> PayGate Inc.
> >>>>> THE STANDARD FOR ONLINE PAYMENT
> >>>>> for Korea, Japan, China, and the World
> >>>>
> >>>>
> >>>
> >>> --
> >>> Peersm : http://www.peersm.com
> >>> node-Tor : https://www.github.com/Ayms/node-Tor
> >>> GitHub : https://www.github.com/Ayms
> >>
> >>
> >
> > --
> > Peersm : http://www.peersm.com
> > node-Tor : https://www.github.com/Ayms/node-Tor
> > GitHub : https://www.github.com/Ayms
>

-- 
Peersm : http://www.peersm.com
node-Tor : https://www.github.com/Ayms/node-Tor
GitHub : https://www.github.com/Ayms