Subject: RE: Withdrawl of Proxy Cert Profile draft from PKIX

From: Steve Tuecke <[email-masked]>
Date: Mon, 16 Sep 2002 14:41:40 -0500

All,

A couple weeks ago, I proposed withdrawal of the Proxy Cert Profile from 
PKIX.  Russ argued against this, which led to posing the following 
straw-poll question:

>Should PKIX sanction the advancement of a proxy cert draft based on the 
>current fundamental approach?  We can argue about the details more later, 
>but the fundamental approach at issue is whether it is reasonable to use 
>end-entity public key certificates to sign proxy certificates. Possible 
>answers are:
>   1) No.
>   2) Yes, but only as Informational Track.
>   3) Yes, as Standards Track.

There were 3 responses.  Russ Housley voted #3.  Phill Hallam-Baker 
suggested forming a new working group, which I would put in the #1 
category.  Denis Pinkas responded, but did not explicitly vote for one of 
these choices -- his closest statement to a vote was 'I do not have [a 
problem with using end-entity public key certificates to sign proxy 
certificates] as long as the draft is using everywhere "proxy certificate" 
and is NOT using the terminology "public key certificate"'.

So it seems the tally is 1 yes, 1 no, 1 abstain, and lots of 
apathy.  Anybody else care to weigh in on this issue?

-Steve

At 01:41 PM 9/9/2002, Hallam-Baker, Phillip wrote:
>Answer: Start a new group
>
>PKIX was formed to do one thing and has become a standing committee that
>will do anything, provided it is in ASN.1 syntax. That is a bad thing.
>
>I would much prefer to see the group split into two. Continuing PKIX would
>be tasked with simply moving the current RFCs through the standards track to
>Draft and Standard. PKIX-EXT would be tasked with developing extensions to
>PKIX where necessary.
>
>
>                 Phill

---

From: Phil Griffin <[email-masked]>
Date: Mon, 16 Sep 2002 17:07:57 -0400

Hoping to foment a groundswell of activity,
I agree with Russ on this.

Phil

Steve Tuecke wrote:

>> Should PKIX sanction the advancement of a proxy cert draft based on 
>> the current fundamental approach?  We can argue about the details more 
>> later, but the fundamental approach at issue is whether it is 
>> reasonable to use end-entity public key certificates to sign proxy 
>> certificates. Possible answers are:
>>   1) No.
> category.  Denis Pinkas responded, but did not explicitly vote for one 
> of these choices -- his closest statement to a vote was 'I do not have 
> [a problem with using end-entity public key certificates to sign proxy 
> certificates] as long as the draft is using everywhere "proxy 
> certificate" and is NOT using the terminology "public key certificate"'.
> 
> So it seems the tally is 1 yes, 1 no, 1 abstain, and lots of apathy.  
> Anybody else care to weigh in on this issue?
> 
> -Steve
>

---

From: Steve Hanna <[email-masked]>
Date: Mon, 16 Sep 2002 17:01:04 -0400

> Should PKIX sanction the advancement of a proxy cert draft based
> on the current fundamental approach?  We can argue about the
> details more later, but the fundamental approach at issue is
> whether it is reasonable to use end-entity public key
> certificates to sign proxy certificates. Possible answers are:
>   1) No.

I'll vote for:

The proxy cert concept is a useful one. It will be increasingly
important as long-running programs (agents or services) need to
act on behalf of users.

