[rs-dev] Draft RFC: Signed Public Key and Challenge

[Dirk-Willem van Gulik]

> On 5 Mar 2020, at 16:16, Graham Leggett <minfrin at redwax.eu> wrote:
> 
> On 05 Mar 2020, at 16:56, Graham Leggett via rs-dev <rs-dev at redwax.eu> wrote:
> 
>> Example has been added:
>> 
>> https://source.redwax.eu/svn/redwax/std/spkac/trunk/draft-leggett-spkac-00.txt
>> 
>> Just need to add references for RSA, etc.
> 
> References have been added, do we need anything else?

I was in de middle of writing below. But have not had the chance to finish it.

Dw.

> https://source.redwax.eu/svn/redwax/std/spkac/trunk/draft-leggett-spkac-00.txt

Index: draft-leggett-spkac-00.xml
===================================================================
--- draft-leggett-spkac-00.xml	(revision 5)
+++ draft-leggett-spkac-00.xml	(working copy)
@@ -76,7 +76,7 @@
 
    <abstract>
       <t>This memo describes the Signed Public Key and Challenge (SPKAC), a syntax to provide
-        Proof-of-Possession of a Public Key. </t>
+        Proof-of-Possession of a Public Key to support federated (client) certificate enrolment.</t>
     </abstract>
   </front>
   <middle>
@@ -100,10 +100,10 @@
         <t>The SPKAC protocol was originally used by the Netscape web browser as
           part of their implementation of what eventually became the
           <xref target="W3C.REC-html5-20141028" format="default">HTML5</xref> keygen
-          tag. The keygen tag allowed a web browser to request a certificate from
+          tag. The keygen tag allowed a web browser to request a (client) certificate from
           a certificate authority over the world wide web, and the SPKAC protocol
           ensured the web browser possessed the key being signed by the certificate
-          authority.
+          authority. 
         </t>
         <t>
           For a long time the Signed Public Key and Challenge was a de facto
@@ -111,9 +111,22 @@
           document the existing use of the protocol, and formalise the protocol into
           a standard.
         </t>
+        <t>
+          Note that, on XX, Google/Mozilla unilaterally decided to retire keygen
+          tag support from the XX engine. 
+        </t>
+        <t>Prior to this; this defacto, interoperable, protocol was widely used by both 
+          centralised certificate certificate authorities (that would issue personal digital
+          x509 certificates) as well as in more local enterprise & federated settings.
+        </t>
       </section>
     </section>
 
+XX mention that historically hardware tokens and softtokens were used in those browsers
+XX no (federated or peer2peer) replacement left once google removed this - due to CORS/single-origin/etc limtis java script.
+XX example of typical enterprise use - often AD intergrated (like at the Beeb)
+XX pointer to MS world Enroll to illustrate that this coverded the whoel gammut interoperable
+
     <section anchor="asn1-module-spkac" numbered="true" toc="default">
       <name>ASN.1 Module SPKAC</name>
       <t>This appendix includes all of the ASN.1 type and value definitions
@@ -192,6 +205,24 @@
           additional steps SHOULD be taken to ensure that SPKAC message is delivered
           over a secure transport, such as <xref target="RFC8446" format="default">TLS</xref>.</t>
       </section>
+      <section numbered="true" toc="default">
+        <name>UI/UX Denial of Service design issues</name>
+         <t>User interfaces in the browser should take care to not allow (rogue) webpages 
+           or javascript generate very large number of keygen requests; as this is not only
+           somewhat resource intensive; but may also deplete cryptographic quality random
+           generator pools (historically a concern). Especially as most implementations
+           will generally keep the cryptographic code and (private) key storage outside
+           the sandbox in which the DOM and Javascript is handled. 
+         </t>
+         <t>Likewise - browsers should be particularly careful when handling solicited (and
+          unsolicited & maliciously repeated/high-volume) responses to a keygen/spkac 
+          submission when storing (and recombining) these in the key store. 
+         </td>
+         <td>Especially has (historically) it was common for such
+          request to be handled asynchronously; with the user receiving an email after, for example
+          human approval, to pick up the signed certificate at a certain URL.
+         </t>
+      </section>
     </section>
   </middle>