headers
Anders Rundgren | 1 Nov 2003 11:08
Picon

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
(Continue reading)

Permalink | Reply | 0 comments |
headers
Dale Gustafson | 3 Nov 2003 03:01

Re: Request change in son-of-rfc2633


Paul Hoffman / IMC wrote

< ... >

> PCs are vulnerable. This doesn't mean we stop all development of
> things that run on PCs.
>
> (FWIW, the paper can be found at
> <http://www.cs.dartmouth.edu/~sws/papers/keyjack.pdf>.)

Interesting paper, although most secure application designers probably realize
that browser keystores are most often protected only by a user-chosen password
which may be weak or even NULL.

The issues raised re: creative ways to insert a "shim DLL" between a secure
application and CryptoAPI (or any other security library using the common DLL
form-factor) are most interesting and apply irrespective of use/non-use of SSL
client authentication.  Anyone know of other recent work in this same area?

> --Paul Hoffman, Director
> --Internet Mail Consortium

Regards,

Dale Gustafson
Permalink | Reply | 0 comments |
headers
Peter Gutmann | 3 Nov 2003 04:18
Picon
Picon
Picon
Favicon

Re: Request change in son-of-rfc2633


Dale Gustafson <dale.gustafson <at> bpsi.net> writes:

>The issues raised re: creative ways to insert a "shim DLL" between a secure
>application and CryptoAPI (or any other security library using the common DLL
>form-factor) are most interesting and apply irrespective of use/non-use of
>SSL client authentication.  Anyone know of other recent work in this same
>area?

I look at it in chapter 6 of my book, "Cryptographic security architecture
design and verification".  There are a million ways to do this under Windows,
you can hijack and subvert pretty much anything you want, from kernel calls
(the kernel entry jump tables are modifiable from user-space) through to
subverting apps in various ways (the coolest one being thread injection, I'm
surprised virii don't use that one more often because you become totally
undetectable with that).  Chapter 6 covers the various implications of this in
more detail (I'm being lazy and just citing the chapter to avoid having to
paraphrase the whole thing here :-).

Peter.
Permalink | Reply | 0 comments |
headers
Frédéric Giudicelli | 3 Nov 2003 05:51

Good certificate renewal practice


Hello,
After reviewing "pkix-roadmap" and "rfc2510bis" I found no details on how
PKIs should handle certificates renewal.
Can a user request a renewal even if his/her certificate is not about to
expiry? If yes, should we revoke the previous certificate and after which
delay?
Can a user request a renewal even if his/her certificate has expired?
I'm just lost on how implementing certificate renewal in my PKI.

Thanks,
Frédéric Giudicelli
http://www.newpki.org
Permalink | Reply | 1 comment |
headers
Peter Gutmann | 3 Nov 2003 07:14
Picon
Picon
Picon
Favicon

Re: Good certificate renewal practice


=?iso-8859-1?Q?Fr=E9d=E9ric_Giudicelli?= <groups <at> newpki.org> writes:

>After reviewing "pkix-roadmap" and "rfc2510bis" I found no details on how
>PKIs should handle certificates renewal.

That's a policy matter.

>Can a user request a renewal even if his/her certificate is not about to
>expiry?

That's a policy matter.

>If yes, should we revoke the previous certificate and after which delay?

That's a policy matter.

>Can a user request a renewal even if his/her certificate has expired?

Th.... well, you get the idea.

Peter.

(Incidentally, the person who originally suggested the ecumenical/policy
 comment has since expressed regret that he didn't trademark it or something
 :-).
Permalink | Reply | 1 comment |
headers
Frédéric Giudicelli | 3 Nov 2003 07:29

Re: Good certificate renewal practice


So I guess that all the earlier-suggested renewal methods are okay.
In any event is there any PKIX draft, that explicit those renewal policies?
I'm having a hard time believing that the WG let some much room for personal
appreciation :)

Frédéric Giudicelli
http://www.newpki.org

(Are you trying to say that you would be rich by now?)

----- Original Message ----- 
From: "Peter Gutmann" <pgut001 <at> cs.auckland.ac.nz>
To: <groups <at> newpki.org>; <ietf-pkix <at> imc.org>
Sent: Monday, November 03, 2003 7:14 AM
Subject: Re: Good certificate renewal practice

> =?iso-8859-1?Q?Fr=E9d=E9ric_Giudicelli?= <groups <at> newpki.org> writes:
>
> >After reviewing "pkix-roadmap" and "rfc2510bis" I found no details on how
> >PKIs should handle certificates renewal.
>
> That's a policy matter.
>
> >Can a user request a renewal even if his/her certificate is not about to
> >expiry?
>
> That's a policy matter.
>
> >If yes, should we revoke the previous certificate and after which delay?
(Continue reading)

