[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Web-PKI Keygen/Certreq Questions
Pierre,
We apparently agree on the state of affaires.
Regarding your particular concerns, I am slightly less in agreement
as I see on-line certification being a provider-defined activity.
To in a PKCS #10 client-created packet "ask" for certain DN attributes
does not apply to such scenarios. It is rather "all-on-the-server".
At least the systems that are rolled out in Europe are definitely
of that type and I think this make sense as well. PKIX standards
(as well as current browser implementations), where designed for
a "collaborative" environment where the user often is supposed to
know about things like key length etc.
But PKIs for on-line banking and e-Governments (C2G) are
targeted at user groups who essentially know nothing about PKI.
The (mostly Java-written) systems I have seen in these areas are
all designed to hide PKI as much as it is technically possible.
These systems, AFAIK, all take a "complete grip" on the whole
process from on-line certification to on-line (web) signatures.
I don't know exactly where that leaves current PKIX standards
or what to do next though.
To get the browser vendors (which are at least five taking the
mobile dittos also in consideration), to cooperate is a major task.
It might actually be easier to define "the whole thing" (on-line
Web-PKI) from scratch using XML and perform this work in W3C
rather than "tweaking" current standards and existing systems.
My 2 öres at least.
Anders
----- Original Message -----
From: "Pierre Heuze" <Pierre.Heuze@xxxxxxxxxxxx>
To: "Stephen Kent" <kent@xxxxxxx>; "Jean-Marc Desperrier" <jmdesp@xxxxxxx>
Cc: <ietf-pkix@xxxxxxx>
Sent: Saturday, November 01, 2003 00:29
Subject: RE: Web-PKI Keygen/Certreq Questions
Anders Rundgren wrote:
>I cannot find any "compilation" of browser (on-line)-adapted mechanisms
>for performing key generation or performing certificate requests.
Indeed there isn't a de-facto reference for this, by now you must realize
every PKI/Browser vendors have developed their ownn solution as mentionned
already, but don't forget the many token/smart card providers who also have
come-up with additional solutions. So it's the jungle out there, as any
request in a search engine for "browser certificate request" or similar will
show (cf Stephen's comment do some more homework.)
Stephen Kent wrote:
> both browsers have had facilities for generating an RSA key pair for
> a user, and sending a cert request for years.
Indeed, at least 1998 from my own experience, but surely someone will claim
an earlier date. In practice, it is almost always based on free/liberal use
of PKCS#10; which has raised many interop issues as you all know, to mention
few (signature and extension format).
Jean-Marc Desperrier wrote:
>So, from the point of view of what should be put on a web page to get a
>browser to generate a certificate request, there is no standard.
>This can be considered not to be a valable item of concern for pkix
thought.
Indeed this topic is somewhat out of the scope of PKIX, but few things to
consider:
- Requesting a certificate is one of the most basic operation to be
completed in the PKI world and browser based application have gained a large
acceptance. So it is a valid concern.
- Requesting a certificate is a somewhat complex operation, and the
browser-based solution too often overlooked basic consideration for the sake
of simplicity, the main drawbacks are:
- No authentication, Proof of Possession (having the key pair) is
often taken as valid
authentication mechanism (sic).
- No standard way to mandate what certificate profile should be used
to fulfil the request
- No control of the certificate life-cycle, each request are handled
separately which
doesn't cater well when certificate need to be renewed, or
re-activated
after suspension.
The above points are in part covered by various PKIX message format, but to
be honest they haven't gained acceptance (yet?) for browser based operations
and if used they are highly not interoperable (i.e. to say the least no
improvement on the interop side compare to using PKCS#10).
So is it the case that one should refine the standard to restrict the use of
existing messages to cover the above scenario as to achieve greater
interoperability and hence acceptance? To me this seems to be a genuine item
for the PKIX group.
Pierre Heuzé
http://www.cardbase.com
-----Original Message-----
From: Stephen Kent [mailto:kent@xxxxxxx]
Sent: 31 October 2003 19:35
To: Jean-Marc Desperrier
Cc: ietf-pkix@xxxxxxx
Subject: Re: Web-PKI Keygen/Certreq Questions
At 19:15 +0100 10/31/03, Jean-Marc Desperrier wrote:
>Stephen Kent wrote:
>
>>At 16:21 +0100 10/31/03, Anders Rundgren wrote:
>>
>>>I cannot find any "compilation" of browser (on-line)-adapted mechanisms
>>>for performing key generation or performing certificate requests.
>>
>>yes, you are wrong.
>>
>>both browsers have had facilities for generating an RSA key pair
>>for a user, and sending a cert request for years.
>
>Facilities is one thing, interoperability is another.
I have not worked this problem recently, but in my experience
developing three different CA products a few years ago, all were able
to accept enrollment requests from both browsers, and all major
providers of CA software did so as well. it was a necessary
prerequisite for selling CA software.
we now have 2 PKIX standards for enrollment protocols: CMP and CMC.
if the browser vendors choose to support these, then we have
interoperable solutions as well, but vendors must choose to make use
of them.
Steve
CardBASE Technologies®
Address: BIM House, Crofton Road, Dun Laoghaire, Co Dublin, Ireland
PH: +353-1-2843233 FAX: +353-1-2843220 WEB: http://www.cardbase.com
***********************************************************************
This e-mail and any attachment, contains information which is private
and confidential and is intended for the addressee only. If you are not
an addressee, you are not authorised to read, copy or use the e-mail
or any attachments. If you have received this e-mail in error, please
notify the sender by return e-mail and then destroy it.
This message has been swept for viruses by anti-virus software.
***********************************************************************