I would prefer an approach that gave a CA certificate to
any user who might need to create a proxy certificate (with
name constraints or other limitations to restrict the
user's authority). This would allow the existing validation
algorithm to be employed. Revocation could be handled by an
shared CRL issuer, using indirect CRLs to remove most overhead,
or by a shared OCSP responder. However, I can live with the
"current fundamental approach".

My main concern is the lack of energy in the PKIX working
group for this effort. If we can't muster more response
than this, I'd say that Steve is right to take this work
elsewhere. The PKIX working group will just slow him down.
Individuals who are interested can join the GSI mailing lists.

Thanks,

Steve Hanna
Sun Microsystems, Inc.

---

From: "Michael Myers" <[email-masked]>
Date: Mon, 16 Sep 2002 14:17:30 -0700

Steve,

I think #3 is a good way to address this recurring class of
unmet needs.

Mike

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of Steve Tuecke
> Sent: Monday, September 16, 2002 12:42 PM
> To: [email-masked]
> Cc: Steve Tuecke
> Subject: RE: Withdrawl of Proxy Cert Profile draft from PKIX
>
>
>
> All,
>

---

From: Dr S N Henson <[email-masked]>
Date: Tue, 17 Sep 2002 00:43:03 +0100

I'll vote for #3 too.

Steve.
-- 
Dr Stephen N. Henson.   http://www.drh-consultancy.demon.co.uk/
Personal Email: [email-masked] 
Senior crypto engineer, Gemplus: http://www.gemplus.com/
Core developer of the   OpenSSL project: http://www.openssl.org/
Business Email: [email-masked] PGP key: via homepage.

---

From: "Dean Adams" <[email-masked]>
Date: Tue, 17 Sep 2002 12:38:44 +0100

Hi,
	Sorry for not following your rules for possible answers, but at the moment
I would prefer to reply with a Provisional vote for #3, since I see a real
business need for proxy support in an S/MIME environment, (e.g. an assistant
signing emails and attachments on behalf of his/her boss).  This is
something that many folks have asked if it is possible with PKI since
current paper based practices involve some of this.

The provisional nature of my vote stems from the fact that the specification
(as I have just read it from the PKIX site) does not mention anywhere the
potential use of a proxy certificate in an S/MIME setting.  Furthermore, the
spec would seem to preclude the use of a proxy certificate in an S/MIME
setting since the spec sates that "The subjectAltName extension MUST NOT be
present in a Proxy Certificate".

Given my very brief reading of this spec, it is likely that I have got the
wrong idea and that S/MIME usage can indeed be supported.  In that case I
apologise, but would appreciate anyone explaining the situation.

	Thanks
	Dean Adams

____________________________________________________________
Dean Adams               mobile:         +44 (0)7989 385914
Trustis Limited          Direct Tel/Fax: +44 (0)1252 734320
49 Whitehall             Office Tel:     +44 (0)20 7451 1490
London SW1A 2BX          Office Fax:     +44 (0)20 7484 7961
email: [email-masked]    Web: http://www.trustis.com
____________________________________________________________
The information in this message is confidential.  It is intended solely for
the addressee.  Access to this message by anyone else is unauthorised.  If
you are not the intended recipient, any disclosure, copying, distribution or
any action taken or omitted to be taken in reliance on it, is prohibited and
may be unlawful.

Any attachments to this message have been checked for viruses, but please
rely on your own virus checker and procedures.

If you contact us by e-mail, we may store your name and address to
facilitate communications.

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]]On Behalf Of Steve Tuecke
Sent: 16 September 2002 20:42
To: [email-masked]
Cc: Steve Tuecke
Subject: RE: Withdrawl of Proxy Cert Profile draft from PKIX

All,

-Steve

---

From: Denis Pinkas <[email-masked]>
Date: Tue, 17 Sep 2002 14:22:16 +0200

Steve,

> any user

This is not RFC 3280 compliant. :-(

> who might need to create a proxy certificate (with
> user's authority).

> This would allow the existing validation algorithm to be employed.

This is exactly what I do not think it is possible. I would not like to
"twist" the validation algorithm just for that purpose. Validating the 
proxy certificate separately, would however not be a problem.

> Revocation could be handled by an

> Individuals who are interested can join the GSI mailing lists.

The big question would still be whether that work would be RFC 3280
compliant or not.

Regards,

Denis

---

From: Denis Pinkas <[email-masked]>
Date: Tue, 17 Sep 2002 14:18:45 +0200

Hi Dean,

Nice to "meet" you again, not face-to-face but on the net.

> current paper based practices involve some of this.

I wonder if the proxy certificate document is the right answer to your very
valid
concern.

The proxy certificate document is targeted for impersonation for access
control 
but not for signature in an S/MIME context.

If your are interested in signature delegation in an S/MIME context, please
refer to
the presentation I made at the 52 nd IETF meeting (Salt Lake City, December
2001)
where I was considering using of profile of an Attribute Certificate. The
title of
that presentation is "Signature delegation" in the slides section from the
S/MIME WG.

> apologise, but would appreciate anyone explaining the situation.

For the time being I would not count your provisional vote for #3.

:-)

Regards,

Denis

---

From: "Dean Adams" <[email-masked]>
Date: Tue, 17 Sep 2002 14:52:57 +0100

Hi Denis,
	Thanks for the pointer.  I've taken a look at your presentation which
proposes an alternative viable approach for achieving what I see as a real
business need to be fulfilled. What feedback and support have you had for
this proposal so far?

My question is: would a solution based on the Proxy Certificate be more
likely to be supported by S/MIME client apps than one based on the use of
attribute certificates?  I have the feeling that in many S/MIME client
applications, the additional effort to support proxy certificates would be
less than that required for attribute certificates.  I do not develop such
client applications and am therefore not best qualified to comment.  Whilst
one approach may be more technically or architecturally pure and correct
than another, my chief interest is in seeing these capabilities being
reflected in real commercial products.

Comments welcomed, particularly from developers of commercial S/MIME client
application.

	Regards
	Dean

-----Original Message-----
From: Denis Pinkas [mailto:[email-masked]]
Sent: 17 September 2002 13:19
To: Dean Adams
Cc: [email-masked]
Subject: Re: Withdrawl of Proxy Cert Profile draft from PKIX

Hi Dean,

:-)

Regards,

Denis

---

From: Denis Pinkas <[email-masked]>
Date: Tue, 17 Sep 2002 17:55:53 +0200

Dean,

>From your very last question, I fear that you are on the wrong mailing list.
You should use [email-masked]

> business need to be fulfilled. What feedback and support have you had for

The idea came during a lunch at Salt Lake City with some well known experts.

>From an idea to a specification and finally a product, this takes a long time.

> less than that required for attribute certificates.

The proposal is to use the format of an Attribute Certificate without the
burden to deploy an Attribute Authority.

Note also that the rule to verify such a delegation cannot be the rule to
verify a PKC, hence one of the main motivations for the proxy certificate
vanishes.

Denis

> I do not develop such

---

From: Steve Hanna <[email-masked]>
Date: Tue, 17 Sep 2002 11:54:45 -0400

> > name constraints or other limitations to restrict the

RFC 3280 doesn't prohibit giving a CA certificate to a user,
if the issuer of that certificate intends that certificates
issued by the user should be honored. In fact, that's the
proper way to indicate that the subject of a certificate
is allowed to issue certificates. If you disagree, please
point out something in RFC 3280 to justify your opinion.

However, we are now headed down a rathole. I will try to
refrain from extended discussions on this topic, since
Steve Tuecke was just just trying to take a poll.

Thanks,

Steve

---

From: "Housley, Russ" <[email-masked]>
Date: Tue, 17 Sep 2002 14:58:00 -0400

Dean:

I do not envision the use of proxy certificates in S/MIME.  The document 
that we are discussing provides a context for the proxy.  Perhaps the title 
should make this context more clear.

Russ

---

From: Denis Pinkas <[email-masked]>
Date: Wed, 18 Sep 2002 12:01:36 +0200

Steve,

> Steve Tuecke was just just trying to take a poll.

OK. In such a case, count my vote as a no vote (i.e. option #1).

:-(

Regards,

Denis

---

From: "Olle Mulmo" <[email-masked]>
Date: Thu, 19 Sep 2002 08:53:14 +0200

I'm not particulary active on this list, but for whatever it's worth,
my vote is on #3.

The can of works opened when handing out CA certs to every user is
indeed big. Being a minimalistic and the most "pure" approach, as
I see it, it falls because of reality reasons, as the user may too
easily be able to do too much in unexpected contexts.

(That isn't a reason for PKIX to stop working on it, but it does raise
acceptability concerns when pushing it out for deployment.)

My two cents,

/Olle

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]]On Behalf Of Steve Hanna
Sent: den 17 september 2002 17:55
To: Denis Pinkas
Cc: [email-masked]
Subject: Re: Withdrawl of Proxy Cert Profile draft from PKIX

Thanks,

Steve

---

From: "Olle Mulmo" <[email-masked]>
Date: Thu, 19 Sep 2002 10:01:01 +0200

My two cents,

/Olle

-----Original Message-----

Thanks,

Steve