Permalink | Reply | 0 comments |
headers
Anders Rundgren | 3 Nov 2003 08:44
Picon

Re: Good certificate renewal practice


I believe this is outside of standards.
But I am sure it should conceptually work as it does for credit-cards,
passports etc.   I.e. you receive (automatically or on your own
responsibility) a new card etc. before the existing has expired.
There are no technical needs for revoking as far as I can see.
In an on-line PKI I would assume that the old certificate would
be replaced by the new one automatically.  But on-line certification
is not standardized, and everyone makes their own "pudding"
and assign their own policy.

From a recent message of mine:

=============================================
   Practically every piece of client-side Web-PKI, ranging
   from on-line certification support to on-line (web-form)
   signing, is currently entirely vendor-dependent
=============================================

I will check out newpki.org!

Anders

----- Original Message -----
From: "Frédéric Giudicelli" <groups <at> newpki.org>
To: <ietf-pkix <at> imc.org>
Sent: Monday, November 03, 2003 05:51
Subject: Good certificate renewal practice

Hello,
(Continue reading)

Permalink | Reply | 0 comments |
headers
Steve Hanna | 3 Nov 2003 20:57
Picon

Draft PKI Action Plan Posted for Review and Comment

The OASIS Public Key Infrastructure Technical Committee
(the OASIS PKI TC) has posted a draft PKI Action Plan for
public review, inviting comments and support from PKI
customers, vendors, experts, and others. This plan is
designed to address obstacles to PKI deployment and usage
identified through surveys conducted earlier this year.

The draft PKI Action Plan is available for review at
http://www.oasis-open.org/committees/pki/pkiactionplan.pdf
The survey results are available at these locations
http://www.oasis-open.org/committees/pki/pkiobstaclesjune2003surveyreport.pdf
http://www.oasis-open.org/committees/pki/pkiobstaclesaugust2003surveyreport.pdf

Comments on the plan should be submitted by clicking the
"Send a Comment" button on the PKI TC's web page at
http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=pki

At the PKIX meeting next week, I will briefly summarize
the survey results and the draft PKI Action Plan.
However, I encourage you to review these documents in
detail and submit your comments to the PKI TC.

Note that the PKI TC recognizes that most of the actions
described in the draft PKI Action Plan must be undertaken
not by the PKI TC, but by others (vendors, standards groups,
users, etc.) and that some of these efforts are already
under way. The PKI TC does not intend to usurp these efforts,
but to serve as a catalyst encouraging and accelerating efforts.

Thanks,
(Continue reading)

Permalink | Reply | 0 comments |
headers
Peter Gutmann | 4 Nov 2003 11:11
Picon
Picon
Picon
Favicon

Re: Request change in son-of-rfc2633


I wrote:

>Mozilla (and no doubt some others that didn't get any publicity) did the same
>thing, and I'm sure they didn't get asked to do that by customers.

Actually that's not right, I thought Mozilla (or at least some apps that used
the Mozilla/Gecko/NSS/whatever code base) were vulnerable because Konqueror
was vulnerable, but it turns out that this was Konqueror with khtml rather
than with kmozilla, with OpenSSL supplying the crypto.  Apologies for the
mixup.

Before this gets read as "OpenSSL is vulnerable", that isn't the case either.
OpenSSL provides application-defined callbacks that can be used to override
some checks (used to handle, as one source aptly described it, "the mass of
broken certs out there").  Some apps provide callbacks that ignore all errors,
which apparently is what happened here.  Standard OpenSSL doesn't have this
problem.

Peter.
Permalink | Reply | 12 comments |
headers
Peter Gutmann | 4 Nov 2003 15:27
Picon
Picon
Picon
Favicon

Re: Good certificate renewal practice


=?iso-8859-1?Q?Fr=E9d=E9ric_Giudicelli?= <groups <at> newpki.org> writes:

>So I guess that all the earlier-suggested renewal methods are okay.

Yup, if your policy allows it.  For example the answer to the question:

  should we revoke the previous certificate and after which delay?

in my code would be that the cert will get revoked once its replacement is
created since to have two otherwise identical certs existing at the same time
will violate the CA database integrity constraints (the CA transaction
engine's ACID properties won't allow this to happen).  Note that the private
key isn't affected (you can still use it, for example, to decrypt data long
after the cert has expired), only the publicly visible CA statement about the
public portion of the key.

However, that's just one particular interpretation.  Everyone else is free to
apply whatever interpretation they choose.

>In any event is there any PKIX draft, that explicit those renewal policies?
>I'm having a hard time believing that the WG let some much room for personal
>appreciation :)

It was a in-joke, a reference to the fact that anything that no-one can really
agree on is made a policy matter, which means that someone else has to take
care of it.

Peter.
(Continue reading)

Permalink | Reply | 2 comments |

Gmane