RE: Drastically cutting primary features [was Re: Last call for public comments on Web Crypto charter]

To the point "nobody uses javax.smartcardio": 
I wrote a Firefox addon that uses javax.smartcardio to "talk" to an javacard applet on an UICC on a phone.
PC --> NFC-Reader -> UICC -> Phone App (infocard selector)

It would be nice if there were an API to simplify some of the steps. 

Axel

-----Original Message-----
From: Anders Rundgren [mailto:anders.rundgren@telia.com] 
Sent: Donnerstag, 24. November 2011 10:40
To: Harry Halpin
Cc: Stephen Farrell; public-identity@w3.org
Subject: Re: Drastically cutting primary features [was Re: Last call for public comments on Web Crypto charter]

IMO, the division between simple and difficult goes between a domain-oriented crypto system and a traditional unrestricted ditto.

In a domain-restricted crypto system everything happens between a specific user/browser and a specific relying part/issuer application.
Privacy-wise there are no issues and security-wise screw-ups are limited to exactly these two parties.

Traditional unrestricted crypto systems essentially targets the Internet which have major implications which (based from the comments on this list...), few people seem to have realized.

I think it is time for the DomCrypt guys to chime-in and say if this description is wrong or not.  Phrases like "we must support smart cards etc in the future" has no room in a charter because that has to proved with respect to *feasibility*.  Oracle has smart card support in Java (javax.smartcardio.*) which nobody uses because it simply doesn't work.

Anders

On 2011-11-24 00:14, Harry Halpin wrote:
> On 11/18/2011 06:34 AM, Stephen Farrell wrote:
>>
>> I've very happy to see how this process has gone and the resulting 
>> charter. I have two comments:-
>>
>> I would strongly argue to move TLS key extraction into the list of 
>> primary features. I guess that function might not always produce a 
>> key, depending on client & server implementations, but I think its 
>> important that it be available since if/when it works, it would mean 
>> that an awful lot of people would not need to develop their own (and 
>> probably broken) key distribution schemes.
> 
> I'm catching up on older comments, and I'd like for people on this 
> mailing list to notice the radical simplifying nature of Stephen's 
> proposal.
> 
> By having key establishment come from TLS as the primary feature, it 
> would get rid of the need for key storage, key agreement, and key 
> generation from primary features. Or at least move those to secondary 
> features!
> 
> What do people think?
> 
> It would be a radically simpler starting point for an API, which 
> appeals to me.
> 
>>
>> I would separately argue that the current list of primary functions 
>> (esp without TLS key extraction) is not really a "high-level API," 
>> right now, it looks much more like just any old crypto API (e.g. if 
>> you have D-H, which many developers might not understand very well). 
>> I think requiring the WG to more somehow at a higher level than 
>> JCE/JCA might be a way to indicate that.
>>
>> Regards,
>> Stephen.
>>
>> On 11/17/2011 03:17 PM, Harry Halpin wrote:
>>> Everyone,
>>>
>>> On next Tuesday, as said earlier, I plan to take the Web 
>>> Cryptography charter [1] from the wiki and put it into HTML as an 
>>> "official draft charter" then ask for preliminary feedback from the 
>>> AC, before going to real AC review in December (thus launching Working Group in January).
>>>
>>> So, if you have any comments, *now* is the time to send to the 
>>> mailing list. Suggested text replacement is most welcome.
>>>
>>>        cheers,
>>>           harry
>>>
>>> [1] http://www.w3.org/wiki/IdentityCharter
>>>
>>>
>>
> 
> 
>

Received on Thursday, 24 November 2011 15:08:27 UTC