0.9.2342.19200300.100.1.1

0.9.2342.19200300.100.1.1 =
http://webid.myxwiki.org/xwiki/bin/view/XWiki/homepw4#me

 

 

I'm convinced that we should allow certs to use the above convention for
indicating the URI, in the case that no SAN URI field are detected.

 

I've convinced myself, because there are just so many tools out there for
making self-signed certs that cannot do SAN URIs (yet). We should focus on
the getting folks to mint self-signed certs, using those tools. This is more
important than the format.

 

For example, on windows:

http://www.iamraf.net/Tools/DeployManager-first-release-certificates-managem
ent

 

This makes minting certs, assigning access controls, choosing trust stores,
pretty easy. It made .p12 output files that I imported into both Opera and
IE9. All I had to do was put "0.9.2342.19200300.100.1.1 =
http://webid.myxwiki.org/xwiki/bin/view/XWiki/homepw4#me" into the name
field, and click save.

 

I was playing with this when experimenting with now putting this second
modulus into my homepw4 foaf card, bound to the same cert:id.

 

To be effective for Windows user (anyone case, given their relevance of this
community in the adoption process?), the self-signed cert should be a trust
anchor - that is: issuer and subject names are identical. An SSL site that
has previously accepted a cert/webid can thus modulate the list of CAs
acceptable to the browser, in a return visit, guessing from the ClientHello
that it should populate 0.9.2342.19200300.100.1.1 =
http://webid.myxwiki.org/xwiki/bin/view/XWiki/homepw4#me as the CA name.
This benefits the UI of cert pickers, considerably, even with today's cert
pickers.