This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 13518 - "The keygen element": The only supported signature algorithm is the outdated and insecure md5WithRSAEncryption. The element should at least have an optional signature algorithm, with the option to use the more secure sha1WithRSAEncryption and sha256WithRS
Summary: "The keygen element": The only supported signature algorithm is the outdated ...
Status: RESOLVED MOVED
Alias: None
Product: HTML WG
Classification: Unclassified
Component: LC1 HTML5 spec (show other bugs)
Version: unspecified
Hardware: Other other
: P3 normal
Target Milestone: ---
Assignee: Ian 'Hixie' Hickson
QA Contact: HTML WG Bugzilla archive list
URL: http://www.whatwg.org/specs/web-apps/...
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2011-08-02 09:25 UTC by contributor
Modified: 2016-04-28 14:35 UTC (History)
8 users (show)

See Also:

Attachments

Description contributor 2011-08-02 09:25:36 UTC 
Specification: http://dev.w3.org/html5/spec/spec.html
Multipage: http://www.whatwg.org/C#top
Complete: http://www.whatwg.org/c#top

Comment:
"The keygen element":
The only supported signature algorithm is the outdated and insecure
md5WithRSAEncryption.

The element should at least have an optional signature algorithm, with the
option to use the more secure sha1WithRSAEncryption and
sha256WithRSAEncryption. Even better would be if md5WithRSAEncryption was not
supported or at least not the default - but that might of course cause
problems for legacy implementations.

Posted from: 193.162.155.202
User agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/535.1 (KHTML, like Gecko) Chrome/14.0.835.8 Safari/535.1
Comment 1 Michael[tm] Smith 2011-08-04 05:02:07 UTC 
mass-moved component to LC1
Comment 2 bblfish 2011-08-06 13:12:22 UTC 
The MD5 situation can be mitigated by the server using a time based challenge. The challenge gets added to to the generated public key and both get signed.  This can reduce the attack surface to a few minutes. I doubt md5 is not up to that.

Better signature would be better of course. But it is not clear to me what is gained anyway by this signature. What attack is it warding off against? Nothing can be done anyway with a certificate for which one does not have the private key.
Comment 3 Anne 2011-08-14 09:31:29 UTC 
EDITOR'S RESPONSE: This is an Editor's Response to your comment. If you are satisfied with this response, please change the state of this bug to CLOSED. If you have additional information and would like the editor to reconsider, please reopen this bug. If you would like to escalate the issue to the full HTML Working Group, please add the TrackerRequest keyword to this bug, and suggest title and text for the tracker issue; or you may create a tracker issue yourself, if you are able to do so. For more details, see this document: <http://dev.w3.org/html5/decision-policy/decision-policy.html>.

Status: Rejected
Change Description: no spec change
Rationale: Is there any interest from vendors in expanding the scope of this element? It seems the current direction for cryptography on the web is APIs.
Comment 4 bblfish 2015-10-07 08:59:45 UTC 
The reason given for closing this issue is that this type of functionality would be taken over by WebCrypto JS APIs. That WG finished its work, but without filling the gap that the keygen functionality enabled.

To be more precise the JS Crypto API work does not provide a standard way for the browser to create public private keys in such a way that both the following hold:

1. it is safe from the origin that generated the key so that the user agent's keystore is the only one to have access to the private key 
2. the generated key is then useable across origins through browser enabled user mediation [2] for authentication

The irresolution of this issue was then used by a number of browsers ( see thread on blink-dev mailing list) as a reason to remove the <keygen> functionality, which was then used as a reason by the WHATWG to deprecate it [3] .




[1] http://www.w3.org/TR/WebCryptoAPI/
[2] http://w3c.github.io/webappsec-credential-management/#user-mediation
https://github.com/whatwg/html/issues/102
[3] https://github.com/whatwg/html/issues/102
Comment 5 Charles McCathieNevile 2016-04-28 14:35:33 UTC 
This has been listed as part of https://github.com/w3c/html/issues/43 - if keygen doesn't get deprecated, it will get addressed otherwise it becomes invalid