On Mon, Apr 6, 2009 at 8:37 PM, Ian Hickson <i...@hixie.ch> wrote:
>> Submission formats:
>>
>> The default format, introduced by Netscape, is the SPKAC format, see the
>> above link, and includes the public key and the Keygen challenge
>> attribute, and is signed by the private key.
>>
>> The actual standardized format is PKCS #10, in form a more advanced and
>> flexible version of SPKAC (it is the format used to request certificates
>> for webservers), and I am not sure if this is now used by default in
>> some clients. In Opera this format can be selected by using a
>> type="pkcs10" attribute in the keygen tag.
>
> I haven't added support for PKCS10 since it doesn't seem to actually add
> anything to the feature set.
...except one marketing checkbox: "Compliant with the Public Key
Cryptography Standards".
>> - An algorithm preference list, specifiying the key algorithms
>> preferred by the server, in order of preference. In this case a keyword
>> registration process should also be defined. Initial keywords should
>> cover RSA, DSA and Elliptic Curves. As some methods may require
>> parameters to be transferred to the client the syntax should cover such
>> extensions, e.g "alg1;param1=x;param2=y,alg2", name of parameters should
>> be selected by the specification for the algorithm, but two parameters
>> should be defined: Minimum length (e.g. "min-len") and Maximum Length
>> ("max-len") of the key that can be used to guide the client in what
>> keylength it should selects (These should be suggestions, not absolute
>> limits, at least for the maximum; the minimum should probably be
>> considered a lower limit)
>
> I haven't added this, because right now the only browser I could find
> which supports more than one algorithm is Firefox, and it just has two
> (RSA and ECs, as far as I could tell).
RSA and DH/DSA are in almost everything. Besides, insisting that the
browser itself hold the keys is counterproductive.
>> It is also conceivable that the server should be able to specify which sites
>> the certificate can be used for. A common usability problem with client
>> certificates in SSL/TLS is selection of certificate, particularly when you
>> have many certificates. A list of hostname:port pairs would probably be a
>> good
>> way to ease that (the SSL/TLS server can also specify which CAs it prefers to
>> the certificate was issued by, but nobody is currently using that
>> capability).
>> A list of such sites provided at generation time might help the user in cases
>> where the SSL/TLS server does not specify preferred CAs.
>
> It seems like we should encourage people to use the existing feature you
> mention rather than adding more features to do effectively the same thing.
The "existing feature" is a list of external authorities that the site
trusts, rather than necessarily showing "all".
>> In the future it is also conceivable that such requests is to be made
>> for keys stored on smartcards, so a source selector might be an idea,
>> perhaps also with the capability to specify specific cards.
>
> I'd rather we didn't specify this before it was ready to be a reality.
I'd rather it be specified before it's ready to be a reality, to
provide marketing pressure for "hey, we've already got support for
it". Otherwise, it's a chicken&egg problem.
-Kyle H
--
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto
