Re: charter revisions

[Stephen Kent <[e-mail]>]

At 10:35 AM +0100 8/30/01, Stephen Farrell wrote:
>Steve (K),
>
>I'd have to agree with Steve H, though maybe not as strongly.
>
>My suggestion would be to limit the additional items to the
>dpd/dpv.
>
>In addition the replacement charter text doesn't mention the
>fact that PKIX has profiled the X.509 AC which I guess I can't
>let pass:-)
>
>Stephen.
>

Steve,

Gee, 3 Steve's in one message! I'll add mention of the Ac profile.

Steve



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f7VIFZZ24479 for ietf-pkix-bks; Fri, 31 Aug 2001 11:15:35 -0700 (PDT)
Received: from gto-mailer1.bbn.com (cam-mailer1.bbn.com [128.33.0.36]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f7VIFYD24474 for <[e-mail]>; Fri, 31 Aug 2001 11:15:34 -0700 (PDT)
Received: from [128.33.84.34] (comsec.bbn.com [128.33.84.34]) by gto-mailer1.bbn.com (8.9.3+Sun/8.9.3) with ESMTP id OAA01710; Fri, 31 Aug 2001 14:13:54 -0400 (EDT)
Mime-Version: 1.0
X-Sender: [e-mail]
Message-Id: <p05010408b7b5840efc68@[128.33.84.34]>
In-Reply-To: <[e-mail]>
References: <p0501040bb7a8214adf35@[128.33.84.34]> <[e-mail]> <[e-mail]>
Date: Fri, 31 Aug 2001 14:13:09 -0400
To: [e-mail]
From: Stephen Kent <[e-mail]>
Subject: Re: charter revisions
Cc: Steve Hanna <[e-mail]>, [e-mail]
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>

At 10:35 AM +0100 8/30/01, Stephen Farrell wrote:
>Steve (K),
>
>I'd have to agree with Steve H, though maybe not as strongly.
>
>My suggestion would be to limit the additional items to the
>dpd/dpv.
>
>In addition the replacement charter text doesn't mention the
>fact that PKIX has profiled the X.509 AC which I guess I can't
>let pass:-)
>
>Stephen.
>

Steve,

Gee, 3 Steve's in one message! I'll add mention of the Ac profile.

Steve


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f7VEMtb15589 for ietf-pkix-bks; Fri, 31 Aug 2001 07:22:55 -0700 (PDT)
Received: from gto-mailer1.bbn.com (cam-mailer1.bbn.com [128.33.0.36]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f7VEMsD15585 for <[e-mail]>; Fri, 31 Aug 2001 07:22:54 -0700 (PDT)
Received: from [128.33.84.34] (comsec.bbn.com [128.33.84.34]) by gto-mailer1.bbn.com (8.9.3+Sun/8.9.3) with ESMTP id KAA06185; Fri, 31 Aug 2001 10:25:06 -0400 (EDT)
Mime-Version: 1.0
X-Sender: [e-mail]
Message-Id: <p05010402b7b54e1e502b@[128.33.84.34]>
In-Reply-To: <[e-mail]>
References: <p0501040bb7a8214adf35@[128.33.84.34]>	 <[e-mail]> <p0501040ab7b458549900@[128.33.238.96]> <[e-mail]>
Date: Fri, 31 Aug 2001 10:24:37 -0400
To: [e-mail]
From: Stephen Kent <[e-mail]>
Subject: Re: charter revisions
Cc: [e-mail]
Content-Type: text/plain; charset="iso-8859-1" ; format="flowed"
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id f7VEMsD15586
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>

At 10:43 AM +0200 8/31/01, Michael Ströder wrote:
>Stephen Kent wrote:
>>
>>  Just as a CA may employ various means to verify a subject's claim to
>>  a name, a CA can employ analogous means to verify a subject's claim
>>  to a logotype.  In fact, this may be relatively easy to verify if the
>>  logo is a registered trademark (something a CA could require via its
>>  CPS).
>
>Unfortunately it's not that easy. As a CA I would simply refuse to
>add logo types to a cert because the CA could be in charge for
>trademark abusing afterwards. There are currently too many such
>cases going to court because some lawyers want to make a lot of
>money out of it (e.g. setting a link on the web page to a name which
>is considered to be similar to a trademarked name). Well, we have
>the same issue with organization field though...but the lawyers did
>not discover it yet.
>
>Ciao, Michael.

Michael,

This is not a problem, it's a local decision by a CA and that's fine 
too. As I noted, this aspect of the logotype extension  issue is 
really quite similar, if not equivalent, to the problem faced by a CA 
when trying to decide if a claimed DN is acceptable.

Steve


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f7V8huS18241 for ietf-pkix-bks; Fri, 31 Aug 2001 01:43:56 -0700 (PDT)
Received: from mailout03.sul.t-online.de (mailout03.sul.t-online.com [194.25.134.81]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f7V8hiD18219 for <[e-mail]>; Fri, 31 Aug 2001 01:43:44 -0700 (PDT)
Received: from fwd00.sul.t-online.de  by mailout03.sul.t-online.de with smtp  id 15cjtv-0007jH-05; Fri, 31 Aug 2001 10:43:43 +0200
Received: from junker.stroeder.com (520010731148-0001@[62.224.163.105]) by fmrl00.sul.t-online.com with esmtp id 15cjti-1h121oC; Fri, 31 Aug 2001 10:43:30 +0200
Received: from stroeder.com (localhost [127.0.0.1]) by junker.stroeder.com (Postfix) with ESMTP id 965F4157170; Fri, 31 Aug 2001 10:43:31 +0200 (CEST)
Message-ID: <[e-mail]>
Date: Fri, 31 Aug 2001 10:43:30 +0200
From: Michael =?iso-8859-1?Q?Str=F6der?= <[e-mail]>
Reply-To: [e-mail]
Organization: stroeder.com
X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.2.19 i686)
X-Accept-Language: de-DE, de, en
MIME-Version: 1.0
To: Stephen Kent <[e-mail]>
Cc: [e-mail]
Subject: Re: charter revisions
References: <p0501040bb7a8214adf35@[128.33.84.34]> <[e-mail]> <p0501040ab7b458549900@[128.33.238.96]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Sender: [e-mail]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>

Stephen Kent wrote:
> 
> Just as a CA may employ various means to verify a subject's claim to
> a name, a CA can employ analogous means to verify a subject's claim
> to a logotype.  In fact, this may be relatively easy to verify if the
> logo is a registered trademark (something a CA could require via its
> CPS).

Unfortunately it's not that easy. As a CA I would simply refuse to
add logo types to a cert because the CA could be in charge for
trademark abusing afterwards. There are currently too many such
cases going to court because some lawyers want to make a lot of
money out of it (e.g. setting a link on the web page to a name which
is considered to be similar to a trademarked name). Well, we have
the same issue with organization field though...but the lawyers did
not discover it yet.

Ciao, Michael.


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f7V0iBj20110 for ietf-pkix-bks; Thu, 30 Aug 2001 17:44:11 -0700 (PDT)
Received: from prv-mail20.provo.novell.com (prv-mail20.provo.novell.com [137.65.81.122]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f7V0i9D20106 for <[e-mail]>; Thu, 30 Aug 2001 17:44:09 -0700 (PDT)
Received: from INET-PRV-MTA by prv-mail20.provo.novell.com with Novell_GroupWise; Thu, 30 Aug 2001 18:41:25 -0600
Message-Id: <[e-mail]>
X-Mailer: Novell GroupWise Internet Agent 6.0
Date: Thu, 30 Aug 2001 16:52:02 -0600
From: "Bob Jueneman" <[e-mail]>
To: <[e-mail]>, <[e-mail]>
Cc: <[e-mail]>, <[e-mail]>
Subject: Re: charter revisions
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=_257F9D25.E081EEC9"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>

This is a MIME message. If you are reading this text, you may want to 
consider changing to a mail reader or gateway that understands how to 
properly handle MIME multipart messages.

--=_257F9D25.E081EEC9
Content-Type: text/plain; charset=ISO-8859-7
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

I agree with Russ and Al.  Validating the appropriateness of the logo is =
no more difficult as a business proposition than the due diligence =
validation of the corporation's right to a particular name, and in the =
case of international companies may actually be easier.

Yes, there are problems with scalability, but I was very impressed with =
the flexibility of Scalable Vector Graphics to handle that problem.  For =
visually impaired or blind users, the "logo" could even be a spoken or =
braille alternative =AF "You've got a Visa/VeriSign/Coca-Cola certificate!"=
  And yes, in the case of subordinate CA's (and boy, are there a lot of =
those, aren't there?) , we could have a problem with the equivalent of =
name subordination. =20

But the alternative is for the various browser vendors to look up the logo =
from a supplied list shipped with the browsers (presumably at a significant=
 cost to the logo owner), and a never-ending secure update problem.  I =
don't think that is an acceptable alternative =AF it's almost as hard as =
managing root certificates.

Of course, accepting the work item as part of the charter doesn't commit =
us to any particular solution.  We might even decide that the whole thing =
is hopeless after all, and throw up our hands.  But we should at least =
take a thoughtful look at the problem.

Bob

Robert R. Jueneman
Security Architect

Novell, Inc -- the leading provider of Net services software



>>> "Housley, Russ" <[e-mail]> 08/30/01 11:33AM >>>

Steve Hanna:

>I haven't seen any comments on the revised charter yet. Most of it looks
>good to me. However, I don't think PKIX should do any work on the
>logotype extension. I know that there is a demand for this from
>marketing folks, but I don't believe that we should standardize it
>unless it can be used securely. This does not seem possible.

You and I agree on most things, but we have a major disagreement here.  =
I=20
do not think that we will see widespread deployment of certificates =
without=20
logos.  One measure of success will be the number of certificates that=20
average Internet user have.  Hopefully every Internet user will have at=20
least one.  I suspect that as we become successful, these logos will be =
the=20
tag by which users select a certificate.

I do not want to see more than one way that logos can be put into=20
certificates.  That is the most important reason for PKIX to be involved =
in=20
the definition.  You seem to agree that the market has a demand for=20
logos.  Letting each vendor devise an independent way to meet this=20
marketing requirement would be very bad for all implementors.

You seem to be concerned with the security of logos.  I am not.  From =
my=20
perspective, we are asking CAs to do many things that are harder than=20
including a URL and hash of a the appropriate logo.  In many, many =
cases,=20
this will be the same logo in every certificate that is issued by that CA.

Anyway, we should not have the complete technical debate on a threat =
about=20
the charter.  I strongly encourage the PKIX working group to include =
this=20
area in the charter sent forward to the Area Directors for approval.  =
Once=20
the revised charter is approved, we can have the technical debate and =
sort=20
out the details.

Russ


--=_257F9D25.E081EEC9
Content-Type: text/plain
Content-Disposition: attachment; filename="Bob Jueneman.vcf"

BEGIN:VCARD
VERSION:2.1
X-GWTYPE:USER
FN:Bob Jueneman
TEL;WORK:01-801/861-7387
ORG:Novell Inc. -- the leading provider of Net services software;DS eBusiness Solutions
TEL;PREF;FAX:[phone]
EMAIL;WORK;PREF;NGW:[e-mail]
N:Jueneman;Bob
TITLE:Consultant Engineer
ADR;INTL;WORK;PARCEL;POSTAL:;;Novell, Inc.\n1800 South Novell Place\n;Provo;Utah;84606;USA
LABEL;INTL;WORK;PARCEL;POSTAL;ENCODING=QUOTED-PRINTABLE:Bob Jueneman=0A=
Novell, Inc.=0A=
1800 South Novell Place=0A=
=0A=
Provo, Utah  84606=0A=
USA
LABEL;DOM;WORK;PARCEL;POSTAL;ENCODING=QUOTED-PRINTABLE:Bob Jueneman=0A=
Novell, Inc.=0A=
1800 South Novell Place=0A=
=0A=
Provo, Utah  84606
END:VCARD

BEGIN:VCARD
VERSION:2.1
X-GWTYPE:USER
FN:Robert R. Jueneman
TEL;WORK:01-801/861-7387
ORG:Novell, Inc.;DS eBusiness Solutions
TEL;PREF;FAX:[phone]
EMAIL;WORK;PREF;NGW:[e-mail]
N:Jueneman;Bob
TITLE:Consultant Engineer
ADR;INTL;WORK;PARCEL;POSTAL:;PRV-F331;122 E. 1700 South;Provo;Utah;84606;USA
LABEL;INTL;WORK;PARCEL;POSTAL;ENCODING=QUOTED-PRINTABLE:Robert R. Jueneman=0A=
PRV-F331=0A=
122 E. 1700 South=0A=
Provo, Utah  84606=0A=
USA
LABEL;DOM;WORK;PARCEL;POSTAL;ENCODING=QUOTED-PRINTABLE:Robert R. Jueneman=0A=
PRV-F331=0A=
122 E. 1700 South=0A=
Provo, Utah  84606
TEL;HOME:1-801-765-4378
TEL;CELL:1-801-361-1410
TEL;PREF:1-801-861-7387, 1-800-453-1267
END:VCARD


--=_257F9D25.E081EEC9--


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f7UMnFJ18731 for ietf-pkix-bks; Thu, 30 Aug 2001 15:49:15 -0700 (PDT)
Received: from po1.bbn.com (PO1.BBN.COM [192.1.50.38]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f7UMnED18727 for <[e-mail]>; Thu, 30 Aug 2001 15:49:14 -0700 (PDT)
Received: from [128.33.84.35] (comsecpb.bbn.com [128.33.84.35]) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id SAA15210; Thu, 30 Aug 2001 18:49:11 -0400 (EDT)
Mime-Version: 1.0
X-Sender: [e-mail] (Unverified)
Message-Id: <p0501040ab7b458549900@[128.33.238.96]>
In-Reply-To: <[e-mail]>
References: <p0501040bb7a8214adf35@[128.33.84.34]> <[e-mail]>
Date: Thu, 30 Aug 2001 17:06:20 -0400
To: Steve Hanna <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: Re: charter revisions
Cc: [e-mail]
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>

Steve,

As you recall, I have not been a fan of the logotype extension. I 
have requested Stefan justify the utility of the extension, in 
concept, and propose a concrete design to be evaluated. Still, I 
think the first of your criticisms is not a good one.

>I haven't seen any comments on the revised charter yet. Most of it looks
>good to me. However, I don't think PKIX should do any work on the
>logotype extension. I know that there is a demand for this from
>marketing folks, but I don't believe that we should standardize it
>unless it can be used securely. This does not seem possible.
>
>First, CAs will find it very hard to verify whether a particular
>logotype should be included in a particular certificate. They'll just
>need to certify whatever the client gives them and disclaim all
>responsibility for its accuracy. With textual names, at least they can
>make some attempt to verify that the name corresponds to the requesting
>client (by requiring a response from an email address before it's
>certified, for instance).

Just as a CA may employ various means to verify a subject's claim to 
a name, a CA can employ analogous means to verify a subject's claim 
to a logotype.  In fact, this may be relatively easy to verify if the 
logo is a registered trademark (something a CA could require via its 
CPS).


>Second, there's no equivalent to name constraints for use in cross
>certificates. If I cross certify someone, I just have to trust that they
>(and anyone they certify) will only put proper logotypes into
>certificates.

This has been my greatest concern as well, and I'd like to see a 
better proposal on how to better control use of the extension. Stefan 
rejected some approaches, and provided rationales for the rejections, 
but that doesn't mean that we have to live with the current proposal 
if the WG finds the inherent security problematic.

>Third, an apparently innocuous logotype can change appearance radically
>when scaled to a smaller size or mapped to a different number of colors.
>This can be exploited to deceive cell phone users into thinking that
>they're communicating with their bank, for instance.

I had not considered this issue. we should explore ways that this 
problem might be avoided. presumably anyone displaying a logo on a 
web page has a similar concern, so maybe there are viable means to 
address this issue.

>Unless these concerns can be addressed, I do not think that this
>proposal is safe and secure. And I do not think that the IETF should
>publish an RFC on a fundamentally insecure idea, especially from a
>security working group.

The attribute RFC has some problems too, in that bad choices of how 
to map an AC to a PKC can result in security failures, right?  So, 
the issue is not whether there are insecure ways to make use of the 
extension, but whether there are ways to make its use secure and 
whether, on the balance, we think appropriate use of the extension is 
beneficial, from a security (not marketing) perspective.

Steve


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f7UKcSl16798 for ietf-pkix-bks; Thu, 30 Aug 2001 13:38:28 -0700 (PDT)
Received: from femail18.sdc1.sfba.home.com (femail18.sdc1.sfba.home.com [24.0.95.145]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f7UKcRD16794 for <[e-mail]>; Thu, 30 Aug 2001 13:38:27 -0700 (PDT)
Received: from workerbee ([24.180.131.6]) by femail18.sdc1.sfba.home.com (InterMail vM.4.01.03.20 201-229-121-120-20010223) with SMTP id <20010830203825.BUVL5652.femail18.sdc1.sfba.home.com@workerbee>; Thu, 30 Aug 2001 13:38:25 -0700
From: "Al Arsenault" <[e-mail]>
To: "Steve Hanna" <[e-mail]>
Cc: "Stephen Kent" <[e-mail]>, <[e-mail]>
Subject: RE: charter revisions
Date: Thu, 30 Aug 2001 16:42:51 -0400
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
In-Reply-To: <[e-mail]>
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>

I agree with Russ here.  The issues involved with logos, while difficult,
are not insurmountable.  They do serve a useful purpose in some
environments, and a standard way of including them will be much better than
letting every CA invents its own.

I believe that the logo work should be in the PKIX charter.

		Al Arsenault
		Chief Security Architect
		Diversinet



-----Original Message-----
From: [e-mail]
[mailto:[e-mail]]On Behalf Of Housley, Russ
Sent: Thursday, August 30, 2001 1:33 PM
To: Steve Hanna
Cc: Stephen Kent; [e-mail]
Subject: Re: charter revisions



Steve Hanna:

>I haven't seen any comments on the revised charter yet. Most of it looks
>good to me. However, I don't think PKIX should do any work on the
>logotype extension. I know that there is a demand for this from
>marketing folks, but I don't believe that we should standardize it
>unless it can be used securely. This does not seem possible.

You and I agree on most things, but we have a major disagreement here.  I
do not think that we will see widespread deployment of certificates without
logos.  One measure of success will be the number of certificates that
average Internet user have.  Hopefully every Internet user will have at
least one.  I suspect that as we become successful, these logos will be the
tag by which users select a certificate.

I do not want to see more than one way that logos can be put into
certificates.  That is the most important reason for PKIX to be involved in
the definition.  You seem to agree that the market has a demand for
logos.  Letting each vendor devise an independent way to meet this
marketing requirement would be very bad for all implementors.

You seem to be concerned with the security of logos.  I am not.  From my
perspective, we are asking CAs to do many things that are harder than
including a URL and hash of a the appropriate logo.  In many, many cases,
this will be the same logo in every certificate that is issued by that CA.

Anyway, we should not have the complete technical debate on a threat about
the charter.  I strongly encourage the PKIX working group to include this
area in the charter sent forward to the Area Directors for approval.  Once
the revised charter is approved, we can have the technical debate and sort
out the details.

Russ



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f7UHmUN13954 for ietf-pkix-bks; Thu, 30 Aug 2001 10:48:30 -0700 (PDT)
Received: from tholian.securitydynamics.com (mail.rsasecurity.com [204.167.112.129]) by above.proper.com (8.11.6/8.11.3) with SMTP id f7UHmOD13950 for <[e-mail]>; Thu, 30 Aug 2001 10:48:24 -0700 (PDT)
Received: from sdtihq24.securid.com by tholian.securitydynamics.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 30 Aug 2001 17:45:58 UT
Received: from exna00.securitydynamics.com (ebola.securid.com [192.168.7.4]) by sdtihq24.securid.com (Pro-8.9.3/Pro-8.9.3) with ESMTP id NAA06788; Thu, 30 Aug 2001 13:47:31 -0400 (EDT)
Received: by exna00.securitydynamics.com with Internet Mail Service (5.5.2653.19) id <QTWCTH4F>; Thu, 30 Aug 2001 13:48:19 -0400
Received: from HOUSLEY-LAP.rsasecurity.com (HOUSLEY-LAP [10.3.1.118]) by exna00.securitydynamics.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id QTWCTH4A; Thu, 30 Aug 2001 13:48:17 -0400
From: "Housley, Russ" <[e-mail]>
To: Steve Hanna <[e-mail]>
Cc: Stephen Kent <[e-mail]>, [e-mail]
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.0.1
Date: Thu, 30 Aug 2001 13:33:24 -0400
Subject: Re: charter revisions
In-Reply-To: <[e-mail]>
References: <p0501040bb7a8214adf35@[128.33.84.34]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>

Steve Hanna:

>I haven't seen any comments on the revised charter yet. Most of it looks
>good to me. However, I don't think PKIX should do any work on the
>logotype extension. I know that there is a demand for this from
>marketing folks, but I don't believe that we should standardize it
>unless it can be used securely. This does not seem possible.

You and I agree on most things, but we have a major disagreement here.  I 
do not think that we will see widespread deployment of certificates without 
logos.  One measure of success will be the number of certificates that 
average Internet user have.  Hopefully every Internet user will have at 
least one.  I suspect that as we become successful, these logos will be the 
tag by which users select a certificate.

I do not want to see more than one way that logos can be put into 
certificates.  That is the most important reason for PKIX to be involved in 
the definition.  You seem to agree that the market has a demand for 
logos.  Letting each vendor devise an independent way to meet this 
marketing requirement would be very bad for all implementors.

You seem to be concerned with the security of logos.  I am not.  From my 
perspective, we are asking CAs to do many things that are harder than 
including a URL and hash of a the appropriate logo.  In many, many cases, 
this will be the same logo in every certificate that is issued by that CA.

Anyway, we should not have the complete technical debate on a threat about 
the charter.  I strongly encourage the PKIX working group to include this 
area in the charter sent forward to the Area Directors for approval.  Once 
the revised charter is approved, we can have the technical debate and sort 
out the details.

Russ


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f7U9ZPc18984 for ietf-pkix-bks; Thu, 30 Aug 2001 02:35:25 -0700 (PDT)
Received: from ocasey.baltimore.com ([193.41.17.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f7U9ZMD18980 for <[e-mail]>; Thu, 30 Aug 2001 02:35:23 -0700 (PDT)
Received: from Baltimore-FW1 ([172.19.1.1]) by ocasey.baltimore.com (8.9.3/8.9.3) with SMTP id KAA26198 for <[e-mail]>; Thu, 30 Aug 2001 10:35:16 +0100
Received: from Baltimore-FW1 (wilde-i-1.ie.baltimore.com) by emeairlsw1.baltimore.com (Content Technologies SMTPRS 4.2.5) with SMTP id <[e-mail]> for <[e-mail]>; Thu, 30 Aug 2001 10:32:24 +0100
Received: from baltimore.ie (wks102-0.ie.baltimore.com [10.153.0.102]) by bobcat.baltimore.ie (8.9.3/8.9.3) with ESMTP id KAA10977; Thu, 30 Aug 2001 10:36:25 +0100
Message-ID: <[e-mail]>
Date: Thu, 30 Aug 2001 10:35:06 +0100
From: Stephen Farrell <[e-mail]>
Reply-To: [e-mail]
Organization: Baltimore Technologies Ltd.
X-Mailer: Mozilla 4.72 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Stephen Kent <[e-mail]>
CC: Steve Hanna <[e-mail]>, [e-mail]
Subject: Re: charter revisions
References: <p0501040bb7a8214adf35@[128.33.84.34]> <[e-mail]>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>

Steve (K),

I'd have to agree with Steve H, though maybe not as strongly. 

My suggestion would be to limit the additional items to the
dpd/dpv.

In addition the replacement charter text doesn't mention the
fact that PKIX has profiled the X.509 AC which I guess I can't
let pass:-)

Stephen.


Steve Hanna wrote:
> 
> I haven't seen any comments on the revised charter yet. Most of it looks
> good to me. However, I don't think PKIX should do any work on the
> logotype extension. I know that there is a demand for this from
> marketing folks, but I don't believe that we should standardize it
> unless it can be used securely. This does not seem possible.
> 
> First, CAs will find it very hard to verify whether a particular
> logotype should be included in a particular certificate. They'll just
> need to certify whatever the client gives them and disclaim all
> responsibility for its accuracy. With textual names, at least they can
> make some attempt to verify that the name corresponds to the requesting
> client (by requiring a response from an email address before it's
> certified, for instance).
> 
> Second, there's no equivalent to name constraints for use in cross
> certificates. If I cross certify someone, I just have to trust that they
> (and anyone they certify) will only put proper logotypes into
> certificates.
> 
> Third, an apparently innocuous logotype can change appearance radically
> when scaled to a smaller size or mapped to a different number of colors.
> This can be exploited to deceive cell phone users into thinking that
> they're communicating with their bank, for instance.
> 
> Unless these concerns can be addressed, I do not think that this
> proposal is safe and secure. And I do not think that the IETF should
> publish an RFC on a fundamentally insecure idea, especially from a
> security working group.
> 
> -Steve

-- 
____________________________________________________________
Stephen Farrell         				   
Baltimore Technologies,   tel: (direct line) [phone]
39 Parkgate Street,                     fax: [phone]
Dublin 8.                mailto:[e-mail]
Ireland                             http://www.baltimore.com


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f7TNTjN15201 for ietf-pkix-bks; Wed, 29 Aug 2001 16:29:45 -0700 (PDT)
Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f7TNThD15197 for <[e-mail]>; Wed, 29 Aug 2001 16:29:43 -0700 (PDT)
Received: from ISI.EDU (jet.isi.edu [128.9.160.87]) by boreas.isi.edu (8.11.6/8.11.2) with ESMTP id f7TNTSn20828; Wed, 29 Aug 2001 16:29:28 -0700 (PDT)
Message-Id: <[e-mail]>
To: IETF-Announce: ;
Subject: RFC 3161 on Time-Stamp Protocol (TSP)
Cc: [e-mail], [e-mail]
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary=NextPart
Date: Wed, 29 Aug 2001 16:29:28 -0700
From: RFC Editor <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>

--NextPart


A new Request for Comments is now available in online RFC libraries.


        RFC 3161

        Title:	    Internet X.509 Public Key Infrastructure
                    Time-Stamp Protocol (TSP)
        Author(s):  C. Adams, P. Cain, D. Pinkas, R. Zuccherato
        Status:     Standards Track
	Date:       August 2001
        Mailbox:    [e-mail], [e-mail],
                    [e-mail],
                    [e-mail] 
        Pages:      26
        Characters: 54582
        Obsoletes/Updates/SeeAlso:    None

        I-D Tag:    draft-ietf-pkix-time-stamp-15.txt

        URL:        ftp://ftp.rfc-editor.org/in-notes/rfc3161.txt


This document describes the format of a request sent to a Time
Stamping Authority (TSA) and of the response that is returned.  It
also establishes several security-relevant requirements for TSA
operation, with regards to processing requests to generate responses.

This document is a product of the Public-Key Infrastructure (C.509)
Working Group of the IETF.

This is now a Proposed Standard Protocol.

This document specifies an Internet standards track protocol for
the Internet community, and requests discussion and suggestions
for improvements.  Please refer to the current edition of the
"Internet Official Protocol Standards" (STD 1) for the
standardization state and status of this protocol.  Distribution
of this memo is unlimited.

This announcement is sent to the IETF list and the RFC-DIST list.
Requests to be added to or deleted from the IETF distribution list
should be sent to [e-mail].  Requests to be
added to or deleted from the RFC-DIST distribution list should
be sent to [e-mail].

Details on obtaining RFCs via FTP or EMAIL may be obtained by sending
an EMAIL message to [e-mail] with the message body 
help: ways_to_get_rfcs.  For example:

        To: [e-mail]
        Subject: getting rfcs

        help: ways_to_get_rfcs

Requests for special distribution should be addressed to either the
author of the RFC in question, or to [e-mail].  Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.echo 
Submissions for Requests for Comments should be sent to
[e-mail].  Please consult RFC 2223, Instructions to RFC
Authors, for further information.


Joyce K. Reynolds and Sandy Ginoza
USC/Information Sciences Institute

...

Below is the data which will enable a MIME compliant Mail Reader 
implementation to automatically retrieve the ASCII version
of the RFCs.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type:  Message/External-body;
        access-type="mail-server";
        server="[e-mail]"

Content-Type: text/plain
Content-ID: <[e-mail]>

RETRIEVE: rfc
DOC-ID: rfc3161

--OtherAccess
Content-Type:   Message/External-body;
        name="rfc3161.txt";
        site="ftp.isi.edu";
        access-type="anon-ftp";
        directory="in-notes"

Content-Type: text/plain
Content-ID: <[e-mail]>

--OtherAccess--
--NextPart--


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f7TL0mk12640 for ietf-pkix-bks; Wed, 29 Aug 2001 14:00:48 -0700 (PDT)
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f7TL0kD12636 for <[e-mail]>; Wed, 29 Aug 2001 14:00:46 -0700 (PDT)
Received: from sunlabs.East.Sun.COM ([129.148.75.250]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA08018; Wed, 29 Aug 2001 15:00:44 -0600 (MDT)
Received: from sun.com (dhcp75-167 [129.148.75.167]) by sunlabs.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id RAA08384; Wed, 29 Aug 2001 17:00:47 -0400 (EDT)
Message-ID: <[e-mail]>
Date: Wed, 29 Aug 2001 17:00:31 -0400
From: Steve Hanna <[e-mail]>
Organization: Sun Microsystems, Inc.
X-Mailer: Mozilla 4.75 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Stephen Kent <[e-mail]>
CC: [e-mail]
Subject: Re: charter revisions
References: <p0501040bb7a8214adf35@[128.33.84.34]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>

I haven't seen any comments on the revised charter yet. Most of it looks
good to me. However, I don't think PKIX should do any work on the
logotype extension. I know that there is a demand for this from
marketing folks, but I don't believe that we should standardize it
unless it can be used securely. This does not seem possible.

First, CAs will find it very hard to verify whether a particular
logotype should be included in a particular certificate. They'll just
need to certify whatever the client gives them and disclaim all
responsibility for its accuracy. With textual names, at least they can
make some attempt to verify that the name corresponds to the requesting
client (by requiring a response from an email address before it's
certified, for instance).

Second, there's no equivalent to name constraints for use in cross
certificates. If I cross certify someone, I just have to trust that they
(and anyone they certify) will only put proper logotypes into
certificates.

Third, an apparently innocuous logotype can change appearance radically
when scaled to a smaller size or mapped to a different number of colors.
This can be exploited to deceive cell phone users into thinking that
they're communicating with their bank, for instance.

Unless these concerns can be addressed, I do not think that this
proposal is safe and secure. And I do not think that the IETF should
publish an RFC on a fundamentally insecure idea, especially from a
security working group.

-Steve


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f7TKEcU12074 for ietf-pkix-bks; Wed, 29 Aug 2001 13:14:38 -0700 (PDT)
Received: from tholian.securitydynamics.com (mail.rsasecurity.com [204.167.112.129]) by above.proper.com (8.11.6/8.11.3) with SMTP id f7TKEaD12070 for <[e-mail]>; Wed, 29 Aug 2001 13:14:36 -0700 (PDT)
Received: from sdtihq24.securitydynamics.com by tholian.securitydynamics.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 29 Aug 2001 20:12:11 UT
Received: from exna00.securitydynamics.com (ebola.securid.com [192.168.7.4]) by sdtihq24.securid.com (Pro-8.9.3/Pro-8.9.3) with ESMTP id QAA25634 for <[e-mail]>; Wed, 29 Aug 2001 16:13:49 -0400 (EDT)
Received: by exna00.securitydynamics.com with Internet Mail Service (5.5.2653.19) id <QTWCS6WT>; Wed, 29 Aug 2001 16:14:37 -0400
Received: from HOUSLEY-LAP.rsasecurity.com (HOUSLEY-LAP [10.3.1.104]) by exna00.securitydynamics.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id QTWCS6WR; Wed, 29 Aug 2001 16:14:31 -0400
From: "Housley, Russ" <[e-mail]>
To: "Christopher S. Francis" <[e-mail]>
Cc: Ietf-Pkix <[e-mail]>
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.0.1
Date: Wed, 29 Aug 2001 16:14:18 -0400
Subject: RE: Use of attribute certificates in SignedData
In-Reply-To: <[e-mail] m>
References: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>

Chris:

We heard from Blake that his application will have a problem.  I hope that 
most will gracefully ignore certificates (of any type) that they do not need.

Russ


At 03:24 PM 8/29/2001 -0400, Christopher S. Francis wrote:
>Thanks Russ.  That confirms my interpretation of 2630.  I'm concerned that
>if I include an AC in SignedData in the "correct" field that commonly
>available applications/toolkits will choke when they try to validate the
>signature on the SignedData object.
>
>I was hoping for a solution in which AC-enabled applications would use the
>AC if one is provided, but commonly available "AC challenged"
>applications/toolkits would just ignore it and rely only on the PKC for
>signature validation.  Based on some of the responses I got from the SMIME
>list, it sounds like I may not be able to achieve this; especially since I
>would prefer to use the X.509 2000 AC syntax.
>
>Chris
>-----Original Message-----
>From: Housley, Russ [mailto:[e-mail]]
>Sent: Wednesday, August 29, 2001 10:24 AM
>To: Christopher S. Francis
>Cc: Ietf-Pkix
>Subject: Re: Use of attribute certificates in SignedData
>
>Chris:
>
>SignedData has the following syntax:
>
>        SignedData ::= SEQUENCE {
>          version CMSVersion,
>          digestAlgorithms DigestAlgorithmIdentifiers,
>          encapContentInfo EncapsulatedContentInfo,
>          certificates [0] IMPLICIT CertificateSet OPTIONAL,
>          crls [1] IMPLICIT CertificateRevocationLists OPTIONAL,
>          signerInfos SignerInfos }
>
>        CertificateSet ::= SET OF CertificateChoices
>
>        CertificateChoices ::= CHOICE {
>          certificate Certificate,                               -- See X.509
>          extendedCertificate [0] IMPLICIT ExtendedCertificate,  -- Obsolete
>          v1AttrCert [1] IMPLICIT AttributeCertificateV1,        -- Obsolete
>          v2AttrCert [2] IMPLICIT AttributeCertificateV2 }       -- See X.509
>
>
>PKCs and ACs needed to process any of the signerInfos should be carried in
>the certificates field.
>
>Russ
>
>At 10:43 AM 8/28/2001 -0400, Christopher S. Francis wrote:
>
> >I have a question for the group concerning attribute certificates.
> >
> >
> >
> >Is there an accepted location to put an attribute certificate associated
> >with the signer in the SignedData data structure?  I have a SignedData
> >object and I m considering putting an attribute certificate associated
> >with the signer in the certificates field of SignedData in addition to the
> >PKC of the signer.
> >
> >Is that a philosophically correct location?  Other options include burying
> >the certificate in the encapsulated content or including it as a Signed or
> >UnSigned attribute.
> >
> >
> >
> >I d appreciate any advice and or lessons learned that you can
> >offer.  Thanks in advance.
> >
> >
> >
> >Chris Francis
> >
> >


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f7TJOqO10931 for ietf-pkix-bks; Wed, 29 Aug 2001 12:24:52 -0700 (PDT)
Received: from gto-mailer1.bbn.com (cam-mailer1.bbn.com [128.33.0.36]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f7TJOpD10925 for <[e-mail]>; Wed, 29 Aug 2001 12:24:51 -0700 (PDT)
Received: from [128.33.84.34] (comsec.bbn.com [128.33.84.34]) by gto-mailer1.bbn.com (8.9.3+Sun/8.9.3) with ESMTP id PAA21613 for <[e-mail]>; Wed, 29 Aug 2001 15:27:05 -0400 (EDT)
Mime-Version: 1.0
X-Sender: [e-mail]
Message-Id: <p05010409b7b2f11a2a5a@[128.33.84.34]>
Date: Wed, 29 Aug 2001 15:21:33 -0400
To: [e-mail]
From: Stephen Kent <[e-mail]>
Subject: revised meeting minutes
Content-Type: multipart/alternative; boundary="============_-1213009282==_ma============"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>

--============_-1213009282==_ma============
Content-Type: text/plain; charset="us-ascii" ; format="flowed"

PKIX WG Meeting 8/6/01
Edited by Steve Kent (WG co-chairs)

The PKIX WG met once during the 51st IETF. A total of approximately 153
individuals participated in the meeting.


Tim quickly reviewed the agenda and document status, noting that there are many
I-Ds in progress. (see slides)

Two new RFCs in the editor's queue:
	RFC 3161	Timestamp Protocol
	RFC xxxx	Attribute Certificate Profile

In the IESG Review Process:
	PKIX Certificate and CRL Profile (a.k.a., son-of-2459)
	Public Key Algorithms and Identifiers for the PKIX Certificate profile

Soon to be Submitted to IESG:
	PKIX Roadmap
	Repository Locator Service

In WG Last Call:
	none

Close to WG last call:
	Certificate Management Protocol (RFC 2510bis)
	Certificate Request Message Framework (RFC 2511bis)
	Transport Protocols for CMP
	Online Certificate Status Protocol (OCSP v2)

New Work:


Logotype Certificates - Stefan Santesson (AddTrust)
	Notion is to embed references to logos in certificates, for
CAs or for EEs,  to allow display of the logo as part of certificate
processing. Argument is that people relate to logos in the physical
world, and don't display certificate contents, so this is a way to
bring branding into PKIs. Major concern is that people could be
mislead by certificates issued by a CA that binds inappropriate logos
to certificates it issues, e.g., there is no way to constrain logo
references the same way we can constrain names. Proposal is to create
a new extension for carrying a pointer (URL) to the logo image, an
indication of the image type, and a hash of the image. (see slides)

Supplemental Algorithms - Ari Singer (NTRU)
	New work item, to contain specs for a set of algorithms that
COULD be used with PKIX data structures. Support for these algorithms
is not mandated, but this document will provide a reference for these
supplemental algorithms. Note need to include appropriate
intellectual property warnings for proprietary algorithms, and to
distinguish between algorithms that are standards, vs, proprietary.
(see slides)

PKI Disaster Recovery - Denis Pinkas (Integris)
	The goal of this new work is to create an informational RFC
which addresses how to deal with compromise or loss of use of a CA,
AA, or TSA key. Different requirements arise for EE signature keys
vs. EE encryption keys, and these are addressed separately. (see
slides)

Using DNS for PKI Support- Simon Josephson (RSA)
	ID published as a personal draft. Focuses on using DNS to
hold certificates and CRLs. Works especially well for S/MINE, given
typical DNS lookup re MX records. Question is whether PKIX should
adopt this as a work item? Will discuss this on the list. (no slides)


Ongoing Work:

LDAP V3 Profile and Certificate Matching Rules - David Chadwick (Univ
of Salford)
	Profile going well, looking for feedback before publishing as
RFC. Matching rules work not as far along, but implementation work
now funded at Salford, which will help progress.

CMC Update - Jim Schaad (Soaring Hawk Consulting)
	Core functions largely unchanged, e.g., ASN syntax and
processing rules will be static. New set of CMC documents being
issued, breaking into multiple pieces to allow easier progression of
pieces, e.g., S/MIME makes use of CMC for symmetric key distribution,
compliance document. VeriSign hosted interoperability testing covering
a large number of protocol features. Several issues were uncovered during
testing. (see slides)

CMP Update - Carlisle Adams (Entrust)
	Interoperability testing yielded clarifications and the
document is now ready to go to Draft Standard status.

Proxy Certificates - Steven Tuecke (Argonne Labs)
	Revised ID has been published. Related draft in TLS WG. Not
many attendees have read this draft, according to a show of hands.
Because it requires changes to certificate path validation, there is
a significant question about whether these changes should be part of
the base standards, or if this processing is a separate step to be
performed after standard path validation processing. (see slides)

OCSPv2 - Michael Myers (VeriSign)
	Authors have decided to publish as experimental for now. This 
includes the OCSPv2 draft, the DPD with OCSP draft, and the DPV 
draft. (no slides)

SCVP - Ambarish Malpani (ValiCert)
	There were two significant changes to the draft: only ASN.1 
syntax is employed and signatures are based on the CMS format. (no 
slides)

DPD/DPV - Denis Pinkas (Integris)
	New ID posed to list. Incorporate new approach to DPV/DPD,
using 3 protocols: DPV, DPD, and a separate protocol for management
of policy data used for validation or discovery. This allows the DPD
and DPV protocols to be smaller and simpler, because the management
of parameters used for DPD/DPV is part of a separate protocol. The
management protocol might not be implemented on many clients, e.g.,
thin clients. References to the parameters (policy) used for
validation are OIDs, and there is a provision for a client to NOT
specify a policy, but have a server employ a default policy and
return that to the user. Extensive use of hashes of ancillary values
to keep messages brief, but allow checking by client. DPV proposal
allows for validation re current time, or past time (re-validation).
DPV can return four answers, reflecting level of knowledge available
to the server, especially with regard to revocation data. DPD and
management protocol also presented in detail. (see slides)

Policy Requirements for Timestamping  Authorities- Denis Pinkas (Integris)
	Discussion of this ETSI document and solicitation of
comments. (see slides)
--============_-1213009282==_ma============
Content-Type: text/html; charset="us-ascii"

<!doctype html public "-//W3C//DTD W3 HTML//EN">
<html><head><style type="text/css"><!--
blockquote, dl, ul, ol, li { margin-top: 0 ; margin-bottom: 0 }
 --></style><title>revised meeting minutes</title></head><body>
<div><font face="Courier" size="+2" color="#000000">PKIX WG Meeting
8/6/01<br>
Edited by Steve Kent (WG co-chairs)<br>
<br>
The PKIX WG met once during the 51st IETF. A total of approximately
153<br>
individuals participated in the meeting.<br>
<br>
<br>
Tim quickly reviewed the agenda and document status, noting that there
are many<br>
I-Ds in progress. (see slides)<br>
<br>
Two new RFCs in the editor's queue:<br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </x-tab>RFC
3161<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</x-tab>Timestamp Protocol<br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </x-tab>RFC
xxxx<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</x-tab>Attribute Certificate Profile<br>
<br>
In the IESG Review Process:<br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </x-tab>PKIX
Certificate and CRL Profile (a.k.a., son-of-2459)<br>
<x-tab>&nbsp; </x-tab>Public Key Algorithms and Identifiers for the
PKIX Certificate profile<br>
<br>
Soon to be Submitted to IESG:<br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp; </x-tab>PKIX Roadmap<br>
<x-tab>&nbsp;&nbsp;&nbsp; </x-tab>Repository Locator Service<br>
<br>
In WG Last Call:<br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </x-tab>none<br>
<br>
Close to WG last call:<br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </x-tab>Certificate Management
Protocol (RFC 2510bis)<br>
<x-tab>&nbsp;&nbsp; </x-tab>Certificate Request Message Framework (RFC
2511bis)<br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp; </x-tab>Transport Protocols for
CMP<br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp; </x-tab>Online Certificate Status
Protocol (OCSP v2)<br>
<br>
New Work:<br>
<br>
<br>
Logotype Certificates - Stefan Santesson (AddTrust)<br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </x-tab>Notion is to
embed references to logos in certificates, for<br>
CAs or for EEs,&nbsp; to allow display of the logo as part of
certificate<br>
processing. Argument is that people relate to logos in the
physical<br>
world, and don't display certificate contents, so this is a way to<br>
bring branding into PKIs. Major concern is that people could be<br>
mislead by certificates issued by a CA that binds inappropriate
logos<br>
to certificates it issues, e.g., there is no way to constrain logo<br>
references the same way we can constrain names. Proposal is to
create<br>
a new extension for carrying a pointer (URL) to the logo image, an<br>
indication of the image type, and a hash of the image. (see
slides)<br>
<br>
Supplemental Algorithms - Ari Singer (NTRU)<br>
<x-tab> </x-tab>New work item, to contain specs for a set of
algorithms that<br>
COULD be used with PKIX data structures. Support for these
algorithms<br>
is not mandated, but this document will provide a reference for
these<br>
supplemental algorithms. Note need to include appropriate<br>
intellectual property warnings for proprietary algorithms, and to<br>
distinguish between algorithms that are standards, vs,
proprietary.<br>
(see slides)<br>
<br>
PKI Disaster Recovery - Denis Pinkas (Integris)<br>
<x-tab>&nbsp; </x-tab>The goal of this new work is to create an
informational RFC<br>
which addresses how to deal with compromise or loss of use of a
CA,<br>
AA, or TSA key. Different requirements arise for EE signature keys<br>
vs. EE encryption keys, and these are addressed separately. (see<br>
slides)<br>
<br>
Using DNS for PKI Support- Simon Josephson (RSA)<br>
<x-tab> </x-tab>ID published as a personal draft. Focuses on using DNS
to<br>
hold certificates and CRLs. Works especially well for S/MINE,
given<br>
typical DNS lookup re MX records. Question is whether PKIX should<br>
adopt this as a work item? Will discuss this on the list. (no
slides)<br>
<br>
<br>
Ongoing Work:<br>
<br>
LDAP V3 Profile and Certificate Matching Rules - David Chadwick
(Univ<br>
of Salford)<br>
<x-tab> </x-tab>Profile going well, looking for feedback before
publishing as<br>
RFC. Matching rules work not as far along, but implementation work<br>
now funded at Salford, which will help progress.<br>
<br>
CMC Update - Jim Schaad (Soaring Hawk Consulting)<br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </x-tab>Core
functions largely unchanged, e.g., ASN syntax and<br>
processing rules will be static. New set of CMC documents being<br>
issued, breaking into multiple pieces to allow easier progression
of<br>
pieces, e.g., S/MIME makes use of CMC for symmetric key
distribution,<br>
compliance document. VeriSign hosted interoperability testing
covering<br>
a large number of protocol features. Several issues were uncovered
during<br>
testing. (see slides)<br>
<br>
CMP Update - Carlisle Adams (Entrust)<br>
<x-tab> </x-tab>Interoperability testing yielded clarifications and
the<br>
document is now ready to go to Draft Standard status.<br>
<br>
Proxy Certificates - Steven Tuecke (Argonne Labs)<br>
<x-tab>&nbsp;&nbsp; </x-tab>Revised ID has been published. Related
draft in TLS WG. Not<br>
many attendees have read this draft, according to a show of hands.<br>
Because it requires changes to certificate path validation, there
is<br>
a significant question about whether these changes should be part
of<br>
the base standards, or if this processing is a separate step to be<br>
performed after standard path validation processing. (see
slides)</font></div>
<div><font face="Courier" size="+2" color="#000000"><br>
OCSPv2 - Michael Myers (VeriSign)<br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </x-tab>Authors have
decided to publish as experimental for now. This includes the OCSPv2
draft, the DPD with OCSP draft, and the DPV draft. (no slides)<br>
<br>
SCVP - Ambarish Malpani (ValiCert)<br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </x-tab>There were two
significant changes to the draft: only ASN.1 syntax is employed and
signatures are based on the CMS format. (no slides)<br>
<br>
DPD/DPV - Denis Pinkas (Integris)<br>
<x-tab> </x-tab>New ID posed to list. Incorporate new approach to
DPV/DPD,<br>
using 3 protocols: DPV, DPD, and a separate protocol for
management<br>
of policy data used for validation or discovery. This allows the
DPD<br>
and DPV protocols to be smaller and simpler, because the
management<br>
of parameters used for DPD/DPV is part of a separate protocol. The<br>
management protocol might not be implemented on many clients,
e.g.,<br>
thin clients. References to the parameters (policy) used for<br>
validation are OIDs, and there is a provision for a client to NOT<br>
specify a policy, but have a server employ a default policy and<br>
return that to the user. Extensive use of hashes of ancillary
values<br>
to keep messages brief, but allow checking by client. DPV proposal<br>
allows for validation re current time, or past time
(re-validation).<br>
DPV can return four answers, reflecting level of knowledge
available<br>
to the server, especially with regard to revocation data. DPD and<br>
management protocol also presented in detail. (see slides)<br>
<br>
Policy Requirements for Timestamping&nbsp; Authorities- Denis Pinkas
(Integris)<br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </x-tab>Discussion
of this ETSI document and solicitation of<br>
comments. (see slides)</font></div>
</body>
</html>
--============_-1213009282==_ma============--


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f7TJOJh10903 for ietf-pkix-bks; Wed, 29 Aug 2001 12:24:19 -0700 (PDT)
Received: from emerald.lightlink.com (emerald.lightlink.com [205.232.34.14]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f7TJOID10898 for <[e-mail]>; Wed, 29 Aug 2001 12:24:18 -0700 (PDT)
Received: from [209.216.70.29] (perm70-29.ij.net [209.216.70.29] (may be forged)) by emerald.lightlink.com (8.8.8/8.8.8) with SMTP id PAA22590; Wed, 29 Aug 2001 15:24:10 -0400
From: "Christopher S. Francis" <[e-mail]>
To: "Housley, Russ" <[e-mail]>
Cc: "Ietf-Pkix" <[e-mail]>
Received: from no.name.available by [209.216.70.29] via smtpd (for smtp.lightlink.com [205.232.34.14]) with SMTP; 29 Aug 2001 19:25:02 UT
Subject: RE: Use of attribute certificates in SignedData
Date: Wed, 29 Aug 2001 15:24:09 -0400
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
Importance: Normal
In-Reply-To: <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>

Thanks Russ.  That confirms my interpretation of 2630.  I'm concerned that
if I include an AC in SignedData in the "correct" field that commonly
available applications/toolkits will choke when they try to validate the
signature on the SignedData object.

I was hoping for a solution in which AC-enabled applications would use the
AC if one is provided, but commonly available "AC challenged"
applications/toolkits would just ignore it and rely only on the PKC for
signature validation.  Based on some of the responses I got from the SMIME
list, it sounds like I may not be able to achieve this; especially since I
would prefer to use the X.509 2000 AC syntax.

Chris
-----Original Message-----
From: Housley, Russ [mailto:[e-mail]]
Sent: Wednesday, August 29, 2001 10:24 AM
To: Christopher S. Francis
Cc: Ietf-Pkix
Subject: Re: Use of attribute certificates in SignedData

Chris:

SignedData has the following syntax:

       SignedData ::= SEQUENCE {
         version CMSVersion,
         digestAlgorithms DigestAlgorithmIdentifiers,
         encapContentInfo EncapsulatedContentInfo,
         certificates [0] IMPLICIT CertificateSet OPTIONAL,
         crls [1] IMPLICIT CertificateRevocationLists OPTIONAL,
         signerInfos SignerInfos }

       CertificateSet ::= SET OF CertificateChoices

       CertificateChoices ::= CHOICE {
         certificate Certificate,                               -- See X.509
         extendedCertificate [0] IMPLICIT ExtendedCertificate,  -- Obsolete
         v1AttrCert [1] IMPLICIT AttributeCertificateV1,        -- Obsolete
         v2AttrCert [2] IMPLICIT AttributeCertificateV2 }       -- See X.509


PKCs and ACs needed to process any of the signerInfos should be carried in
the certificates field.

Russ

At 10:43 AM 8/28/2001 -0400, Christopher S. Francis wrote:

>I have a question for the group concerning attribute certificates.
>
>
>
>Is there an accepted location to put an attribute certificate associated
>with the signer in the SignedData data structure?  I have a SignedData
>object and I m considering putting an attribute certificate associated
>with the signer in the certificates field of SignedData in addition to the
>PKC of the signer.
>
>Is that a philosophically correct location?  Other options include burying
>the certificate in the encapsulated content or including it as a Signed or
>UnSigned attribute.
>
>
>
>I d appreciate any advice and or lessons learned that you can
>offer.  Thanks in advance.
>
>
>
>Chris Francis
>
>



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f7TEWkE00704 for ietf-pkix-bks; Wed, 29 Aug 2001 07:32:46 -0700 (PDT)
Received: from SOTTMXS01.entrust.com (gatekeeper.entrust.com [204.101.128.170]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f7TEWiD00700 for <[e-mail]>; Wed, 29 Aug 2001 07:32:44 -0700 (PDT)
Received: by SOTTMXS01.entrust.com with Internet Mail Service (5.5.2650.21) id <RZ45XQD1>; Wed, 29 Aug 2001 10:32:39 -0400
Message-ID: <[e-mail]>
From: Carlisle Adams <[e-mail]>
To: "'li yunfeng'" <[e-mail]>
Cc: [e-mail], [e-mail]
Subject: RE: 
Date: Wed, 29 Aug 2001 10:32:37 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C13097.736F3F30"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C13097.736F3F30
Content-Type: text/plain

Hi,

> ----------
> From: 	li yunfeng[SMTP:[e-mail]]
> Sent: 	Wednesday, August 29, 2001 3:00 AM
> To: 	[e-mail]
> Cc: 	[e-mail]
> 
> 
> Dear peter:
> When I program the PKIX protocal, I found I have to
> process the PBMParamenter struct in which there are a
> member "mac AlgorithmIdentifier".Rfc2510 said that one
> have to give the DES-MAC or TRIPLE-DES-MAC's oid in
> the "mac" field. But I could not found the
> TRIPLE-DES-MAC's OID in your docunment dunmoid.* so I
> want to know what OID should I give to the "mac"
> field.
 
Actually, according to Appendix B2, the MAC to use in PasswordBasedMac is
HMAC (and the OID is provided).

Carlisle.


------_=_NextPart_001_01C13097.736F3F30
Content-Type: text/html
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3DUS-ASCII">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2652.35">
<TITLE>RE: </TITLE>
</HEAD>
<BODY>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New Roman">Hi,</FONT>
</P>
<UL>
<P><FONT SIZE=3D2 FACE=3D"MS Sans Serif">----------</FONT>
<BR><B><FONT SIZE=3D2 FACE=3D"MS Sans Serif">From:</FONT></B> &nbsp; =
<FONT SIZE=3D2 FACE=3D"MS Sans Serif">li =
yunfeng[SMTP:[e-mail]]</FONT>
<BR><B><FONT SIZE=3D2 FACE=3D"MS Sans Serif">Sent:</FONT></B> &nbsp; =
<FONT SIZE=3D2 FACE=3D"MS Sans Serif">Wednesday, August 29, 2001 3:00 =
AM</FONT>
<BR><B><FONT SIZE=3D2 FACE=3D"MS Sans Serif">To:</FONT></B> =
&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2 FACE=3D"MS Sans =
Serif">[e-mail]</FONT>
<BR><B><FONT SIZE=3D2 FACE=3D"MS Sans Serif">Cc:</FONT></B> =
&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2 FACE=3D"MS Sans =
Serif">[e-mail]</FONT>
</P>
<BR>

<P><FONT SIZE=3D2 FACE=3D"MS Song">Dear peter:</FONT>
<BR><FONT SIZE=3D2 FACE=3D"MS Song">When I program the PKIX protocal, I =
found I have to</FONT>
<BR><FONT SIZE=3D2 FACE=3D"MS Song">process the PBMParamenter struct in =
which there are a</FONT>
<BR><FONT SIZE=3D2 FACE=3D"MS Song">member &quot;mac =
AlgorithmIdentifier&quot;.Rfc2510 said that one</FONT>
<BR><FONT SIZE=3D2 FACE=3D"MS Song">have to give the DES-MAC or =
TRIPLE-DES-MAC's oid in</FONT>
<BR><FONT SIZE=3D2 FACE=3D"MS Song">the &quot;mac&quot; field. But I =
could not found the</FONT>
<BR><FONT SIZE=3D2 FACE=3D"MS Song">TRIPLE-DES-MAC's OID in your =
docunment dunmoid.* so I</FONT>
<BR><FONT SIZE=3D2 FACE=3D"MS Song">want to know what OID should I give =
to the &quot;mac&quot;</FONT>
<BR><FONT SIZE=3D2 FACE=3D"MS Song">field.</FONT>
</UL>
<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New =
Roman">&nbsp;</FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New Roman">Actually, =
according to Appendix B2, the MAC to use in PasswordBasedMac is HMAC =
(and the OID is provided).</FONT>
</P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New =
Roman">Carlisle.</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C13097.736F3F30--


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f7TERPU00613 for ietf-pkix-bks; Wed, 29 Aug 2001 07:27:25 -0700 (PDT)
Received: from tholian.securitydynamics.com (mail.rsasecurity.com [204.167.112.129]) by above.proper.com (8.11.6/8.11.3) with SMTP id f7TERND00609 for <[e-mail]>; Wed, 29 Aug 2001 07:27:24 -0700 (PDT)
Received: from sdtihq24.securitydynamics.com by tholian.securitydynamics.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 29 Aug 2001 14:24:58 UT
Received: from exna00.securitydynamics.com (ebola.securid.com [192.168.7.4]) by sdtihq24.securid.com (Pro-8.9.3/Pro-8.9.3) with ESMTP id KAA21029 for <[e-mail]>; Wed, 29 Aug 2001 10:26:33 -0400 (EDT)
Received: by exna00.securitydynamics.com with Internet Mail Service (5.5.2653.19) id <QTWCS4Q4>; Wed, 29 Aug 2001 10:27:20 -0400
Received: from HOUSLEY-LAP.rsasecurity.com (HOUSLEY-LAP [10.3.1.121]) by exna00.securitydynamics.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id QTWCS4QR; Wed, 29 Aug 2001 10:27:16 -0400
From: "Housley, Russ" <[e-mail]>
To: "Christopher S. Francis" <[e-mail]>
Cc: Ietf-Pkix <[e-mail]>
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.0.1
Date: Wed, 29 Aug 2001 10:23:45 -0400
Subject: Re: Use of attribute certificates in SignedData
In-Reply-To: <[e-mail] m>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>

Chris:

SignedData has the following syntax:

       SignedData ::= SEQUENCE {
         version CMSVersion,
         digestAlgorithms DigestAlgorithmIdentifiers,
         encapContentInfo EncapsulatedContentInfo,
         certificates [0] IMPLICIT CertificateSet OPTIONAL,
         crls [1] IMPLICIT CertificateRevocationLists OPTIONAL,
         signerInfos SignerInfos }

       CertificateSet ::= SET OF CertificateChoices

       CertificateChoices ::= CHOICE {
         certificate Certificate,                               -- See X.509
         extendedCertificate [0] IMPLICIT ExtendedCertificate,  -- Obsolete
         v1AttrCert [1] IMPLICIT AttributeCertificateV1,        -- Obsolete
         v2AttrCert [2] IMPLICIT AttributeCertificateV2 }       -- See X.509


PKCs and ACs needed to process any of the signerInfos should be carried in 
the certificates field.

Russ

At 10:43 AM 8/28/2001 -0400, Christopher S. Francis wrote:

>I have a question for the group concerning attribute certificates.
>
>
>
>Is there an accepted location to put an attribute certificate associated 
>with the signer in the SignedData data structure?  I have a SignedData 
>object and I m considering putting an attribute certificate associated 
>with the signer in the certificates field of SignedData in addition to the 
>PKC of the signer.
>
>Is that a philosophically correct location?  Other options include burying 
>the certificate in the encapsulated content or including it as a Signed or 
>UnSigned attribute.
>
>
>
>I d appreciate any advice and or lessons learned that you can 
>offer.  Thanks in advance.
>
>
>
>Chris Francis
>
>


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f7TDXhG28503 for ietf-pkix-bks; Wed, 29 Aug 2001 06:33:43 -0700 (PDT)
Received: from kakapo.cs.auckland.ac.nz (kakapo.cs.auckland.ac.nz [130.216.34.10]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f7TDXfD28495 for <[e-mail]>; Wed, 29 Aug 2001 06:33:41 -0700 (PDT)
Received: from ruru.cs.auckland.ac.nz (firebird.cs.auckland.ac.nz [130.216.34.12]) by kakapo.cs.auckland.ac.nz (8.8.6/8.8.6/cs-master) with ESMTP id BAA23896; Thu, 30 Aug 2001 01:33:02 +1200 (NZST) (sender [e-mail])
Received: (from pgut001@localhost) by ruru.cs.auckland.ac.nz (8.9.3/8.8.6/cs-slave) id BAA473710; Thu, 30 Aug 2001 01:33:01 +1200 (NZST) (sender [e-mail])
Date: Thu, 30 Aug 2001 01:33:01 +1200 (NZST)
Message-ID: <[e-mail]>
From: [e-mail] (Peter Gutmann)
To: [e-mail], [e-mail]
Subject: Re: New test TSA available
Cc: [e-mail], [e-mail]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>

tho <[e-mail]> writes:

>draft (rfc) states that "The eContent SHALL be the DER-encoded value of
>TSTInfo" instead it seems that you wrapped it into a further SEQUENCE so that
>the resulting token appears as
>
>[...]
>
>is there any particular reason for this double wrapping ?

Yes, PKCS #7 and AuthentiCode.  What happened was that RFC 2630 slightly
changed the definition for eContent, in PKCS #7 this was:

        content [0] EXPLICIT ANY DEFINED BY contentType OPTIONAL

but now it's:

        eContent [0] EXPLICIT OCTET STRING OPTIONAL

however there are some implementations which still use the PKCS #7
interpretation (specifically, AuthentiCode, which AFAIK is the only widely-
deployed implementation which signs something other than data (= OCTET STRING)
content).  This uses the ANY DEFINED BY interpretation where ANY is a SEQUENCE
{ ... }, so you get:

        content [0] EXPLICIT SEQUENCE [...]

rather than an OCTET STRING.  My code has a horrible kludge in there to check
the contentType and vary the encoding depending on whether it's an
spcIndirectDataContext or not, so it will produce this encoding as well under
the right circumstances (and in fact in the TSTInfo you saw it had this turned
on for any eContent type, which was wrong, I'll rebuild the test program with
the option disabled in a minute.  With any luck I'll have broken the
AuthentiCode handling now :-).

(I've suggested to the RFC 2630 author that it might be worth including a
cautionary note about this in the RFC update).

Peter.



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f7TARiA19727 for ietf-pkix-bks; Wed, 29 Aug 2001 03:27:44 -0700 (PDT)
Received: from firewall.andxor.it (firewall.andxor.it [195.223.2.2]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f7TARfD19716 for <[e-mail]>; Wed, 29 Aug 2001 03:27:42 -0700 (PDT)
Received: from tho.andxor.com (tho.andxor.it [195.223.2.222]) by firewall.andxor.it (8.9.2/8.9.2) with ESMTP id MAA44096; Wed, 29 Aug 2001 12:27:40 +0200 (CEST) (envelope-from [e-mail])
Received: (from tho@localhost) by tho.andxor.com (8.9.3/8.9.3) id MAA46698; Wed, 29 Aug 2001 12:27:47 +0200 (CEST) (envelope-from tho)
Date: Wed, 29 Aug 2001 12:27:46 +0200
From: tho <[e-mail]>
To: Peter Gutmann <[e-mail]>
Cc: [e-mail], [e-mail]
Subject: Re: New test TSA available
Message-ID: <[e-mail]>
References: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2i
In-Reply-To: <[e-mail]>; from [e-mail] on Tue, Aug 28, 2001 at 02:54:20AM +1200
X-Operating-System: FreeBSD
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>

hi peter, 

i've tried a tsreq against the updated tsa.cryptoapps.com and i had a problem 
with eContent while decoding the response:

draft (rfc) states that "The eContent SHALL be the DER-encoded value of 
TSTInfo" instead it seems that you wrapped it into a further SEQUENCE so that 
the resulting token appears as


    ...
    {                            (EncapsulatedContentInfo)
      1.2.840.113549.1.9.16.1.4, (id-ct-TSTInfo)
      ANY [length = 94]          (SEQUENCE { DER encoded TSTInfo })
        30:5C:30:5A:02:01:01:06:0A:2B:06:01:04:01:97:55:
        38:24:36:30:1F:30:07:06:05:2B:0E:03:02:1A:04:14:
        31:32:33:34:35:36:37:38:39:30:61:62:63:64:65:66:
        67:68:69:6C:02:11:00:BD:F4:4F:D9:70:D7:27:D3:14:
        96:C2:CB:7F:86:73:96:18:0F:32:30:30:31:30:38:32:
        39:30:32:31:32:35:36:5A:02:04:00:9A:21:12
    },
    ...

rather than

    ...
    {                            (EncapsulatedContentInfo)
      1.2.840.113549.1.9.16.1.4, (id-ct-TSTInfo)
      ANY [length = 94]          (DER encoded TSTInfo)
        30:5A:02:01:01:06:0A:2B:06:01:04:01:97:55:38:24:
        36:30:1F:30:07:06:05:2B:0E:03:02:1A:04:14:31:32:
        33:34:35:36:37:38:39:30:61:62:63:64:65:66:67:68:
        69:6C:02:11:00:BD:F4:4F:D9:70:D7:27:D3:14:96:C2:
        CB:7F:86:73:96:18:0F:32:30:30:31:30:38:32:39:30:
        32:31:32:35:36:5A:02:04:00:9A:21:12
    },
    ... 

is there any particular reason for this double wrapping ?

bye, tho
-- 


Received: by above.proper.com (8.11.6/8.11.3) id f7T70fB29355 for ietf-pkix-bks; Wed, 29 Aug 2001 00:00:41 -0700 (PDT)
Received: from web13703.mail.yahoo.com (web13703.mail.yahoo.com [216.136.175.136]) by above.proper.com (8.11.6/8.11.3) with SMTP id f7T70eD29351 for <[e-mail]>; Wed, 29 Aug 2001 00:00:40 -0700 (PDT)
Message-ID: <[e-mail]>
Received: from [61.139.82.202] by web13703.mail.yahoo.com via HTTP; Wed, 29 Aug 2001 15:00:40 CST
Date: Wed, 29 Aug 2001 15:00:40 +0800 (CST)
From: =?gb2312?q?li=20yunfeng?= <[e-mail]>
To: [e-mail]
Cc: [e-mail]
In-Reply-To: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=gb2312
Content-Transfer-Encoding: 8bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>

Dear peter:
When I program the PKIX protocal, I found I have to
process the PBMParamenter struct in which there are a
member "mac AlgorithmIdentifier".Rfc2510 said that one
have to give the DES-MAC or TRIPLE-DES-MAC's oid in
the "mac" field. But I could not found the
TRIPLE-DES-MAC's OID in your docunment dunmoid.* so I
want to know what OID should I give to the "mac"
field.



_________________________________________________________
Do You Yahoo!? µÇ¼Ãâ·ÑÑÅ»¢µçÓÊ! http://mail.yahoo.com.cn

<font color=#6666FF>ÎÞÁÄ£¿ÓôÃÆ£¿¸ßÐË£¿Ã»ÀíÓÉ£¿¶¼À´ÁÄÌì°É£¡</font>¡ª¡ª 
ÑÅ»¢È«ÐÂÁÄÌìÊÒ! http://cn.chat.yahoo.com/c/roomlist.html


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f7T5rJn17152 for ietf-pkix-bks; Tue, 28 Aug 2001 22:53:19 -0700 (PDT)
Received: from phnxpop2.phnx.uswest.net (phnxpop2.phnx.uswest.net [206.80.192.2]) by above.proper.com (8.11.6/8.11.3) with SMTP id f7T5rGD17145 for <[e-mail]>; Tue, 28 Aug 2001 22:53:16 -0700 (PDT)
Received: (qmail 54989 invoked by uid 0); 29 Aug 2001 05:53:15 -0000
Received: from udialup141.phnx.uswest.net (HELO ?192.168.0.3?) (209.181.104.141) by phnxpop2.phnx.uswest.net with SMTP; 29 Aug 2001 05:53:15 -0000
Date: Tue, 28 Aug 2001 22:51:08 -0700
Message-Id: <a05100300b7b22cea015c@[192.168.0.3]>
From: "Hoyt L. Kesterson II" <[e-mail]>
To: "X.509": ;
Mime-Version: 1.0
X-Sender: [e-mail] (Unverified)
Subject: DTC-3 circulated for ballot
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>

Draft Technical Corrigendum 3 for the 4th edition of X.509 (2000) has 
been circulated for ballot. The ballot comment period will close 27 
November 2001.The DTC is available in pdf and doc formats at

ftp://ftp.bull.com/pub/OSIdirectory/DefectResolution/DraftTechnicalCorrigenda/closing27Nov2001/6N12016X.509DTC-3%284th%29.pdf 
and

ftp://ftp.bull.com/pub/OSIdirectory/DefectResolution/DraftTechnicalCorrigenda/closing27Nov2001/6N12016X.509DTC-3%284th%29.doc

Comments and questions should be sent to Sharon Boeyen 
([e-mail]) and myself

    hoyt


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f7SFVA826894 for ietf-pkix-bks; Tue, 28 Aug 2001 08:31:10 -0700 (PDT)
Received: from sottmxs02.entrust.com (gatekeeper.entrust.com [204.101.128.170]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f7SFV8D26890 for <[e-mail]>; Tue, 28 Aug 2001 08:31:08 -0700 (PDT)
Received: by sottmxs02.entrust.com with Internet Mail Service (5.5.2650.21) id <NL0CJC1T>; Tue, 28 Aug 2001 11:31:02 -0400
Message-ID: <[e-mail]>
From: Carlisle Adams <[e-mail]>
To: "'[e-mail]'" <[e-mail]>
Cc: [e-mail]
Subject: RE: New test TSA available
Date: Tue, 28 Aug 2001 11:30:59 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C12FD6.706AF890"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C12FD6.706AF890
Content-Type: text/plain

Hi Peter,

> ----------
> From: 	[e-mail][SMTP:[e-mail]]
> Sent: 	Tuesday, August 28, 2001 12:06 AM
> To: 	[e-mail]; [e-mail]
> Cc: 	[e-mail]
> Subject: 	RE: New test TSA available
> 
> 
> Carlisle Adams <[e-mail]> writes:
> 
> >Might I suggest that you some day write your own Internet Draft and
> >successfully guide it to standards-track RFC status, carefully
> negotiating
> >your way through scores of requests for additional functionality and
> never-
> >ending clarification (over a period of several years) without
> compromising
> >your original desire for brevity and simplicity in any way?
> 
> I've already done that, thanks for asking.  There was one change I had to
> make
> in one of them which as far as I can see was purely for cargo cult
> purposes
> which I wasn't terribly happy with (it violated the "Never include a
> statement
> if its negation is obviously false" rule), but mostly they turned out the
> way I
> wanted them (that is, I didn't feel the need to credit them to Alan
> Smithee
> after they were complete :-).
 
Apologies if I jumped to the wrong conclusion.  I did search the RFC index
for your name (all fields (including author), for all RFC types (including
standards-track)) prior to making my suggestion above.  I got the "zero
matches; sorry, please try again" message.

The search engine must have been broken in some way.  Which IETF
standards-track RFCs did you write?

Carlisle.


------_=_NextPart_001_01C12FD6.706AF890
Content-Type: text/html
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3DUS-ASCII">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2652.35">
<TITLE>RE: New test TSA available</TITLE>
</HEAD>
<BODY>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New Roman">Hi =
Peter,</FONT>
</P>
<UL>
<P><FONT SIZE=3D2 FACE=3D"MS Sans Serif">----------</FONT>
<BR><B><FONT SIZE=3D2 FACE=3D"MS Sans Serif">From:</FONT></B> &nbsp; =
<FONT SIZE=3D2 FACE=3D"MS Sans =
Serif">[e-mail][SMTP:[e-mail]]</FONT>
<BR><B><FONT SIZE=3D2 FACE=3D"MS Sans Serif">Sent:</FONT></B> &nbsp; =
<FONT SIZE=3D2 FACE=3D"MS Sans Serif">Tuesday, August 28, 2001 12:06 =
AM</FONT>
<BR><B><FONT SIZE=3D2 FACE=3D"MS Sans Serif">To:</FONT></B> =
&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2 FACE=3D"MS Sans =
Serif">[e-mail]; [e-mail]</FONT>
<BR><B><FONT SIZE=3D2 FACE=3D"MS Sans Serif">Cc:</FONT></B> =
&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2 FACE=3D"MS Sans =
Serif">[e-mail]</FONT>
<BR><B><FONT SIZE=3D2 FACE=3D"MS Sans Serif">Subject:</FONT></B> =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2 FACE=3D"MS Sans =
Serif">RE: New test TSA available</FONT>
</P>
<BR>

<P><FONT SIZE=3D2 FACE=3D"Arial">Carlisle Adams =
&lt;[e-mail]&gt; writes:</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">&gt;Might I suggest that you some day =
write your own Internet Draft and</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt;successfully guide it to =
standards-track RFC status, carefully negotiating</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt;your way through scores of =
requests for additional functionality and never-</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt;ending clarification (over a =
period of several years) without compromising</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt;your original desire for brevity =
and simplicity in any way?</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">I've already done that, thanks for =
asking.&nbsp; There was one change I had to make</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">in one of them which as far as I can =
see was purely for cargo cult purposes</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">which I wasn't terribly happy with =
(it violated the &quot;Never include a statement</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">if its negation is obviously =
false&quot; rule), but mostly they turned out the way I</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">wanted them (that is, I didn't feel =
the need to credit them to Alan Smithee</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">after they were complete :-).</FONT>
</UL>
<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New =
Roman">&nbsp;</FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New Roman">Apologies =
if I jumped to the wrong conclusion.&nbsp; I did search the RFC index =
for your name (all fields (including author), for all RFC types =
(including standards-track)) prior to making my suggestion above.&nbsp; =
I got the &quot;zero matches; sorry, please try again&quot; =
message.</FONT></P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New Roman">The search =
engine must have been broken in some way.&nbsp; Which IETF =
standards-track RFCs did you write?</FONT>
</P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New =
Roman">Carlisle.</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C12FD6.706AF890--


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f7SEhHW24591 for ietf-pkix-bks; Tue, 28 Aug 2001 07:43:17 -0700 (PDT)
Received: from emerald.lightlink.com (emerald.lightlink.com [205.232.34.14]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f7SEhDD24573 for <[e-mail]>; Tue, 28 Aug 2001 07:43:14 -0700 (PDT)
Received: from [209.216.70.29] (perm70-29.ij.net [209.216.70.29] (may be forged)) by emerald.lightlink.com (8.8.8/8.8.8) with SMTP id KAA10281 for <[e-mail]>; Tue, 28 Aug 2001 10:43:02 -0400
From: "Christopher S. Francis" <[e-mail]>
To: "Ietf-Pkix" <[e-mail]>
Received: from no.name.available by [209.216.70.29] via smtpd (for smtp.lightlink.com [205.232.34.14]) with SMTP; 28 Aug 2001 14:44:02 UT
Subject: Use of attribute certificates in SignedData
Date: Tue, 28 Aug 2001 10:43:02 -0400
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0026_01C12FAE.364808B0"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
Importance: Normal
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>

This is a multi-part message in MIME format.

------=_NextPart_000_0026_01C12FAE.364808B0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

I have a question for the group concerning attribute certificates.=20
=20
Is there an accepted location to put an attribute certificate associated =
with the signer in the SignedData data structure?  I have a SignedData =
object and I=92m considering putting an attribute certificate associated =
with the signer in the =91certificates=92 field of SignedData in =
addition to the PKC of the signer. =20
=20
Is that a =93philosophically correct=94 location?  I have some concern =
about standard decoders being able to successfully decode the SignedData =
structure if includes an attribute certificate.  Other options include =
burying the certificate in the encapsulated content or including it as a =
Signed or UnSigned attribute.
=20
I=92d appreciate any advice and or lessons learned that you can offer.  =
Thanks in advance. =20
=20
Chris Francis
=20

------=_NextPart_000_0026_01C12FAE.364808B0
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<html xmlns:o=3D"urn:schemas-microsoft-com:office:office" =
xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns=3D"http://www.w3.org/TR/REC-html40">

<head>
<meta http-equiv=3DContent-Type content=3D"text/html; =
charset=3Diso-8859-1">
<meta name=3DProgId content=3DWord.Document>
<meta name=3DGenerator content=3D"Microsoft Word 9">
<meta name=3DOriginator content=3D"Microsoft Word 9">
<link rel=3DFile-List href=3D"cid:filelist.xml@01C12FAE.0FE97E60">
<!--[if gte mso 9]><xml>
 <o:OfficeDocumentSettings>
  <o:DoNotRelyOnCSS/>
 </o:OfficeDocumentSettings>
</xml><![endif]--><!--[if gte mso 9]><xml>
 <w:WordDocument>
  <w:View>Normal</w:View>
  <w:Zoom>0</w:Zoom>
  <w:DocumentKind>DocumentEmail</w:DocumentKind>
  <w:EnvelopeVis/>
 </w:WordDocument>
</xml><![endif]-->
<style>
<!--
 /* Font Definitions */
@font-face
	{font-family:"Comic Sans MS";
	panose-1:3 15 7 2 3 3 2 2 2 4;
	mso-font-charset:0;
	mso-generic-font-family:script;
	mso-font-pitch:variable;
	mso-font-signature:647 0 0 0 159 0;}
 /* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
	{mso-style-parent:"";
	margin:0in;
	margin-bottom:.0001pt;
	mso-pagination:widow-orphan;
	font-size:12.0pt;
	font-family:"Times New Roman";
	mso-fareast-font-family:"Times New Roman";}
h1
	{mso-style-next:Normal;
	margin-top:12.0pt;
	margin-right:0in;
	margin-bottom:3.0pt;
	margin-left:0in;
	mso-pagination:widow-orphan;
	page-break-after:avoid;
	mso-outline-level:1;
	font-size:16.0pt;
	font-family:Arial;
	mso-font-kerning:16.0pt;}
p.MsoBodyText, li.MsoBodyText, div.MsoBodyText
	{margin-top:13.2pt;
	margin-right:0in;
	margin-bottom:0in;
	margin-left:1.0in;
	margin-bottom:.0001pt;
	line-height:120%;
	mso-pagination:widow-orphan;
	font-size:11.0pt;
	mso-bidi-font-size:10.0pt;
	font-family:"Times New Roman";
	mso-fareast-font-family:"Times New Roman";
	mso-font-kerning:11.0pt;}
a:link, span.MsoHyperlink
	{color:blue;
	text-decoration:underline;
	text-underline:single;}
a:visited, span.MsoHyperlinkFollowed
	{color:purple;
	text-decoration:underline;
	text-underline:single;}
p.MsoAutoSig, li.MsoAutoSig, div.MsoAutoSig
	{margin:0in;
	margin-bottom:.0001pt;
	mso-pagination:widow-orphan;
	font-size:12.0pt;
	font-family:"Times New Roman";
	mso-fareast-font-family:"Times New Roman";}
span.EmailStyle15
	{mso-style-type:personal-compose;
	mso-ansi-font-size:12.0pt;
	mso-ascii-font-family:"Comic Sans MS";
	mso-hansi-font-family:"Comic Sans MS";
	mso-bidi-font-family:Arial;
	color:black;}
p.Heading1NoTOC, li.Heading1NoTOC, div.Heading1NoTOC
	{mso-style-name:"Heading 1 No TOC";
	mso-style-parent:"Heading 1";
	margin-top:12.0pt;
	margin-right:0in;
	margin-bottom:3.0pt;
	margin-left:0in;
	text-align:center;
	mso-pagination:widow-orphan;
	page-break-after:avoid;
	mso-outline-level:1;
	font-size:14.0pt;
	mso-bidi-font-size:10.0pt;
	font-family:Arial;
	mso-fareast-font-family:"Times New Roman";
	mso-bidi-font-family:"Times New Roman";
	mso-font-kerning:14.0pt;
	font-weight:bold;
	mso-bidi-font-weight:normal;}
p.TableText, li.TableText, div.TableText
	{mso-style-name:"Table Text";
	margin-top:3.0pt;
	margin-right:0in;
	margin-bottom:3.0pt;
	margin-left:0in;
	line-height:110%;
	mso-pagination:widow-orphan lines-together;
	font-size:10.0pt;
	font-family:"Times New Roman";
	mso-fareast-font-family:"Times New Roman";
	mso-font-kerning:10.0pt;}
span.EmailStyle21
	{mso-style-type:personal;
	mso-ansi-font-size:12.0pt;
	mso-ascii-font-family:"Comic Sans MS";
	mso-hansi-font-family:"Comic Sans MS";
	mso-bidi-font-family:Arial;
	color:black;}
span.EmailStyle22
	{mso-style-type:personal;
	mso-ansi-font-size:12.0pt;
	mso-ascii-font-family:"Comic Sans MS";
	mso-hansi-font-family:"Comic Sans MS";
	mso-bidi-font-family:Arial;
	color:black;}
@page Section1
	{size:8.5in 11.0in;
	margin:1.0in 1.25in 1.0in 1.25in;
	mso-header-margin:.5in;
	mso-footer-margin:.5in;
	mso-paper-source:0;}
div.Section1
	{page:Section1;}
-->
</style>
</head>

<body lang=3DEN-US link=3Dblue vlink=3Dpurple =
style=3D'tab-interval:.5in'>

<div class=3DSection1>

<p class=3DMsoNormal><span class=3DEmailStyle21><font size=3D3 =
color=3Dblack
face=3D"Comic Sans MS"><span =
style=3D'font-size:12.0pt;font-family:"Comic Sans MS"'>I
have a question for the group concerning attribute certificates. =
<o:p></o:p></span></font></span></p>

<p class=3DMsoNormal><span class=3DEmailStyle21><font size=3D3 =
color=3Dblack
face=3D"Comic Sans MS"><span =
style=3D'font-size:12.0pt;font-family:"Comic Sans =
MS"'>&nbsp;<o:p></o:p></span></font></span></p>

<p class=3DMsoNormal><span class=3DEmailStyle22><font size=3D3 =
color=3Dblack
face=3D"Comic Sans MS"><span =
style=3D'font-size:12.0pt;font-family:"Comic Sans MS"'>Is
there an accepted location to put an attribute certificate associated =
with the
signer in the SignedData data structure?<span style=3D"mso-spacerun: =
yes">&nbsp;
</span>I have a SignedData object and I&#8217;m considering putting an =
attribute
certificate associated with the signer in the &#8216;certificates&#8217; =
field of
SignedData in addition to the PKC of the signer.<span =
style=3D"mso-spacerun:
yes">&nbsp; </span><o:p></o:p></span></font></span></p>

<p class=3DMsoNormal><span class=3DEmailStyle22><font size=3D3 =
color=3Dblack
face=3D"Comic Sans MS"><span =
style=3D'font-size:12.0pt;font-family:"Comic Sans =
MS"'>&nbsp;<o:p></o:p></span></font></span></p>

<p class=3DMsoNormal><span class=3DEmailStyle22><font size=3D3 =
color=3Dblack
face=3D"Comic Sans MS"><span =
style=3D'font-size:12.0pt;font-family:"Comic Sans MS"'>Is
that a &#8220;philosophically correct&#8221; location?<span =
style=3D"mso-spacerun:
yes">&nbsp; </span>I have some concern about standard decoders being =
able to
successfully decode the SignedData structure if includes an attribute
certificate.<span style=3D"mso-spacerun: yes">&nbsp; </span>Other =
options include
burying the certificate in the encapsulated content or including it as a =
Signed
or UnSigned attribute.<o:p></o:p></span></font></span></p>

<p class=3DMsoNormal><span class=3DEmailStyle22><font size=3D3 =
color=3Dblack
face=3D"Comic Sans MS"><span =
style=3D'font-size:12.0pt;font-family:"Comic Sans =
MS"'>&nbsp;<o:p></o:p></span></font></span></p>

<p class=3DMsoNormal><span class=3DEmailStyle22><font size=3D3 =
color=3Dblack
face=3D"Comic Sans MS"><span =
style=3D'font-size:12.0pt;font-family:"Comic Sans MS"'>I&#8217;d
appreciate any advice and or lessons learned that you can offer.<span
style=3D"mso-spacerun: yes">&nbsp; </span>Thanks in advance.<span
style=3D"mso-spacerun: yes">&nbsp; </span></span></font></span><span
class=3DEmailStyle21><font color=3Dblack face=3D"Comic Sans MS"><span
style=3D'font-family:"Comic Sans =
MS"'><o:p></o:p></span></font></span></p>

<p class=3DMsoNormal><span class=3DEmailStyle21><font size=3D3 =
color=3Dblack
face=3D"Comic Sans MS"><span =
style=3D'font-size:12.0pt;font-family:"Comic Sans =
MS"'>&nbsp;<o:p></o:p></span></font></span></p>

<p class=3DMsoNormal><span class=3DEmailStyle21><font size=3D3 =
color=3Dblack
face=3D"Comic Sans MS"><span =
style=3D'font-size:12.0pt;font-family:"Comic Sans MS"'>Chris
Francis<o:p></o:p></span></font></span></p>

<p class=3DMsoNormal><font size=3D3 color=3Dblack face=3D"Times New =
Roman"><span
style=3D'font-size:12.0pt;color:black'><![if =
!supportEmptyParas]>&nbsp;<![endif]></span></font><font
color=3Dblack><span =
style=3D'color:black;mso-color-alt:windowtext'><o:p></o:p></span></font><=
/p>

</div>

</body>

</html>

------=_NextPart_000_0026_01C12FAE.364808B0--



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f7S6raU12883 for ietf-pkix-bks; Mon, 27 Aug 2001 23:53:36 -0700 (PDT)
Received: from p-mail2.cnet.fr (p-mail2.rd.francetelecom.com [193.49.124.32]) by above.proper.com (8.11.6/8.11.3) with SMTP id f7S6rXD12872 for <[e-mail]>; Mon, 27 Aug 2001 23:53:34 -0700 (PDT)
Received: by p-voyageur.rd.francetelecom.fr with Internet Mail Service (5.5.2653.19) id <RQ85SWYB>; Tue, 28 Aug 2001 08:36:02 +0200
Received: from francetelecom.com (161.104.58.152 [161.104.58.152]) by l-mhs1.rd.francetelecom.fr with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id RJ40W6Z0; Tue, 28 Aug 2001 08:35:12 +0200
Message-ID: <[e-mail]>
Date: Sun, 26 Aug 2001 08:55:42 +0000
From: Olivier Dubuisson <[e-mail]>
Organization: France Telecom R&D
X-Mailer: Mozilla 4.75 [en] (Win95; U)
X-Accept-Language: en,fr-FR
MIME-Version: 1.0
To: =?iso-8859-1?Q?=B1=E8=20=C3=E6=B1=E6?= <[e-mail]>
CC: [e-mail]
Subject: Re: Question about ECDSA.
References: <[e-mail]>
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>

±è Ãæ±æ wrote:
> 
> I can't found ECDSA PriveKey OID.
> There is no information about it in X9.62 and your draft-ietf-pkix-ipki-
> pkalgs-03.txt.
> 
> I want to know ECDSA PrivateKey ASN.1 syntax, OID and
> PrivateKeyAlgorithms OID.
> where can I that information?

I take this opportunity to keep you informed that an OID repository is
available on the ASN.1 website at http://asn1.elibel.tm.fr/oid/
Use the search engine of the website to check if some information
available concerning ECDSA.

We are in a process to redesign it and also to merge the data with those
of Harald Alvestrand's repository <http://www.alvestrand.no/objectid>.
In the October 2001 timeframe a lot more information should be available
regarding OIDs.
-- 
Olivier DUBUISSON
france telecom R&D
     _                 DTL/MSV - 22307 Lannion Cedex - France
    ( )           tel: [phone] - fax: [phone]
    / \/               --------------------------------------
    \_/\               Site ASN.1 : http://asn1.elibel.tm.fr/



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f7S46Lc29423 for ietf-pkix-bks; Mon, 27 Aug 2001 21:06:21 -0700 (PDT)
Received: from kakapo.cs.auckland.ac.nz (kakapo.cs.auckland.ac.nz [130.216.34.10]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f7S46JD29419 for <[e-mail]>; Mon, 27 Aug 2001 21:06:19 -0700 (PDT)
Received: from ruru.cs.auckland.ac.nz (firebird.cs.auckland.ac.nz [130.216.34.12]) by kakapo.cs.auckland.ac.nz (8.8.6/8.8.6/cs-master) with ESMTP id QAA09921; Tue, 28 Aug 2001 16:06:16 +1200 (NZST) (sender [e-mail])
Received: (from pgut001@localhost) by ruru.cs.auckland.ac.nz (8.9.3/8.8.6/cs-slave) id QAA438415; Tue, 28 Aug 2001 16:06:16 +1200 (NZST) (sender [e-mail])
Date: Tue, 28 Aug 2001 16:06:16 +1200 (NZST)
Message-ID: <[e-mail]>
From: [e-mail] (Peter Gutmann)
To: [e-mail], [e-mail]
Subject: RE: New test TSA available
Cc: [e-mail]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>

Carlisle Adams <[e-mail]> writes:

>I'm sure we all appreciated your edifying rant.

Thanks, it was good for me too :-).

>Might I suggest that you some day write your own Internet Draft and
>successfully guide it to standards-track RFC status, carefully negotiating
>your way through scores of requests for additional functionality and never-
>ending clarification (over a period of several years) without compromising
>your original desire for brevity and simplicity in any way?

I've already done that, thanks for asking.  There was one change I had to make
in one of them which as far as I can see was purely for cargo cult purposes
which I wasn't terribly happy with (it violated the "Never include a statement
if its negation is obviously false" rule), but mostly they turned out the way I
wanted them (that is, I didn't feel the need to credit them to Alan Smithee
after they were complete :-).

Peter.



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f7S2gCa17566 for ietf-pkix-bks; Mon, 27 Aug 2001 19:42:12 -0700 (PDT)
Received: from mx01.melco.co.jp (mx01.melco.co.jp [192.218.140.41]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f7S2g7D17546 for <[e-mail]>; Mon, 27 Aug 2001 19:42:07 -0700 (PDT)
Received: by mx01.melco.co.jp (mx01) id LAA21672; Tue, 28 Aug 2001 11:42:01 +0900 (JST)
Received: by mr03.melco.co.jp (mr03) id LAA01852; Tue, 28 Aug 2001 11:41:54 +0900 (JST)
Received: from elmail by elgw.isl.melco.co.jp (8.8.8/3.6W) id LAA09974; Tue, 28 Aug 2001 11:41:53 +0900 (JST)
Received: from iss.isl.melco.co.jp (iss.isl.melco.co.jp [10.74.5.60]) by elmail.isl.melco.co.jp (iPlanet Messaging Server 5.0 Patch 3 (built Mar 23 2001)) with ESMTP id <[e-mail]>; Tue, 28 Aug 2001 11:41:52 +0900 (JST)
Received: from belize by iss.isl.melco.co.jp (8.8.8/3.6W) id LAA09212; Tue, 28 Aug 2001 11:41:53 +0900 (JST)
Date: Tue, 28 Aug 2001 11:48:07 +0900
From: Hiroyuki Sakakibara <[e-mail]>
Subject: Re: Path validation and self-signed certificates
To: "David A. Cooper" <[e-mail]>, [e-mail]
Message-id: <002101c12f6b$de7796b0$[e-mail]>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
Content-type: text/plain; charset=iso-8859-1
Content-transfer-encoding: 7BIT
X-Priority: 3
X-MSMail-priority: Normal
References: <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>

David

Thank you for four comments.

In (2) and (4), as you mentioned, following the latest X.509 standard,
if a validation system tries to check extensions in self-signed
certificates,
certificatePolicies, nameConstraints etc,
the result of validation will not be identical to the result of validation
ignoring self-signed certificates and will be an interoperability problem.

I think that IF a validation system checks self-signed certs,
the software shall check validity and revocation only,
because these are additional checks to enhance security of validation.

But the current X.509 does not allow these processing unfortunatelly.

David Cooper ----->
Hiroyuki Sakakibara presented an example in which processing self-signed
certificates helped to prevent a security breach.  In his example, A issues
a cross-certificate to B and B's private key is compromised. Hiroyuki
pointed out that by processing B's self-signed certificate (to see if it
has expired or has been revoked) one may have a chance to detect the
compromise even if A does not cooperate by revoking the certificate that
it issued to B.  However, as he pointed out, this is not foolproof. The
entity that
compromised B's key could issue a new self-signed certificate with a later
notAfter date along with CRLs that make it appear as if B's certificates
are still good. If on the other hand, B were able to get its own CRLs to
relying parties, it could just revoke all of its certificates instead of
just its
self-signed certificate, thus ensuring that any relying party that receives
its CRLs will know that its certificates can not be trusted, whether they
process B's self-signed certificates or not.
<-----David Cooper

OK, I see.
as your example ( also in (3) ), in the case of revocation of B,
B can announce its revocation by issuing a CRL that containts all certs
that B issued(including its self-signed),
even though A does not issue a CRL which revokes a cert from A to B.

In the case of  revocation of Bridge CA, a CRL issued by Bridge CA
would be large depending on the number of CAs it cross certifies with.
Killing Bridgne CA itself only in the CRL, size of it will be quite small.

David Cooper ----->
In general though, if a certification path of the form ... --> A --> B -->
... is being processed, I don't think there is much that B can do to
protect relying parties from A's improper behavior. If A issues certificates
to B
with notAfter dates that are later than they should be or if A refuses to
revoke B's certificate when requested to do so, there is little that B can
do to protect A's relying parties (or the relying parties of any CA that
preceded A in the path) from A, particularly in the case when B's private
key has been compromised.
<----- David Cooper

I agree with you.

I still suppose that checking self-signed certs validity  (notBefore/After)
or revocation would be some help to detect improper behavior of A
in some cases.
And considering Peter's comments, some implementation would validate
self-signed certs though it would be rare.

Peter Hesse ----->
- Not all certificate validation systems allow any self-signed
certificates to appear as intermediate certificates in paths.
This is primarily for two reasons: 1) Preventing same subject name and
public key from appearing twice in a path prevents loops, and
2) some argue that the same public key appearing twice in the path dilutes
the trust chain.
<-----Peter Hesse

While I think that validating self-signed certs in a path would be
meaningful,
it would not possible for a RP to find self-signed certs always.
Because, when the RP does not find a self-signed cert for a CA,
the RP could not automatically judge that "a self-signed cert for this CA is
not present in LDAP by accident"
or
"originally it does not exist( was not issued)",
on the other hand, the RP can construct a path without self-signed certs.

Is there any idea that a RP detects CA's improper behavior ... ?

------------------------------------------------------------------------

[my personal opinion]

I would like to summurize my personal opinion considering replies from
Peter and David.

* the latest X.509 inhibits validation of self-signed certs in a path.
   On the other hand, some implementation already would have adopted
   cheking self-signed certs, and in some cases it would be meaningful,
   therefore it is not good that self-signed certs are entirely ignored.
   "may be ignored" is better, I think.

* PKIX shall follow X.509. For interoperability,
   as most of implements would have applyied,
   if self-signed certs appear in the middle of a path,
   they shall be ignored, WHEN VALIDATION, not construction.
    Namely, this processing is the subset of  the above bullet
    ( self-signed certs "may" be  ignored in the above bullet)

------------------------------------------------------------------------

I thank for Peter Hesse and David A. Cooper 's many comments.
While I still suppose that it is meaningful to check self-signed
certificates in some cases,
I suppose that cheking self-signed certificates does not protect a CA's
improper behaivior always and perfectly and
a path will be longer and complicated than one without self-signed certs.

Anyway, I think it is better that son of 2459 describes some recommendations
about including / not including self-signed certs in a path.
In this case, the latest X.509 ignores self-signed certs when
validation( not construction), hence, son of 2459 reccomends that
coresspondingly.

[Question]

I have a related question about path construction and validation.
Based on the current X.509, a path may containts self-signed certs,
however, they shall be ignored when validation.

For example,

B issues its EndEntity a certificate whose AKI explicitly indicates
B's self-signed with authorityCertIssuer/SerialNumber.
Relying Parties in B's PKI system use B's self-signed as the trust anchor's
cert.

Later, A and B agree with cross-certification between them,
then, A issues a cross certificate to B.

hence, a path in the cross certification may be constructed as

(1) A->B,  B(self-signed),  B->EE
or
(2) A->B,  B->EE

(1) refferencing AKI of  B->EE which explicitly indicates B(self-sign)
with authorityCertIssuer/SerialNumber

(2) ignoring AKI of  B->EE or refferencing keyId in AKI only if exists.

According to the latest X.509, even thogh a path is constructed as (1),
B(self-signed) shall be ignored when validation.

Is my interpretation correct ?
or self-signed certs shall be ignored when path construction ?
( if they are ignored when path construction, it will be more efficient.)

Hiroyuki Sakakibara

---------------------------------------
Hiroyuki Sakakibara
MITSUBISHI ELECTRIC CORPORATION
Information Technology R&D Center
5-1-1 Ofuna, Kamakura, Kanagawa, Japan
PHONE: [phone]
FAX:   [phone]
E-mail : [e-mail]

----- Original Message -----
From: "David A. Cooper" <[e-mail]>
To: <[e-mail]>
Sent: Sunday, August 26, 2001 6:33 AM
Subject: RE: Path validation and self-signed certificates


>
> All,
>
> I believe that PKIX should either discourage or forbid the inclusion of
self-signed certificates in certification paths for the following reasons:
>
> 1) Section 8.1.5 of the 4th edition of X.509 states that
>
>          There are three circumstances under which a certification
authority may
>          issue a certificate to itself:
>
>          a) as a convenient way of encoding its public key for
communication to,
>               and storage by, its certificate users;
>
>          b) ...
>
>          For purposes of path validation, self-issued certificates of type
a) are verified
>          with the public key contained in them, and if they are
encountered in the path,
>          they shall be ignored.
>
> So, X.509 states that self-signed certificate are only to be used as a
convenient way of encoding a public key, and that self-signed certificates,
if they are encountered in a certification path are to be ignored. Thus, if
PKIX were to allow the processing of self-signed certificates, it would not
be compliant with X.509.
>
> 2) As Peter Hesse pointed out, many CAs issue self-signed certificates
with a minimum necessary information (e.g., a version 1 certificate with
just a name, public key, and validity dates).  Any such certificates
included in a certification path would result in an empty valid_policy_tree.
Old-with-new and new-with-old self-issued certificates are designed to be
used as part of certification paths and so should contain all of the
necessary extensions (e.g., basicConstraints, certificatePolicies), but
self-signed certificates may be been issued simply as a means of
distributing the public key to relying parties that will use that key as a
trust anchor. If these certificates are included in, and are processed as
parts of, certification paths, the results may be rejecting end certificates
that should be have been accepted.
>
> 3) If a CA suspects that its key has been compromised (or it otherwise
determines that none of the certificates it has issued should be considered
valid), it should request that every certificate issued to it be revoked (as
is stated in the Security Considerations section).  If possible, it should
also revoke all of the certificates it has issued (not just its self-signed
certificate). If a CA can revoke its own self-signed certificate then it can
revoke all of the certificates it has issued. Doing so will ensure that all
relying parties know about the revocation, not just those relying parties
that check to see whether the signed-signed certificate has been revoked.
>
> 4) If an organization uses client software that processes self-signed
certificates, there is risk that that organization will issue certificates
from its own CA assuming that relying parties process self-signed
certificates. This organization's CA may then issue self-signed certificates
with constraints (e.g., name constraints, path length constraints, etc.)
that they expect relying parties to see, but the CA, assuming that relying
parties will process its self-signed certificates, may not include the
constraints in any of its other certificates.
>
> So, if there is no set rule, there is the risk that relying parties that
do process self-signed certificates will lose some interoperability and
those that do not will overlook intended path processing constraints.
>
> Hiroyuki Sakakibara presented an example in which processing self-signed
certificates helped to prevent a security breach.  In his example, A issues
a cross-certificate to B and B's private key is compromised. Hiroyuki
pointed out that by processing B's self-signed certificate (to see if it has
expired or has been revoked) one may have a chance to detect the compromise
even if A does not cooperate by revoking the certificate that it issued to
B.  However, as he pointed out, this is not foolproof. The entity that
compromised B's key could issue a new self-signed certificate with a later
notAfter date along with CRLs that make it appear as if B's certificates are
still good. If on the other hand, B were able to get its own CRLs to relying
parties, it could just revoke all of its certificates instead of just its
self-signed certificate, thus ensuring that any relying party that receives
its CRLs will know that its certificates can not be trusted, whether they
process B's self-s!
> igned certificates or not.
>
> In general though, if a certification path of the form ... --> A --> B -->
... is being processed, I don't think there is much that B can do to protect
relying parties from A's improper behavior. If A issues certificates to B
with notAfter dates that are later than they should be or if A refuses to
revoke B's certificate when requested to do so, there is little that B can
do to protect A's relying parties (or the relying parties of any CA that
preceded A in the path) from A, particularly in the case when B's private
key has been compromised.  I don't think that it is worth diverging from
X.509 and introducing interoperability problems into PKIX in an attempt to
try.
>
> Dave
>
> At 04:37 PM 8/24/01 -0700, Ryan Hurst wrote:
> >Peter -
> >
> >I agree with your comments on self-signed certificates in chains with
only one exception, specifically in regards to revocation. There are several
cases where the revocation of a self-signed CA would make sense, what about
cessationOfOperation, superseded and affiliationChanged? These reasons do
not imply any sort of compromise of key material. We make many "known
assumptions" in PKI and the catch 22 of key material management and trust is
one of them, without these "known assumptions" many of the things in son-off
fall apart.
> >
> >Ryan
>
>
>





Received: by above.proper.com (8.11.6/8.11.3) id f7S2URv13604 for ietf-pkix-bks; Mon, 27 Aug 2001 19:30:27 -0700 (PDT)
Received: from kakapo.cs.auckland.ac.nz (kakapo.cs.auckland.ac.nz [130.216.34.10]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f7S2UPD13600 for <[e-mail]>; Mon, 27 Aug 2001 19:30:25 -0700 (PDT)
Received: from ruru.cs.auckland.ac.nz (firebird.cs.auckland.ac.nz [130.216.34.12]) by kakapo.cs.auckland.ac.nz (8.8.6/8.8.6/cs-master) with ESMTP id OAA06836; Tue, 28 Aug 2001 14:29:37 +1200 (NZST) (sender [e-mail])
Received: (from pgut001@localhost) by ruru.cs.auckland.ac.nz (8.9.3/8.8.6/cs-slave) id OAA436733; Tue, 28 Aug 2001 14:29:31 +1200 (NZST) (sender [e-mail])
Date: Tue, 28 Aug 2001 14:29:31 +1200 (NZST)
Message-ID: <[e-mail]>
From: [e-mail] (Peter Gutmann)
To: [e-mail], [e-mail], [e-mail]
Subject: RE: Question about ECDSA.
Cc: [e-mail]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>

"Jim Schaad" <[e-mail]> writes:

>I had to look, but it appears that RFC2511bis does not do this even though I
>might have expected it to.  There are now some private key items put into the
>CMC-Archive document but I don't currently have any EC private keys documented
>there.

Doesn't PKCS #15 do this, along with a wide variety of other private key
formats?

Peter.


Received: by above.proper.com (8.11.6/8.11.3) id f7S2NY211234 for ietf-pkix-bks; Mon, 27 Aug 2001 19:23:34 -0700 (PDT)
Received: from kakapo.cs.auckland.ac.nz (kakapo.cs.auckland.ac.nz [130.216.34.10]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f7S2NVD11196 for <[e-mail]>; Mon, 27 Aug 2001 19:23:32 -0700 (PDT)
Received: from ruru.cs.auckland.ac.nz (firebird.cs.auckland.ac.nz [130.216.34.12]) by kakapo.cs.auckland.ac.nz (8.8.6/8.8.6/cs-master) with ESMTP id OAA06662; Tue, 28 Aug 2001 14:23:25 +1200 (NZST) (sender [e-mail])
Received: (from pgut001@localhost) by ruru.cs.auckland.ac.nz (8.9.3/8.8.6/cs-slave) id OAA436198; Tue, 28 Aug 2001 14:23:21 +1200 (NZST) (sender [e-mail])
Date: Tue, 28 Aug 2001 14:23:21 +1200 (NZST)
Message-ID: <[e-mail]>
From: [e-mail] (Peter Gutmann)
To: [e-mail], [e-mail]
Subject: Re: New test TSA available
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>

Jean-Marc Desperrier <[e-mail]> writes:
>Peter Gutmann wrote:
>>The first item in "Security Considerations" (referred to above) is pretty
>>risky.  An un-compromised TSA key should be destroyed, but not explicitly
>>revoked.  If it is revoked then it's necessary to create a benign vs serious
>>revocation condition (which is what the text does) which can be exploited
>>because all I need to do after stealing the TSA key is to revoke it in a benign
>>manner and then generate all the fake timestamps I want.
>
>The TSA is signed by a CA. If I steal the TSA key, I can forge timestamp, but
>not the revocation information. I'd need to steal both keys to do that.

Not really:

 Steal the TSA key
 Use it to submit a benign revocation request to the CA
   (CA revokes cert with a reason like cessation-of-operation).
 Generate as many bogus timestamps as you like
   (The real key owner can't stop you, since the cert/key is
    already revoked).

>If I get two different revocation information for a TSA, information A saying
>it's benign revocation, and B saying it's serious revocation, I would consider
>it serious revocation.

A human probably would, but there's no guarantee a CA will (in a
straightforward implementation, a CA will reject any request to revoke a cert
which is already revoked since it's a duplicate).  Basing the correct
functioning of a TSA on what a CA might or might not do (depending on how it's
implemented) is kind of risky.

Peter.



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f7RJsIC25523 for ietf-pkix-bks; Mon, 27 Aug 2001 12:54:18 -0700 (PDT)
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f7RJsHD25519 for <[e-mail]>; Mon, 27 Aug 2001 12:54:17 -0700 (PDT)
Received: from sunlabs.East.Sun.COM ([129.148.75.250]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA00588; Mon, 27 Aug 2001 12:54:18 -0700 (PDT)
Received: from sun.com (dhcp75-167 [129.148.75.167]) by sunlabs.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA28105; Mon, 27 Aug 2001 15:54:18 -0400 (EDT)
Message-ID: <[e-mail]>
Date: Mon, 27 Aug 2001 15:53:53 -0400
From: Steve Hanna <[e-mail]>
Organization: Sun Microsystems, Inc.
X-Mailer: Mozilla 4.75 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Tom Gindin <[e-mail]>
CC: [e-mail]
Subject: Re: excludedSubtrees (was Re: draft-ietf-pkix-new-part1-08)
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>

Tom Gindin wrote:
> While your point that case sensitivity is a cause of name
> constraint mismatches is valid, why is this not an issue for RFC822
> addresses as well? Suppose an attacker lists your domain as
> "Sun.COM"?  In section 11.3.2 of the latest X.509 draft, the
> subject is finessed by having certificates match if the
> subjectAltName contains a component of the same name type as
> the one being checked.

RFC 2459 and son-of-2459 both say that rfc822 names are
case-insensitive. So if I issue a CA certificate containing an
excludedSubtree of type rfc822Name and value "sun.com" and the
subject of that certificate issues a certificate with a subject
alternative name of type rfc822Name and value "Sun.COM", a path
consisting of those two certificates is not valid.

Section 11.3.2 of X.509 (4th edition, draft 8) refers to the
certificate match rule, which is used to fetch certificates
from a directory. You can include an AltNameType to say "only
return certificates that contain a subject alternative name of
this type."

When retrieving certificates from a directory, that's probably fine.
You wouldn't want to make the directory server implement support for
matching all sorts of alternative name forms. But a validation
library that encounters an excludedSubtree of type rfc822Name
had better understand how to match names of that type and not allow
a subsequent certificate in the path to contain a name that
matches the excludedSubtree.

The paragraph that you're proposing to change (in the Security
Considerations section of son-of-2459) is concerned solely with
risks caused by inconsistent application of name comparison rules
for distinguished names. son-of-2459 doesn't allow any
inconsistencies in name comparison rules for rfc822Names, so
there's no risk there (except for buggy implementations that don't
meet the spec, which is an entirely different problem).

In my commentary on your proposed change, I was just pointing out
that it's possible to run into inconsistencies in name comparison
rules for distinguished names even if both names use the same
encoding. Two UTF8Strings with values "Tom" and "TOM" will be
considered equivalent by an implementation that supports case-
insensitive comparison of UTF8Strings and not equivalent by an
implementation that just does a binary comparison for attributes
that are not encoded with PrintableString. So changing that
paragraph to focus solely on inconsistencies caused by different
encodings is probably not a good idea.

Am I missing something here?

-Steve

Tom Gindin wrote:
> 
>      While your point that case sensitivity is a cause of name constraint
> mismatches is valid, why is this not an issue for RFC822 addresses as well?
> Suppose an attacker lists your domain as "Sun.COM"?  In section 11.3.2 of
> the latest X.509 draft, the subject is finessed by having certificates
> match if the subjectAltName contains a component of the same name type as
> the one being checked.
> 
>           Tom Gindin
> 
> Steve Hanna <[e-mail]> on 08/27/2001 09:57:30 AM
> 
> To:   Tom Gindin/Watson/IBM@IBMUS
> cc:   [e-mail]
> Subject:  Re: excludedSubtrees (was Re: draft-ietf-pkix-new-part1-08)
> 
> Tom Gindin wrote:
> > As far as I can tell, the only excludedSubtree with DirectoryName
> > which is widely usable and doesn't run into the character code
> > problems discussed earlier is one which contains a countryName and
> > no other attributes. Thus I would not change the last sentence of
> > the paragraph (it's good advice anyway)
> 
> I'm glad we agree on that.
> 
> > but would add a new sentence to it after the first sentence as
> > follows: "This is particularly hard to guarantee when one or more
> > of the attributes in the DN specification is encoded as a CHOICE,
> > such as DirectoryString." and change the beginning of the next
> > sentence to "If the encodings differ" from "If not".
> 
> For those following along at home, that would change the text to:
> 
>    In addition, name constraints for distinguished names MUST be
>    stated identically to the encoding used in the subject field or
>    subjectAltName extension. This is particularly hard to guarantee
>    when one or more of the attributes in the DN specification is
>    encoded as a CHOICE, such as DirectoryString. If the encodings
>    differ, then name constraints stated as excludedSubTrees will not
>    match and invalid paths will be accepted and name constraints
>    expressed as permittedSubtrees will not match and valid paths will
>    be rejected.  To avoid acceptance of invalid paths, CAs SHOULD
>    state name constraints for distinguished names as
>    permittedSubtrees wherever possible.
> 
> Why do you want to make this change? It seems to narrow the focus of
> this paragraph to only cases of differing encodings. But different
> encodings aren't the only cause of name constraint mismatches. Two
> UTF8Strings with values "Tom" and "TOM" won't match using the minimum
> son-of-2459 rules, which use binary comparison for UTF8String values.
> 
> -Steve


Received: by above.proper.com (8.11.6/8.11.3) id f7RJGBh24869 for ietf-pkix-bks; Mon, 27 Aug 2001 12:16:11 -0700 (PDT)
Received: from e1.ny.us.ibm.com (e1.ny.us.ibm.com [32.97.182.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f7RJG9D24865 for <[e-mail]>; Mon, 27 Aug 2001 12:16:09 -0700 (PDT)
Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.117.200.22]) by e1.ny.us.ibm.com (8.9.3/8.9.3) with ESMTP id PAA276776; Mon, 27 Aug 2001 15:13:55 -0400
Received: from d01ml062.pok.ibm.com (d01ml062.pok.ibm.com [9.117.250.163]) by northrelay02.pok.ibm.com (8.11.1m3/NCO v4.97.1) with ESMTP id f7RJ84c173644; Mon, 27 Aug 2001 15:08:04 -0400
Importance: Normal
Subject: Re: excludedSubtrees (was Re: draft-ietf-pkix-new-part1-08)
To: Steve Hanna <[e-mail]>
Cc: [e-mail]
X-Mailer: Lotus Notes Release 5.0.3 (Intl) 21 March 2000
Message-ID: <[e-mail]>
From: "Tom Gindin" <[e-mail]>
Date: Mon, 27 Aug 2001 15:16:03 -0400
X-MIMETrack: Serialize by Router on D01ML062/01/M/IBM(Release 5.0.8 SPR #MIAS4UTJ8H |June 21, 2001) at 08/27/2001 03:16:05 PM
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>

     While your point that case sensitivity is a cause of name constraint
mismatches is valid, why is this not an issue for RFC822 addresses as well?
Suppose an attacker lists your domain as "Sun.COM"?  In section 11.3.2 of
the latest X.509 draft, the subject is finessed by having certificates
match if the subjectAltName contains a component of the same name type as
the one being checked.

          Tom Gindin


Steve Hanna <[e-mail]> on 08/27/2001 09:57:30 AM

To:   Tom Gindin/Watson/IBM@IBMUS
cc:   [e-mail]
Subject:  Re: excludedSubtrees (was Re: draft-ietf-pkix-new-part1-08)


Tom Gindin wrote:
> As far as I can tell, the only excludedSubtree with DirectoryName
> which is widely usable and doesn't run into the character code
> problems discussed earlier is one which contains a countryName and
> no other attributes. Thus I would not change the last sentence of
> the paragraph (it's good advice anyway)

I'm glad we agree on that.

> but would add a new sentence to it after the first sentence as
> follows: "This is particularly hard to guarantee when one or more
> of the attributes in the DN specification is encoded as a CHOICE,
> such as DirectoryString." and change the beginning of the next
> sentence to "If the encodings differ" from "If not".

For those following along at home, that would change the text to:

   In addition, name constraints for distinguished names MUST be
   stated identically to the encoding used in the subject field or
   subjectAltName extension. This is particularly hard to guarantee
   when one or more of the attributes in the DN specification is
   encoded as a CHOICE, such as DirectoryString. If the encodings
   differ, then name constraints stated as excludedSubTrees will not
   match and invalid paths will be accepted and name constraints
   expressed as permittedSubtrees will not match and valid paths will
   be rejected.  To avoid acceptance of invalid paths, CAs SHOULD
   state name constraints for distinguished names as
   permittedSubtrees wherever possible.

Why do you want to make this change? It seems to narrow the focus of
this paragraph to only cases of differing encodings. But different
encodings aren't the only cause of name constraint mismatches. Two
UTF8Strings with values "Tom" and "TOM" won't match using the minimum
son-of-2459 rules, which use binary comparison for UTF8String values.

-Steve




Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f7RJ6cH24563 for ietf-pkix-bks; Mon, 27 Aug 2001 12:06:38 -0700 (PDT)
Received: from femail42.sdc1.sfba.home.com (femail42.sdc1.sfba.home.com [24.254.60.36]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f7RJ6bD24558 for <[e-mail]>; Mon, 27 Aug 2001 12:06:37 -0700 (PDT)
Received: from revelation ([65.4.166.11]) by femail42.sdc1.sfba.home.com (InterMail vM.4.01.03.20 201-229-121-120-20010223) with ESMTP id <20010827190632.MWMC8180.femail42.sdc1.sfba.home.com@revelation>; Mon, 27 Aug 2001 12:06:32 -0700
Reply-To: <[e-mail]>
From: "Jim Schaad" <[e-mail]>
To: "'Housley, Russ'" <[e-mail]>, <[e-mail]>
Cc: <[e-mail]>
Subject: RE: Question about ECDSA.
Date: Mon, 27 Aug 2001 12:06:49 -0700
Message-ID: <001201c12f2b$6e67f350$[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.2627
In-reply-to: <[e-mail]>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2505.0000
Importance: Normal
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>

I had to look, but it appears that RFC2511bis does not do this even
though I might have expected it to.  There are now some private key
items put into the CMC-Archive document but I don't currently have any
EC private keys documented there.

jim

> -----Original Message-----
> From: [e-mail] 
> [mailto:[e-mail]] On Behalf Of Housley, Russ
> Sent: Thursday, August 23, 2001 7:22 AM
> To: [e-mail]
> Cc: [e-mail]
> Subject: Re: Question about ECDSA.
> 
> 
> 
> The ANSI X9 and PKIX documents have never included specifications for 
> private key syntax.
> 
> Perhaps Certicom can offer a recommended syntax.
> 
> Russ
> 
> 
> 
> 
> >I can't found ECDSA PriveKey OID.
> >There is no information about it in X9.62 and your 
> draft-ietf-pkix-ipki-
> >pkalgs-03.txt.
> >
> >I want to know ECDSA PrivateKey ASN.1 syntax, OID and
> >PrivateKeyAlgorithms OID.
> >where can I that information?
> >
> >Thanks.
> 



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f7RJ4c624527 for ietf-pkix-bks; Mon, 27 Aug 2001 12:04:38 -0700 (PDT)
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f7RJ4aD24523 for <[e-mail]>; Mon, 27 Aug 2001 12:04:36 -0700 (PDT)
Received: from sunlabs.East.Sun.COM ([129.148.75.250]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA04929; Mon, 27 Aug 2001 13:04:34 -0600 (MDT)
Received: from sun.com (dhcp75-167 [129.148.75.167]) by sunlabs.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA10150; Mon, 27 Aug 2001 15:04:36 -0400 (EDT)
Message-ID: <[e-mail]>
Date: Mon, 27 Aug 2001 15:04:11 -0400
From: Steve Hanna <[e-mail]>
Organization: Sun Microsystems, Inc.
X-Mailer: Mozilla 4.75 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Peter Sylvester <[e-mail]>
CC: [e-mail], [e-mail]
Subject: Re: Path validation and self-signed certificates
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>

Peter Sylvester wrote:
> Why does PKIX need to say something that is essentially
> already in X.509? Aren't self-signed certificates of type a)
> ignored for path validation in X.509?

Most of son-of-2459 is already in X.509. The purpose of our
document is to provide a profile of X.509 suitable for the
Internet. Why mention name chaining or signature checking in
son-of-2459? Because they're part of our profile.

Even if we decide to adopt the X.509 behavior and ignore
self-signed certificates, we should still mention that in
son-of-2459. It's not reasonable to expect people to figure out
that some requirement is part of the PKIX profile just because
there's one sentence on page 31 of the X.509 spec that explains it.

I'm suggesting that we add an additional requirement to our
validation algorithm, as we have done before by requiring
that the Issuer field MUST contain a non-empty distinguished
name (for instance). This requirement would be that the path
not contain any self-signed certificates.

-Steve


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f7RHttr23273 for ietf-pkix-bks; Mon, 27 Aug 2001 10:55:55 -0700 (PDT)
Received: from edelweb.fr (edelweb.fr [212.234.46.16]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f7RHtqD23269 for <[e-mail]>; Mon, 27 Aug 2001 10:55:53 -0700 (PDT)
Received: from champagne.edelweb.fr (localhost.edelweb.fr [127.0.0.1]) by edelweb.fr with ESMTP id TAA25061; Mon, 27 Aug 2001 19:55:49 +0200 (MET DST)
Received: from champagne.edelweb.fr (champagne.edelweb.fr [193.51.14.161]) by edelweb.fr (nospam/1.3); Mon, 27 Aug 2001 19:55:49 +0200 (MET DST)
Received: from emeriau.edelweb.fr (emeriau.edelweb.fr [193.51.14.5]) by champagne.edelweb.fr (8.7.6/8.6.6) with ESMTP id TAA29056; Mon, 27 Aug 2001 19:55:47 +0200 (MET DST)
From: Peter Sylvester <[e-mail]>
Received: (sylvest@localhost) by emeriau.edelweb.fr (8.7.6/8.6.6) id TAA10571; Mon, 27 Aug 2001 19:55:47 +0200 (MET DST)
Date: Mon, 27 Aug 2001 19:55:47 +0200 (MET DST)
Message-Id: <[e-mail]>
To: [e-mail], [e-mail]
Subject: Re: Path validation and self-signed certificates
Cc: [e-mail]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>

> This makes path discovery even harder than it was before. If we
> require that self-signed certificates be forbidden or ignored in
> PKIX path validation, none of this will be a concern.
> 

Why does PKIX need to say something that is essentially
already in X.509? Aren't self-signed certificates of type a)
ignored for path validation in X.509?


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f7RHdnj22955 for ietf-pkix-bks; Mon, 27 Aug 2001 10:39:49 -0700 (PDT)
Received: from tholian.securitydynamics.com (mail.rsasecurity.com [204.167.112.129]) by above.proper.com (8.11.6/8.11.3) with SMTP id f7RHdmD22951 for <[e-mail]>; Mon, 27 Aug 2001 10:39:48 -0700 (PDT)
Received: from sdtihq24.securid.com by tholian.securitydynamics.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 27 Aug 2001 17:37:25 UT
Received: from tuna.rsa.com (tuna.rsa.com [10.80.211.153]) by sdtihq24.securid.com (Pro-8.9.3/Pro-8.9.3) with ESMTP id NAA03897; Mon, 27 Aug 2001 13:35:50 -0400 (EDT)
Received: from rsasecurity.com ([10.81.217.242]) by tuna.rsa.com (8.8.8+Sun/8.8.8) with ESMTP id KAA13048; Mon, 27 Aug 2001 10:12:52 -0700 (PDT)
Message-ID: <[e-mail]>
Date: Mon, 27 Aug 2001 10:08:48 -0700
From: Jeff Jacoby <[e-mail]>
Organization: RSA Security, Inc.
X-Mailer: Mozilla 4.75 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: "David A. Cooper" <[e-mail]>
CC: "'[e-mail]'" <[e-mail]>
Subject: Re: Recommended changes to draft-ietf-pkix-new-part1-08
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>

Dave,

Thank you for the answers (and also to the other question I'd
had on "any-policy"), they are of enormous help.  Excellent 
artwork, too! 

Jeff


"David A. Cooper" wrote:
> 
> At 03:12 PM 8/21/01 -0700, Jeff Jacoby wrote:
> 
> Section 6.1.4 Preperation for certificate i+1, step (b)(1). the
> second paragraph reads:
> 
>   "If no node of depth i in the valid_policy_tree has a
>    valid_policy of ID-P but there is a node of depth i with a
>    valid_policy of any-policy, then generate a child node of the
>    node of depth i-1 that has a valid_policy of any-policy as
>    follows:"
> 
> Should it really be:
> 
>   "If no node of depth i in the valid_policy_tree has a
>    valid_policy of ID-P but there is a node of depth i-1 with a
>    valid_policy of any-policy, then generate a child node of the
>    node of depth i-1 that has a valid_policy of any-policy as
>    follows:"
> 
> (note the difference in the first sentence, "i" vs "i-1").  Afterall,
> the last sentence implies there must be a node of depth i-1 with a
> valid_policy of any-policy.
> 
> Actually, I believe that the original text was correct. To see why,
> consider the following two examples:
> 
> In the first example, the first certificate in the path contains the
> following policy extensions:
> 
> certificatePolicies = {anyPolicy, a}
> policyMappings = {a --> c, b --> d}
> 
> After carrying out the steps in section 6.1.3, the valid_policy_tree,
> excluding the qualifier_set and criticality_indicator fields, would be
> (NOTE: this is best viewed with a fixed-width font):
> 
>               +----------------+
>               |   any-policy   |   <---- valid_policy
>               +----------------+
>               |   any-policy   |   <---- expected_policy_set
>               +----------------+
>                  /            \
>                 /              \
> +----------------+            +----------------+
> |   any-policy   |            |       a        |  <---- valid_policy
> +----------------+            +----------------+
> |   any-policy   |            |      {a}       |  <----
> expected_policy_set
> +----------------+            +----------------+
> 
> After the policy mappings extension is processed, the result is:
> 
>                    +----------------+
>                    |   any-policy   |   <---- valid_policy
>                    +----------------+
>                    |   any-policy   |   <---- expected_policy_set
>                    +----------------+
>                   /        |         \
>                  /         |          \
> +----------------+ +----------------+ +----------------+
> |   any-policy   | |       b        | |       a        | <----
> valid_policy
> +----------------+ +----------------+ +----------------+
> |   any-policy   | |      {d}       | |      {c}       | <----
> expected_policy_set
> +----------------+ +----------------+ +----------------+
> 
> In this case, the result would be the same whether the current text or
> the proposed text were used. Note that, by construction, if there is a
> node of depth i with valid_policy any-policy, there must also be a node
> of depth i-1 with valid_policy any-policy.
> 
> The second example shows a case in which the two algorithms differ. In
> this case, the first certificate in the path contains the following
> policy extensions:
> 
> certificatePolicies = {a}
> policyMappings = {a --> c, b --> d}
> 
> +----------------+
> |   any-policy   |   <---- valid_policy
> +----------------+
> |   any-policy   |   <---- expected_policy_set
> +----------------+
>                |
>                |
> +----------------+
> |      a         |   <---- valid_policy
> +----------------+
> |     {a}        |   <---- expected_policy_set
> +----------------+
> 
> When the policy mappings extension is processed, the expected_policy_set
> for the node at depth 1 is changed from {a} to {c}. Since there is no
> node of depth 1 with a valid_policy of any-policy, the mapping from b to
> d is ignored. The result is:
> 
> +----------------+
> |   any-policy   |   <---- valid_policy
> +----------------+
> |   any-policy   |   <---- expected_policy_set
> +----------------+
>                |
>                |
> +----------------+
> |      a         |   <---- valid_policy
> +----------------+
> |     {c}        |   <---- expected_policy_set
> +----------------+
> 
> If the proposed text were followed, a node of depth i with a
> valid_policy of b and expected_policy_set of {d} would be created.
> However, this would make it appear as if b appeared in the
> certificatePolicies extension.  In the first example, this was OK since
> b was implicitly included in the certificatePolicies extension through
> the inclusion of anyPolicy. In the second example, however, b was
> neither explicitly nor implicitly included in the certificatePolicies
> extension. So, in the second example, b should not appear as the
> valid_policy in any node of depth i.
> 
> So, in effect, the phrase "if ... there is a node of depth i with a
> valid_policy of any-policy" is checking to see if anyPolicy was included
> in the certificatePolicies extension. If so, then the issuing domain
> policy ID-P was implicitly included in the certificatePolicies extension
> and the mapping from the issuing domain policy to the subject domain
> policy can be included in the valid_policy tree just as if the issuing
> domain policy had been explicitly included in the certificatePolicies
> extension. If neither the issuing domain policy nor anyPolicy was
> included in the certificatePolicies extension, then the mapping should
> be ignored.
> 
> Second issue is a simple typo.  The very last sentence in section 6.1.4
> reads:
> 
>   "If (a), (k), (l), (n) and (o) have completed successfully, increment
>    i and perform the basic certificate processing specified in 6.1.2."
> 
> it should be:
> 
>   "If (a), (k), (l), (n) and (o) have completed successfully, increment
>    i and perform the basic certificate processing specified in 6.1.3."
> 
> (6.1.2 is Initialization)
> 
> Good catch.
> 
> Finally, in the wrap-up description, section 6.1.5 step (g)(iii) 1.
> reads:
> 
>   "1.  Determine the set of policy nodes whose ancestor nodes
>    have a valid_policy of any-policy.  This is the
> valid_policy_node_set."
> 
> Since the root node (depth 0) has valid_policy of any-policy, and it is
> an ancestor to every node in the tree, this would seem to mean (to me)
> the whole tree is in the valid_policy_node_set.  Or does "ancestor node"
> mean something different?
> 
> I believe that "ancestor" should be replaced by "parent".  The idea is
> to compare policies from the user-initial-policy-set to policies in the
> valid_policy_tree that came from the domain of the relying party. Thus,
> we must look at nodes in the valid_policy_tree as close to the root as
> possible, before any policy mappings have taken place. If a node's
> parent has a valid_policy of any-policy, then no policy mappings could
> have been performed in any of that node's ancestors (i.e., in each of
> the node's ancestors, the expected_policy_set and the valid_policy are
> both any-policy) and so it is reasonable to check whether that node's
> valid_policy appears in the user-initial-policy-set.  If a node's parent
> vald_policy other than any-policy then either a policy mapping has
> occurred (in which case the node's valid_policy should not be compared
> to the user-initial-policy-set) or no mapping has occurred (in which
> case one or more of the node's ancestors contains the same valid_policy,
> and one of those ancestor nodes will be compared against the
> user-initial-policy-set).
> 
> Dave


-- 
Jeff Jacoby, Sr. Programmer                
RSA Security Inc., SMDC                    [e-mail]
2755 Campus Dr., Ste. 300                  [phone]
San Mateo, CA  94403


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f7RHQXX22709 for ietf-pkix-bks; Mon, 27 Aug 2001 10:26:33 -0700 (PDT)
Received: from carbone.certplus.com ([195.101.88.81]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f7RHQVD22705 for <[e-mail]>; Mon, 27 Aug 2001 10:26:31 -0700 (PDT)
Received: from certplus.com ([192.168.212.27]) by carbone.certplus.com with Microsoft SMTPSVC(5.0.2195.2966); Mon, 27 Aug 2001 19:26:24 +0200
Message-ID: <[e-mail]>
Date: Mon, 27 Aug 2001 19:26:41 +0200
From: Jean-Marc Desperrier <[e-mail]>
Organization: Certplus
X-Mailer: Mozilla 4.75 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: [e-mail]
Subject: Re: New test TSA available
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 27 Aug 2001 17:26:24.0406 (UTC) FILETIME=[655A5360:01C12F1D]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>

Peter Gutmann wrote:

> The first item in "Security Considerations" (referred to above) is pretty
> risky.  An un-compromised TSA key should be destroyed, but not explicitly
> revoked.  If it is revoked then it's necessary to create a benign vs serious
> revocation condition (which is what the text does) which can be exploited
> because all I need to do after stealing the TSA key is to revoke it in a benign
> manner and then generate all the fake timestamps I want.

The TSA is signed by a CA.
If I steal the TSA key, I can forge timestamp, but not the revocation information.
I'd need to steal both keys to do that.

Self-signed TSA certificate is against the letter of the draft, the key should be
used only to sign request.
I know this is pushing it a bit far, but in a discussion about that, the draft's
authors seemed to agree with that interpretation.

> The real key owner
> can't do anything about it because my benign revocation has pre-empted any
> attempt at a serious revocation.

I'm not sure.

If the TSA's CA does not revoke the TSA, that mean it will sign information that
says it's not revoked.
The key stealer has the choice between signing non-revoked information or benign
revocation information.

If I get two different revocation information for a TSA, information A saying it's
benign revocation, and B saying it's serious revocation, I would consider it
serious revocation.

Guessing what the user will be able to do in case of compromise of the key used for
revocation information is a bit difficult.



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f7RG0xO21022 for ietf-pkix-bks; Mon, 27 Aug 2001 09:00:59 -0700 (PDT)
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f7RG0vD21018 for <[e-mail]>; Mon, 27 Aug 2001 09:00:57 -0700 (PDT)
Received: from sunlabs.East.Sun.COM ([129.148.75.250]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA09817; Mon, 27 Aug 2001 09:00:57 -0700 (PDT)
Received: from sun.com (dhcp75-167 [129.148.75.167]) by sunlabs.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA28340; Mon, 27 Aug 2001 12:00:56 -0400 (EDT)
Message-ID: <[e-mail]>
Date: Mon, 27 Aug 2001 12:00:28 -0400
From: Steve Hanna <[e-mail]>
Organization: Sun Microsystems, Inc.
X-Mailer: Mozilla 4.75 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: "David A. Cooper" <[e-mail]>
CC: [e-mail]
Subject: Re: Path validation and self-signed certificates
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>

I agree with David on this.

One more reason that self-signed certificates should be forbidden in
path validation is that, if they are allowed, there are situations
where a path may be valid if a self-signed certificate is added to
it and invalid otherwise (if the self-signed certificate contains
policy mappings, for instance). This situation should never arise
in a well-managed PKI, but it means that in order for a path
discovery library to be *absolutely* certain that no valid path
can be constructed from a given set of certificates, self-signed
certificates must be considered. In fact, there are cases where a
self-signed certificate may need to appear multiple times in a row!
This makes path discovery even harder than it was before. If we
require that self-signed certificates be forbidden or ignored in
PKIX path validation, none of this will be a concern.

I suggest that son-of-2459 forbid the use of self-signed certificates
in paths. We should require that any path containing a self-signed
certificate be regarded as invalid.

It's tempting to simply ignore self-signed certificates, as X.509
now does. This would provide maximum compatibility with X.509 and
handle the common case where a trust anchor is accidentally included
at the start of a certification path. But I think this can lead to
security holes. If a self-signed certificate is the last certificate
in the chain and validation of the chain succeeds, a naive
application may extract the subject alternative name or other fields
from the self-signed certificate and assume that they have been
validated (when in fact the entire certificate was ignored). We could
forbid the use of self-signed certificates as the last certificate in
the chain and specify that they are ignored otherwise, but this just
complicates the algorithm. And do we really want to allow a valid
path to contain a certificate whose revocation status and signature
has not been checked?

Simply discouraging the inclusion of self-signed certificates in
certification paths but not forbidding their inclusion leaves open the
question of how validation routines should process them. This
increases the chances of the problems described below. So I recommend
that son-of-2459 specify that any path that contains a self-signed
certificate is invalid.

-Steve

"David A. Cooper" wrote:
> 
> All,
> 
> I believe that PKIX should either discourage or forbid the inclusion of self-signed certificates in certification paths for the following reasons:
> 
> 1) Section 8.1.5 of the 4th edition of X.509 states that
> 
>          There are three circumstances under which a certification authority may
>          issue a certificate to itself:
> 
>          a) as a convenient way of encoding its public key for communication to,
>               and storage by, its certificate users;
> 
>          b) ...
> 
>          For purposes of path validation, self-issued certificates of type a) are verified
>          with the public key contained in them, and if they are encountered in the path,
>          they shall be ignored.
> 
> So, X.509 states that self-signed certificate are only to be used as a convenient way of encoding a public key, and that self-signed certificates, if they are encountered in a certification path are to be ignored. Thus, if PKIX were to allow the processing of self-signed certificates, it would not be compliant with X.509.
> 
> 2) As Peter Hesse pointed out, many CAs issue self-signed certificates with a minimum necessary information (e.g., a version 1 certificate with just a name, public key, and validity dates).  Any such certificates included in a certification path would result in an empty valid_policy_tree.  Old-with-new and new-with-old self-issued certificates are designed to be used as part of certification paths and so should contain all of the necessary extensions (e.g., basicConstraints, certificatePolicies), but self-signed certificates may be been issued simply as a means of distributing the public key to relying parties that will use that key as a trust anchor. If these certificates are included in, and are processed as parts of, certification paths, the results may be rejecting end certificates that should be have been accepted.
> 
> 3) If a CA suspects that its key has been compromised (or it otherwise determines that none of the certificates it has issued should be considered valid), it should request that every certificate issued to it be revoked (as is stated in the Security Considerations section).  If possible, it should also revoke all of the certificates it has issued (not just its self-signed certificate). If a CA can revoke its own self-signed certificate then it can revoke all of the certificates it has issued. Doing so will ensure that all relying parties know about the revocation, not just those relying parties that check to see whether the signed-signed certificate has been revoked.
> 
> 4) If an organization uses client software that processes self-signed certificates, there is risk that that organization will issue certificates from its own CA assuming that relying parties process self-signed certificates. This organization's CA may then issue self-signed certificates with constraints (e.g., name constraints, path length constraints, etc.) that they expect relying parties to see, but the CA, assuming that relying parties will process its self-signed certificates, may not include the constraints in any of its other certificates.
> 
> So, if there is no set rule, there is the risk that relying parties that do process self-signed certificates will lose some interoperability and those that do not will overlook intended path processing constraints.
> 
> Hiroyuki Sakakibara presented an example in which processing self-signed certificates helped to prevent a security breach.  In his example, A issues a cross-certificate to B and B's private key is compromised. Hiroyuki pointed out that by processing B's self-signed certificate (to see if it has expired or has been revoked) one may have a chance to detect the compromise even if A does not cooperate by revoking the certificate that it issued to B.  However, as he pointed out, this is not foolproof. The entity that compromised B's key could issue a new self-signed certificate with a later notAfter date along with CRLs that make it appear as if B's certificates are still good. If on the other hand, B were able to get its own CRLs to relying parties, it could just revoke all of its certificates instead of just its self-signed certificate, thus ensuring that any relying party that receives its CRLs will know that its certificates can not be trusted, whether they process B's self-s!
!
!
> igned certificates or not.
> 
> In general though, if a certification path of the form ... --> A --> B --> ... is being processed, I don't think there is much that B can do to protect relying parties from A's improper behavior. If A issues certificates to B with notAfter dates that are later than they should be or if A refuses to revoke B's certificate when requested to do so, there is little that B can do to protect A's relying parties (or the relying parties of any CA that preceded A in the path) from A, particularly in the case when B's private key has been compromised.  I don't think that it is worth diverging from X.509 and introducing interoperability problems into PKIX in an attempt to try.
> 
> Dave
> 
> At 04:37 PM 8/24/01 -0700, Ryan Hurst wrote:
> >Peter -
> >
> >I agree with your comments on self-signed certificates in chains with only one exception, specifically in regards to revocation. There are several cases where the revocation of a self-signed CA would make sense, what about cessationOfOperation, superseded and affiliationChanged? These reasons do not imply any sort of compromise of key material. We make many "known assumptions" in PKI and the catch 22 of key material management and trust is one of them, without these "known assumptions" many of the things in son-off fall apart.
> >
> >Ryan


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f7RFrM219704 for ietf-pkix-bks; Mon, 27 Aug 2001 08:53:22 -0700 (PDT)
Received: from SOTTMXS01.entrust.com (gatekeeper.entrust.com [204.101.128.170]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f7RFrJD19692 for <[e-mail]>; Mon, 27 Aug 2001 08:53:20 -0700 (PDT)
Received: by SOTTMXS01.entrust.com with Internet Mail Service (5.5.2650.21) id <Q8L2DFSL>; Mon, 27 Aug 2001 11:53:13 -0400
Message-ID: <[e-mail]>
From: Carlisle Adams <[e-mail]>
To: "'[e-mail]'" <[e-mail]>
Cc: [e-mail]
Subject: RE: New test TSA available
Date: Mon, 27 Aug 2001 11:53:12 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C12F10.607ECEF0"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C12F10.607ECEF0
Content-Type: text/plain

Hi Peter,

> ----------
> From: 	[e-mail][SMTP:[e-mail]]
> Sent: 	Monday, August 27, 2001 10:54 AM
> To: 	[e-mail]
> Subject: 	Re: New test TSA available
> 
> 
> I've now updated the TSA to conform to the latest draft (except for the
> TSA
> cert, because I'm using a shared generic cert which gets recycled for SSL,
> OCSP, CMP, and everything else).  And now a rant about the latest draft...
> 
> <rant>
> 
> Since I last looked at this, it seems to have picked up an incredible
> amount of
> unnecessary and confusing cruft.  There are two main things which stand
> out,
> the first is that everything seems to be repeated two or three times over,
> sometimes in consecutive sentences but usually spread far apart and stated
> in a
> contradictory and confusing manner.  The other thing is that there seems
> to be
> way too much text in there which doesn't serve any purpose except to
> confuse
> the reader.  For example consider the bit which begins:
 
(...some text deleted...)

> </rant>
> 
> Peter.
 
I'm sure we all appreciated your edifying rant.

Might I suggest that you some day write your own Internet Draft and
successfully guide it to standards-track RFC status, carefully negotiating
your way through scores of requests for additional functionality and
never-ending clarification (over a period of several years) without
compromising your original desire for brevity and simplicity in any way?

Once you have done this, you will no doubt win the heart-felt (albeit
silent) respect of many of your peers.  Unfortunately, you will probably
also have to endure the heart-felt (albeit vocal) criticism of those few who
are still not satisfied.

It's a thankless task, but one I would be happy to see you undertake.

Carlisle.


------_=_NextPart_001_01C12F10.607ECEF0
Content-Type: text/html
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3DUS-ASCII">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2652.35">
<TITLE>RE: New test TSA available</TITLE>
</HEAD>
<BODY>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New Roman">Hi =
Peter,</FONT>
</P>
<UL>
<P><FONT SIZE=3D2 FACE=3D"MS Sans Serif">----------</FONT>
<BR><B><FONT SIZE=3D2 FACE=3D"MS Sans Serif">From:</FONT></B> &nbsp; =
<FONT SIZE=3D2 FACE=3D"MS Sans =
Serif">[e-mail][SMTP:[e-mail]]</FONT>
<BR><B><FONT SIZE=3D2 FACE=3D"MS Sans Serif">Sent:</FONT></B> &nbsp; =
<FONT SIZE=3D2 FACE=3D"MS Sans Serif">Monday, August 27, 2001 10:54 =
AM</FONT>
<BR><B><FONT SIZE=3D2 FACE=3D"MS Sans Serif">To:</FONT></B> =
&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2 FACE=3D"MS Sans =
Serif">[e-mail]</FONT>
<BR><B><FONT SIZE=3D2 FACE=3D"MS Sans Serif">Subject:</FONT></B> =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2 FACE=3D"MS Sans =
Serif">Re: New test TSA available</FONT>
</P>
<BR>

<P><FONT SIZE=3D2 FACE=3D"Arial">I've now updated the TSA to conform to =
the latest draft (except for the TSA</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">cert, because I'm using a shared =
generic cert which gets recycled for SSL,</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">OCSP, CMP, and everything =
else).&nbsp; And now a rant about the latest draft...</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">&lt;rant&gt;</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Since I last looked at this, it seems =
to have picked up an incredible amount of</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">unnecessary and confusing =
cruft.&nbsp; There are two main things which stand out,</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">the first is that everything seems to =
be repeated two or three times over,</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">sometimes in consecutive sentences =
but usually spread far apart and stated in a</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">contradictory and confusing =
manner.&nbsp; The other thing is that there seems to be</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">way too much text in there which =
doesn't serve any purpose except to confuse</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">the reader.&nbsp; For example =
consider the bit which begins:</FONT>
</UL>
<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New =
Roman">&nbsp;</FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New Roman">(...some =
text deleted...)</FONT>
</P>
<UL>
<P><FONT SIZE=3D2 FACE=3D"Arial">&lt;/rant&gt;</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Peter.</FONT>
</UL>
<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New =
Roman">&nbsp;</FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New Roman">I'm sure =
we all appreciated your edifying rant.</FONT>
</P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New Roman">Might I =
suggest that you some day write your own Internet Draft and =
successfully guide it to standards-track RFC status, carefully =
negotiating your way through scores of requests for additional =
functionality and never-ending clarification (over a period of several =
years) without compromising your original desire for brevity and =
simplicity in any way?</FONT></P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New Roman">Once you =
have done this, you will no doubt win the heart-felt (albeit silent) =
respect of many of your peers.&nbsp; Unfortunately, you will probably =
also have to endure the heart-felt (albeit vocal) criticism of those =
few who are still not satisfied.</FONT></P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New Roman">It's a =
thankless task, but one I would be happy to see you undertake.</FONT>
</P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New =
Roman">Carlisle.</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C12F10.607ECEF0--


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f7REsQW15325 for ietf-pkix-bks; Mon, 27 Aug 2001 07:54:26 -0700 (PDT)
Received: from kakapo.cs.auckland.ac.nz (kakapo.cs.auckland.ac.nz [130.216.34.10]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f7REsPD15321 for <[e-mail]>; Mon, 27 Aug 2001 07:54:25 -0700 (PDT)
Received: from ruru.cs.auckland.ac.nz (firebird.cs.auckland.ac.nz [130.216.34.12]) by kakapo.cs.auckland.ac.nz (8.8.6/8.8.6/cs-master) with ESMTP id CAA21237 for <[e-mail]>; Tue, 28 Aug 2001 02:54:21 +1200 (NZST) (sender [e-mail])
Received: (from pgut001@localhost) by ruru.cs.auckland.ac.nz (8.9.3/8.8.6/cs-slave) id CAA422476 for [e-mail]; Tue, 28 Aug 2001 02:54:20 +1200 (NZST) (sender [e-mail])
Date: Tue, 28 Aug 2001 02:54:20 +1200 (NZST)
Message-ID: <[e-mail]>
From: [e-mail] (Peter Gutmann)
To: [e-mail]
Subject: Re: New test TSA available
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>

I've now updated the TSA to conform to the latest draft (except for the TSA
cert, because I'm using a shared generic cert which gets recycled for SSL,
OCSP, CMP, and everything else).  And now a rant about the latest draft...

<rant>

Since I last looked at this, it seems to have picked up an incredible amount of
unnecessary and confusing cruft.  There are two main things which stand out,
the first is that everything seems to be repeated two or three times over,
sometimes in consecutive sentences but usually spread far apart and stated in a
contradictory and confusing manner.  The other thing is that there seems to be
way too much text in there which doesn't serve any purpose except to confuse
the reader.  For example consider the bit which begins:

  The messageImprint field SHOULD contain the hash of the datum to be time
  stamped.  The hash is represented as an OCTET STRING. Its length MUST match
  the length of the hash value for that algorithm (e.g. 20 bytes for SHA-1 or
  16 bytes for MD5).

As opposed to the alternative 50-byte OCTET STRING for SHA-1?  What other
option is there, and why is it even necessary to specify this?  One useful rule
which someone once told me when writing something like this is "Never include a
statement if its negation is obviously false", there's no need for that entire
statement because there's no other length possible for a given hash function.

  The hash algorithm indicated in the hashAlgorithm field SHOULD be a known
  hash algorithm (one-way and collision resistant). That means that it SHOULD
  be one-way and collision resistant.

As opposed to a hashAlgorithm for a known hash algorithm (one-way and collision
resistant) which isn't one-way and collision resistant perhaps?

  The Time Stamp Authority SHOULD check whether or not the given hash algorithm
  is known to be "sufficient" (based on the current state of knowledge in
  cryptanalysis and the current state of the art in computational resources,
  for example). If the TSA does not recognize the hash algorithm or knows that
  the hash algorithm is weak (a decision left to the discretion of each
  individual TSA), then the TSA SHOULD refuse to provide the Time Stamp Token
  by returning a pkiStatusInfo of 'bad_alg'.

This whole text block doesn't say anything useful, and even if it did it's
matter of TSA policy and/or interop profiles/signature legislation/whatever to
decide what does and doesn't constitute an acceptable hash algorithm.  Since
the text doesn't say anything useful (it leaves it open to the TSA to do
whatever they want), why is it even here?

  If the certReq field is missing or if the certReq field is present and set to
  false then the certificates field from the SignedData structure MUST not be
  present in the response.

Given that the field is DEFAULT FALSE, it can never be "present and set to
false".

  The extensions field is a generic way to add additional information to the
  request in the future. Extensions is defined in [RFC 2459]. If an extension,
  whether it is marked critical or not critical, is used by a requester but is
  not recognized by a time stamping server, the server SHALL not issue a token
  and SHALL return a failure (unacceptedExtension).

This text first defines extensions in terms of RFC 2459 and then in the next
sentence specifies handling of extensions which directly contradicts RFC 2459.
Why is it necessary to have this special-case handling for extensions?  Given
that TSAs will (presumably) be using standard implementations of whatever
standards are appropriate (X.509 and CMS), is it really necessary to specify an
extension-handling behaviour which differs from either of the standards which
TSP is built on?

It's made even worse in the second place where extension-handling behaviour
is specified:

  Conforming timestamping requesters MUST be able to recognize version 1
  Timestamp tokens with all the optional fields present, but are not mandated
  to understand the semantics of any extension, if present.

This time it's still behaviour which contradicts RFC 2459, but now it also
contradicts the behaviour mandated earlier in the same draft (admittedly one is
for clients and the other for servers).  Is there any reason for not following
the standard (that is, RFC 2459) on this?

There are other places where non-RFC 2459 behaviour is mandated, for example:

  When the reasonCode extension relative to the revoked certificate from the
  TSA is present in the CRL entry extensions, it SHALL be set either to
  unspecified (0), affiliationChanged (3), superseded (4) or
  cessationOfOperation (5).

when RFC 2459 says:

  CAs are strongly encouraged to include meaningful reason codes in CRL
  entries; however, the reason code CRL entry extension SHOULD be absent
  instead of using the unspecified (0) reasonCode value.

(in fact the whole section which contains this text is a bad idea, I'll go into
this in more detail further on).

Now we get to a tour de force example of the "Never include a statement if its
negation is obviously false" rule:

  Compliant servers SHOULD NOT produce any other values.

Given that there are no other values defined, what other option could there
possibly be? -> Never include a statement if its negation is obviously false.

  Compliant clients MUST generate an error if values it does not understand are
  present.

As opposed to, say, inventing values which look plausible and continuing? ->
Never include a statement if its negation is obviously false

  These are the only values of PKIFailureInfo that SHALL be supported.

Given that there are no other values defined, what other option could there
possibly be? -> Never include a statement if its negation is obviously false.

  Compliant servers SHOULD NOT produce any other values.

Yes, we know, you just told us that -> Never include a statement if its
negation is obviously false.

  Compliant clients MUST generate an error if values it does not understand are
  present.

See above -> Never include a statement if its negation is obviously false.

  The certificate identifier (ESSCertID) of the TSA certificate MUST be
  included as a signerInfo attribute inside a SigningCertificate attribute.

  [...]

  the certificate identifier (ESSCertID Attribute) inside a SigningCertificate
  attribute which is part of the signerInfo (See Section 5 of [ESS]).

This appears to be contradictory, but if you read it carefully it's probably
saying the same thing.  This is another example of how repeating the same thing
several times in different locations does nothing but confuse the reader. There
are other places where similar things occur... I'm sure that I could remove at
least 25% of the total text in the draft without it having any effect except to
improve legibility.

The first item in "Security Considerations" (referred to above) is pretty
risky.  An un-compromised TSA key should be destroyed, but not explicitly
revoked.  If it is revoked then it's necessary to create a benign vs serious
revocation condition (which is what the text does) which can be exploited
because all I need to do after stealing the TSA key is to revoke it in a benign
manner and then generate all the fake timestamps I want.  The real key owner
can't do anything about it because my benign revocation has pre-empted any
attempt at a serious revocation.  A better suggestion would be to use short-
term TSA keys, which sidesteps the whole problem.

</rant>

Peter.


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f7RE0jF12530 for ietf-pkix-bks; Mon, 27 Aug 2001 07:00:45 -0700 (PDT)
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f7RE0hD12523 for <[e-mail]>; Mon, 27 Aug 2001 07:00:43 -0700 (PDT)
Received: from sunlabs.East.Sun.COM ([129.148.75.250]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id GAA15398; Mon, 27 Aug 2001 07:00:13 -0700 (PDT)
Received: from sun.com (dhcp75-167 [129.148.75.167]) by sunlabs.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA13694; Mon, 27 Aug 2001 09:58:00 -0400 (EDT)
Message-ID: <[e-mail]>
Date: Mon, 27 Aug 2001 09:57:30 -0400
From: Steve Hanna <[e-mail]>
Organization: Sun Microsystems, Inc.
X-Mailer: Mozilla 4.75 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Tom Gindin <[e-mail]>
CC: [e-mail]
Subject: Re: excludedSubtrees (was Re: draft-ietf-pkix-new-part1-08)
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>

Tom Gindin wrote:
> As far as I can tell, the only excludedSubtree with DirectoryName
> which is widely usable and doesn't run into the character code
> problems discussed earlier is one which contains a countryName and
> no other attributes. Thus I would not change the last sentence of
> the paragraph (it's good advice anyway)

I'm glad we agree on that.

> but would add a new sentence to it after the first sentence as
> follows: "This is particularly hard to guarantee when one or more
> of the attributes in the DN specification is encoded as a CHOICE,
> such as DirectoryString." and change the beginning of the next
> sentence to "If the encodings differ" from "If not".

For those following along at home, that would change the text to:

   In addition, name constraints for distinguished names MUST be
   stated identically to the encoding used in the subject field or
   subjectAltName extension. This is particularly hard to guarantee
   when one or more of the attributes in the DN specification is
   encoded as a CHOICE, such as DirectoryString. If the encodings
   differ, then name constraints stated as excludedSubTrees will not
   match and invalid paths will be accepted and name constraints
   expressed as permittedSubtrees will not match and valid paths will
   be rejected.  To avoid acceptance of invalid paths, CAs SHOULD
   state name constraints for distinguished names as
   permittedSubtrees wherever possible.

Why do you want to make this change? It seems to narrow the focus of
this paragraph to only cases of differing encodings. But different
encodings aren't the only cause of name constraint mismatches. Two
UTF8Strings with values "Tom" and "TOM" won't match using the minimum
son-of-2459 rules, which use binary comparison for UTF8String values.

-Steve


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f7RBhOp27526 for ietf-pkix-bks; Mon, 27 Aug 2001 04:43:24 -0700 (PDT)
Received: from kakapo.cs.auckland.ac.nz (kakapo.cs.auckland.ac.nz [130.216.34.10]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f7RBhMD27522 for <[e-mail]>; Mon, 27 Aug 2001 04:43:22 -0700 (PDT)
Received: from ruru.cs.auckland.ac.nz (firebird.cs.auckland.ac.nz [130.216.34.12]) by kakapo.cs.auckland.ac.nz (8.8.6/8.8.6/cs-master) with ESMTP id XAA17707; Mon, 27 Aug 2001 23:41:42 +1200 (NZST) (sender [e-mail])
Received: (from pgut001@localhost) by ruru.cs.auckland.ac.nz (8.9.3/8.8.6/cs-slave) id XAA419420; Mon, 27 Aug 2001 23:41:38 +1200 (NZST) (sender [e-mail])
Date: Mon, 27 Aug 2001 23:41:38 +1200 (NZST)
Message-ID: <[e-mail]>
From: [e-mail] (Peter Gutmann)
To: [e-mail]
Subject: Re: New test TSA available
Cc: [e-mail]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>

Jean-Marc Desperrier <[e-mail]> writes:

>A draft is just that, a draft. There isn't, and hasn't to be a formalism for
>interoperability between versions of a draft.

That's exactly the point I was trying to make, that you can't have versions for
something which hasn't even reached 1.0 yet.  Based on the last message from
Todd Glassey, I have the feeling we've been talking about two completely
different things, or at least I don't see how his concept of a version
coincides with the way I thought they worked.

(Actually given that some RFCs seem to be in a perpetual draft state, you may
 need versions for drafts after all :-).

Peter.


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f7R9w8F20550 for ietf-pkix-bks; Mon, 27 Aug 2001 02:58:08 -0700 (PDT)
Received: from carbone.certplus.com (facteur.certplus.com [195.101.88.81]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f7R9w6D20540 for <[e-mail]>; Mon, 27 Aug 2001 02:58:07 -0700 (PDT)
Received: from certplus.com ([192.168.212.27]) by carbone.certplus.com with Microsoft SMTPSVC(5.0.2195.2966); Mon, 27 Aug 2001 11:57:34 +0200
Message-ID: <[e-mail]>
Date: Mon, 27 Aug 2001 11:57:50 +0200
From: Jean-Marc Desperrier <[e-mail]>
Organization: Certplus
X-Mailer: Mozilla 4.75 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
CC: [e-mail]
Subject: Re: New test TSA available
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 27 Aug 2001 09:57:34.0421 (UTC) FILETIME=[B1D4B850:01C12EDE]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>

Peter Gutmann wrote:

> But the token only allows one version value, v1, which is always present anyway
> (that is, it's a non-optional field).  Thus my earlier questions, that there's
> no way to indicate that you're using draft-n because it's assumed there's only
> one version, v1, as per the final RFC.  That means that anything from
> draft-....-01 through to RFCxxxx can only indicate use of v1.

A draft is just that, a draft.
" It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress"
And basically, you want them to become reference material.
There isn't, and hasn't to be a formalism for interoperability between versions of
a draft.

What is needed is a finalized version of this protocol in an RFC, so that _this_
becomes a reference, and something one can actually use for interoperability.
As long as this doesn't exist, the tokens can't be anything more than laboratory
experiments.
Therefore the true question is why is this RFC still not there when supposedly the
draft is on the last stages of approval since monthes, and there hasn't been any
point raised about it in this mailing list since a long time ?




Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f7R307H18756 for ietf-pkix-bks; Sun, 26 Aug 2001 20:00:07 -0700 (PDT)
Received: from mtiwmhc23.worldnet.att.net (mtiwmhc23.worldnet.att.net [204.127.131.48]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f7R305D18751 for <[e-mail]>; Sun, 26 Aug 2001 20:00:05 -0700 (PDT)
Received: from tsg1 ([12.81.65.104]) by mtiwmhc23.worldnet.att.net (InterMail vM.4.01.03.16 201-229-121-116-20010115) with SMTP id <20010827030002.DERY18450.mtiwmhc23.worldnet.att.net@tsg1>; Mon, 27 Aug 2001 03:00:02 +0000
Message-ID: <000601c12ea4$3c6e9980$020aff0c@tsg1>
From: "todd glassey" <[e-mail]>
To: "Peter Gutmann" <[e-mail]>
Cc: <[e-mail]>
References: <[e-mail]>
Subject: Re: New test TSA available
Date: Sun, 26 Aug 2001 07:33:23 -0700
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.3018.1300
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.3018.1300
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>

Peter - the token's only allowing for one version spells its demise in my
book. The legal processes of timestamping are far from formalized and with
GLB and the ECPA here in the states its a can of worms to say the least.

What that means is that any token system must be able to permute or evolve
to meet any number of event capture and representation needs or the protocol
is of such little use that there is no reason to standardize it other than
our egos.

You and many others may not like those words but since we are finally to a
place where the tokens are supposed to represent evidentiary marques, doing
anything less is foolish IMHO.

Todd Glassey
----- Original Message -----
From: "Peter Gutmann" <[e-mail]>
To: <[e-mail]>; <[e-mail]>
Cc: <>
Sent: Saturday, August 25, 2001 8:00 PM
Subject: Re: New test TSA available


>
> "todd glassey" <[e-mail]> writes:
>
> >Stick it (the version tag) in the token,
>
> But the token only allows one version value, v1, which is always present
anyway
> (that is, it's a non-optional field).  Thus my earlier questions, that
there's
> no way to indicate that you're using draft-n because it's assumed there's
only
> one version, v1, as per the final RFC.  That means that anything from
> draft-....-01 through to RFCxxxx can only indicate use of v1.
>
> Peter.



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f7Q30p218877 for ietf-pkix-bks; Sat, 25 Aug 2001 20:00:51 -0700 (PDT)
Received: from kakapo.cs.auckland.ac.nz (kakapo.cs.auckland.ac.nz [130.216.34.10]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f7Q30lD18873 for <[e-mail]>; Sat, 25 Aug 2001 20:00:48 -0700 (PDT)
Received: from ruru.cs.auckland.ac.nz (firebird.cs.auckland.ac.nz [130.216.34.12]) by kakapo.cs.auckland.ac.nz (8.8.6/8.8.6/cs-master) with ESMTP id PAA08909; Sun, 26 Aug 2001 15:00:41 +1200 (NZST) (sender [e-mail])
Received: (from pgut001@localhost) by ruru.cs.auckland.ac.nz (8.9.3/8.8.6/cs-slave) id PAA385198; Sun, 26 Aug 2001 15:00:40 +1200 (NZST) (sender [e-mail])
Date: Sun, 26 Aug 2001 15:00:40 +1200 (NZST)
Message-ID: <[e-mail]>
From: [e-mail] (Peter Gutmann)
To: [e-mail], [e-mail]
Subject: Re: New test TSA available
Cc: [e-mail]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>

"todd glassey" <[e-mail]> writes:

>Stick it (the version tag) in the token,  

But the token only allows one version value, v1, which is always present anyway
(that is, it's a non-optional field).  Thus my earlier questions, that there's
no way to indicate that you're using draft-n because it's assumed there's only
one version, v1, as per the final RFC.  That means that anything from
draft-....-01 through to RFCxxxx can only indicate use of v1.

Peter.


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f7Q2Kgi18312 for ietf-pkix-bks; Sat, 25 Aug 2001 19:20:42 -0700 (PDT)
Received: from mtiwmhc23.worldnet.att.net (mtiwmhc23.worldnet.att.net [204.127.131.48]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f7Q2KeD18308 for <[e-mail]>; Sat, 25 Aug 2001 19:20:40 -0700 (PDT)
Received: from tsg1 ([12.81.65.107]) by mtiwmhc23.worldnet.att.net (InterMail vM.4.01.03.16 201-229-121-116-20010115) with SMTP id <20010826022024.QRAD18450.mtiwmhc23.worldnet.att.net@tsg1>; Sun, 26 Aug 2001 02:20:24 +0000
Message-ID: <0c8501c12dd5$8ce582e0$020aff0c@tsg1>
From: "todd glassey" <[e-mail]>
To: "Peter Gutmann" <[e-mail]>
Cc: <[e-mail]>
References: <[e-mail]>
Subject: Re: New test TSA available
Date: Sat, 25 Aug 2001 19:19:21 -0700
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.3018.1300
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.3018.1300
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>

Peter -
Stick it (the version tag) in the token,  and the reason is that from an
evaluation side view, to remove all doubt as to compliance of the token to
the spec level.

For instance 5 years form now when there are 50 versions of the V1 system
deployed all churning out V1 tokens and the V2 structure and rule set is in
review by PKIX we may wish we could differentiate the two tokens from each
other in the same protocol.

Todd
----- Original Message -----
From: "Peter Gutmann" <[e-mail]>
To: <[e-mail]>; <[e-mail]>;
<[e-mail]>
Cc: <>; <[e-mail]>
Sent: Saturday, August 25, 2001 5:57 PM
Subject: Re: New test TSA available


>
> "todd glassey" <[e-mail]> writes:
>
> >The TSA should by its response message also identify which standard or
draft
> >level it complies to.
>
> How?  And why?  Since there's only supposed to be one version of the
standard
> (the final RFC), there doesn't seem to be any means of indicating which
draft
> was used (actually my code does implicitly indicate which draft was used,
which
> is "not a very recent one" :-).
>
> Peter.
>



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f7Q0wMN16555 for ietf-pkix-bks; Sat, 25 Aug 2001 17:58:22 -0700 (PDT)
Received: from kakapo.cs.auckland.ac.nz (kakapo.cs.auckland.ac.nz [130.216.34.10]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f7Q0wKD16549 for <[e-mail]>; Sat, 25 Aug 2001 17:58:20 -0700 (PDT)
Received: from ruru.cs.auckland.ac.nz (firebird.cs.auckland.ac.nz [130.216.34.12]) by kakapo.cs.auckland.ac.nz (8.8.6/8.8.6/cs-master) with ESMTP id MAA07145; Sun, 26 Aug 2001 12:57:34 +1200 (NZST) (sender [e-mail])
Received: (from pgut001@localhost) by ruru.cs.auckland.ac.nz (8.9.3/8.8.6/cs-slave) id MAA383133; Sun, 26 Aug 2001 12:57:28 +1200 (NZST) (sender [e-mail])
Date: Sun, 26 Aug 2001 12:57:28 +1200 (NZST)
Message-ID: <[e-mail]>
From: [e-mail] (Peter Gutmann)
To: [e-mail], [e-mail], [e-mail]
Subject: Re: New test TSA available
Cc: [e-mail], [e-mail]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>

"todd glassey" <[e-mail]> writes:

>The TSA should by its response message also identify which standard or draft
>level it complies to.

How?  And why?  Since there's only supposed to be one version of the standard
(the final RFC), there doesn't seem to be any means of indicating which draft
was used (actually my code does implicitly indicate which draft was used, which
is "not a very recent one" :-).

Peter.



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f7PLZVm12974 for ietf-pkix-bks; Sat, 25 Aug 2001 14:35:31 -0700 (PDT)
Received: from email.nist.gov (email.nist.gov [129.6.2.7]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f7PLZUD12970 for <[e-mail]>; Sat, 25 Aug 2001 14:35:30 -0700 (PDT)
Received: from krdp2 (krdp2.ncsl.nist.gov [129.6.54.107]) by email.nist.gov (8.9.3/8.9.3) with ESMTP id RAA14346 for <[e-mail]>; Sat, 25 Aug 2001 17:35:47 -0400 (EDT)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 
Date: Sat, 25 Aug 2001 17:33:29 -0400
To: [e-mail]
From: "David A. Cooper" <[e-mail]>
Subject: RE: Path validation and self-signed certificates
In-Reply-To: <[e-mail] .com>
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id f7PLZUD12971
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>

All,

I believe that PKIX should either discourage or forbid the inclusion of self-signed certificates in certification paths for the following reasons:

1) Section 8.1.5 of the 4th edition of X.509 states that

         There are three circumstances under which a certification authority may
         issue a certificate to itself:

         a) as a convenient way of encoding its public key for communication to,
              and storage by, its certificate users;

         b) ...

         For purposes of path validation, self-issued certificates of type a) are verified
         with the public key contained in them, and if they are encountered in the path,
         they shall be ignored.

So, X.509 states that self-signed certificate are only to be used as a convenient way of encoding a public key, and that self-signed certificates, if they are encountered in a certification path are to be ignored. Thus, if PKIX were to allow the processing of self-signed certificates, it would not be compliant with X.509.

2) As Peter Hesse pointed out, many CAs issue self-signed certificates with a minimum necessary information (e.g., a version 1 certificate with just a name, public key, and validity dates).  Any such certificates included in a certification path would result in an empty valid_policy_tree.  Old-with-new and new-with-old self-issued certificates are designed to be used as part of certification paths and so should contain all of the necessary extensions (e.g., basicConstraints, certificatePolicies), but self-signed certificates may be been issued simply as a means of distributing the public key to relying parties that will use that key as a trust anchor. If these certificates are included in, and are processed as parts of, certification paths, the results may be rejecting end certificates that should be have been accepted.

3) If a CA suspects that its key has been compromised (or it otherwise determines that none of the certificates it has issued should be considered valid), it should request that every certificate issued to it be revoked (as is stated in the Security Considerations section).  If possible, it should also revoke all of the certificates it has issued (not just its self-signed certificate). If a CA can revoke its own self-signed certificate then it can revoke all of the certificates it has issued. Doing so will ensure that all relying parties know about the revocation, not just those relying parties that check to see whether the signed-signed certificate has been revoked.

4) If an organization uses client software that processes self-signed certificates, there is risk that that organization will issue certificates from its own CA assuming that relying parties process self-signed certificates. This organization's CA may then issue self-signed certificates with constraints (e.g., name constraints, path length constraints, etc.) that they expect relying parties to see, but the CA, assuming that relying parties will process its self-signed certificates, may not include the constraints in any of its other certificates.

So, if there is no set rule, there is the risk that relying parties that do process self-signed certificates will lose some interoperability and those that do not will overlook intended path processing constraints.

Hiroyuki Sakakibara presented an example in which processing self-signed certificates helped to prevent a security breach.  In his example, A issues a cross-certificate to B and B's private key is compromised. Hiroyuki pointed out that by processing B's self-signed certificate (to see if it has expired or has been revoked) one may have a chance to detect the compromise even if A does not cooperate by revoking the certificate that it issued to B.  However, as he pointed out, this is not foolproof. The entity that compromised B's key could issue a new self-signed certificate with a later notAfter date along with CRLs that make it appear as if B's certificates are still good. If on the other hand, B were able to get its own CRLs to relying parties, it could just revoke all of its certificates instead of just its self-signed certificate, thus ensuring that any relying party that receives its CRLs will know that its certificates can not be trusted, whether they process B's self-signed certificates or not.

In general though, if a certification path of the form ... --> A --> B --> ... is being processed, I don't think there is much that B can do to protect relying parties from A's improper behavior. If A issues certificates to B with notAfter dates that are later than they should be or if A refuses to revoke B's certificate when requested to do so, there is little that B can do to protect A's relying parties (or the relying parties of any CA that preceded A in the path) from A, particularly in the case when B's private key has been compromised.  I don't think that it is worth diverging from X.509 and introducing interoperability problems into PKIX in an attempt to try.

Dave

At 04:37 PM 8/24/01 -0700, Ryan Hurst wrote:
>Peter -
>
>I agree with your comments on self-signed certificates in chains with only one exception, specifically in regards to revocation. There are several cases where the revocation of a self-signed CA would make sense, what about cessationOfOperation, superseded and affiliationChanged? These reasons do not imply any sort of compromise of key material. We make many "known assumptions" in PKI and the catch 22 of key material management and trust is one of them, without these "known assumptions" many of the things in son-off fall apart.
>
>Ryan




Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f7PKBgY11519 for ietf-pkix-bks; Sat, 25 Aug 2001 13:11:42 -0700 (PDT)
Received: from email.nist.gov (email.nist.gov [129.6.2.7]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f7PKBfD11515 for <[e-mail]>; Sat, 25 Aug 2001 13:11:41 -0700 (PDT)
Received: from krdp2 (krdp2.ncsl.nist.gov [129.6.54.107]) by email.nist.gov (8.9.3/8.9.3) with ESMTP id QAA29767; Sat, 25 Aug 2001 16:11:54 -0400 (EDT)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 
Date: Sat, 25 Aug 2001 16:10:53 -0400
To: Jeff Jacoby <[e-mail]>, "'[e-mail]'" <[e-mail]>
From: "David A. Cooper" <[e-mail]>
Subject: Re: Recommended changes to draft-ietf-pkix-new-part1-08
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="=====================_6398477==_.ALT"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>

--=====================_6398477==_.ALT
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

At 03:12 PM 8/21/01 -0700, Jeff Jacoby wrote:
>Section 6.1.4 Preperation for certificate i+1, step (b)(1). the
>second paragraph reads:
>
>   "If no node of depth i in the valid_policy_tree has a
>    valid_policy of ID-P but there is a node of depth i with a
>    valid_policy of any-policy, then generate a child node of the
>    node of depth i-1 that has a valid_policy of any-policy as
>    follows:"
>
>Should it really be:
>
>   "If no node of depth i in the valid_policy_tree has a
>    valid_policy of ID-P but there is a node of depth i-1 with a
>    valid_policy of any-policy, then generate a child node of the
>    node of depth i-1 that has a valid_policy of any-policy as
>    follows:"
>
>(note the difference in the first sentence, "i" vs "i-1").  Afterall,
>the last sentence implies there must be a node of depth i-1 with a
>valid_policy of any-policy.

Actually, I believe that the original text was correct. To see why, consider=
 the following two examples:

In the first example, the first certificate in the path contains the=
 following policy extensions:

certificatePolicies =3D {anyPolicy, a}
policyMappings =3D {a --> c, b --> d}

After carrying out the steps in section 6.1.3, the valid_policy_tree,=
 excluding the qualifier_set and criticality_indicator fields, would be=
 (NOTE: this is best viewed with a fixed-width font):

               +----------------+
               |   any-policy   |   <---- valid_policy
               +----------------+
               |   any-policy   |   <---- expected_policy_set
               +----------------+
                  /            \
                 /              \
+----------------+            +----------------+
|   any-policy   |            |       a        |  <---- valid_policy
+----------------+            +----------------+
|   any-policy   |            |      {a}       |  <---- expected_policy_set
+----------------+            +----------------+

After the policy mappings extension is processed, the result is:

                    +----------------+
                    |   any-policy   |   <---- valid_policy
                    +----------------+
                    |   any-policy   |   <---- expected_policy_set
                    +----------------+
                   /        |         \
                  /         |          \
+----------------+ +----------------+ +----------------+
|   any-policy   | |       b        | |       a        | <---- valid_policy
+----------------+ +----------------+ +----------------+
|   any-policy   | |      {d}       | |      {c}       | <----=
 expected_policy_set
+----------------+ +----------------+ +----------------+


In this case, the result would be the same whether the current text or the=
 proposed text were used. Note that, by construction, if there is a node of=
 depth i with valid_policy any-policy, there must also be a node of depth=
 i-1 with valid_policy any-policy.


The second example shows a case in which the two algorithms differ. In this=
 case, the first certificate in the path contains the following policy=
 extensions:

certificatePolicies =3D {a}
policyMappings =3D {a --> c, b --> d}

+----------------+
|   any-policy   |   <---- valid_policy
+----------------+
|   any-policy   |   <---- expected_policy_set
+----------------+
                |
                |
+----------------+
|      a         |   <---- valid_policy
+----------------+
|     {a}        |   <---- expected_policy_set
+----------------+

When the policy mappings extension is processed, the expected_policy_set for=
 the node at depth 1 is changed from {a} to {c}. Since there is no node of=
 depth 1 with a valid_policy of any-policy, the mapping from b to d is=
 ignored. The result is:

+----------------+
|   any-policy   |   <---- valid_policy
+----------------+
|   any-policy   |   <---- expected_policy_set
+----------------+
                |
                |
+----------------+
|      a         |   <---- valid_policy
+----------------+
|     {c}        |   <---- expected_policy_set
+----------------+

If the proposed text were followed, a node of depth i with a valid_policy of=
 b and expected_policy_set of {d} would be created. However, this would make=
 it appear as if b appeared in the certificatePolicies extension.  In the=
 first example, this was OK since b was implicitly included in the=
 certificatePolicies extension through the inclusion of anyPolicy. In the=
 second example, however, b was neither explicitly nor implicitly included=
 in the certificatePolicies extension. So, in the second example, b should=
 not appear as the valid_policy in any node of depth i.

So, in effect, the phrase "if ... there is a node of depth i with a=
 valid_policy of any-policy" is checking to see if anyPolicy was included in=
 the certificatePolicies extension. If so, then the issuing domain policy=
 ID-P was implicitly included in the certificatePolicies extension and the=
 mapping from the issuing domain policy to the subject domain policy can be=
 included in the valid_policy tree just as if the issuing domain policy had=
 been explicitly included in the certificatePolicies extension. If neither=
 the issuing domain policy nor anyPolicy was included in the=
 certificatePolicies extension, then the mapping should be ignored.


>Second issue is a simple typo.  The very last sentence in section 6.1.4
>reads:
>
>   "If (a), (k), (l), (n) and (o) have completed successfully, increment
>    i and perform the basic certificate processing specified in 6.1.2."
>
>it should be:
>
>   "If (a), (k), (l), (n) and (o) have completed successfully, increment
>    i and perform the basic certificate processing specified in 6.1.3."
>
>(6.1.2 is Initialization)

Good catch.

>Finally, in the wrap-up description, section 6.1.5 step (g)(iii) 1.
>reads:
>
>   "1.  Determine the set of policy nodes whose ancestor nodes
>    have a valid_policy of any-policy.  This is the
>valid_policy_node_set."
>
>Since the root node (depth 0) has valid_policy of any-policy, and it is
>an ancestor to every node in the tree, this would seem to mean (to me)
>the whole tree is in the valid_policy_node_set.  Or does "ancestor node"
>mean something different?

I believe that "ancestor" should be replaced by "parent".  The idea is to=
 compare policies from the user-initial-policy-set to policies in the=
 valid_policy_tree that came from the domain of the relying party. Thus, we=
 must look at nodes in the valid_policy_tree as close to the root as=
 possible, before any policy mappings have taken place. If a node's parent=
 has a valid_policy of any-policy, then no policy mappings could have been=
 performed in any of that node's ancestors (i.e., in each of the node's=
 ancestors, the expected_policy_set and the valid_policy are both=
 any-policy) and so it is reasonable to check whether that node's=
 valid_policy appears in the user-initial-policy-set.  If a node's parent=
 vald_policy other than any-policy then either a policy mapping has occurred=
 (in which case the node's valid_policy should not be compared to the=
 user-initial-policy-set) or no mapping has occurred (in which case one or=
 more of the node's ancestors contains the same valid_policy, and one of=
 those ancestor nodes will be compared against the user-initial-policy-set).

Dave

--=====================_6398477==_.ALT
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<html>
At 03:12 PM 8/21/01 -0700, Jeff Jacoby wrote:<br>
<blockquote type=3Dcite cite>Section 6.1.4 Preperation for certificate i+1,
step (b)(1). the<br>
second paragraph reads:<br>
<br>
&nbsp; &quot;If no node of depth i in the valid_policy_tree has a<br>
&nbsp;&nbsp; valid_policy of ID-P but there is a node of depth i with
a<br>
&nbsp;&nbsp; valid_policy of any-policy, then generate a child node of
the<br>
&nbsp;&nbsp; node of depth i-1 that has a valid_policy of any-policy
as<br>
&nbsp;&nbsp; follows:&quot;<br>
<br>
Should it really be:<br>
<br>
&nbsp; &quot;If no node of depth i in the valid_policy_tree has a<br>
&nbsp;&nbsp; valid_policy of ID-P but there is a node of depth i-1 with
a<br>
&nbsp;&nbsp; valid_policy of any-policy, then generate a child node of
the<br>
&nbsp;&nbsp; node of depth i-1 that has a valid_policy of any-policy
as<br>
&nbsp;&nbsp; follows:&quot;<br>
<br>
(note the difference in the first sentence, &quot;i&quot; vs
&quot;i-1&quot;).&nbsp; Afterall,<br>
the last sentence implies there must be a node of depth i-1 with a<br>
valid_policy of any-policy.</blockquote><br>
Actually, I believe that the original text was correct. To see why,
consider the following two examples:<br>
<br>
In the first example, the first certificate in the path contains the
following policy extensions:<br>
<br>
certificatePolicies =3D {anyPolicy, a}<br>
policyMappings =3D {a --&gt; c, b --&gt; d}<br>
<br>
After carrying out the steps in section 6.1.3, the valid_policy_tree,
excluding the qualifier_set and criticality_indicator fields, would be
(NOTE: this is best viewed with a fixed-width font):<br>
<br>
<tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;
+----------------+<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;
|&nbsp;&nbsp; any-policy&nbsp;&nbsp; |&nbsp;&nbsp; &lt;----
valid_policy<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;
+----------------+<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;
|&nbsp;&nbsp; any-policy&nbsp;&nbsp; |&nbsp;&nbsp; &lt;----
expected_policy_set<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;
+----------------+<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;
/&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
\<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;
/&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;
\<br>
+----------------+&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;
+----------------+<br>
|&nbsp;&nbsp; any-policy&nbsp;&nbsp;
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
a&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |&nbsp; &lt;----
valid_policy<br>
+----------------+&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;
+----------------+<br>
|&nbsp;&nbsp; any-policy&nbsp;&nbsp;
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; {a}&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp; &lt;---- expected_policy_set<br>
+----------------+&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;
+----------------+<br>
<br>
</tt>After the policy mappings extension is processed, the result
is:<br>
<br>
<tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
+----------------+<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp; any-policy&nbsp;&nbsp; |&nbsp;&nbsp; &lt;----
valid_policy<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
+----------------+<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp; any-policy&nbsp;&nbsp; |&nbsp;&nbsp; &lt;----
expected_policy_set<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
+----------------+<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;
/&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; \<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;
/&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; \<br>
+----------------+ +----------------+ +----------------+<br>
|&nbsp;&nbsp; any-policy&nbsp;&nbsp; |
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
b&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
a&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; | &lt;---- valid_policy<br>
+----------------+ +----------------+ +----------------+<br>
|&nbsp;&nbsp; any-policy&nbsp;&nbsp; | |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
{d}&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; | |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
{c}&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; | &lt;----
expected_policy_set<br>
+----------------+ +----------------+ +----------------+<br>
<br>
<br>
</tt>In this case, the result would be the same whether the current text
or the proposed text were used. Note that, by construction, if there is a
node of depth i with valid_policy any-policy, there must also be a node
of depth i-1 with valid_policy any-policy.<br>
<br>
<br>
The second example shows a case in which the two algorithms differ. In
this case, the first certificate in the path contains the following
policy extensions:<br>
<br>
certificatePolicies =3D {a}<br>
policyMappings =3D {a --&gt; c, b --&gt; d}<br>
<br>
<tt>+----------------+<br>
|&nbsp;&nbsp; any-policy&nbsp;&nbsp; |&nbsp;&nbsp; &lt;----
valid_policy<br>
+----------------+<br>
|&nbsp;&nbsp; any-policy&nbsp;&nbsp; |&nbsp;&nbsp; &lt;----
expected_policy_set<br>
+----------------+<br>
</tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;
|<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;
|<br>
<tt>+----------------+<br>
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
a&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp; &lt;----
valid_policy<br>
+----------------+<br>
|&nbsp;&nbsp;&nbsp;&nbsp; {a}&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp; &lt;---- expected_policy_set<br>
+----------------+<br>
<br>
</tt>When the policy mappings extension is processed, the
expected_policy_set for the node at depth 1 is changed from {a} to {c}.
Since there is no node of depth 1 with a valid_policy of any-policy, the
mapping from b to d is ignored. The result is:<br>
<br>
<tt>+----------------+<br>
|&nbsp;&nbsp; any-policy&nbsp;&nbsp; |&nbsp;&nbsp; &lt;----
valid_policy<br>
+----------------+<br>
|&nbsp;&nbsp; any-policy&nbsp;&nbsp; |&nbsp;&nbsp; &lt;----
expected_policy_set<br>
+----------------+<br>
</tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;
|<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;
|<br>
<tt>+----------------+<br>
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
a&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp; &lt;----
valid_policy<br>
+----------------+<br>
|&nbsp;&nbsp;&nbsp;&nbsp; {c}&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp; &lt;---- expected_policy_set<br>
+----------------+<br>
<br>
</tt>If the proposed text were followed, a node of depth i with a
valid_policy of b and expected_policy_set of {d} would be created.
However, this would make it appear as if b appeared in the
certificatePolicies extension.&nbsp; In the first example, this was OK
since b was implicitly included in the certificatePolicies extension
through the inclusion of anyPolicy. In the second example, however, b was
neither explicitly nor implicitly included in the certificatePolicies
extension. So, in the second example, b should not appear as the
valid_policy in any node of depth i.<br>
<br>
So, in effect, the phrase &quot;if ... there is a node of depth i with a
valid_policy of any-policy&quot; is checking to see if anyPolicy was
included in the certificatePolicies extension. If so, then the issuing
domain policy ID-P was implicitly included in the certificatePolicies
extension and the mapping from the issuing domain policy to the subject
domain policy can be included in the valid_policy tree just as if the
issuing domain policy had been explicitly included in the
certificatePolicies extension. If neither the issuing domain policy nor
anyPolicy was included in the certificatePolicies extension, then the
mapping should be ignored.<br>
<br>
<br>
<blockquote type=3Dcite cite>Second issue is a simple typo.&nbsp; The very
last sentence in section 6.1.4<br>
reads:<br>
<br>
&nbsp; &quot;If (a), (k), (l), (n) and (o) have completed successfully,
increment<br>
&nbsp;&nbsp; i and perform the basic certificate processing specified in
6.1.2.&quot;<br>
<br>
it should be:<br>
<br>
&nbsp; &quot;If (a), (k), (l), (n) and (o) have completed successfully,
increment<br>
&nbsp;&nbsp; i and perform the basic certificate processing specified in
6.1.3.&quot;<br>
<br>
(6.1.2 is Initialization)</blockquote><br>
Good catch.<br>
<br>
<blockquote type=3Dcite cite>Finally, in the wrap-up description, section
6.1.5 step (g)(iii) 1.<br>
reads:<br>
<br>
&nbsp; &quot;1.&nbsp; Determine the set of policy nodes whose ancestor
nodes<br>
&nbsp;&nbsp; have a valid_policy of any-policy.&nbsp; This is the<br>
valid_policy_node_set.&quot;<br>
<br>
Since the root node (depth 0) has valid_policy of any-policy, and it
is<br>
an ancestor to every node in the tree, this would seem to mean (to
me)<br>
the whole tree is in the valid_policy_node_set.&nbsp; Or does
&quot;ancestor node&quot;<br>
mean something different?</blockquote><br>
I believe that &quot;ancestor&quot; should be replaced by
&quot;parent&quot;.&nbsp; The idea is to compare policies from the
user-initial-policy-set to policies in the valid_policy_tree that came
from the domain of the relying party. Thus, we must look at nodes in the
valid_policy_tree as close to the root as possible, before any policy
mappings have taken place. If a node's parent has a valid_policy of
any-policy, then no policy mappings could have been performed in any of
that node's ancestors (i.e., in each of the node's ancestors, the
expected_policy_set and the valid_policy are both any-policy) and so it
is reasonable to check whether that node's valid_policy appears in the
user-initial-policy-set.&nbsp; If a node's parent vald_policy other than
any-policy then either a policy mapping has occurred (in which case the
node's valid_policy should not be compared to the
user-initial-policy-set) or no mapping has occurred (in which case one or
more of the node's ancestors contains the same valid_policy, and one of
those ancestor nodes will be compared against the
user-initial-policy-set).<br>
<br>
Dave<br>
</html>

--=====================_6398477==_.ALT--



Received: by above.proper.com (8.11.6/8.11.3) id f7P0WNT10408 for ietf-pkix-bks; Fri, 24 Aug 2001 17:32:23 -0700 (PDT)
Received: from e1.ny.us.ibm.com (e1.ny.us.ibm.com [32.97.182.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f7P0WLD10404 for <[e-mail]>; Fri, 24 Aug 2001 17:32:21 -0700 (PDT)
Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.117.200.22]) by e1.ny.us.ibm.com (8.9.3/8.9.3) with ESMTP id UAA254504; Fri, 24 Aug 2001 20:30:09 -0400
Received: from d01ml062.pok.ibm.com (d01ml062.pok.ibm.com [9.117.250.163]) by northrelay02.pok.ibm.com (8.11.1m3/NCO v4.97.1) with ESMTP id f7P0OJL260846; Fri, 24 Aug 2001 20:24:19 -0400
Importance: Normal
Subject: Re: excludedSubtrees (was Re: draft-ietf-pkix-new-part1-08)
To: Steve Hanna <[e-mail]>
Cc: [e-mail]
X-Mailer: Lotus Notes Release 5.0.3 (Intl) 21 March 2000
Message-ID: <[e-mail]>
From: "Tom Gindin" <[e-mail]>
Date: Fri, 24 Aug 2001 20:32:23 -0400
X-MIMETrack: Serialize by Router on D01ML062/01/M/IBM(Release 5.0.8 SPR #MIAS4UTJ8H |June 21, 2001) at 08/24/2001 08:32:18 PM
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>

     As far as I can tell, the only excludedSubtree with DirectoryName
which is widely usable and doesn't run into the character code problems
discussed earlier is one which contains a countryName and no other
attributes.  Thus I would not change the last sentence of the paragraph
(it's good advice anyway) but would add a new sentence to it after the
first sentence as follows: "This is particularly hard to guarantee when one
or more of the attributes in the DN specification is encoded as a CHOICE,
such as DirectoryString." and change the beginning of the next sentence to
"If the encodings differ" from "If not".

          Tom Gindin

Steve Hanna <[e-mail]> on 08/23/2001 10:20:04 AM

To:   Tom Gindin <[e-mail]>
cc:   Peter Sylvester <[e-mail]>, [e-mail]
Subject:  Re: excludedSubtrees (was Re: draft-ietf-pkix-new-part1-08)


Tom Gindin wrote:
> On a more constructive note, however, any attribute which can only
> be encoded in PrintableString or NumericString (or Object ID) can
> safely be used in excludedSubtrees.  The most useful of these is
> probably Country.

Right. So I can safely use excludedSubtrees with directoryNames as long
as the only attributes in the excluded DN are countryName, dnQualifier,
and serialNumber. But I suspect that most DNs that people would want to
exclude would contain organizationName and the like.

So I still think that using excludedSubtrees with directoryNames is
generally a bad idea. The Security Considerations section of
new-part1-08 basically says this, so I don't think any changes to the
draft are required.

-Steve




Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f7ONhU109663 for ietf-pkix-bks; Fri, 24 Aug 2001 16:43:30 -0700 (PDT)
Received: from ext-mail.valicert.com (ns1.valicert.com [63.65.221.10]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f7ONhSD09658 for <[e-mail]>; Fri, 24 Aug 2001 16:43:28 -0700 (PDT)
Received: from CONVERSION-DAEMON by ext-mail.valicert.com (PMDF V5.2-33 #46613) id <[e-mail]> for [e-mail]; Fri, 24 Aug 2001 16:44:04 -0700 (PDT)
Received: from polaris.valicert.com ([192.168.2.34]) by ext-mail.valicert.com (PMDF V5.2-33 #46613) with ESMTP id <[e-mail]>; Fri, 24 Aug 2001 16:44:03 -0700 (PDT)
Received: by exchange.valicert.com with Internet Mail Service (5.5.2650.21) id <QP4K47X4>; Fri, 24 Aug 2001 16:37:30 -0700
Content-return: allowed
Date: Fri, 24 Aug 2001 16:37:30 -0700
From: Ryan Hurst <[e-mail]>
Subject: RE: Path validation and self-signed certificates (was RE: Recomme	nded changes to draft-ietf-pkix-new-part1-08)
To: "'Peter Hesse'" <[e-mail]>, "'Hiroyuki Sakakibara'" <[e-mail]>, "Housley, Russ" <[e-mail]>
Cc: [e-mail]
Message-id: <[e-mail]>
MIME-version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-type: multipart/alternative; boundary="Boundary_(ID_aof3KuOaA08d4bGQ37koiw)"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

--Boundary_(ID_aof3KuOaA08d4bGQ37koiw)
Content-type: text/plain

Peter -
 
I agree with your comments on self-signed certificates in chains with only
one exception, specifically in regards to revocation. There are several
cases where the revocation of a self-signed CA would make sense, what about
cessationOfOperation, superseded and affiliationChanged? These reasons do
not imply any sort of compromise of key material. We make many "known
assumptions" in PKI and the catch 22 of key material management and trust is
one of them, without these "known assumptions" many of the things in son-off
fall apart :-).
 
 
Ryan
 
 
 
 
 
-----Original Message-----
From: Peter Hesse [mailto:[e-mail]] 
Sent: Wednesday, August 22, 2001 6:46 AM
To: 'Hiroyuki Sakakibara'; Housley, Russ; Peter Hesse
Cc: [e-mail]
Subject: Path validation and self-signed certificates (was RE: Recommended
changes to draft-ietf-pkix-new-part1-08)
 
Hiroyuki, 
I will attempt to discuss a few of these issues inline. 
> -----Original Message----- 
> From: Hiroyuki Sakakibara [mailto:[e-mail]
<mailto:[e-mail]> ] 
> Sent: Wednesday, August 22, 2001 1:51 AM 
> To: Housley, Russ; Peter Hesse 
> Cc: [e-mail]; [e-mail]; [e-mail]; 
> [e-mail]; [e-mail] 
> Subject: Re: Recommended changes to draft-ietf-pkix-new-part1-08 
> 
> 
> Hello. I have a comment related to path validation with a self-signed 
> certificate. 
> 
> I think that in 6.1  Basic Path Validation, it is not clear 
> that whether 
> self-signed 
> NON trust certificates may be included in a path or not. 
> (namely intermediate self-signed certs, not oldWithNew, newWithOld) 
> 
> Plese note that I am not talking about a self-signed 
> certificate to begin a 
> path, 
> talking about self-signed certificates in the middle of a path. 
I think this vagueness is somewhat purposeful.  It is not directly allowed
or prohibited.  Whether or not a self-signed certificate is found within the
path, the path is still complete.  Any benefit or detriment that comes from
having the self-signed certificate within the path will not always be
encountered for two reasons, 
        1) Other implementations may not allow the path to have a
self-signed certificate within it 
        2) You may find the path without the self-signed certificate first 
> 
> For example, 
> 
> CA1 cross certifies with BridgeCA 
> CA2 cross certifies with BridgeCA 
> CA2 issues Cert_EE.(EndEntity cert) 
> SelfSignedCert_CA1 is trust anchor. 
> BridgeCA has a selfsigned certificate(SelfSignedCert_BridgeCA). 
> 
> Based on the relation ship between issuer and subject or AKI/SKI, 
> the following 2 paths would be constructed. 
> 
> (1) SelfSignedCert_CA1 -> CrossCert_CA1toBridgeCA 
>      ->  CrossCert_BridgeCAtoCA2 -> Cert_EE 
> 
> (2) SelfSigned_CA1 -> CrossCert_CA1toBridgeCA 
>     ->  SelfSignedCert_BridgeCA -> CrossCert_BridgeCAtoCA2 -> Cert_EE 
I think it is a bad idea for Bridge CAs to post self-signed certificates in
the directory.  They are not a trust anchor for anyone, so they should not
publish a self-signed certificate as a key container.  However this point
and demonstration remain the same if you consider just three CAs that have
cross-certified without a bridge.
  
> I suppose that most validation softwares implement (1), simple one, 
> and it could be a minimum requirement for interoperability. 
> 
> In case of  (2), there is an advantage that a validation 
> software could 
> check 
> the status of SelfSignedCert_BridgeCA, shown in the appendix below. 
> 
> So, I think that it should be clear that intermediate self-signed 
> certificates may be 
> included(optionally), or ignored,  in the document. 
> I think that (1) is mandatory, and (2) is optional(not inhibited). 
> 
> Folks, what do you think about this issue ? 
Again, my opinion is that since both are complete paths, both are equally
valid and may be used by different implementations.  However, many
implementations have made a simplifying assumption to prevent certificate
path loops which would prevent #2 from ever being validated.  So any benefit
that might be gained by allowing #2 cannot be counted on.
There seems to be little benefit gained by including two or more
certificates with the same subject distinguished name and subject public key
within the same path.  I have looked through your examples below and must
admit I am not understanding them fully.  Let's look at this example
TR -> A -> B -> (B self signed) -> C -> EE 
Let's say that A->B has a notAfter date of 12/31/2002, (B self signed) has a
notAfter date of 12/31/2001, and B->C has a notAfter date of 12/31/2002.  If
this path was developed and validated, the path would be invalid if the
current date was after  12/31/2001.
> * About ISO/IEC 9594-8 
> 
> According to current ISO/IEC 9594-8 document, in 8.1.5 Self-Issued 
> certificates 
> it seems that intermediate self-signed certificates shall be 
> ignored in path 
> construction/validation. 
> However, considering  the advantage of checking intermediate 
> self-signed 
> certificates shown below, 
>  I don't understand why they "shall be ignored", 
> because checking them would be meaningful from the point of view of 
> security. 
> 
> I think that investigation of intermediate self-signed 
> ceritificates may be 
> optional, 
> should not inhibited, so, "may be ignored" would be better. 
> 
> This is not a mailing list for 9594-8, however RFC2459 
> related documents are 
> based on 
> 9594-8, so, I will also send my opinioin about it. 
> 
> -------------------- Advantage of  validation of path 
> (2) -------------------- 
> 
> If a validation software implements (2), 
> the software could check the validity status of 
> SelfSignedCert_BridgeCA. 
> 
> Assume that CA1 issues a cross certificate whose 
> notAfter excess notAfter of self-signed certificate of BridgeCA. 
> 
> such as 
> notAfter of SelfSignedCert_BridgeCA is "2001/12/31" 
> notAfter of CrossCert_CA1toBridgeCA  is "2002/12/31" . 
> 
> when BridgeCA inhibits such cross certificate, it will be an invalid 
> cross-certificate. 
> 
> Useally, BridgeCA checks a cross-certificate from CA1 when issuance, 
> however, if CA1 is a rough CA, or a bug CA(including mis-operations), 
> after issuance of a valid cross certificate, 
> CA1 could issue an additional invalid certificate and 
> distribute it to LDAP 
> etc... 
> without BrigeCA's permission . 
> 
> ( In this case, for a RP, CA1 is a trust anchor, so, CA1 must 
> not be a rough 
> CA, however, this kind of rough operation would happen in 
> another example. 
> for example, 
> 
> CA1(has self-signed cert, trust anchor) -> CA2(has 
> self-signed cert) -> CA3 
> -> CA4( has self-signed cert)  -> EE 
> 
> CA3 issues an invalid cross certificate to CA4. 
> In this example, a trust anchor CA1 behaves properly, however, 
> CA3 does rough operations. ) 
> 
> RP could check the revocation status of Cert_BridgeCASelfsigned also. 
> 
In the case of self-signed revocation, I am not sure why a CA would revoke
itself.  If the CA was truly operating as a "rogue", it would not revoke
itself in order to keep whatever trust it still had.  Can you trust a CA
that revokes itself?  I am reminded of the old puzzle in which you encounter
two people at a crossroads, a truthteller and a liar.  You do not know which
is which, and must ask one of them a question in order to know if you should
turn left or right to get to where you want to go.  
--Peter 
---------------------------------------------------------------- 
 Peter M. Hesse            CygnaCom Solutions, a division of 
 Phone: [phone]                   Entrust 
 ICQ:   1942828                 Securing the Internet 
---------------------------------------------------------------- 
"Pay no attention to what the critics say; there has never been 
a statue set up in honor of a critic." --Jean Sibelius 
 
> This kind of problem would happen in a multi CA products environment. 
> 
> To avoid this problem, interoperability test, operation, management 
> among multi CA products should be done well, 
> or a RP should check the status of intermediate self-signed 
> certificates, 
> or a CA which cross-certifies with other CAs should observe 
> behavior of 
> other CAs, etc...? 
> 

--Boundary_(ID_aof3KuOaA08d4bGQ37koiw)
Content-type: text/html
Content-transfer-encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<html xmlns:o=3D"urn:schemas-microsoft-com:office:office" =
xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns=3D"http://www.w3.org/TR/REC-html40">

<head>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3DUS-ASCII">


<meta name=3DProgId content=3DWord.Document>
<meta name=3DGenerator content=3D"Microsoft Word 10">
<meta name=3DOriginator content=3D"Microsoft Word 10">
<link rel=3DFile-List href=3D"cid:filelist.xml@01C12CBB.E3E70840">
<title>Path validation and self-signed certificates (was RE: =
Recommended
changes to draft-ietf-pkix-new-part1-08)</title>
<!--[if gte mso 9]><xml>
 <o:OfficeDocumentSettings>
  <o:DoNotRelyOnCSS/>
 </o:OfficeDocumentSettings>
</xml><![endif]--><!--[if gte mso 9]><xml>
 <w:WordDocument>
  <w:GrammarState>Clean</w:GrammarState>
  <w:DocumentKind>DocumentEmail</w:DocumentKind>
  <w:EnvelopeVis/>
  <w:BrowserLevel>MicrosoftInternetExplorer4</w:BrowserLevel>
 </w:WordDocument>
</xml><![endif]-->
<style>
<!--
 /* Font Definitions */
 @font-face
	{font-family:Wingdings;
	panose-1:5 0 0 0 0 0 0 0 0 0;
	mso-font-charset:2;
	mso-generic-font-family:auto;
	mso-font-pitch:variable;
	mso-font-signature:0 268435456 0 0 -2147483648 0;}
@font-face
	{font-family:Tahoma;
	panose-1:2 11 6 4 3 5 4 4 2 4;
	mso-font-charset:0;
	mso-generic-font-family:swiss;
	mso-font-pitch:variable;
	mso-font-signature:553679495 -2147483648 8 0 66047 0;}
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{mso-style-parent:"";
	margin:0in;
	margin-bottom:.0001pt;
	mso-pagination:widow-orphan;
	font-size:12.0pt;
	font-family:"Times New Roman";
	mso-fareast-font-family:"Times New Roman";}
a:link, span.MsoHyperlink
	{color:blue;
	text-decoration:underline;
	text-underline:single;}
a:visited, span.MsoHyperlinkFollowed
	{color:blue;
	text-decoration:underline;
	text-underline:single;}
p
	{mso-margin-top-alt:auto;
	margin-right:0in;
	mso-margin-bottom-alt:auto;
	margin-left:0in;
	mso-pagination:widow-orphan;
	font-size:12.0pt;
	font-family:"Times New Roman";
	mso-fareast-font-family:"Times New Roman";}
pre
	{margin:0in;
	margin-bottom:.0001pt;
	mso-pagination:widow-orphan;
	tab-stops:45.8pt 91.6pt 137.4pt 183.2pt 229.0pt 274.8pt 320.6pt =
366.4pt 412.2pt 458.0pt 503.8pt 549.6pt 595.4pt 641.2pt 687.0pt =
732.8pt;
	font-size:10.0pt;
	font-family:"Courier New";
	mso-fareast-font-family:"Times New Roman";}
span.EmailStyle18
	{mso-style-type:personal-reply;
	mso-style-noshow:yes;
	mso-ansi-font-size:10.0pt;
	mso-bidi-font-size:10.0pt;
	font-family:Arial;
	mso-ascii-font-family:Arial;
	mso-hansi-font-family:Arial;
	mso-bidi-font-family:Arial;
	color:navy;}
span.GramE
	{mso-style-name:"";
	mso-gram-e:yes;}
@page Section1
	{size:8.5in 11.0in;
	margin:1.0in 1.25in 1.0in 1.25in;
	mso-header-margin:.5in;
	mso-footer-margin:.5in;
	mso-paper-source:0;}
div.Section1
	{page:Section1;}
-->
</style>
<!--[if gte mso 10]>
<style>
 /* Style Definitions */=20
 table.MsoNormalTable
	{mso-style-name:"Table Normal";
	mso-tstyle-rowband-size:0;
	mso-tstyle-colband-size:0;
	mso-style-noshow:yes;
	mso-style-parent:"";
	mso-padding-alt:0in 5.4pt 0in 5.4pt;
	mso-para-margin:0in;
	mso-para-margin-bottom:.0001pt;
	mso-pagination:widow-orphan;
	font-size:10.0pt;
	font-family:"Times New Roman";}
</style>
<![endif]-->
</head>

<body lang=3DEN-US link=3Dblue vlink=3Dblue =
style=3D'tab-interval:.5in'>

<div class=3DSection1>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>Peter =
-<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p></span></font></p>=


<p class=3DMsoNormal style=3D'text-indent:.5in'><font size=3D2 =
color=3Dnavy face=3DArial><span
style=3D'font-size:10.0pt;font-family:Arial;color:navy'>I agree with =
your
comments on self-signed certificates in chains with only one exception, =
specifically
in regards to revocation. There are several cases where the revocation =
of a
self-signed CA would make sense, what about =
</span></font>cessationOfOperation,
superseded and affiliationChanged? <font size=3D2 color=3Dnavy =
face=3DArial><span
style=3D'font-size:10.0pt;font-family:Arial;color:navy'>These reasons =
do not
imply any sort of compromise of key material. We make many "known =
assumptions"
in PKI and the catch 22 of key material management and trust is one of =
them, without
these "known assumptions" many of the things in son-off fall apart =
</span></font><font
size=3D2 color=3Dnavy face=3DWingdings><span =
style=3D'font-size:10.0pt;font-family:
Wingdings;mso-ascii-font-family:Arial;mso-hansi-font-family:Arial;mso-bi=
di-font-family:
Arial;color:navy;mso-char-type:symbol;mso-symbol-font-family:Wingdings'>=
<span
style=3D'mso-char-type:symbol;mso-symbol-font-family:Wingdings'>J</span>=
</span></font><font
size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:10.0pt;font-family:Arial;
color:navy'>.<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p></span></font></p>=


<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p></span></font></p>=


<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>Ryan<o:p></o:p></span></font></p>

<p class=3DMsoNormal style=3D'text-indent:.5in'><font size=3D2 =
color=3Dnavy face=3DArial><span
style=3D'font-size:10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p=
></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p></span></font></p>=


<p class=3DMsoNormal style=3D'text-indent:.5in'><font size=3D2 =
color=3Dnavy face=3DArial><span
style=3D'font-size:10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p=
></span></font></p>

<p class=3DMsoNormal style=3D'text-indent:.5in'><font size=3D2 =
color=3Dnavy face=3DArial><span
style=3D'font-size:10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p=
></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p></span></font></p>=


<p class=3DMsoNormal style=3D'margin-left:.5in'><font size=3D2 =
face=3DTahoma><span
style=3D'font-size:10.0pt;font-family:Tahoma'>-----Original =
Message-----<br>
<b><span style=3D'font-weight:bold'>From:</span></b> Peter Hesse =
[mailto:[e-mail]]
<br>
<b><span style=3D'font-weight:bold'>Sent:</span></b> Wednesday, August =
22, 2001
6:46 AM<br>
<b><span style=3D'font-weight:bold'>To:</span></b> 'Hiroyuki =
Sakakibara';
Housley, Russ; Peter Hesse<br>
<b><span style=3D'font-weight:bold'>Cc:</span></b> =
[e-mail]<br>
<b><span style=3D'font-weight:bold'>Subject:</span></b> Path validation =
and
self-signed certificates (was RE: Recommended changes to
draft-ietf-pkix-new-part1-08)</span></font></p>

<p class=3DMsoNormal style=3D'margin-left:.5in'><font size=3D3 =
face=3D"Times New Roman"><span
style=3D'font-size:12.0pt'><o:p>&nbsp;</o:p></span></font></p>

<p style=3D'margin-left:.5in'><font size=3D2 face=3D"Times New =
Roman"><span
style=3D'font-size:10.0pt'>Hiroyuki,</span></font> <o:p></o:p></p>

<p style=3D'margin-left:.5in'><font size=3D2 face=3D"Times New =
Roman"><span
style=3D'font-size:10.0pt'>I will attempt to discuss a few of these =
issues
inline.</span></font> <o:p></o:p></p>

<p style=3D'margin-left:.5in'><font size=3D2 face=3D"Times New =
Roman"><span
style=3D'font-size:10.0pt'>&gt; -----Original =
Message-----</span></font> <br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; From: Hiroyuki =
Sakakibara [<a
href=3D"mailto:[e-mail]">mailto:[e-mail].c=
o.jp</a>]</span></font>
<br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; Sent: Wednesday, =
August 22,
2001 1:51 AM</span></font> <br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; To: Housley, Russ; =
Peter Hesse</span></font>
<br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; Cc: =
[e-mail];
[e-mail]; [e-mail];</span></font> <br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; [e-mail]; =
[e-mail]</span></font>
<br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; Subject: Re: =
Recommended
changes to draft-ietf-pkix-new-part1-08</span></font> <br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; </span></font><br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; </span></font><br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; Hello. I have a =
comment
related to path validation with a self-signed</span></font> <br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; =
certificate.</span></font> <br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; </span></font><br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; I think that in =
6.1&nbsp;
Basic Path Validation, it is not clear </span></font><br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; that =
whether</span></font> <br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; =
self-signed</span></font> <br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; NON trust =
certificates may be
included in a path or not.</span></font> <br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; (namely =
intermediate
self-signed certs, not oldWithNew, newWithOld)</span></font> <br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt;</span></font> <br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; Plese note that I =
am not
talking about a self-signed </span></font><br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; certificate to =
begin a</span></font>
<br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; =
path,</span></font> <br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; talking about =
self-signed
certificates in the middle of a path.</span></font> <o:p></o:p></p>

<p style=3D'margin-left:.5in'><font size=3D2 face=3D"Times New =
Roman"><span
style=3D'font-size:10.0pt'>I think this vagueness is somewhat =
purposeful.&nbsp;
It is not directly allowed or prohibited.&nbsp; Whether or not a =
self-signed
certificate is found within the path, the path is still complete.&nbsp; =
Any
benefit or detriment that comes from having the self-signed certificate =
within
the path will not always be encountered for two reasons, =
</span></font><o:p></o:p></p>

<p style=3D'margin-left:.5in'><font size=3D3 face=3D"Times New =
Roman"><span
style=3D'font-size:12.0pt'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
</span></font><font
size=3D2><span style=3D'font-size:10.0pt'>1) Other implementations may =
not allow
the path to have a self-signed certificate within it</span></font> <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <font size=3D2><span =
style=3D'font-size:
10.0pt'>2) You may find the path without the self-signed certificate =
first</span></font>
<o:p></o:p></p>

<p style=3D'margin-left:.5in'><font size=3D2 face=3D"Times New =
Roman"><span
style=3D'font-size:10.0pt'>&gt; </span></font><br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; For =
example,</span></font> <br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; </span></font><br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; CA1 cross =
certifies with
BridgeCA</span></font> <br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; CA2 cross =
certifies with
BridgeCA</span></font> <br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; CA2 issues =
Cert_EE.(EndEntity
cert)</span></font> <br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; SelfSignedCert_CA1 =
is trust
anchor.</span></font> <br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; BridgeCA has a =
selfsigned
certificate(SelfSignedCert_BridgeCA).</span></font> <br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; </span></font><br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; Based on the =
relation ship
between issuer and subject or AKI/SKI,</span></font> <br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; the following 2 =
paths would be
constructed.</span></font> <br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; </span></font><br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; (1) =
SelfSignedCert_CA1 -&gt;
CrossCert_CA1toBridgeCA</span></font> <br>
<font size=3D2><span =
style=3D'font-size:10.0pt'>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
-&gt;&nbsp; CrossCert_BridgeCAtoCA2 -&gt; Cert_EE</span></font> <br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; </span></font><br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; (2) SelfSigned_CA1 =
-&gt;
CrossCert_CA1toBridgeCA</span></font> <br>
<font size=3D2><span =
style=3D'font-size:10.0pt'>&gt;&nbsp;&nbsp;&nbsp;&nbsp;
-&gt;&nbsp; SelfSignedCert_BridgeCA -&gt; CrossCert_BridgeCAtoCA2 -&gt; =
Cert_EE</span></font>
<o:p></o:p></p>

<p style=3D'margin-left:.5in'><font size=3D2 face=3D"Times New =
Roman"><span
style=3D'font-size:10.0pt'>I think it is a bad idea for Bridge CAs to =
post
self-signed certificates in the directory.&nbsp; They are not a trust =
anchor
for anyone, so they should not publish a self-signed certificate as a =
key
container.&nbsp; However this point and demonstration remain the same =
if you
consider just three CAs that have cross-certified without a =
bridge.</span></font><o:p></o:p></p>

<p style=3D'margin-left:.5in'><font size=3D2 face=3D"Times New =
Roman"><span
style=3D'font-size:10.0pt'>&nbsp;</span></font> <br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; I suppose that =
most validation
softwares implement (1), simple one,</span></font> <br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; and it could be a =
minimum
requirement for interoperability.</span></font> <br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; </span></font><br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; In case of&nbsp; =
(2), there is
an advantage that a validation </span></font><br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; software =
could</span></font> <br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; =
check</span></font> <br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; the status of
SelfSignedCert_BridgeCA, shown in the appendix below.</span></font> =
<br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; </span></font><br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; So, I think that =
it should be
clear that intermediate self-signed</span></font> <br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; certificates may =
be</span></font>
<br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; =
included(optionally), or
ignored,&nbsp; in the document.</span></font> <br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; I think that (1) =
is mandatory,
and (2) is optional(not inhibited).</span></font> <br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; </span></font><br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; Folks, what do you =
think about
this issue ?</span></font> <o:p></o:p></p>

<p style=3D'margin-left:.5in'><font size=3D2 face=3D"Times New =
Roman"><span
style=3D'font-size:10.0pt'>Again, my opinion is that since both are =
complete
paths, both are equally valid and may be used by different
implementations.&nbsp; However, many implementations have made a =
simplifying
assumption to prevent certificate path loops which would prevent #2 =
from ever
being validated.&nbsp; So any benefit that might be gained by allowing =
#2
cannot be counted on.</span></font><o:p></o:p></p>

<p style=3D'margin-left:.5in'><font size=3D2 face=3D"Times New =
Roman"><span
style=3D'font-size:10.0pt'>There seems to be little benefit gained by =
including
two or more certificates with the same subject distinguished name and =
subject
public key within the same path.&nbsp; I have looked through your =
examples
below and must admit I am not understanding them fully.&nbsp; Let's =
look at
this example</span></font><o:p></o:p></p>

<p style=3D'margin-left:.5in'><font size=3D2 face=3D"Times New =
Roman"><span
style=3D'font-size:10.0pt'>TR -&gt; A -&gt; B -&gt; (B self signed) =
-&gt; C -&gt;
EE</span></font> <o:p></o:p></p>

<p style=3D'margin-left:.5in'><font size=3D2 face=3D"Times New =
Roman"><span
style=3D'font-size:10.0pt'>Let's say that A-&gt;B has a notAfter date =
of
12/31/2002, (B self signed) has a notAfter date of 12/31/2001, and =
B-&gt;C has
a notAfter date of 12/31/2002.&nbsp; If this path was developed and =
validated,
the path would be invalid if the current date was after&nbsp; =
12/31/2001.</span></font><o:p></o:p></p>

<p style=3D'margin-left:.5in'><font size=3D2 face=3D"Times New =
Roman"><span
style=3D'font-size:10.0pt'>&gt; * About ISO/IEC 9594-8</span></font> =
<br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; </span></font><br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; According to =
current ISO/IEC
9594-8 document, in 8.1.5 Self-Issued</span></font> <br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; =
certificates</span></font> <br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; it seems that =
intermediate
self-signed certificates shall be </span></font><br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; ignored in =
path</span></font> <br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; =
construction/validation.</span></font>
<br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; However, =
considering&nbsp; the
advantage of checking intermediate </span></font><br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; =
self-signed</span></font> <br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; certificates shown =
below,</span></font>
<br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt;&nbsp; I don't =
understand why
they &quot;shall be ignored&quot;,</span></font> <br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; because checking =
them would be
meaningful from the point of view of</span></font> <br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; =
security.</span></font> <br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; </span></font><br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; I think that =
investigation of
intermediate self-signed </span></font><br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; ceritificates may =
be</span></font>
<br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; =
optional,</span></font> <br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; should not =
inhibited, so,
&quot;may be ignored&quot; would be better.</span></font> <br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; </span></font><br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; This is not a =
mailing list for
9594-8, however RFC2459 </span></font><br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; related documents =
are</span></font>
<br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; based =
on</span></font> <br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; 9594-8, so, I will =
also send
my opinioin about it.</span></font> <br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; </span></font><br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; =
-------------------- Advantage
of&nbsp; validation of path</span></font> <br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; (2) =
--------------------</span></font>
<br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; </span></font><br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; If a validation =
software
implements (2),</span></font> <br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; the software could =
check the
validity status of </span></font><br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; =
SelfSignedCert_BridgeCA.</span></font>
<br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; </span></font><br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; Assume that CA1 =
issues a cross
certificate whose</span></font> <br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; notAfter excess =
notAfter of
self-signed certificate of BridgeCA.</span></font> <br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; </span></font><br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; such =
as</span></font> <br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; notAfter of
SelfSignedCert_BridgeCA is &quot;2001/12/31&quot;</span></font> <br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; notAfter of
CrossCert_CA1toBridgeCA&nbsp; is &quot;2002/12/31&quot; .</span></font> =
<br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; </span></font><br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; when BridgeCA =
inhibits such
cross certificate, it will be an invalid</span></font> <br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; =
cross-certificate.</span></font>
<br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; </span></font><br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; Useally, BridgeCA =
checks a
cross-certificate from CA1 when issuance,</span></font> <br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; however, if CA1 is =
a rough CA,
or a bug CA(including mis-operations),</span></font> <br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; after issuance of =
a valid
cross certificate,</span></font> <br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; CA1 could issue an =
additional
invalid certificate and </span></font><br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; distribute it to =
LDAP</span></font>
<br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; =
etc...</span></font> <br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; without BrigeCA's =
permission .</span></font>
<br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; </span></font><br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; ( In this case, =
for a RP, CA1
is a trust anchor, so, CA1 must </span></font><br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; not be a =
rough</span></font> <br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; CA, however, this =
kind of
rough operation would happen in </span></font><br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; another =
example.</span></font>
<br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; for =
example,</span></font> <br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; </span></font><br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; CA1(has =
self-signed cert,
trust anchor) -&gt; CA2(has </span></font><br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; self-signed cert) =
-&gt; CA3</span></font>
<br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; -&gt; CA4( has =
self-signed
cert)&nbsp; -&gt; EE</span></font> <br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; </span></font><br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; CA3 issues an =
invalid cross
certificate to CA4.</span></font> <br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; In this example, a =
trust
anchor CA1 behaves properly, however,</span></font> <br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; CA3 does rough =
operations. )</span></font>
<br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; </span></font><br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; RP could check the =
revocation
status of Cert_BridgeCASelfsigned also.</span></font> <br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; =
</span></font><o:p></o:p></p>

<p style=3D'margin-left:.5in'><font size=3D2 face=3D"Times New =
Roman"><span
style=3D'font-size:10.0pt'>In the case of self-signed revocation, I am =
not sure
why a CA would revoke itself.&nbsp; If the CA was truly operating as a =
&quot;rogue&quot;,
it would not revoke itself in order to keep whatever trust it still =
had.&nbsp;
Can you trust a CA that revokes itself?&nbsp; I am reminded of the old =
puzzle
in which you encounter two people at a crossroads, a truthteller and a =
liar.&nbsp;
You do not know which is which, and must ask one of them a question in =
order to
know if you should turn left or right to get to where you want to =
go.&nbsp; </span></font><o:p></o:p></p>

<p style=3D'margin-left:.5in'><font size=3D2 face=3D"Times New =
Roman"><span
style=3D'font-size:10.0pt'>--Peter</span></font> <o:p></o:p></p>

<p style=3D'margin-left:.5in'><font size=3D2 face=3D"Times New =
Roman"><span
style=3D'font-size:10.0pt'>---------------------------------------------=
-------------------
</span></font><br>
<font size=3D2><span style=3D'font-size:10.0pt'>&nbsp;Peter M.
Hesse&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
CygnaCom
Solutions, a division of</span></font> <br>
<font size=3D2><span style=3D'font-size:10.0pt'>&nbsp;Phone:
703-270-3523&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Entrust</span></font> <br>
<font size=3D2><span style=3D'font-size:10.0pt'>&nbsp;ICQ:&nbsp;&nbsp;
1942828&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Securing the Internet</span></font> <br>
<font size=3D2><span =
style=3D'font-size:10.0pt'>---------------------------------------------=
-------------------
</span></font><br>
<font size=3D2><span style=3D'font-size:10.0pt'>&quot;Pay no attention =
to what the
critics say; there has never been </span></font><br>
<font size=3D2><span style=3D'font-size:10.0pt'>a statue set up in =
honor of a
critic.&quot; --Jean Sibelius</span></font> <o:p></o:p></p>

<p class=3DMsoNormal style=3D'margin-left:.5in'><font size=3D3 =
face=3D"Times New Roman"><span
style=3D'font-size:12.0pt'><o:p>&nbsp;</o:p></span></font></p>

<p style=3D'margin-left:.5in'><font size=3D2 face=3D"Times New =
Roman"><span
style=3D'font-size:10.0pt'>&gt; This kind of problem would happen in a =
multi CA
products environment.</span></font> <br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; </span></font><br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; To avoid this =
problem,
interoperability test, operation, management</span></font> <br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; among multi CA =
products should
be done well,</span></font> <br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; or a RP should =
check the
status of intermediate self-signed </span></font><br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; =
certificates,</span></font> <br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; or a CA which =
cross-certifies
with other CAs should observe </span></font><br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; behavior =
of</span></font> <br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; other CAs, =
etc...?</span></font>
<br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; =
</span></font><o:p></o:p></p>

</div>

</body>

</html>

--Boundary_(ID_aof3KuOaA08d4bGQ37koiw)--


Received: by above.proper.com (8.11.6/8.11.3) id f7OFRPk17912 for ietf-pkix-bks; Fri, 24 Aug 2001 08:27:25 -0700 (PDT)
Received: from mail.phaos.com ([198.78.132.50]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f7OFRND17908 for <[e-mail]>; Fri, 24 Aug 2001 08:27:24 -0700 (PDT)
Received: from phaos_arik.phaos.com ([198.78.132.60]) by mail.phaos.com (8.9.3/8.9.3) with ESMTP id KAA17952; Fri, 24 Aug 2001 10:17:32 -0400
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Fri, 24 Aug 2001 11:34:04 -0400
To: Cristian Marinescu <[e-mail]>, [e-mail]
From: Ari Kermaier <[e-mail]>
Subject: RE: more tsa testing
In-Reply-To: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>

Christian,

Try using POST ( http://195.223.2.6:8080/  displays a page with some info 
about the TSA ).

Ari Kermaier
Sr. Software Engineer
Phaos Technology Corp.



>Hi
>
>This is what you offer under your web interface??
>(http://195.223.2.6:8080/timestamp)
>
>
><CUT>
>=================================================
>Method Not Allowed
>The requested method GET is not allowed for the URL /timestamp.
>
>
>--------------------------------------------------------------------------------
>
>Apache/1.3.9 Server at mulo.andxor.it Port 8080
>=================================================
><CUT>
>
>=========================
>D.I. Cristian Marinescu
>Software Developer
>OMICRON electronics GmbH
>Oberes Ried 1
>A-6833 Klaus
>Austria
>Tel: [phone]
>Fax: [phone]
>E-Mail: [e-mail]
>WWW: http://www.omicron.at
>
>
>
> > -----Original Message-----
> > From: tho [mailto:[e-mail]]
> > Sent: Friday, August 24, 2001 10:59 AM
> > To: [e-mail]
> > Subject: more tsa testing
> >
> >
> >
> > hello,
> >
> > if anyone would like another TSA to test here you can find ours:
> >
> >    http://195.223.2.6:8080
> >
> > it is a freebsd box with an apache module that acts as a frontend
> > and translator to a socket based protocol backend.
> >
> > the backend is still directly reached at address 195.223.2.6
> > port 3318 while if
> > you prefer the http interface you should go to
> > http://195.223.2.6:8080/timestamp
> >
> > of course let me know :)
> >
> > tho
> > --
> > (__)
> > (oo)
> >  \/-------\
> >   ||     | \
> >   ||---W||  *
> >



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f7OExnk16329 for ietf-pkix-bks; Fri, 24 Aug 2001 07:59:49 -0700 (PDT)
Received: from firewall.andxor.it (firewall.andxor.it [195.223.2.2]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f7OExkD16325 for <[e-mail]>; Fri, 24 Aug 2001 07:59:46 -0700 (PDT)
Received: from tho.andxor.com (tho.andxor.it [195.223.2.222]) by firewall.andxor.it (8.9.2/8.9.2) with ESMTP id QAA24289 for <[e-mail]>; Fri, 24 Aug 2001 16:59:46 +0200 (CEST) (envelope-from [e-mail])
Received: (from tho@localhost) by tho.andxor.com (8.9.3/8.9.3) id QAA33186 for [e-mail]; Fri, 24 Aug 2001 16:59:48 +0200 (CEST) (envelope-from tho)
Date: Fri, 24 Aug 2001 16:59:48 +0200
From: tho <[e-mail]>
To: [e-mail]
Subject: Re: more tsa testing
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2i
In-Reply-To: <[e-mail]>; from [e-mail] on Fri, Aug 24, 2001 at 03:28:14PM +0200
X-Operating-System: FreeBSD
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>

tho wrote:
> infact the time stamp request has to be PUT at that url :)

please replace PUT with POST ;)
(now we should be ok)

tho
-- 
(__)         
(oo)        
 \/-------\
  ||     | \  
  ||---W||  * 


Received: by above.proper.com (8.11.6/8.11.3) id f7ODSFs10036 for ietf-pkix-bks; Fri, 24 Aug 2001 06:28:15 -0700 (PDT)
Received: from firewall.andxor.it (firewall.andxor.it [195.223.2.2]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f7ODSCD10032 for <[e-mail]>; Fri, 24 Aug 2001 06:28:12 -0700 (PDT)
Received: from tho.andxor.com (tho.andxor.it [195.223.2.222]) by firewall.andxor.it (8.9.2/8.9.2) with ESMTP id PAA22866 for <[e-mail]>; Fri, 24 Aug 2001 15:28:12 +0200 (CEST) (envelope-from [e-mail])
Received: (from tho@localhost) by tho.andxor.com (8.9.3/8.9.3) id PAA32717 for [e-mail]; Fri, 24 Aug 2001 15:28:14 +0200 (CEST) (envelope-from tho)
Date: Fri, 24 Aug 2001 15:28:14 +0200
From: tho <[e-mail]>
To: [e-mail]
Subject: Re: more tsa testing
Message-ID: <[e-mail]>
References: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2i
In-Reply-To: <[e-mail]>; from [e-mail] on Fri, Aug 24, 2001 at 01:59:15PM +0200
X-Operating-System: FreeBSD
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>

Cristian Marinescu wrote:
> Hi
> 
> This is what you offer under your web interface??
> (http://195.223.2.6:8080/timestamp)
> 
> 
> <CUT>
> =================================================
> Method Not Allowed
>
> <CUT>

infact the time stamp request has to be PUT at that url :)

tho
-- 
(__)         
(oo)        
 \/-------\
  ||     | \  
  ||---W||  * 


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f7OBxVn02263 for ietf-pkix-bks; Fri, 24 Aug 2001 04:59:31 -0700 (PDT)
Received: from omicron.at (gw.omicron.at [212.183.10.29]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f7OBxTD02259 for <[e-mail]>; Fri, 24 Aug 2001 04:59:29 -0700 (PDT)
Received: by gw.omicron.at id <29579>; Fri, 24 Aug 2001 14:00:24 +0200
Message-Id: <[e-mail]>
From: Cristian Marinescu <[e-mail]>
To: tho <[e-mail]>, [e-mail]
Subject: RE: more tsa testing
Date: Fri, 24 Aug 2001 13:59:15 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.0.1460.8)
Content-Type: text/plain; charset="windows-1252"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>

Hi

This is what you offer under your web interface??
(http://195.223.2.6:8080/timestamp)


<CUT>
=================================================
Method Not Allowed
The requested method GET is not allowed for the URL /timestamp.


--------------------------------------------------------------------------------

Apache/1.3.9 Server at mulo.andxor.it Port 8080
=================================================
<CUT>

=========================
D.I. Cristian Marinescu
Software Developer
OMICRON electronics GmbH
Oberes Ried 1
A-6833 Klaus
Austria
Tel: [phone]
Fax: [phone]
E-Mail: [e-mail]
WWW: http://www.omicron.at



> -----Original Message-----
> From: tho [mailto:[e-mail]]
> Sent: Friday, August 24, 2001 10:59 AM
> To: [e-mail]
> Subject: more tsa testing
> 
> 
> 
> hello, 
> 
> if anyone would like another TSA to test here you can find ours:
> 
>    http://195.223.2.6:8080
> 
> it is a freebsd box with an apache module that acts as a frontend
> and translator to a socket based protocol backend.
> 
> the backend is still directly reached at address 195.223.2.6 
> port 3318 while if
> you prefer the http interface you should go to 
> http://195.223.2.6:8080/timestamp
> 
> of course let me know :)
> 
> tho
> -- 
> (__)         
> (oo)        
>  \/-------\
>   ||     | \  
>   ||---W||  * 
> 


Received: by above.proper.com (8.11.6/8.11.3) id f7O8xMi06719 for ietf-pkix-bks; Fri, 24 Aug 2001 01:59:22 -0700 (PDT)
Received: from firewall.andxor.it (firewall.andxor.it [195.223.2.2]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f7O8xID06701 for <[e-mail]>; Fri, 24 Aug 2001 01:59:19 -0700 (PDT)
Received: from tho.andxor.com (tho.andxor.it [195.223.2.222]) by firewall.andxor.it (8.9.2/8.9.2) with ESMTP id KAA21158 for <[e-mail]>; Fri, 24 Aug 2001 10:59:17 +0200 (CEST) (envelope-from [e-mail])
Received: (from tho@localhost) by tho.andxor.com (8.9.3/8.9.3) id KAA31727 for [e-mail]; Fri, 24 Aug 2001 10:59:18 +0200 (CEST) (envelope-from tho)
Date: Fri, 24 Aug 2001 10:59:18 +0200
From: tho <[e-mail]>
To: [e-mail]
Subject: more tsa testing
Message-ID: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2i
X-Operating-System: FreeBSD
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>

hello, 

if anyone would like another TSA to test here you can find ours:

   http://195.223.2.6:8080

it is a freebsd box with an apache module that acts as a frontend
and translator to a socket based protocol backend.

the backend is still directly reached at address 195.223.2.6 port 3318 while if
you prefer the http interface you should go to http://195.223.2.6:8080/timestamp

of course let me know :)

tho
-- 
(__)         
(oo)        
 \/-------\
  ||     | \  
  ||---W||  * 


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f7O8sDU05348 for ietf-pkix-bks; Fri, 24 Aug 2001 01:54:13 -0700 (PDT)
Received: from dolk.extundo.com (dolk.extundo.com [195.42.214.242]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f7O8s9D05338 for <[e-mail]>; Fri, 24 Aug 2001 01:54:10 -0700 (PDT)
Received: from barbar.josefsson.org (slipsten.extundo.com [195.42.214.241]) (authenticated) by dolk.extundo.com (8.11.3/8.11.3) with ESMTP id f7O8sAw29476; Fri, 24 Aug 2001 10:54:11 +0200
To: "David Cross" <[e-mail]>
Cc: <[e-mail]>
Subject: Re: draft minutes (using DNS for PKI support)
References: <[e-mail]>
From: Simon Josefsson <[e-mail]>
In-Reply-To: <[e-mail]> ("David Cross"'s message of "Thu, 23 Aug 2001 16:43:13 -0700")
Date: Fri, 24 Aug 2001 10:54:02 +0200
Message-ID: <[e-mail]>
Lines: 180
User-Agent: Gnus/5.090004 (Oort Gnus v0.04) Emacs/21.0.104
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>

David,

Yes it is.

However it updates the DNS domain owner name recommendations of RFC
2538, to be more "natural".  Basically this draft says that
certificates used for e.g. S/MIME should be stored under the simplest
translation of the email address of the user who owns the certificate.
RFC 2538 has more complex rules to derive a recommended owner name
which doesn't always make for a useful owner name.

I should point out that there are two problems with using the simplest
translation of the email address.  This is an open issue.  There are
two problems:

1) [e-mail] may have several certificates,
   e.g. S/MIME and PGP.  Storing them both under the same name wastes
   bandwidth and requires the client to intelligently select between
   them.

2) You cannot delegate management of the certificate hosting for the
   domain without also delegating management of the entire zone.
   E.g. say that example.com does not wish to host their certificates,
   but rather wishes that thirdparty.com hosts them.

Both problems may be solved by storing the certificates under a
subdomain, e.g. sjosefsson._smime.rsasecurity.com.  The owner name
will only be used by S/MIME certs, and it is possible to delegate
control of the entire subdomain to someone else.

Comments on this are most appreciated.

Regards Simon

"David Cross" <[e-mail]> writes:

> Sorry I missed the meeting.  Is this proposal based on RFC 2538?
>
>  
>
> Using DNS for PKI Support- Simon Josephson (RSA)
> ID published as a personal draft. Focuses on using DNS to
> hold certificates and CRLs. Works especially well for S/MINE, given
> typical DNS lookup re MX records. Question is whether PKIX should
> adopt this as a work item? Will discuss this on the list. (no slides)
>
>  
>
> http://www.ietf.org/rfc/rfc2538.txt?number=2538
>
>  
>
>  
>
>  
>
>  
>
> David B. Cross
>
>           
>           -----Original Message----- From: Stephen Kent
>      [mailto:[e-mail]] Sent: Tuesday, August 21, 2001 7:32 AM To:
>      [e-mail] Subject: draft minutes     
>      
>
>           Folks,
>                
>
>           Please review the meeting minutes and get back to me with any
>      corrections by 8/28, so that I can submit them to the IETF
>      secretariat by the end of the month.
>                
>
>           Thanks,
>                
>
>           Steve
>           --------
>                
>
>           PKIX WG Meeting 8/6/01 Edited by Steve Kent (WG co-chairs)     
>      The PKIX WG met once during the 51st IETF. A total of approximately
>      153 individuals participated in the meeting.     
>      
>      Tim quickly reviewed the agenda and document status, noting that
>      there are many I-Ds in progress. (see slides)     
>      Two new RFCs in the editor's queue:         RFC xxxx       
>      Timestamp Protocol       RFC xxxx        Attribute Certificate
>      Profile     
>      In the IESG Review Process:         PKIX Certificate and CRL Profile
>      (a.k.a., son-of-2459)   Public Key Algorithms and Identifiers for
>      the PKIX Certificate profile     
>      Soon to be Submitted to IESG:      PKIX Roadmap     Repository
>      Locator Service     
>      In WG Last Call:       none     
>      Close to WG last call:       Certificate Management Protocol (RFC
>      2510bis)    Certificate Request Message Framework (RFC 2511bis)     
>      Transport Protocols for CMP      Online Certificate Status Protocol
>      (OCSP v2)     
>      New Work:     
>      
>      Logotype Certificates - Stefan Santesson (AddTrust)         Notion
>      is to embed references to logos in certificates, for CAs or for
>      EEs,  to allow display of the logo as part of certificate
>      processing. Argument is that people relate to logos in the physical
>      world, and don't display certificate contents, so this is a way to
>      bring branding into PKIs. Major concern is that people could be
>      mislead by certificates issued by a CA that binds inappropriate
>      logos to certificates it issues, e.g., there is no way to constrain
>      logo references the same way we can constrain names. Proposal is to
>      create a new extension for carrying a pointer (URL) to the logo
>      image, an indication of the image type, and a hash of the
>      image. (see slides)     
>      Supplemental Algorithms - Ari Singer (NTRU) New work item, to
>      contain specs for a set of algorithms that COULD be used with PKIX
>      data structures. Support for these algorithms is not mandated, but
>      this document will provide a reference for these supplemental
>      algorithms. Note need to include appropriate intellectual property
>      warnings for proprietary algorithms, and to distinguish between
>      algorithms that are standards, vs, proprietary.  (see slides)     
>      PKI Disaster Recovery - Denis Pinkas (Integris)   The goal of this
>      new work is to create an informational RFC which addresses how to
>      deal with compromise or loss of use of a CA, AA, or TSA
>      key. Different requirements arise for EE signature keys vs. EE
>      encryption keys, and these are addressed separately. (see slides)     
>      Using DNS for PKI Support- Simon Josephson (RSA) ID published as a
>      personal draft. Focuses on using DNS to hold certificates and
>      CRLs. Works especially well for S/MINE, given typical DNS lookup re
>      MX records. Question is whether PKIX should adopt this as a work
>      item? Will discuss this on the list. (no slides)     
>      
>      Ongoing Work:     
>      LDAP V3 Profile and Certificate Matching Rules - David Chadwick
>      (Univ of Salford) Profile going well, looking for feedback before
>      publishing as RFC. Matching rules work not as far along, but
>      implementation work now funded at Salford, which will help progress.     
>      CMC Update - Jim Schaad (Soaring Hawk Consulting)         Core
>      functions largely unchanged, e.g., ASN syntax and processing rules
>      wil be static. New set of CMC documents being issued, breaking into
>      multiple pieces to allow easier progression of pieces, e.g.,
>      transport, archive (also used by S/MIME), compliance
>      document. VeriSign hosted interoperability testing covering a large
>      number of protocol features. Several issues were uncovered during
>      testing. (see slides)     
>      CMP Update - Carlisle Adams (Entrust)         Interoperability
>      testing yielded clarifications and the document is now ready to go
>      to Draft Standard status.     
>      Proxy Certificates - Stephen Tuecke (Argonne Labs)   Revised ID has
>      been published. Related draft in TLS WG. Not many attendees have
>      read this draft, according to a show of hands.  Because it requires
>      changes to certificate path validation, there is
>           a significant question about whether these changes should be
>      part of the base standards, or if this processing is a separate step
>      to be performed after standard path validation processing. (see
>      slides)     
>      OCSPv2 - Michael Myers (VeriSign)         Authors have decided to
>      publish as experimental for now. (no slides)     
>      SCVP - Ambarish Malpani (ValiCert)   No significant changes for
>      now. (no slides)     
>      DPD/DPV - Denis Pinkas (Integris)     New ID posed to
>      list. Incorporate new approach to DPV/DPD, using 3 protocols: DPV,
>      DPD, and a separate protocol for management of policy data used for
>      validation or discovery. This allows the DPD and DPV protocols to be
>      smaller and simpler, because the management of parameters used for
>      DPD/DPV is part of a separate protocol. The management protocol
>      might not be implemented on many clients, e.g., thin
>      clients. References to the parameters (policy) used for validation
>      are OIDs, and there is a provision for a client to NOT specify a
>      policy, but have a server employ a default policy and return that to
>      the user. Extensive use of hashes of ancillary values to keep
>      messages brief, but allow checking by client. DPV proposal allows
>      for validation re current time, or past time (re-validation).  DPV
>      can return four answers, reflecting level of knowledge available to
>      the server, especially with regard to revocation data. DPD and
>      management protocol also presented in detail. (see slides)     
>      Policy Requirements for Timestamping  Authorities- Denis Pinkas
>      (Integris)         Discussion of this ETSI document and solicitation
>      of comments. (see slides)
> 



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f7NNhGq20442 for ietf-pkix-bks; Thu, 23 Aug 2001 16:43:16 -0700 (PDT)
Received: from INET-VRS-07.redmond.corp.microsoft.com ([131.107.3.51]) by above.proper.com (8.11.6/8.11.3) with SMTP id f7NNhFD20438 for <[e-mail]>; Thu, 23 Aug 2001 16:43:15 -0700 (PDT)
Received: from 157.54.9.104 by INET-VRS-07.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Thu, 23 Aug 2001 16:43:13 -0700
Received: from red-msg-02.redmond.corp.microsoft.com ([157.54.12.70]) by inet-imc-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Thu, 23 Aug 2001 16:43:13 -0700
X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="------------InterScan_NT_MIME_Boundary"
Subject: RE: draft minutes (using DNS for PKI support)
Date: Thu, 23 Aug 2001 16:43:13 -0700
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: draft minutes (using DNS for PKI support)
Thread-Index: AcEqT0HO0m+EL9CTQ9qo2u3rvs4w5QB3bJ8g
From: "David Cross" <[e-mail]>
To: <[e-mail]>
X-OriginalArrivalTime: 23 Aug 2001 23:43:13.0273 (UTC) FILETIME=[5FA2A690:01C12C2D]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>

This is a multi-part message in MIME format.

--------------InterScan_NT_MIME_Boundary
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C12C2D.5FA69E34"

------_=_NextPart_001_01C12C2D.5FA69E34
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Sorry I missed the meeting.  Is this proposal based on RFC 2538?
=20
Using DNS for PKI Support- Simon Josephson (RSA)
ID published as a personal draft. Focuses on using DNS to
hold certificates and CRLs. Works especially well for S/MINE, given
typical DNS lookup re MX records. Question is whether PKIX should
adopt this as a work item? Will discuss this on the list. (no slides)

=20
http://www.ietf.org/rfc/rfc2538.txt?number=3D2538
=20
=20
=20
=20

David B. Cross


	-----Original Message-----
	From: Stephen Kent [mailto:[e-mail]]=20
	Sent: Tuesday, August 21, 2001 7:32 AM
	To: [e-mail]
	Subject: draft minutes
=09
=09
	Folks,
=09
=09
	Please review the meeting minutes and get back to me with any
corrections by 8/28, so that I can submit them to the IETF secretariat
by the end of the month.
=09
=09
	Thanks,
=09
=09
	Steve
	--------
=09
=09
	PKIX WG Meeting 8/6/01
	Edited by Steve Kent (WG co-chairs)
=09
	The PKIX WG met once during the 51st IETF. A total of
approximately 153
	individuals participated in the meeting.
=09
=09
	Tim quickly reviewed the agenda and document status, noting that
there are many
	I-Ds in progress. (see slides)
=09
	Two new RFCs in the editor's queue:
	        RFC xxxx        Timestamp Protocol
	      RFC xxxx        Attribute Certificate Profile
=09
	In the IESG Review Process:
	        PKIX Certificate and CRL Profile (a.k.a., son-of-2459)
	  Public Key Algorithms and Identifiers for the PKIX Certificate
profile
=09
	Soon to be Submitted to IESG:
	     PKIX Roadmap
	    Repository Locator Service
=09
	In WG Last Call:
	      none
=09
	Close to WG last call:
	      Certificate Management Protocol (RFC 2510bis)
	   Certificate Request Message Framework (RFC 2511bis)
	     Transport Protocols for CMP
	     Online Certificate Status Protocol (OCSP v2)
=09
	New Work:
=09
=09
	Logotype Certificates - Stefan Santesson (AddTrust)
	        Notion is to embed references to logos in certificates,
for
	CAs or for EEs,  to allow display of the logo as part of
certificate
	processing. Argument is that people relate to logos in the
physical
	world, and don't display certificate contents, so this is a way
to
	bring branding into PKIs. Major concern is that people could be
	mislead by certificates issued by a CA that binds inappropriate
logos
	to certificates it issues, e.g., there is no way to constrain
logo
	references the same way we can constrain names. Proposal is to
create
	a new extension for carrying a pointer (URL) to the logo image,
an
	indication of the image type, and a hash of the image. (see
slides)
=09
	Supplemental Algorithms - Ari Singer (NTRU)
	New work item, to contain specs for a set of algorithms that
	COULD be used with PKIX data structures. Support for these
algorithms
	is not mandated, but this document will provide a reference for
these
	supplemental algorithms. Note need to include appropriate
	intellectual property warnings for proprietary algorithms, and
to
	distinguish between algorithms that are standards, vs,
proprietary.
	(see slides)
=09
	PKI Disaster Recovery - Denis Pinkas (Integris)
	  The goal of this new work is to create an informational RFC
	which addresses how to deal with compromise or loss of use of a
CA,
	AA, or TSA key. Different requirements arise for EE signature
keys
	vs. EE encryption keys, and these are addressed separately. (see
	slides)
=09
	Using DNS for PKI Support- Simon Josephson (RSA)
	ID published as a personal draft. Focuses on using DNS to
	hold certificates and CRLs. Works especially well for S/MINE,
given
	typical DNS lookup re MX records. Question is whether PKIX
should
	adopt this as a work item? Will discuss this on the list. (no
slides)
=09
=09
	Ongoing Work:
=09
	LDAP V3 Profile and Certificate Matching Rules - David Chadwick
(Univ
	of Salford)
	Profile going well, looking for feedback before publishing as
	RFC. Matching rules work not as far along, but implementation
work
	now funded at Salford, which will help progress.
=09
	CMC Update - Jim Schaad (Soaring Hawk Consulting)
	        Core functions largely unchanged, e.g., ASN syntax and
	processing rules wil be static. New set of CMC documents being
	issued, breaking into multiple pieces to allow easier
progression of
	pieces, e.g., transport, archive (also used by S/MIME),
compliance
	document. VeriSign hosted interoperability testing covering a
large
	number of protocol features. Several issues were uncovered
during
	testing. (see slides)
=09
	CMP Update - Carlisle Adams (Entrust)
	        Interoperability testing yielded clarifications and the
	document is now ready to go to Draft Standard status.
=09
	Proxy Certificates - Stephen Tuecke (Argonne Labs)
	  Revised ID has been published. Related draft in TLS WG. Not
	many attendees have read this draft, according to a show of
hands.
	Because it requires changes to certificate path validation,
there is
	a significant question about whether these changes should be
part of
	the base standards, or if this processing is a separate step to
be
	performed after standard path validation processing. (see
slides)
=09
	OCSPv2 - Michael Myers (VeriSign)
	        Authors have decided to publish as experimental for now.
(no slides)
=09
	SCVP - Ambarish Malpani (ValiCert)
	  No significant changes for now. (no slides)
=09
	DPD/DPV - Denis Pinkas (Integris)
	    New ID posed to list. Incorporate new approach to DPV/DPD,
	using 3 protocols: DPV, DPD, and a separate protocol for
management
	of policy data used for validation or discovery. This allows the
DPD
	and DPV protocols to be smaller and simpler, because the
management
	of parameters used for DPD/DPV is part of a separate protocol.
The
	management protocol might not be implemented on many clients,
e.g.,
	thin clients. References to the parameters (policy) used for
	validation are OIDs, and there is a provision for a client to
NOT
	specify a policy, but have a server employ a default policy and
	return that to the user. Extensive use of hashes of ancillary
values
	to keep messages brief, but allow checking by client. DPV
proposal
	allows for validation re current time, or past time
(re-validation).
	DPV can return four answers, reflecting level of knowledge
available
	to the server, especially with regard to revocation data. DPD
and
	management protocol also presented in detail. (see slides)
=09
	Policy Requirements for Timestamping  Authorities- Denis Pinkas
(Integris)
	        Discussion of this ETSI document and solicitation of
	comments. (see slides)


------_=_NextPart_001_01C12C2D.5FA69E34
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD><TITLE>Message</TITLE>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Dus-ascii">
<STYLE type=3Dtext/css>BLOCKQUOTE {
	MARGIN-TOP: 0px; MARGIN-BOTTOM: 0px
}
DL {
	MARGIN-TOP: 0px; MARGIN-BOTTOM: 0px
}
UL {
	MARGIN-TOP: 0px; MARGIN-BOTTOM: 0px
}
OL {
	MARGIN-TOP: 0px; MARGIN-BOTTOM: 0px
}
LI {
	MARGIN-TOP: 0px; MARGIN-BOTTOM: 0px
}
</STYLE>

<META content=3D"MSHTML 6.00.2600.0" name=3DGENERATOR></HEAD>
<BODY>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN =
class=3D228134023-23082001>Sorry=20
I missed the meeting.&nbsp; Is this proposal based on RFC=20
2538?</SPAN></FONT></DIV>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN=20
class=3D228134023-23082001></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN =
class=3D228134023-23082001><FONT=20
face=3DCourier color=3D#000000 size=3D5>Using DNS for PKI Support- Simon =
Josephson=20
(RSA)<BR><X-TAB></X-TAB>ID published as a personal draft. Focuses on =
using DNS=20
to<BR>hold certificates and CRLs. Works especially well for S/MINE,=20
given<BR>typical DNS lookup re MX records. Question is whether PKIX=20
should<BR>adopt this as a work item? Will discuss this on the list. (no=20
slides)</FONT><BR></SPAN></FONT></DIV>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN=20
class=3D228134023-23082001></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN =
class=3D228134023-23082001><A=20
href=3D"http://www.ietf.org/rfc/rfc2538.txt?number=3D2538">http://www.iet=
f.org/rfc/rfc2538.txt?number=3D2538</A></SPAN></FONT></DIV>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN=20
class=3D228134023-23082001></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN=20
class=3D228134023-23082001></SPAN></FONT>&nbsp;</DIV>
<DIV>&nbsp;</DIV>
<DIV>&nbsp;</DIV>
<DIV align=3Dleft>
<P dir=3Dltr align=3Dleft><B><FONT face=3DArial size=3D1>David B.=20
Cross</FONT></B><BR></P></DIV>
<BLOCKQUOTE dir=3Dltr style=3D"MARGIN-RIGHT: 0px">
  <DIV></DIV>
  <DIV class=3DOutlookMessageHeader lang=3Den-us dir=3Dltr =
align=3Dleft><FONT=20
  face=3DTahoma size=3D2>-----Original Message-----<BR><B>From:</B> =
Stephen Kent=20
  [mailto:[e-mail]] <BR><B>Sent:</B> Tuesday, August 21, 2001 7:32=20
  AM<BR><B>To:</B> [e-mail]<BR><B>Subject:</B> draft=20
  minutes<BR><BR></FONT></DIV>
  <DIV><FONT color=3D#000000>Folks,</FONT></DIV>
  <DIV><FONT color=3D#000000><BR></FONT></DIV>
  <DIV><FONT color=3D#000000>Please review the meeting minutes and get =
back to me=20
  with any corrections by 8/28, so that I can submit them to the IETF=20
  secretariat by the end of the month.</FONT></DIV>
  <DIV><FONT color=3D#000000><BR></FONT></DIV>
  <DIV><FONT color=3D#000000>Thanks,</FONT></DIV>
  <DIV><FONT color=3D#000000><BR></FONT></DIV>
  <DIV><FONT color=3D#000000>Steve</FONT></DIV>
  <DIV><FONT color=3D#000000>--------</FONT></DIV>
  <DIV><FONT face=3DCourier color=3D#000000 size=3D+2><BR></FONT></DIV>
  <DIV><FONT face=3DCourier color=3D#000000 size=3D+2>PKIX WG Meeting =
8/6/01<BR>Edited=20
  by Steve Kent (WG co-chairs)<BR><BR>The PKIX WG met once during the =
51st IETF.=20
  A total of approximately 153<BR>individuals participated in the=20
  meeting.<BR><BR><BR>Tim quickly reviewed the agenda and document =
status,=20
  noting that there are many<BR>I-Ds in progress. (see =
slides)<BR><BR>Two new=20
  RFCs in the editor's=20
  queue:<BR><X-TAB>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
</X-TAB>RFC=20
  xxxx<X-TAB>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
</X-TAB>Timestamp=20
  Protocol<BR><X-TAB>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </X-TAB>RFC=20
  xxxx<X-TAB>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
</X-TAB>Attribute=20
  Certificate Profile<BR><BR>In the IESG Review=20
  Process:<BR><X-TAB>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
</X-TAB>PKIX=20
  Certificate and CRL Profile (a.k.a., son-of-2459)<BR><X-TAB>&nbsp;=20
  </X-TAB>Public Key Algorithms and Identifiers for the PKIX Certificate =

  profile<BR><BR>Soon to be Submitted to=20
  IESG:<BR><X-TAB>&nbsp;&nbsp;&nbsp;&nbsp; </X-TAB>PKIX=20
  Roadmap<BR><X-TAB>&nbsp;&nbsp;&nbsp; </X-TAB>Repository Locator=20
  Service<BR><BR>In WG Last =
Call:<BR><X-TAB>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  </X-TAB>none<BR><BR>Close to WG last=20
  call:<BR><X-TAB>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </X-TAB>Certificate =
Management=20
  Protocol (RFC 2510bis)<BR><X-TAB>&nbsp;&nbsp; </X-TAB>Certificate =
Request=20
  Message Framework (RFC 2511bis)<BR><X-TAB>&nbsp;&nbsp;&nbsp;&nbsp;=20
  </X-TAB>Transport Protocols for CMP<BR><X-TAB>&nbsp;&nbsp;&nbsp;&nbsp; =

  </X-TAB>Online Certificate Status Protocol (OCSP v2)<BR><BR>New=20
  Work:<BR><BR><BR>Logotype Certificates - Stefan Santesson=20
  (AddTrust)<BR><X-TAB>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
</X-TAB>Notion=20
  is to embed references to logos in certificates, for<BR>CAs or for =
EEs,&nbsp;=20
  to allow display of the logo as part of certificate<BR>processing. =
Argument is=20
  that people relate to logos in the physical<BR>world, and don't =
display=20
  certificate contents, so this is a way to<BR>bring branding into PKIs. =
Major=20
  concern is that people could be<BR>mislead by certificates issued by a =
CA that=20
  binds inappropriate logos<BR>to certificates it issues, e.g., there is =
no way=20
  to constrain logo<BR>references the same way we can constrain names. =
Proposal=20
  is to create<BR>a new extension for carrying a pointer (URL) to the =
logo=20
  image, an<BR>indication of the image type, and a hash of the image. =
(see=20
  slides)<BR><BR>Supplemental Algorithms - Ari Singer=20
  (NTRU)<BR><X-TAB></X-TAB>New work item, to contain specs for a set of=20
  algorithms that<BR>COULD be used with PKIX data structures. Support =
for these=20
  algorithms<BR>is not mandated, but this document will provide a =
reference for=20
  these<BR>supplemental algorithms. Note need to include=20
  appropriate<BR>intellectual property warnings for proprietary =
algorithms, and=20
  to<BR>distinguish between algorithms that are standards, vs,=20
  proprietary.<BR>(see slides)<BR><BR>PKI Disaster Recovery - Denis =
Pinkas=20
  (Integris)<BR><X-TAB>&nbsp; </X-TAB>The goal of this new work is to =
create an=20
  informational RFC<BR>which addresses how to deal with compromise or =
loss of=20
  use of a CA,<BR>AA, or TSA key. Different requirements arise for EE =
signature=20
  keys<BR>vs. EE encryption keys, and these are addressed separately.=20
  (see<BR>slides)<BR><BR>Using DNS for PKI Support- Simon Josephson=20
  (RSA)<BR><X-TAB></X-TAB>ID published as a personal draft. Focuses on =
using DNS=20
  to<BR>hold certificates and CRLs. Works especially well for S/MINE,=20
  given<BR>typical DNS lookup re MX records. Question is whether PKIX=20
  should<BR>adopt this as a work item? Will discuss this on the list. =
(no=20
  slides)<BR><BR><BR>Ongoing Work:<BR><BR>LDAP V3 Profile and =
Certificate=20
  Matching Rules - David Chadwick (Univ<BR>of =
Salford)<BR><X-TAB></X-TAB>Profile=20
  going well, looking for feedback before publishing as<BR>RFC. Matching =
rules=20
  work not as far along, but implementation work<BR>now funded at =
Salford, which=20
  will help progress.<BR><BR>CMC Update - Jim Schaad (Soaring Hawk=20
  Consulting)<BR><X-TAB>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
</X-TAB>Core=20
  functions largely unchanged, e.g., ASN syntax and<BR>processing rules =
wil be=20
  static. New set of CMC documents being<BR>issued, breaking into =
multiple=20
  pieces to allow easier progression of<BR>pieces, e.g., transport, =
archive=20
  (also used by S/MIME), compliance<BR>document. VeriSign hosted=20
  interoperability testing covering a large<BR>number of protocol =
features.=20
  Several issues were uncovered during<BR>testing. (see =
slides)<BR><BR>CMP=20
  Update - Carlisle Adams=20
  (Entrust)<BR><X-TAB>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  </X-TAB>Interoperability testing yielded clarifications and =
the<BR>document is=20
  now ready to go to Draft Standard status.<BR><BR>Proxy Certificates - =
Stephen=20
  Tuecke (Argonne Labs)<BR><X-TAB>&nbsp; </X-TAB>Revised ID has been =
published.=20
  Related draft in TLS WG. Not<BR>many attendees have read this draft, =
according=20
  to a show of hands.<BR>Because it requires changes to certificate path =

  validation, there is</FONT></DIV>
  <DIV><FONT face=3DCourier color=3D#000000 size=3D+2>a significant =
question about=20
  whether these changes should be part of<BR>the base standards, or if =
this=20
  processing is a separate step to be<BR>performed after standard path=20
  validation processing. (see slides)<BR><BR>OCSPv2 - Michael Myers=20
  (VeriSign)<BR><X-TAB>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  </X-TAB>Authors have decided to publish as experimental for now. (no=20
  slides)<BR><BR>SCVP - Ambarish Malpani (ValiCert)<BR><X-TAB>&nbsp; =
</X-TAB>No=20
  significant changes for now. (no slides)<BR><BR>DPD/DPV - Denis Pinkas =

  (Integris)<BR><X-TAB>&nbsp;&nbsp;&nbsp; </X-TAB>New ID posed to list.=20
  Incorporate new approach to DPV/DPD,<BR>using 3 protocols: DPV, DPD, =
and a=20
  separate protocol for management<BR>of policy data used for validation =
or=20
  discovery. This allows the DPD<BR>and DPV protocols to be smaller and =
simpler,=20
  because the management<BR>of parameters used for DPD/DPV is part of a =
separate=20
  protocol. The<BR>management protocol might not be implemented on many =
clients,=20
  e.g.,<BR>thin clients. References to the parameters (policy) used=20
  for<BR>validation are OIDs, and there is a provision for a client to=20
  NOT<BR>specify a policy, but have a server employ a default policy=20
  and<BR>return that to the user. Extensive use of hashes of ancillary=20
  values<BR>to keep messages brief, but allow checking by client. DPV=20
  proposal<BR>allows for validation re current time, or past time=20
  (re-validation).<BR>DPV can return four answers, reflecting level of =
knowledge=20
  available<BR>to the server, especially with regard to revocation data. =
DPD=20
  and<BR>management protocol also presented in detail. (see=20
  slides)<BR><BR>Policy Requirements for Timestamping&nbsp; Authorities- =
Denis=20
  Pinkas (Integris)<BR><X-TAB>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =

  </X-TAB>Discussion of this ETSI document and solicitation =
of<BR>comments. (see=20
  slides)</FONT></DIV></BLOCKQUOTE></BODY></HTML>
=00
------_=_NextPart_001_01C12C2D.5FA69E34--

--------------InterScan_NT_MIME_Boundary--



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f7NFc6M25429 for ietf-pkix-bks; Thu, 23 Aug 2001 08:38:06 -0700 (PDT)
Received: from SOTTMXS01.entrust.com (gatekeeper.entrust.com [204.101.128.170]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f7NFc4D25419 for <[e-mail]>; Thu, 23 Aug 2001 08:38:04 -0700 (PDT)
Received: by SOTTMXS01.entrust.com with Internet Mail Service (5.5.2650.21) id <Q8L2CKRN>; Thu, 23 Aug 2001 11:37:55 -0400
Message-ID: <[e-mail]>
From: Peter Hesse <[e-mail]>
To: "'Hiroyuki Sakakibara'" <[e-mail]>, "Housley, Russ" <[e-mail]>, Peter Hesse <[e-mail]>
Cc: [e-mail]
Subject: RE: about validation of intermediate self-signed certs in a path
Date: Thu, 23 Aug 2001 11:26:11 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C12BE7.F05A1600"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C12BE7.F05A1600
Content-Type: text/plain;
	charset="iso-2022-jp"

Hiroyuki,

Thank you for your detailed explanations of two cases in which validating
the self-signed certificate within the path become valuable.

My main concern is with operational systems.  I've been on development teams
for numerous CA and certificate validation products, and been involved with
interoperability testing with many other products.  I have gained the
following insights on the subject of self-signed certificates:

- Not all CA products generate self-signed certificates to be treated as a
certificate within a certificate path.  By this, I mean that not all
products are concerned with setting extensions such as constraints and
policies so that a path containing this certificate would successfully
validate.  Many CA products issue a signed name and public key in the
simplest form possible.

- Not all certificate validation systems place the trust root self-signed
certificate within the path for validation.  This is the guidance provided
by RFC 2459, but is changing in son-of-2459.  This is partially because of
the bullet above.

- Not all certificate validation systems allow any self-signed certificates
to appear as intermediate certificates in paths.  This is primarily for two
reasons: 1) Preventing same subject name and public key from appearing twice
in a path prevents loops, and 2) some argue that the same public key
appearing twice in the path dilutes the trust chain.

Since these are operational realities, I would be concerned with giving
strong guidance within son-of-2459 about whether or not self-signed
certificates should or should not appear within certificate paths.  That
said, I do think we could some mention of the fact that including or not
including them can change the results of validation.  I am primarily
concerned with making sure that son-of-2459 does not allow trust root
self-signed certificates at the start of paths, and not so concerned about
eliminating self-signed certificates from ever appearing in a path.

--Peter

----------------------------------------------------------------
 Peter M. Hesse            CygnaCom Solutions, a division of
 Phone: [phone]                   Entrust
 ICQ:   1942828                 Securing the Internet
----------------------------------------------------------------
"Pay no attention to what the critics say; there has never been
a statue set up in honor of a critic." --Jean Sibelius


-----Original Message-----
From: Hiroyuki Sakakibara [mailto:[e-mail]]
Sent: Thursday, August 23, 2001 5:52 AM
To: Housley, Russ; Peter Hesse
Cc: [e-mail]; [e-mail]; [e-mail];
[e-mail]; [e-mail]
Subject: about validation of intermediate self-signed certs in a path



Peter

Thank you for your comments.

Peter Hesse wrote:
>TR -> A -> B -> (B self signed) -> C -> EE
>Let's say that A->B has a notAfter date of 12/31/2002,
>(B self signed) has a notAfter date of 12/31/2001, and B->C has a notAfter
date of 12/31/2002.
>If this path was developed and validated, the path would be invalid
>if the current date was after  12/31/2001.

Excuse me that the example was not good.

again, (sorry for a long mail)

[example]

* A, B, C are CAs
* A has a key pair whose validity term is 1 years
* B has a key pair whose validity term is 1 years
* C has a key pair whose validity term is 1 years


     2001/01/01  06/01   2002/01/01    06/01  2003/01/01
        +-----------+-----------+-----------+---------+

A->B                     <----------------------->

B->B <----------------------><--------------------->
                        (1)                                 (2)

B->C                     <----------------------->


B issues a self-signed cert (1), notBefore 2001/01/01 notAfter 2001/12/31.
B is going to issue a new self-signed cert (2) which
containts the public key in (1), notBefore 2002/01/01 notAfter 2002/12/31,
if the public key in (1) has no problem on 2001/12/31.
( notBefore of (2) may be 2001/01/01 )
B announces the schedule of issuance of (2) to A and C beforehand.

A issues a certificate to B, notBefore 2001/06/01 notAfter 2002/5/31.
A expects that B is going to issue (2), hence, A can issue A->B
whose notAfter excesses notAfter of (1) and the validity term
of A->B is exactly 1 year.

B issues a certificate to C, notBefore 2001/06/01 notAfter 2002/05/31.
Because B is going to issue (2) on 2002/01/01, hence B can issue
B->C whose notAfter excesses notAfter of (1).

In this example, B can use the same public key continuously, in (1) and (2).
As a result, A can issue a cert to B whose validity term is always 1 year,
whennever A issues.
B can issue a cert to C whose validity term is always 1 year,
whennever B issues, also.

I suppose that some PKI systems adopt this kind of cert issuance.


[problem]

However, assume that B does not issues (2), by incident,
or rough operation etc....

if on 2002/01/02 a validation software can constructs,

"A->B, B->C" path only,

hence the software could not notice that the trouble
with issuance of (2).
Therefore it is not certain that the B's public key
is good or not.
In order to avoid this situation, A has to observe that
B issues and published (2) in LDAP etc about 2002/01/01
and if B does not issues (2), A should alarm that.

If the software constructs "A->B, B->B(1), B->C" path,
it can notice that the path is wrong, because B->B(1) is expired,
and would try to construct another path, "A->B, B->B(2), B->C"
however, B->B(2) is not present, so, it would give up, or
construct "A->B, B->C", eventhough it may be invalid.

Therefore, the result of validation of the path "A->B, B->C"
and the result of validation of the path "A->B, B->B(2), B->C"
are not identical in this case.


[revocation example]

Peter Hesse wrote:
>In the case of self-signed revocation, I am not sure why a CA would revoke
itself.  If the >CA was truly operating as a "rogue", it would not revoke
itself in order to keep whatever >trust it still had.  Can you trust a CA
that revokes itself?  I am reminded of the old puzzle >in which you
encounter two people at a crossroads, a truthteller and a liar.  You do not
>know which is which, and must ask one of them a question in order to know
if you should >turn left or right to get to where you want to go

I agree with you.
But in the case that A issues a cross certificate to B and
B issues a self-signed cert to itself,
not only B but also A would do rough operation.

If B is a rough CA, as you mentioned, B would not revoke itself and not
announce
the revocation status of B to A, then a path could be validated as good.

If A is a rough CA, even though B asks A to revoke the cross-cert from A to
B,
A would not, then a path could be valdiated as good also.

I will show an example where a validation software
would had better check revocation status of self-signed certificates.
( this is an example of latter case.)

1. B's private key was revoked.

2. B issues a CRL asserting "B is revoked"
   with its revoked privatekey.

3. B announces its revocaton to other CAs, then other CAs
   should revoke cross-certs to B.

If the procedure 3 is done immediately, the procedure 2 is not neccesarry.
But if not, because of trouble of CA sysytems or rough operateion what else,
I suppose that adoption of the procedure 2 is a good idea.

Actually, there is a risk that a bad person who knows B's private key issues
a fake CRL asserting "B is OK(not on the list)",
and a validation software uses the fake one accidentally.

A validation software can not distinguish that an obtained CRL is issued by
B
or by the bad person,
however if the software obtains the correct CRL issued by "B" first or
obtains both the correct one and the fake one, the software can
notice that the revocation of B, even though the procedure 3 is not done
immediately.

Offcourse, it is not able to prevent a validation software from obtaining
only the fake CRL first, however issuing a CRL in the procedure 2 could
reduce a risk that the software ALWAYS referes only the fake one.


[my interpretation]

I think that a validation software could gain some additional benefits
by checking self-signed certificates in a path in the case of some
PKI system such as the shown example.

However when mis-operations or troubles among CAs seldom happen,
a validation software would not need to check them.

So, section 6.1, considering your comments,
my interpretation became as follows,

* validating a path without self-signed certs ONLY -> GOOD
* validating a path with self-signed certs ONLY -> GOOD
* validating BOTH paths -> GOOD

actually, I agree with that most implementations apply the first one
because of its simplicity as you mentioned.

Also, I think that any guidline of a recommended
path pattern (such as the first one) is useful.

---------------------------------------
Hiroyuki Sakakibara
MITSUBISHI ELECTRIC CORPORATION
Information Technology R&D Center
5-1-1 Ofuna, Kamakura, Kanagawa, Japan
PHONE: [phone]
FAX:   [phone]
E-mail : [e-mail]

------_=_NextPart_001_01C12BE7.F05A1600
Content-Type: text/html;
	charset="iso-2022-jp"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-2022-jp">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2652.35">
<TITLE>RE: about validation of intermediate self-signed certs in a =
path</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>Hiroyuki,</FONT>
</P>

<P><FONT SIZE=3D2>Thank you for your detailed explanations of two cases =
in which validating the self-signed certificate within the path become =
valuable.</FONT></P>

<P><FONT SIZE=3D2>My main concern is with operational systems.&nbsp; =
I've been on development teams for numerous CA and certificate =
validation products, and been involved with interoperability testing =
with many other products.&nbsp; I have gained the following insights on =
the subject of self-signed certificates:</FONT></P>

<P><FONT SIZE=3D2>- Not all CA products generate self-signed =
certificates to be treated as a certificate within a certificate =
path.&nbsp; By this, I mean that not all products are concerned with =
setting extensions such as constraints and policies so that a path =
containing this certificate would successfully validate.&nbsp; Many CA =
products issue a signed name and public key in the simplest form =
possible.</FONT></P>

<P><FONT SIZE=3D2>- Not all certificate validation systems place the =
trust root self-signed certificate within the path for =
validation.&nbsp; This is the guidance provided by RFC 2459, but is =
changing in son-of-2459.&nbsp; This is partially because of the bullet =
above.</FONT></P>

<P><FONT SIZE=3D2>- Not all certificate validation systems allow any =
self-signed certificates to appear as intermediate certificates in =
paths.&nbsp; This is primarily for two reasons: 1) Preventing same =
subject name and public key from appearing twice in a path prevents =
loops, and 2) some argue that the same public key appearing twice in =
the path dilutes the trust chain.</FONT></P>

<P><FONT SIZE=3D2>Since these are operational realities, I would be =
concerned with giving strong guidance within son-of-2459 about whether =
or not self-signed certificates should or should not appear within =
certificate paths.&nbsp; That said, I do think we could some mention of =
the fact that including or not including them can change the results of =
validation.&nbsp; I am primarily concerned with making sure that =
son-of-2459 does not allow trust root self-signed certificates at the =
start of paths, and not so concerned about eliminating self-signed =
certificates from ever appearing in a path.</FONT></P>

<P><FONT SIZE=3D2>--Peter</FONT>
</P>

<P><FONT =
SIZE=3D2>---------------------------------------------------------------=
-</FONT>
<BR><FONT SIZE=3D2>&nbsp;Peter M. =
Hesse&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
CygnaCom Solutions, a division of</FONT>
<BR><FONT SIZE=3D2>&nbsp;Phone: =
703-270-3523&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Entrust</FONT>
<BR><FONT SIZE=3D2>&nbsp;ICQ:&nbsp;&nbsp; =
1942828&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Securing the Internet</FONT>
<BR><FONT =
SIZE=3D2>---------------------------------------------------------------=
-</FONT>
<BR><FONT SIZE=3D2>&quot;Pay no attention to what the critics say; =
there has never been</FONT>
<BR><FONT SIZE=3D2>a statue set up in honor of a critic.&quot; --Jean =
Sibelius</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>-----Original Message-----</FONT>
<BR><FONT SIZE=3D2>From: Hiroyuki Sakakibara [<A =
HREF=3D"mailto:[e-mail]">mailto:[e-mail].c=
o.jp</A>]</FONT>
<BR><FONT SIZE=3D2>Sent: Thursday, August 23, 2001 5:52 AM</FONT>
<BR><FONT SIZE=3D2>To: Housley, Russ; Peter Hesse</FONT>
<BR><FONT SIZE=3D2>Cc: [e-mail]; [e-mail]; =
[e-mail]; [e-mail]; [e-mail]</FONT>
<BR><FONT SIZE=3D2>Subject: about validation of intermediate =
self-signed certs in a path</FONT>
</P>
<BR>
<BR>

<P><FONT SIZE=3D2>Peter</FONT>
</P>

<P><FONT SIZE=3D2>Thank you for your comments.</FONT>
</P>

<P><FONT SIZE=3D2>Peter Hesse wrote:</FONT>
<BR><FONT SIZE=3D2>&gt;TR -&gt; A -&gt; B -&gt; (B self signed) -&gt; C =
-&gt; EE</FONT>
<BR><FONT SIZE=3D2>&gt;Let's say that A-&gt;B has a notAfter date of =
12/31/2002,</FONT>
<BR><FONT SIZE=3D2>&gt;(B self signed) has a notAfter date of =
12/31/2001, and B-&gt;C has a notAfter</FONT>
<BR><FONT SIZE=3D2>date of 12/31/2002.</FONT>
<BR><FONT SIZE=3D2>&gt;If this path was developed and validated, the =
path would be invalid</FONT>
<BR><FONT SIZE=3D2>&gt;if the current date was after&nbsp; =
12/31/2001.</FONT>
</P>

<P><FONT SIZE=3D2>Excuse me that the example was not good.</FONT>
</P>

<P><FONT SIZE=3D2>again, (sorry for a long mail)</FONT>
</P>

<P><FONT SIZE=3D2>[example]</FONT>
</P>

<P><FONT SIZE=3D2>* A, B, C are CAs</FONT>
<BR><FONT SIZE=3D2>* A has a key pair whose validity term is 1 =
years</FONT>
<BR><FONT SIZE=3D2>* B has a key pair whose validity term is 1 =
years</FONT>
<BR><FONT SIZE=3D2>* C has a key pair whose validity term is 1 =
years</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp; 2001/01/01&nbsp; =
06/01&nbsp;&nbsp; 2002/01/01&nbsp;&nbsp;&nbsp; 06/01&nbsp; =
2003/01/01</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
+-----------+-----------+-----------+---------+</FONT>
</P>

<P><FONT =
SIZE=3D2>A-&gt;B&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&lt;-----------------------&gt;</FONT>
</P>

<P><FONT SIZE=3D2>B-&gt;B =
&lt;----------------------&gt;&lt;---------------------&gt;</FONT>
<BR><FONT =
SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp; =
(1)&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; (2)</FONT>
</P>

<P><FONT =
SIZE=3D2>B-&gt;C&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&lt;-----------------------&gt;</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>B issues a self-signed cert (1), notBefore 2001/01/01 =
notAfter 2001/12/31.</FONT>
<BR><FONT SIZE=3D2>B is going to issue a new self-signed cert (2) =
which</FONT>
<BR><FONT SIZE=3D2>containts the public key in (1), notBefore =
2002/01/01 notAfter 2002/12/31,</FONT>
<BR><FONT SIZE=3D2>if the public key in (1) has no problem on =
2001/12/31.</FONT>
<BR><FONT SIZE=3D2>( notBefore of (2) may be 2001/01/01 )</FONT>
<BR><FONT SIZE=3D2>B announces the schedule of issuance of (2) to A and =
C beforehand.</FONT>
</P>

<P><FONT SIZE=3D2>A issues a certificate to B, notBefore 2001/06/01 =
notAfter 2002/5/31.</FONT>
<BR><FONT SIZE=3D2>A expects that B is going to issue (2), hence, A can =
issue A-&gt;B</FONT>
<BR><FONT SIZE=3D2>whose notAfter excesses notAfter of (1) and the =
validity term</FONT>
<BR><FONT SIZE=3D2>of A-&gt;B is exactly 1 year.</FONT>
</P>

<P><FONT SIZE=3D2>B issues a certificate to C, notBefore 2001/06/01 =
notAfter 2002/05/31.</FONT>
<BR><FONT SIZE=3D2>Because B is going to issue (2) on 2002/01/01, hence =
B can issue</FONT>
<BR><FONT SIZE=3D2>B-&gt;C whose notAfter excesses notAfter of =
(1).</FONT>
</P>

<P><FONT SIZE=3D2>In this example, B can use the same public key =
continuously, in (1) and (2).</FONT>
<BR><FONT SIZE=3D2>As a result, A can issue a cert to B whose validity =
term is always 1 year,</FONT>
<BR><FONT SIZE=3D2>whennever A issues.</FONT>
<BR><FONT SIZE=3D2>B can issue a cert to C whose validity term is =
always 1 year,</FONT>
<BR><FONT SIZE=3D2>whennever B issues, also.</FONT>
</P>

<P><FONT SIZE=3D2>I suppose that some PKI systems adopt this kind of =
cert issuance.</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>[problem]</FONT>
</P>

<P><FONT SIZE=3D2>However, assume that B does not issues (2), by =
incident,</FONT>
<BR><FONT SIZE=3D2>or rough operation etc....</FONT>
</P>

<P><FONT SIZE=3D2>if on 2002/01/02 a validation software can =
constructs,</FONT>
</P>

<P><FONT SIZE=3D2>&quot;A-&gt;B, B-&gt;C&quot; path only,</FONT>
</P>

<P><FONT SIZE=3D2>hence the software could not notice that the =
trouble</FONT>
<BR><FONT SIZE=3D2>with issuance of (2).</FONT>
<BR><FONT SIZE=3D2>Therefore it is not certain that the B's public =
key</FONT>
<BR><FONT SIZE=3D2>is good or not.</FONT>
<BR><FONT SIZE=3D2>In order to avoid this situation, A has to observe =
that</FONT>
<BR><FONT SIZE=3D2>B issues and published (2) in LDAP etc about =
2002/01/01</FONT>
<BR><FONT SIZE=3D2>and if B does not issues (2), A should alarm =
that.</FONT>
</P>

<P><FONT SIZE=3D2>If the software constructs &quot;A-&gt;B, B-&gt;B(1), =
B-&gt;C&quot; path,</FONT>
<BR><FONT SIZE=3D2>it can notice that the path is wrong, because =
B-&gt;B(1) is expired,</FONT>
<BR><FONT SIZE=3D2>and would try to construct another path, =
&quot;A-&gt;B, B-&gt;B(2), B-&gt;C&quot;</FONT>
<BR><FONT SIZE=3D2>however, B-&gt;B(2) is not present, so, it would =
give up, or</FONT>
<BR><FONT SIZE=3D2>construct &quot;A-&gt;B, B-&gt;C&quot;, eventhough =
it may be invalid.</FONT>
</P>

<P><FONT SIZE=3D2>Therefore, the result of validation of the path =
&quot;A-&gt;B, B-&gt;C&quot;</FONT>
<BR><FONT SIZE=3D2>and the result of validation of the path =
&quot;A-&gt;B, B-&gt;B(2), B-&gt;C&quot;</FONT>
<BR><FONT SIZE=3D2>are not identical in this case.</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>[revocation example]</FONT>
</P>

<P><FONT SIZE=3D2>Peter Hesse wrote:</FONT>
<BR><FONT SIZE=3D2>&gt;In the case of self-signed revocation, I am not =
sure why a CA would revoke</FONT>
<BR><FONT SIZE=3D2>itself.&nbsp; If the &gt;CA was truly operating as a =
&quot;rogue&quot;, it would not revoke</FONT>
<BR><FONT SIZE=3D2>itself in order to keep whatever &gt;trust it still =
had.&nbsp; Can you trust a CA</FONT>
<BR><FONT SIZE=3D2>that revokes itself?&nbsp; I am reminded of the old =
puzzle &gt;in which you</FONT>
<BR><FONT SIZE=3D2>encounter two people at a crossroads, a truthteller =
and a liar.&nbsp; You do not</FONT>
<BR><FONT SIZE=3D2>&gt;know which is which, and must ask one of them a =
question in order to know</FONT>
<BR><FONT SIZE=3D2>if you should &gt;turn left or right to get to where =
you want to go</FONT>
</P>

<P><FONT SIZE=3D2>I agree with you.</FONT>
<BR><FONT SIZE=3D2>But in the case that A issues a cross certificate to =
B and</FONT>
<BR><FONT SIZE=3D2>B issues a self-signed cert to itself,</FONT>
<BR><FONT SIZE=3D2>not only B but also A would do rough =
operation.</FONT>
</P>

<P><FONT SIZE=3D2>If B is a rough CA, as you mentioned, B would not =
revoke itself and not</FONT>
<BR><FONT SIZE=3D2>announce</FONT>
<BR><FONT SIZE=3D2>the revocation status of B to A, then a path could =
be validated as good.</FONT>
</P>

<P><FONT SIZE=3D2>If A is a rough CA, even though B asks A to revoke =
the cross-cert from A to</FONT>
<BR><FONT SIZE=3D2>B,</FONT>
<BR><FONT SIZE=3D2>A would not, then a path could be valdiated as good =
also.</FONT>
</P>

<P><FONT SIZE=3D2>I will show an example where a validation =
software</FONT>
<BR><FONT SIZE=3D2>would had better check revocation status of =
self-signed certificates.</FONT>
<BR><FONT SIZE=3D2>( this is an example of latter case.)</FONT>
</P>

<P><FONT SIZE=3D2>1. B's private key was revoked.</FONT>
</P>

<P><FONT SIZE=3D2>2. B issues a CRL asserting &quot;B is =
revoked&quot;</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp; with its revoked privatekey.</FONT>
</P>

<P><FONT SIZE=3D2>3. B announces its revocaton to other CAs, then other =
CAs</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp; should revoke cross-certs to B.</FONT>
</P>

<P><FONT SIZE=3D2>If the procedure 3 is done immediately, the procedure =
2 is not neccesarry.</FONT>
<BR><FONT SIZE=3D2>But if not, because of trouble of CA sysytems or =
rough operateion what else,</FONT>
<BR><FONT SIZE=3D2>I suppose that adoption of the procedure 2 is a good =
idea.</FONT>
</P>

<P><FONT SIZE=3D2>Actually, there is a risk that a bad person who knows =
B's private key issues</FONT>
<BR><FONT SIZE=3D2>a fake CRL asserting &quot;B is OK(not on the =
list)&quot;,</FONT>
<BR><FONT SIZE=3D2>and a validation software uses the fake one =
accidentally.</FONT>
</P>

<P><FONT SIZE=3D2>A validation software can not distinguish that an =
obtained CRL is issued by</FONT>
<BR><FONT SIZE=3D2>B</FONT>
<BR><FONT SIZE=3D2>or by the bad person,</FONT>
<BR><FONT SIZE=3D2>however if the software obtains the correct CRL =
issued by &quot;B&quot; first or</FONT>
<BR><FONT SIZE=3D2>obtains both the correct one and the fake one, the =
software can</FONT>
<BR><FONT SIZE=3D2>notice that the revocation of B, even though the =
procedure 3 is not done</FONT>
<BR><FONT SIZE=3D2>immediately.</FONT>
</P>

<P><FONT SIZE=3D2>Offcourse, it is not able to prevent a validation =
software from obtaining</FONT>
<BR><FONT SIZE=3D2>only the fake CRL first, however issuing a CRL in =
the procedure 2 could</FONT>
<BR><FONT SIZE=3D2>reduce a risk that the software ALWAYS referes only =
the fake one.</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>[my interpretation]</FONT>
</P>

<P><FONT SIZE=3D2>I think that a validation software could gain some =
additional benefits</FONT>
<BR><FONT SIZE=3D2>by checking self-signed certificates in a path in =
the case of some</FONT>
<BR><FONT SIZE=3D2>PKI system such as the shown example.</FONT>
</P>

<P><FONT SIZE=3D2>However when mis-operations or troubles among CAs =
seldom happen,</FONT>
<BR><FONT SIZE=3D2>a validation software would not need to check =
them.</FONT>
</P>

<P><FONT SIZE=3D2>So, section 6.1, considering your comments,</FONT>
<BR><FONT SIZE=3D2>my interpretation became as follows,</FONT>
</P>

<P><FONT SIZE=3D2>* validating a path without self-signed certs ONLY =
-&gt; GOOD</FONT>
<BR><FONT SIZE=3D2>* validating a path with self-signed certs ONLY =
-&gt; GOOD</FONT>
<BR><FONT SIZE=3D2>* validating BOTH paths -&gt; GOOD</FONT>
</P>

<P><FONT SIZE=3D2>actually, I agree with that most implementations =
apply the first one</FONT>
<BR><FONT SIZE=3D2>because of its simplicity as you mentioned.</FONT>
</P>

<P><FONT SIZE=3D2>Also, I think that any guidline of a =
recommended</FONT>
<BR><FONT SIZE=3D2>path pattern (such as the first one) is =
useful.</FONT>
</P>

<P><FONT SIZE=3D2>---------------------------------------</FONT>
<BR><FONT SIZE=3D2>Hiroyuki Sakakibara</FONT>
<BR><FONT SIZE=3D2>MITSUBISHI ELECTRIC CORPORATION</FONT>
<BR><FONT SIZE=3D2>Information Technology R&amp;D Center</FONT>
<BR><FONT SIZE=3D2>5-1-1 Ofuna, Kamakura, Kanagawa, Japan</FONT>
<BR><FONT SIZE=3D2>PHONE: [phone]</FONT>
<BR><FONT SIZE=3D2>FAX:&nbsp;&nbsp; [phone]</FONT>
<BR><FONT SIZE=3D2>E-mail : [e-mail]</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C12BE7.F05A1600--


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f7NEajf21174 for ietf-pkix-bks; Thu, 23 Aug 2001 07:36:45 -0700 (PDT)
Received: from tholian.securitydynamics.com (mail.rsasecurity.com [204.167.112.129]) by above.proper.com (8.11.6/8.11.3) with SMTP id f7NEabD21165 for <[e-mail]>; Thu, 23 Aug 2001 07:36:38 -0700 (PDT)
Received: from sdtihq24.securitydynamics.com by tholian.securitydynamics.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 23 Aug 2001 14:34:19 UT
Received: from exna00.securitydynamics.com (ebola.securid.com [192.168.7.4]) by sdtihq24.securid.com (Pro-8.9.3/Pro-8.9.3) with ESMTP id KAA29964 for <[e-mail]>; Thu, 23 Aug 2001 10:35:50 -0400 (EDT)
Received: by exna00.securitydynamics.com with Internet Mail Service (5.5.2653.19) id <QTWCQ4B8>; Thu, 23 Aug 2001 10:36:28 -0400
Received: from HOUSLEY-LAP.rsasecurity.com (HOUSLEY-LAP [10.3.1.45]) by exna00.securitydynamics.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id QTWCQ4BY; Thu, 23 Aug 2001 10:36:25 -0400
From: "Housley, Russ" <[e-mail]>
To: [e-mail]
Cc: [e-mail]
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.0.1
Date: Thu, 23 Aug 2001 10:22:27 -0400
Subject: Re: Question about ECDSA.
In-Reply-To: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>

The ANSI X9 and PKIX documents have never included specifications for 
private key syntax.

Perhaps Certicom can offer a recommended syntax.

Russ




>I can't found ECDSA PriveKey OID.
>There is no information about it in X9.62 and your draft-ietf-pkix-ipki-
>pkalgs-03.txt.
>
>I want to know ECDSA PrivateKey ASN.1 syntax, OID and
>PrivateKeyAlgorithms OID.
>where can I that information?
>
>Thanks.


Received: by above.proper.com (8.11.6/8.11.3) id f7NERqx20939 for ietf-pkix-bks; Thu, 23 Aug 2001 07:27:52 -0700 (PDT)
Received: from mail.ca.certicom.com (ip6.certicom.com [209.121.99.6]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f7NERoD20935 for <[e-mail]>; Thu, 23 Aug 2001 07:27:50 -0700 (PDT)
Received: from smtpmail.certicom.com (smtpmail.certicom.com [10.0.1.25]) by mail.ca.certicom.com (8.9.3/8.9.3) with SMTP id KAA29732 for <[e-mail]>; Thu, 23 Aug 2001 10:20:55 -0400 (EDT)
Received: by smtpmail.certicom.com(Lotus SMTP MTA v4.6.4  (830.2 3-23-1999))  id 85256AB1.004F64A3 ; Thu, 23 Aug 2001 10:27:11 -0400
X-Lotus-FromDomain: CERTICOM
From: "Simon Blake-Wilson" <[e-mail]>
To: [e-mail]
Message-ID: <[e-mail]>
Date: Thu, 23 Aug 2001 10:24:12 -0400
Subject: Re: Question about ECDSA.
Mime-Version: 1.0
Content-type: multipart/mixed;  Boundary="0__=Trc6vVswVJYHMBNJTGEp26QMejjMvnL4N84OeMHGg5n4wipYe4iuIpsX"
Content-Disposition: inline
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>

--0__=Trc6vVswVJYHMBNJTGEp26QMejjMvnL4N84OeMHGg5n4wipYe4iuIpsX
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline


ECDSA private key syntax is suggested in SEC1 ... you should be able to download
from www.secg.org. The syntax suggested there is the only standardized ECC
private key syntax as far as I know.

Best regards. Simon






--0__=Trc6vVswVJYHMBNJTGEp26QMejjMvnL4N84OeMHGg5n4wipYe4iuIpsX
Content-type: text/plain; charset=euc-kr
Content-Disposition: inline

±è Ãæ±æ <[e-mail]> on 08/23/2001 05:39:13 AM

To:   [e-mail]
cc:    (bcc: Simon Blake-Wilson/Certicom)

Subject:  Question about ECDSA.



--0__=Trc6vVswVJYHMBNJTGEp26QMejjMvnL4N84OeMHGg5n4wipYe4iuIpsX
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline



I can't found ECDSA PriveKey OID.
There is no information about it in X9.62 and your draft-ietf-pkix-ipki-
pkalgs-03.txt.

I want to know ECDSA PrivateKey ASN.1 syntax, OID and
PrivateKeyAlgorithms OID.
where can I that information?

Thanks.



--0__=Trc6vVswVJYHMBNJTGEp26QMejjMvnL4N84OeMHGg5n4wipYe4iuIpsX--



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f7NEKoh20802 for ietf-pkix-bks; Thu, 23 Aug 2001 07:20:50 -0700 (PDT)
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f7NEKmD20797 for <[e-mail]>; Thu, 23 Aug 2001 07:20:48 -0700 (PDT)
Received: from sunlabs.East.Sun.COM ([129.148.75.250]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA09639; Thu, 23 Aug 2001 08:20:45 -0600 (MDT)
Received: from sun.com (dhcp75-167 [129.148.75.167]) by sunlabs.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA11317; Thu, 23 Aug 2001 10:20:43 -0400 (EDT)
Message-ID: <[e-mail]>
Date: Thu, 23 Aug 2001 10:20:04 -0400
From: Steve Hanna <[e-mail]>
Organization: Sun Microsystems, Inc.
X-Mailer: Mozilla 4.75 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Tom Gindin <[e-mail]>
CC: Peter Sylvester <[e-mail]>, [e-mail]
Subject: Re: excludedSubtrees (was Re: draft-ietf-pkix-new-part1-08)
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>

Tom Gindin wrote:
> On a more constructive note, however, any attribute which can only
> be encoded in PrintableString or NumericString (or Object ID) can
> safely be used in excludedSubtrees.  The most useful of these is
> probably Country.

Right. So I can safely use excludedSubtrees with directoryNames as long
as the only attributes in the excluded DN are countryName, dnQualifier,
and serialNumber. But I suspect that most DNs that people would want to
exclude would contain organizationName and the like.

So I still think that using excludedSubtrees with directoryNames is
generally a bad idea. The Security Considerations section of
new-part1-08 basically says this, so I don't think any changes to the
draft are required.

-Steve


Received: by above.proper.com (8.11.6/8.11.3) id f7NCwUI18123 for ietf-pkix-bks; Thu, 23 Aug 2001 05:58:30 -0700 (PDT)
Received: from email.nist.gov (email.nist.gov [129.6.2.7]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f7NCwTD18119 for <[e-mail]>; Thu, 23 Aug 2001 05:58:29 -0700 (PDT)
Received: from krdp2 (krdp2.ncsl.nist.gov [129.6.54.107]) by email.nist.gov (8.9.3/8.9.3) with ESMTP id IAA24716; Thu, 23 Aug 2001 08:58:43 -0400 (EDT)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 
Date: Thu, 23 Aug 2001 08:57:46 -0400
To: Jeff Jacoby <[e-mail]>, "'[e-mail]'" <[e-mail]>
From: "David A. Cooper" <[e-mail]>
Subject: Re: Recommended changes to draft-ietf-pkix-new-part1-08
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>

Jeff,

any-policy and anyPolicy are different, although the difference is somewhat subtle.  The term any-policy is essentially a mathematical variable representing the set of all possible certificate policies (i.e., any-policy = {OID | OID is an object identifier that represents a certificate policy}).  anyPolicy, on the other hand, is a variable defined in an ASN.1 module and it represents a specific object identifier (anyPolicy OBJECT IDENTIFIER ::= { id-ce-certificate-policies 0 }).

So, anyPolicy is an object identifier that may appear in the certificatePolicies extension of a certificate.  any-policy represents a mathematical value that can be the value of a state variable in section 6 (e.g., user-initial-policy-set, expected_policy_set).

At least, this was the intention.  In responding to your question I noticed that "any-policy" was sometimes used where "anyPolicy" should have been.  This will need to be corrected.

Dave

At 02:41 PM 8/22/01 -0700, Jeff Jacoby wrote:

>"Jacoby, Jeffrey" wrote:
> > 
> > To all,
> > 
> > Jumping on the bandwagon here...
> > 
> > There are three points I believe could use clarification (at least
> > I'm having trouble grokking them).
>
>One more minor item.  The term "any-policy" is used 
>throughout the document .  However, the ASN.1 name 
>is anyPolicy:
>
>     anyPolicy OBJECT IDENTIFIER ::= { id-ce-certificate-policies 0 }
>
>and in fact "anyPolicy" is also used in several places in the
>document.  
>
>Is the use of "any-policy" meant to imply a difference from "anyPolicy", 
>or do these two terms really mean the exact same thing?  If the latter,
>then 
>I believe "any-policy" should be replaced by "anyPolicy" throughout.
>
>Jeff




Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f7N9kAW07275 for ietf-pkix-bks; Thu, 23 Aug 2001 02:46:10 -0700 (PDT)
Received: from mx02.melco.co.jp (mx01.melco.co.jp [192.218.140.41]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f7N9k5D07269 for <[e-mail]>; Thu, 23 Aug 2001 02:46:05 -0700 (PDT)
Received: by mx02.melco.co.jp (mx02) id SAA14504; Thu, 23 Aug 2001 18:46:01 +0900 (JST)
Received: by mr03.melco.co.jp (mr03) id SAA25189; Thu, 23 Aug 2001 18:46:00 +0900 (JST)
Received: from elmail by elgw.isl.melco.co.jp (8.8.8/3.6W) id SAA11821; Thu, 23 Aug 2001 18:45:59 +0900 (JST)
Received: from iss.isl.melco.co.jp (iss.isl.melco.co.jp [10.74.5.60]) by elmail.isl.melco.co.jp (iPlanet Messaging Server 5.0 Patch 3 (built Mar 23 2001)) with ESMTP id <[e-mail]> for [e-mail]; Thu, 23 Aug 2001 18:45:56 +0900 (JST)
Received: from belize by iss.isl.melco.co.jp (8.8.8/3.6W) id SAA12220; Thu, 23 Aug 2001 18:45:56 +0900 (JST)
Date: Thu, 23 Aug 2001 18:52:04 +0900
From: Hiroyuki Sakakibara <[e-mail]>
Subject: about validation of intermediate self-signed certs in a path
To: "Housley, Russ" <[e-mail]>, Peter Hesse <[e-mail]>
Cc: [e-mail], [e-mail], [e-mail], [e-mail], [e-mail]
Message-id: <00df01c12bb9$43966b40$[e-mail]>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
Content-type: text/plain; charset=iso-2022-jp
Content-transfer-encoding: 7BIT
X-Priority: 3
X-MSMail-priority: Normal
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>

Peter

Thank you for your comments.

Peter Hesse wrote:
>TR -> A -> B -> (B self signed) -> C -> EE
>Let's say that A->B has a notAfter date of 12/31/2002,
>(B self signed) has a notAfter date of 12/31/2001, and B->C has a notAfter
date of 12/31/2002.
>If this path was developed and validated, the path would be invalid
>if the current date was after  12/31/2001.

Excuse me that the example was not good.

again, (sorry for a long mail)

[example]

* A, B, C are CAs
* A has a key pair whose validity term is 1 years
* B has a key pair whose validity term is 1 years
* C has a key pair whose validity term is 1 years


     2001/01/01  06/01   2002/01/01    06/01  2003/01/01
        +-----------+-----------+-----------+---------+

A->B                     <----------------------->

B->B <----------------------><--------------------->
                        (1)                                 (2)

B->C                     <----------------------->


B issues a self-signed cert (1), notBefore 2001/01/01 notAfter 2001/12/31.
B is going to issue a new self-signed cert (2) which
containts the public key in (1), notBefore 2002/01/01 notAfter 2002/12/31,
if the public key in (1) has no problem on 2001/12/31.
( notBefore of (2) may be 2001/01/01 )
B announces the schedule of issuance of (2) to A and C beforehand.

A issues a certificate to B, notBefore 2001/06/01 notAfter 2002/5/31.
A expects that B is going to issue (2), hence, A can issue A->B
whose notAfter excesses notAfter of (1) and the validity term
of A->B is exactly 1 year.

B issues a certificate to C, notBefore 2001/06/01 notAfter 2002/05/31.
Because B is going to issue (2) on 2002/01/01, hence B can issue
B->C whose notAfter excesses notAfter of (1).

In this example, B can use the same public key continuously, in (1) and (2).
As a result, A can issue a cert to B whose validity term is always 1 year,
whennever A issues.
B can issue a cert to C whose validity term is always 1 year,
whennever B issues, also.

I suppose that some PKI systems adopt this kind of cert issuance.


[problem]

However, assume that B does not issues (2), by incident,
or rough operation etc....

if on 2002/01/02 a validation software can constructs,

"A->B, B->C" path only,

hence the software could not notice that the trouble
with issuance of (2).
Therefore it is not certain that the B's public key
is good or not.
In order to avoid this situation, A has to observe that
B issues and published (2) in LDAP etc about 2002/01/01
and if B does not issues (2), A should alarm that.

If the software constructs "A->B, B->B(1), B->C" path,
it can notice that the path is wrong, because B->B(1) is expired,
and would try to construct another path, "A->B, B->B(2), B->C"
however, B->B(2) is not present, so, it would give up, or
construct "A->B, B->C", eventhough it may be invalid.

Therefore, the result of validation of the path "A->B, B->C"
and the result of validation of the path "A->B, B->B(2), B->C"
are not identical in this case.


[revocation example]

Peter Hesse wrote:
>In the case of self-signed revocation, I am not sure why a CA would revoke
itself.  If the >CA was truly operating as a "rogue", it would not revoke
itself in order to keep whatever >trust it still had.  Can you trust a CA
that revokes itself?  I am reminded of the old puzzle >in which you
encounter two people at a crossroads, a truthteller and a liar.  You do not
>know which is which, and must ask one of them a question in order to know
if you should >turn left or right to get to where you want to go

I agree with you.
But in the case that A issues a cross certificate to B and
B issues a self-signed cert to itself,
not only B but also A would do rough operation.

If B is a rough CA, as you mentioned, B would not revoke itself and not
announce
the revocation status of B to A, then a path could be validated as good.

If A is a rough CA, even though B asks A to revoke the cross-cert from A to
B,
A would not, then a path could be valdiated as good also.

I will show an example where a validation software
would had better check revocation status of self-signed certificates.
( this is an example of latter case.)

1. B's private key was revoked.

2. B issues a CRL asserting "B is revoked"
   with its revoked privatekey.

3. B announces its revocaton to other CAs, then other CAs
   should revoke cross-certs to B.

If the procedure 3 is done immediately, the procedure 2 is not neccesarry.
But if not, because of trouble of CA sysytems or rough operateion what else,
I suppose that adoption of the procedure 2 is a good idea.

Actually, there is a risk that a bad person who knows B's private key issues
a fake CRL asserting "B is OK(not on the list)",
and a validation software uses the fake one accidentally.

A validation software can not distinguish that an obtained CRL is issued by
B
or by the bad person,
however if the software obtains the correct CRL issued by "B" first or
obtains both the correct one and the fake one, the software can
notice that the revocation of B, even though the procedure 3 is not done
immediately.

Offcourse, it is not able to prevent a validation software from obtaining
only the fake CRL first, however issuing a CRL in the procedure 2 could
reduce a risk that the software ALWAYS referes only the fake one.


[my interpretation]

I think that a validation software could gain some additional benefits
by checking self-signed certificates in a path in the case of some
PKI system such as the shown example.

However when mis-operations or troubles among CAs seldom happen,
a validation software would not need to check them.

So, section 6.1, considering your comments,
my interpretation became as follows,

* validating a path without self-signed certs ONLY -> GOOD
* validating a path with self-signed certs ONLY -> GOOD
* validating BOTH paths -> GOOD

actually, I agree with that most implementations apply the first one
because of its simplicity as you mentioned.

Also, I think that any guidline of a recommended
path pattern (such as the first one) is useful.

---------------------------------------
Hiroyuki Sakakibara
MITSUBISHI ELECTRIC CORPORATION
Information Technology R&D Center
5-1-1 Ofuna, Kamakura, Kanagawa, Japan
PHONE: [phone]
FAX:   [phone]
E-mail : [e-mail]




Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f7N9cAR06230 for ietf-pkix-bks; Thu, 23 Aug 2001 02:38:10 -0700 (PDT)
Received: from file.initech.com ([61.74.133.21]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f7N9c7D06226 for <[e-mail]>; Thu, 23 Aug 2001 02:38:07 -0700 (PDT)
Subject: Question about ECDSA.
Date: Thu, 23 Aug 2001 18:39:13 +0900
Message-ID: <[e-mail]>
MIME-Version: 1.0
X-MS-Has-Attach: 
Content-Type: text/plain; charset="euc-kr"
X-MS-TNEF-Correlator: 
Thread-Topic: Question about ECDSA.
content-class: urn:content-classes:message
Thread-Index: AcErt7EmQQauvEBHTfOeJIAxrX1TfQ==
X-MimeOLE: Produced By Microsoft Exchange V6.0.4417.0
From: =?euc-kr?B?seggw+ax5g==?= <[e-mail]>
To: <[e-mail]>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from base64 to 8bit by above.proper.com id f7N9c9D06227
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>

I can't found ECDSA PriveKey OID.
There is no information about it in X9.62 and your draft-ietf-pkix-ipki-
pkalgs-03.txt.

I want to know ECDSA PrivateKey ASN.1 syntax, OID and
PrivateKeyAlgorithms OID.
where can I that information?

Thanks.


Received: by above.proper.com (8.11.6/8.11.3) id f7N8Zm602646 for ietf-pkix-bks; Thu, 23 Aug 2001 01:35:48 -0700 (PDT)
Received: from server.speedcom.it (server.speedcom.it [195.32.69.66]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f7N8ZkD02639 for <[e-mail]>; Thu, 23 Aug 2001 01:35:46 -0700 (PDT)
Received: (from adg@localhost) by server.speedcom.it (0.0.0/0.0.0) id KAA07162; Thu, 23 Aug 2001 10:18:50 +0200
Date: Thu, 23 Aug 2001 10:18:50 +0200
From: Alfonso De Gregorio <[e-mail]>
To: Peter Gutmann <[e-mail]>
Cc: [e-mail], [e-mail], [e-mail]
Subject: Re: New test TSA available
Message-ID: <[e-mail]>
Reply-To: [e-mail]
References: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
In-Reply-To: <[e-mail]>
User-Agent: mymua
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>

On Thu, Aug 23, 2001 at 07:20:10AM +1200, Peter Gutmann wrote:

> >i see the point, i also understand that version choice in SignedData is 
> >somewhat a minor issue, but it would be nice if we all stick to cms rfc 
> >rather than develop something broken just to permit interoperability with 
> >other broken implementations

Hi Peter,

> It's really a pragmatic decision, if I do what the RFC says I'll get
> 10,000 users complaining that my code is broken because $RANDOM_IMPLEMENTATION
> doesn't work with it, if I ignore what the RFC says I'll get one person on a
> mailing list :-) saying it's not right.  I'll accept the latter as less
> painful.
> 
> (Obviously you can never do this for something critical like crypto-related 
>  information, but for something as minor as a version number I doubt I'll be 
>  going to hell for it).

<playful argument>
AFAIK, while IETF partecipants meet each other three times a year,
while they work via mailing list, while they send comments on proposed 
standards, they are trying to achive interoperability hopefully by 
_standardization_ :-) 

Does IETF WGs still make sense if we prefer to be not completelly compliant
with RFCs? :-)
</playful argument>

alfonso 


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f7N2LqH06022 for ietf-pkix-bks; Wed, 22 Aug 2001 19:21:52 -0700 (PDT)
Received: from mtiwmhc24.worldnet.att.net (mtiwmhc24.worldnet.att.net [204.127.131.49]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f7N2LeD06016 for <[e-mail]>; Wed, 22 Aug 2001 19:21:40 -0700 (PDT)
Received: from tsg1 ([12.81.64.68]) by mtiwmhc24.worldnet.att.net (InterMail vM.4.01.03.16 201-229-121-116-20010115) with SMTP id <20010823022127.OVBR21828.mtiwmhc24.worldnet.att.net@tsg1>; Thu, 23 Aug 2001 02:21:27 +0000
Message-ID: <07d201c12b7a$41190dd0$020aff0c@tsg1>
From: "todd glassey" <[e-mail]>
To: "Peter Gutmann" <[e-mail]>, <[e-mail]>
Cc: <[e-mail]>, <[e-mail]>
References: <[e-mail]>
Subject: Re: New test TSA available
Date: Wed, 22 Aug 2001 19:15:42 -0700
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.3018.1300
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.3018.1300
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>

----- Original Message -----
From: "Peter Gutmann" <[e-mail]>
To: <[e-mail]>; <[e-mail]>
Cc: <[e-mail]>; <[e-mail]>
Sent: Tuesday, August 21, 2001 5:03 PM
Subject: Re: New test TSA available


>
> tho <[e-mail]> writes:
>
> >(A) draft-ietf-pkix-time-stamp-15 states that eContentType for a time
> >    stamping token should be id-ct-TSTInfo why is it instead set to
> >    id-data ?
>
> Probably because the implementation was done back when draft-06 or
> something was current :-).  This is also why various other things
> required by newer drafts aren't present, I'll fix this when I next
> update the code (because of the environment it's in, there's a bit of
> latency involved when making changes).
>

The TSA should by its response message also identify which standard or draft
level it complies to.

> >since the encapsulated content type is set to id-data, version
> >field in SignedData is (`correctly' since (A)) set to 1 and not to 3
>
> This one's deliberate, since CMS implementations are split 50/50 between
> ones which ignore the version entirely and ones which require it to be
> what PKCS #7 set it to, I always use the PKCS #7 version value because
> that means it'll work with everything.
>
> >signatureAlgorithm in SignerInfo is rsaEncryption, shouldn't it be more
> >likely sha1withRSAEncryption ?
>
> Since the CMS signature splits the hash and signing algorithm, the first
> OID is a pure hash (SHA-1) and the second is a pure signature algorithm
> (RSA).
>
> Peter.



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f7MMlv428358 for ietf-pkix-bks; Wed, 22 Aug 2001 15:47:57 -0700 (PDT)
Received: from e1.ny.us.ibm.com (e1.ny.us.ibm.com [32.97.182.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f7MMltN28354 for <[e-mail]>; Wed, 22 Aug 2001 15:47:55 -0700 (PDT)
Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.117.200.22]) by e1.ny.us.ibm.com (8.9.3/8.9.3) with ESMTP id SAA159572; Wed, 22 Aug 2001 18:45:41 -0400
Received: from d01ml062.pok.ibm.com (d01ml062.pok.ibm.com [9.117.250.163]) by northrelay02.pok.ibm.com (8.11.1m3/NCO v4.97.1) with ESMTP id f7MMdqk79376; Wed, 22 Aug 2001 18:39:52 -0400
Importance: Normal
Subject: Re: excludedSubtrees (was Re: draft-ietf-pkix-new-part1-08)
To: Steve Hanna <[e-mail]>
Cc: Peter Sylvester <[e-mail]>, [e-mail]
X-Mailer: Lotus Notes Release 5.0.3 (Intl) 21 March 2000
Message-ID: <[e-mail]>
From: "Tom Gindin" <[e-mail]>
Date: Wed, 22 Aug 2001 18:47:53 -0400
X-MIMETrack: Serialize by Router on D01ML062/01/M/IBM(Release 5.0.8 SPR #MIAS4UTJ8H |June 21, 2001) at 08/22/2001 06:47:49 PM
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>

     Actually, I think we could stop people from playing games with
TeletexString in excludedSubtrees by requiring that any validator consider
that a TeletexString which he cannot convert to UTF-8 successfully be
considered to match any excluded subtree with that same attribute specified
as UTF8String, UniversalString, or BMPString.  That doesn't, of course,
prevent someone from adding a junk character to a Unicode encoding,
skipping accents, or such, so it's probably still bad practice.
     On a more constructive note, however, any attribute which can only be
encoded in PrintableString or NumericString (or Object ID) can safely be
used in excludedSubtrees.  The most useful of these is probably Country.

          Tom Gindin


Steve Hanna <[e-mail]>@mail.imc.org on 08/22/2001 05:17:11 PM

Sent by:  [e-mail]


To:   Peter Sylvester <[e-mail]>
cc:   [e-mail]
Subject:  Re: excludedSubtrees (was Re: draft-ietf-pkix-new-part1-08)



Peter Sylvester wrote:
> Chapter 4.1.1.11 says:
>
>    When applying restrictions of the form directoryName, an
>    implementation MUST compare DN attributes.  At a minimum,
>    implementations MUST perform the DN comparison rules specified in
>    Section 4.1.2.4.  CAs issuing certificates with a restriction of the
>    form directoryName SHOULD NOT rely on implementation of the full ISO
>    DN name comparison algorithm.  This implies name restrictions shall
>    be stated identically to the encoding used in the subject field or
>    subjectAltName extension.
>
> Does this mean that excludedSubtrees are practically unusable ?

That depends. They're still usable for name types other than
directoryName. And if you know (somehow, via some out of band mechanism)
that the relying party will only accept or trust printableString (or a
small subset of UTF8String), then you can use excludedSubtrees for
directoryName. Admittedly, that's not very likely and not good practice.
That's why the last paragraph in the Security Considerations section
talks about this problem and ends by saying "To avoid acceptance of
invalid paths, CAs SHOULD state name constraints for distinguished names
as permittedSubtrees wherever possible."

It's very hard to make excludedSubtrees work with multiple encodings (or
even with a large character set like Unicode). It's like trying to hit a
bullet with a bullet. Even if we required everyone to implement full ISO
name comparison rules for UTF8String and PrintableString, the bad guys
could encode their name with TeletexString using escape sequences or add
an accent to a character in a UTF8String or change one character in an
excluded name to another Unicode character that looks similar ...

-Steve






Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f7MLk1f27197 for ietf-pkix-bks; Wed, 22 Aug 2001 14:46:01 -0700 (PDT)
Received: from tholian.securitydynamics.com (mail.rsasecurity.com [204.167.112.129]) by above.proper.com (8.11.3/8.11.3) with SMTP id f7MLjxN27193 for <[e-mail]>; Wed, 22 Aug 2001 14:45:59 -0700 (PDT)
Received: from sdtihq24.securitydynamics.com by tholian.securitydynamics.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 22 Aug 2001 21:43:43 UT
Received: from exna00.securitydynamics.com (ebola.securid.com [192.168.7.4]) by sdtihq24.securid.com (Pro-8.9.3/Pro-8.9.3) with ESMTP id RAA13267 for <[e-mail]>; Wed, 22 Aug 2001 17:45:23 -0400 (EDT)
Received: by exna00.securitydynamics.com with Internet Mail Service (5.5.2653.19) id <QTWCQN1W>; Wed, 22 Aug 2001 17:46:01 -0400
Received: from HOUSLEY-LAP.rsasecurity.com (HOUSLEY-LAP [10.3.1.56]) by exna00.securitydynamics.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id QTWCQN1Q; Wed, 22 Aug 2001 17:45:55 -0400
From: "Housley, Russ" <[e-mail]>
To: Peter Sylvester <[e-mail]>
Cc: [e-mail]
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.0.1
Date: Wed, 22 Aug 2001 17:28:08 -0400
Subject: Re: draft-ietf-pkix-new-part1-08
In-Reply-To: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>

Peter:

Not completely.  It just means that you cannot rely on white space trimming 
and case changes in any character encoding other than PrintableString.

Russ

At 03:04 PM 8/22/2001 +0200, Peter Sylvester wrote:


>Chapter 4.1.1.11 says:
>
>    When applying restrictions of the form directoryName, an
>    implementation MUST compare DN attributes.  At a minimum,
>    implementations MUST perform the DN comparison rules specified in
>    Section 4.1.2.4.  CAs issuing certificates with a restriction of the
>    form directoryName SHOULD NOT rely on implementation of the full ISO
>    DN name comparison algorithm.  This implies name restrictions shall
>    be stated identically to the encoding used in the subject field or
>    subjectAltName extension.
>
>Does this mean that excludedSubtrees are practically unusable ?


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f7MLhDs27128 for ietf-pkix-bks; Wed, 22 Aug 2001 14:43:13 -0700 (PDT)
Received: from tholian.securitydynamics.com (mail.rsasecurity.com [204.167.112.129]) by above.proper.com (8.11.3/8.11.3) with SMTP id f7MLhCN27124 for <[e-mail]>; Wed, 22 Aug 2001 14:43:12 -0700 (PDT)
Received: from sdtihq24.securid.com by tholian.securitydynamics.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 22 Aug 2001 21:40:55 UT
Received: from tuna.rsa.com (tuna.rsa.com [10.80.211.153]) by sdtihq24.securid.com (Pro-8.9.3/Pro-8.9.3) with ESMTP id RAA13042 for <[e-mail]>; Wed, 22 Aug 2001 17:42:31 -0400 (EDT)
Received: from rsasecurity.com ([10.81.217.242]) by tuna.rsa.com (8.8.8+Sun/8.8.8) with ESMTP id OAA03619 for <[e-mail]>; Wed, 22 Aug 2001 14:45:08 -0700 (PDT)
Message-ID: <[e-mail]>
Date: Wed, 22 Aug 2001 14:41:11 -0700
From: Jeff Jacoby <[e-mail]>
Organization: RSA Security, Inc.
X-Mailer: Mozilla 4.75 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: "'[e-mail]'" <[e-mail]>
Subject: Re: Recommended changes to draft-ietf-pkix-new-part1-08
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>

"Jacoby, Jeffrey" wrote:
> 
> To all,
> 
> Jumping on the bandwagon here...
> 
> There are three points I believe could use clarification (at least
> I'm having trouble grokking them).

One more minor item.  The term "any-policy" is used 
throughout the document .  However, the ASN.1 name 
is anyPolicy:

    anyPolicy OBJECT IDENTIFIER ::= { id-ce-certificate-policies 0 }

and in fact "anyPolicy" is also used in several places in the
document.  

Is the use of "any-policy" meant to imply a difference from "anyPolicy", 
or do these two terms really mean the exact same thing?  If the latter,
then 
I believe "any-policy" should be replaced by "anyPolicy" throughout.

Jeff
-- 
Jeff Jacoby, Sr. Programmer                
RSA Security Inc., SMDC                    [e-mail]
2755 Campus Dr., Ste. 300                  [phone]
San Mateo, CA  94403


Received: by above.proper.com (8.11.3/8.11.3) id f7MLHnE26536 for ietf-pkix-bks; Wed, 22 Aug 2001 14:17:49 -0700 (PDT)
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f7MLHlN26532 for <[e-mail]>; Wed, 22 Aug 2001 14:17:47 -0700 (PDT)
Received: from sunlabs.East.Sun.COM ([129.148.75.250]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA15527; Wed, 22 Aug 2001 15:17:46 -0600 (MDT)
Received: from sun.com (dhcp75-167 [129.148.75.167]) by sunlabs.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id RAA06103; Wed, 22 Aug 2001 17:17:48 -0400 (EDT)
Message-ID: <[e-mail]>
Date: Wed, 22 Aug 2001 17:17:11 -0400
From: Steve Hanna <[e-mail]>
Organization: Sun Microsystems, Inc.
X-Mailer: Mozilla 4.75 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Peter Sylvester <[e-mail]>
CC: [e-mail]
Subject: Re: excludedSubtrees (was Re: draft-ietf-pkix-new-part1-08)
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>

Peter Sylvester wrote:
> Chapter 4.1.1.11 says:
> 
>    When applying restrictions of the form directoryName, an
>    implementation MUST compare DN attributes.  At a minimum,
>    implementations MUST perform the DN comparison rules specified in
>    Section 4.1.2.4.  CAs issuing certificates with a restriction of the
>    form directoryName SHOULD NOT rely on implementation of the full ISO
>    DN name comparison algorithm.  This implies name restrictions shall
>    be stated identically to the encoding used in the subject field or
>    subjectAltName extension.
> 
> Does this mean that excludedSubtrees are practically unusable ?

That depends. They're still usable for name types other than
directoryName. And if you know (somehow, via some out of band mechanism)
that the relying party will only accept or trust printableString (or a
small subset of UTF8String), then you can use excludedSubtrees for
directoryName. Admittedly, that's not very likely and not good practice.
That's why the last paragraph in the Security Considerations section
talks about this problem and ends by saying "To avoid acceptance of
invalid paths, CAs SHOULD state name constraints for distinguished names
as permittedSubtrees wherever possible."

It's very hard to make excludedSubtrees work with multiple encodings (or
even with a large character set like Unicode). It's like trying to hit a
bullet with a bullet. Even if we required everyone to implement full ISO
name comparison rules for UTF8String and PrintableString, the bad guys
could encode their name with TeletexString using escape sequences or add
an accent to a character in a UTF8String or change one character in an
excluded name to another Unicode character that looks similar ...

-Steve


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f7MJL0c24242 for ietf-pkix-bks; Wed, 22 Aug 2001 12:21:00 -0700 (PDT)
Received: from kakapo.cs.auckland.ac.nz (kakapo.cs.auckland.ac.nz [130.216.34.10]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f7MJKwN24234 for <[e-mail]>; Wed, 22 Aug 2001 12:20:58 -0700 (PDT)
Received: from ruru.cs.auckland.ac.nz (firebird.cs.auckland.ac.nz [130.216.34.12]) by kakapo.cs.auckland.ac.nz (8.8.6/8.8.6/cs-master) with ESMTP id HAA13553; Thu, 23 Aug 2001 07:20:20 +1200 (NZST) (sender [e-mail])
Received: (from pgut001@localhost) by ruru.cs.auckland.ac.nz (8.9.3/8.8.6/cs-slave) id HAA303664; Thu, 23 Aug 2001 07:20:10 +1200 (NZST) (sender [e-mail])
Date: Thu, 23 Aug 2001 07:20:10 +1200 (NZST)
Message-ID: <[e-mail]>
From: [e-mail] (Peter Gutmann)
To: [e-mail], [e-mail]
Subject: Re: New test TSA available
Cc: [e-mail], [e-mail]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>

tho <[e-mail]> writes:
>Peter Gutmann wrote:
>>>since the encapsulated content type is set to id-data, version
>>>field in SignedData is (`correctly' since (A)) set to 1 and not to 3
>> 
>>This one's deliberate, since CMS implementations are split 50/50 between
>>ones which ignore the version entirely and ones which require it to be
>>what PKCS #7 set it to, I always use the PKCS #7 version value because
>>that means it'll work with everything.
>
>i see the point, i also understand that version choice in SignedData is 
>somewhat a minor issue, but it would be nice if we all stick to cms rfc 
>rather than develop something broken just to permit interoperability with 
>other broken implementations

It's really a pragmatic decision, if I do what the RFC says I'll get
10,000 users complaining that my code is broken because $RANDOM_IMPLEMENTATION
doesn't work with it, if I ignore what the RFC says I'll get one person on a
mailing list :-) saying it's not right.  I'll accept the latter as less
painful.

(Obviously you can never do this for something critical like crypto-related 
 information, but for something as minor as a version number I doubt I'll be 
 going to hell for it).

>the former should be read taking into account the fact that the number of 
>tsp client at present is still rather small and developers are surely in 
>time to fix their bugs  :)) 

The problem is that my code (and I assume a lot of other code as well)
isn't only a TSA implementation, it's TSA built using generic PKCS #7/
CMS code, which means that "fixing" the TSA would require fixing an
arbitrarily large number of PKCS #7/CMS implementations.  I really have no
strong opinion either way, I'm just pointing out that the situation isn't
as straightforward as it seems.

Peter.


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f7MDwMs11248 for ietf-pkix-bks; Wed, 22 Aug 2001 06:58:22 -0700 (PDT)
Received: from SOTTMXS01.entrust.com (gatekeeper.entrust.com [204.101.128.170]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f7MDwIN11244 for <[e-mail]>; Wed, 22 Aug 2001 06:58:18 -0700 (PDT)
Received: by SOTTMXS01.entrust.com with Internet Mail Service (5.5.2650.21) id <Q8L2B7WX>; Wed, 22 Aug 2001 09:58:13 -0400
Message-ID: <[e-mail]>
From: Peter Hesse <[e-mail]>
To: "'Hiroyuki Sakakibara'" <[e-mail]>, "Housley, Russ" <[e-mail]>, Peter Hesse <[e-mail]>
Cc: [e-mail]
Subject: Path validation and self-signed certificates (was RE: Recommended changes to draft-ietf-pkix-new-part1-08)
Date: Wed, 22 Aug 2001 09:46:25 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C12B10.D5D40E80"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C12B10.D5D40E80
Content-Type: text/plain;
	charset="iso-8859-1"

Hiroyuki,

I will attempt to discuss a few of these issues inline.

> -----Original Message-----
> From: Hiroyuki Sakakibara [mailto:[e-mail]]
> Sent: Wednesday, August 22, 2001 1:51 AM
> To: Housley, Russ; Peter Hesse
> Cc: [e-mail]; [e-mail]; [e-mail];
> [e-mail]; [e-mail]
> Subject: Re: Recommended changes to draft-ietf-pkix-new-part1-08
> 
> 
> Hello. I have a comment related to path validation with a self-signed
> certificate.
> 
> I think that in 6.1  Basic Path Validation, it is not clear 
> that whether
> self-signed
> NON trust certificates may be included in a path or not.
> (namely intermediate self-signed certs, not oldWithNew, newWithOld)
>
> Plese note that I am not talking about a self-signed 
> certificate to begin a
> path,
> talking about self-signed certificates in the middle of a path.

I think this vagueness is somewhat purposeful.  It is not directly allowed
or prohibited.  Whether or not a self-signed certificate is found within the
path, the path is still complete.  Any benefit or detriment that comes from
having the self-signed certificate within the path will not always be
encountered for two reasons, 
	1) Other implementations may not allow the path to have a
self-signed certificate within it
	2) You may find the path without the self-signed certificate first

> 
> For example,
> 
> CA1 cross certifies with BridgeCA
> CA2 cross certifies with BridgeCA
> CA2 issues Cert_EE.(EndEntity cert)
> SelfSignedCert_CA1 is trust anchor.
> BridgeCA has a selfsigned certificate(SelfSignedCert_BridgeCA).
> 
> Based on the relation ship between issuer and subject or AKI/SKI,
> the following 2 paths would be constructed.
> 
> (1) SelfSignedCert_CA1 -> CrossCert_CA1toBridgeCA
>      ->  CrossCert_BridgeCAtoCA2 -> Cert_EE
> 
> (2) SelfSigned_CA1 -> CrossCert_CA1toBridgeCA
>     ->  SelfSignedCert_BridgeCA -> CrossCert_BridgeCAtoCA2 -> Cert_EE

I think it is a bad idea for Bridge CAs to post self-signed certificates in
the directory.  They are not a trust anchor for anyone, so they should not
publish a self-signed certificate as a key container.  However this point
and demonstration remain the same if you consider just three CAs that have
cross-certified without a bridge.
 
> I suppose that most validation softwares implement (1), simple one,
> and it could be a minimum requirement for interoperability.
> 
> In case of  (2), there is an advantage that a validation 
> software could
> check
> the status of SelfSignedCert_BridgeCA, shown in the appendix below.
> 
> So, I think that it should be clear that intermediate self-signed
> certificates may be
> included(optionally), or ignored,  in the document.
> I think that (1) is mandatory, and (2) is optional(not inhibited).
> 
> Folks, what do you think about this issue ?

Again, my opinion is that since both are complete paths, both are equally
valid and may be used by different implementations.  However, many
implementations have made a simplifying assumption to prevent certificate
path loops which would prevent #2 from ever being validated.  So any benefit
that might be gained by allowing #2 cannot be counted on.

There seems to be little benefit gained by including two or more
certificates with the same subject distinguished name and subject public key
within the same path.  I have looked through your examples below and must
admit I am not understanding them fully.  Let's look at this example

TR -> A -> B -> (B self signed) -> C -> EE

Let's say that A->B has a notAfter date of 12/31/2002, (B self signed) has a
notAfter date of 12/31/2001, and B->C has a notAfter date of 12/31/2002.  If
this path was developed and validated, the path would be invalid if the
current date was after  12/31/2001.

> * About ISO/IEC 9594-8
> 
> According to current ISO/IEC 9594-8 document, in 8.1.5 Self-Issued
> certificates
> it seems that intermediate self-signed certificates shall be 
> ignored in path
> construction/validation.
> However, considering  the advantage of checking intermediate 
> self-signed
> certificates shown below,
>  I don't understand why they "shall be ignored",
> because checking them would be meaningful from the point of view of
> security.
> 
> I think that investigation of intermediate self-signed 
> ceritificates may be
> optional,
> should not inhibited, so, "may be ignored" would be better.
> 
> This is not a mailing list for 9594-8, however RFC2459 
> related documents are
> based on
> 9594-8, so, I will also send my opinioin about it.
> 
> -------------------- Advantage of  validation of path
> (2) --------------------
> 
> If a validation software implements (2),
> the software could check the validity status of 
> SelfSignedCert_BridgeCA.
> 
> Assume that CA1 issues a cross certificate whose
> notAfter excess notAfter of self-signed certificate of BridgeCA.
> 
> such as
> notAfter of SelfSignedCert_BridgeCA is "2001/12/31"
> notAfter of CrossCert_CA1toBridgeCA  is "2002/12/31" .
> 
> when BridgeCA inhibits such cross certificate, it will be an invalid
> cross-certificate.
> 
> Useally, BridgeCA checks a cross-certificate from CA1 when issuance,
> however, if CA1 is a rough CA, or a bug CA(including mis-operations),
> after issuance of a valid cross certificate,
> CA1 could issue an additional invalid certificate and 
> distribute it to LDAP
> etc...
> without BrigeCA's permission .
> 
> ( In this case, for a RP, CA1 is a trust anchor, so, CA1 must 
> not be a rough
> CA, however, this kind of rough operation would happen in 
> another example.
> for example,
> 
> CA1(has self-signed cert, trust anchor) -> CA2(has 
> self-signed cert) -> CA3
> -> CA4( has self-signed cert)  -> EE
> 
> CA3 issues an invalid cross certificate to CA4.
> In this example, a trust anchor CA1 behaves properly, however,
> CA3 does rough operations. )
> 
> RP could check the revocation status of Cert_BridgeCASelfsigned also.
> 

In the case of self-signed revocation, I am not sure why a CA would revoke
itself.  If the CA was truly operating as a "rogue", it would not revoke
itself in order to keep whatever trust it still had.  Can you trust a CA
that revokes itself?  I am reminded of the old puzzle in which you encounter
two people at a crossroads, a truthteller and a liar.  You do not know which
is which, and must ask one of them a question in order to know if you should
turn left or right to get to where you want to go.  

--Peter

---------------------------------------------------------------- 
 Peter M. Hesse            CygnaCom Solutions, a division of
 Phone: [phone]                   Entrust
 ICQ:   1942828                 Securing the Internet
---------------------------------------------------------------- 
"Pay no attention to what the critics say; there has never been 
a statue set up in honor of a critic." --Jean Sibelius


> This kind of problem would happen in a multi CA products environment.
> 
> To avoid this problem, interoperability test, operation, management
> among multi CA products should be done well,
> or a RP should check the status of intermediate self-signed 
> certificates,
> or a CA which cross-certifies with other CAs should observe 
> behavior of
> other CAs, etc...?
> 

------_=_NextPart_001_01C12B10.D5D40E80
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2652.35">
<TITLE>Path validation and self-signed certificates (was RE: =
Recommended changes to draft-ietf-pkix-new-part1-08)</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>Hiroyuki,</FONT>
</P>

<P><FONT SIZE=3D2>I will attempt to discuss a few of these issues =
inline.</FONT>
</P>

<P><FONT SIZE=3D2>&gt; -----Original Message-----</FONT>
<BR><FONT SIZE=3D2>&gt; From: Hiroyuki Sakakibara [<A =
HREF=3D"mailto:[e-mail]">mailto:[e-mail].c=
o.jp</A>]</FONT>
<BR><FONT SIZE=3D2>&gt; Sent: Wednesday, August 22, 2001 1:51 AM</FONT>
<BR><FONT SIZE=3D2>&gt; To: Housley, Russ; Peter Hesse</FONT>
<BR><FONT SIZE=3D2>&gt; Cc: [e-mail]; [e-mail]; =
[e-mail];</FONT>
<BR><FONT SIZE=3D2>&gt; [e-mail]; [e-mail]</FONT>
<BR><FONT SIZE=3D2>&gt; Subject: Re: Recommended changes to =
draft-ietf-pkix-new-part1-08</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Hello. I have a comment related to path =
validation with a self-signed</FONT>
<BR><FONT SIZE=3D2>&gt; certificate.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; I think that in 6.1&nbsp; Basic Path =
Validation, it is not clear </FONT>
<BR><FONT SIZE=3D2>&gt; that whether</FONT>
<BR><FONT SIZE=3D2>&gt; self-signed</FONT>
<BR><FONT SIZE=3D2>&gt; NON trust certificates may be included in a =
path or not.</FONT>
<BR><FONT SIZE=3D2>&gt; (namely intermediate self-signed certs, not =
oldWithNew, newWithOld)</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt; Plese note that I am not talking about a =
self-signed </FONT>
<BR><FONT SIZE=3D2>&gt; certificate to begin a</FONT>
<BR><FONT SIZE=3D2>&gt; path,</FONT>
<BR><FONT SIZE=3D2>&gt; talking about self-signed certificates in the =
middle of a path.</FONT>
</P>

<P><FONT SIZE=3D2>I think this vagueness is somewhat purposeful.&nbsp; =
It is not directly allowed or prohibited.&nbsp; Whether or not a =
self-signed certificate is found within the path, the path is still =
complete.&nbsp; Any benefit or detriment that comes from having the =
self-signed certificate within the path will not always be encountered =
for two reasons, </FONT></P>

<P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2>1) Other =
implementations may not allow the path to have a self-signed =
certificate within it</FONT>
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2>2) You =
may find the path without the self-signed certificate first</FONT>
</P>

<P><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; For example,</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; CA1 cross certifies with BridgeCA</FONT>
<BR><FONT SIZE=3D2>&gt; CA2 cross certifies with BridgeCA</FONT>
<BR><FONT SIZE=3D2>&gt; CA2 issues Cert_EE.(EndEntity cert)</FONT>
<BR><FONT SIZE=3D2>&gt; SelfSignedCert_CA1 is trust anchor.</FONT>
<BR><FONT SIZE=3D2>&gt; BridgeCA has a selfsigned =
certificate(SelfSignedCert_BridgeCA).</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Based on the relation ship between issuer and =
subject or AKI/SKI,</FONT>
<BR><FONT SIZE=3D2>&gt; the following 2 paths would be =
constructed.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; (1) SelfSignedCert_CA1 -&gt; =
CrossCert_CA1toBridgeCA</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; -&gt;&nbsp; =
CrossCert_BridgeCAtoCA2 -&gt; Cert_EE</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; (2) SelfSigned_CA1 -&gt; =
CrossCert_CA1toBridgeCA</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp; -&gt;&nbsp; =
SelfSignedCert_BridgeCA -&gt; CrossCert_BridgeCAtoCA2 -&gt; =
Cert_EE</FONT>
</P>

<P><FONT SIZE=3D2>I think it is a bad idea for Bridge CAs to post =
self-signed certificates in the directory.&nbsp; They are not a trust =
anchor for anyone, so they should not publish a self-signed certificate =
as a key container.&nbsp; However this point and demonstration remain =
the same if you consider just three CAs that have cross-certified =
without a bridge.</FONT></P>

<P><FONT SIZE=3D2>&nbsp;</FONT>
<BR><FONT SIZE=3D2>&gt; I suppose that most validation softwares =
implement (1), simple one,</FONT>
<BR><FONT SIZE=3D2>&gt; and it could be a minimum requirement for =
interoperability.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; In case of&nbsp; (2), there is an advantage =
that a validation </FONT>
<BR><FONT SIZE=3D2>&gt; software could</FONT>
<BR><FONT SIZE=3D2>&gt; check</FONT>
<BR><FONT SIZE=3D2>&gt; the status of SelfSignedCert_BridgeCA, shown in =
the appendix below.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; So, I think that it should be clear that =
intermediate self-signed</FONT>
<BR><FONT SIZE=3D2>&gt; certificates may be</FONT>
<BR><FONT SIZE=3D2>&gt; included(optionally), or ignored,&nbsp; in the =
document.</FONT>
<BR><FONT SIZE=3D2>&gt; I think that (1) is mandatory, and (2) is =
optional(not inhibited).</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Folks, what do you think about this issue =
?</FONT>
</P>

<P><FONT SIZE=3D2>Again, my opinion is that since both are complete =
paths, both are equally valid and may be used by different =
implementations.&nbsp; However, many implementations have made a =
simplifying assumption to prevent certificate path loops which would =
prevent #2 from ever being validated.&nbsp; So any benefit that might =
be gained by allowing #2 cannot be counted on.</FONT></P>

<P><FONT SIZE=3D2>There seems to be little benefit gained by including =
two or more certificates with the same subject distinguished name and =
subject public key within the same path.&nbsp; I have looked through =
your examples below and must admit I am not understanding them =
fully.&nbsp; Let's look at this example</FONT></P>

<P><FONT SIZE=3D2>TR -&gt; A -&gt; B -&gt; (B self signed) -&gt; C =
-&gt; EE</FONT>
</P>

<P><FONT SIZE=3D2>Let's say that A-&gt;B has a notAfter date of =
12/31/2002, (B self signed) has a notAfter date of 12/31/2001, and =
B-&gt;C has a notAfter date of 12/31/2002.&nbsp; If this path was =
developed and validated, the path would be invalid if the current date =
was after&nbsp; 12/31/2001.</FONT></P>

<P><FONT SIZE=3D2>&gt; * About ISO/IEC 9594-8</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; According to current ISO/IEC 9594-8 document, =
in 8.1.5 Self-Issued</FONT>
<BR><FONT SIZE=3D2>&gt; certificates</FONT>
<BR><FONT SIZE=3D2>&gt; it seems that intermediate self-signed =
certificates shall be </FONT>
<BR><FONT SIZE=3D2>&gt; ignored in path</FONT>
<BR><FONT SIZE=3D2>&gt; construction/validation.</FONT>
<BR><FONT SIZE=3D2>&gt; However, considering&nbsp; the advantage of =
checking intermediate </FONT>
<BR><FONT SIZE=3D2>&gt; self-signed</FONT>
<BR><FONT SIZE=3D2>&gt; certificates shown below,</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; I don't understand why they &quot;shall =
be ignored&quot;,</FONT>
<BR><FONT SIZE=3D2>&gt; because checking them would be meaningful from =
the point of view of</FONT>
<BR><FONT SIZE=3D2>&gt; security.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; I think that investigation of intermediate =
self-signed </FONT>
<BR><FONT SIZE=3D2>&gt; ceritificates may be</FONT>
<BR><FONT SIZE=3D2>&gt; optional,</FONT>
<BR><FONT SIZE=3D2>&gt; should not inhibited, so, &quot;may be =
ignored&quot; would be better.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; This is not a mailing list for 9594-8, however =
RFC2459 </FONT>
<BR><FONT SIZE=3D2>&gt; related documents are</FONT>
<BR><FONT SIZE=3D2>&gt; based on</FONT>
<BR><FONT SIZE=3D2>&gt; 9594-8, so, I will also send my opinioin about =
it.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; -------------------- Advantage of&nbsp; =
validation of path</FONT>
<BR><FONT SIZE=3D2>&gt; (2) --------------------</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; If a validation software implements (2),</FONT>
<BR><FONT SIZE=3D2>&gt; the software could check the validity status of =
</FONT>
<BR><FONT SIZE=3D2>&gt; SelfSignedCert_BridgeCA.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Assume that CA1 issues a cross certificate =
whose</FONT>
<BR><FONT SIZE=3D2>&gt; notAfter excess notAfter of self-signed =
certificate of BridgeCA.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; such as</FONT>
<BR><FONT SIZE=3D2>&gt; notAfter of SelfSignedCert_BridgeCA is =
&quot;2001/12/31&quot;</FONT>
<BR><FONT SIZE=3D2>&gt; notAfter of CrossCert_CA1toBridgeCA&nbsp; is =
&quot;2002/12/31&quot; .</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; when BridgeCA inhibits such cross certificate, =
it will be an invalid</FONT>
<BR><FONT SIZE=3D2>&gt; cross-certificate.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Useally, BridgeCA checks a cross-certificate =
from CA1 when issuance,</FONT>
<BR><FONT SIZE=3D2>&gt; however, if CA1 is a rough CA, or a bug =
CA(including mis-operations),</FONT>
<BR><FONT SIZE=3D2>&gt; after issuance of a valid cross =
certificate,</FONT>
<BR><FONT SIZE=3D2>&gt; CA1 could issue an additional invalid =
certificate and </FONT>
<BR><FONT SIZE=3D2>&gt; distribute it to LDAP</FONT>
<BR><FONT SIZE=3D2>&gt; etc...</FONT>
<BR><FONT SIZE=3D2>&gt; without BrigeCA's permission .</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; ( In this case, for a RP, CA1 is a trust =
anchor, so, CA1 must </FONT>
<BR><FONT SIZE=3D2>&gt; not be a rough</FONT>
<BR><FONT SIZE=3D2>&gt; CA, however, this kind of rough operation would =
happen in </FONT>
<BR><FONT SIZE=3D2>&gt; another example.</FONT>
<BR><FONT SIZE=3D2>&gt; for example,</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; CA1(has self-signed cert, trust anchor) -&gt; =
CA2(has </FONT>
<BR><FONT SIZE=3D2>&gt; self-signed cert) -&gt; CA3</FONT>
<BR><FONT SIZE=3D2>&gt; -&gt; CA4( has self-signed cert)&nbsp; -&gt; =
EE</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; CA3 issues an invalid cross certificate to =
CA4.</FONT>
<BR><FONT SIZE=3D2>&gt; In this example, a trust anchor CA1 behaves =
properly, however,</FONT>
<BR><FONT SIZE=3D2>&gt; CA3 does rough operations. )</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; RP could check the revocation status of =
Cert_BridgeCASelfsigned also.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
</P>

<P><FONT SIZE=3D2>In the case of self-signed revocation, I am not sure =
why a CA would revoke itself.&nbsp; If the CA was truly operating as a =
&quot;rogue&quot;, it would not revoke itself in order to keep whatever =
trust it still had.&nbsp; Can you trust a CA that revokes itself?&nbsp; =
I am reminded of the old puzzle in which you encounter two people at a =
crossroads, a truthteller and a liar.&nbsp; You do not know which is =
which, and must ask one of them a question in order to know if you =
should turn left or right to get to where you want to go.&nbsp; =
</FONT></P>

<P><FONT SIZE=3D2>--Peter</FONT>
</P>

<P><FONT =
SIZE=3D2>---------------------------------------------------------------=
- </FONT>
<BR><FONT SIZE=3D2>&nbsp;Peter M. =
Hesse&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
CygnaCom Solutions, a division of</FONT>
<BR><FONT SIZE=3D2>&nbsp;Phone: =
703-270-3523&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Entrust</FONT>
<BR><FONT SIZE=3D2>&nbsp;ICQ:&nbsp;&nbsp; =
1942828&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Securing the Internet</FONT>
<BR><FONT =
SIZE=3D2>---------------------------------------------------------------=
- </FONT>
<BR><FONT SIZE=3D2>&quot;Pay no attention to what the critics say; =
there has never been </FONT>
<BR><FONT SIZE=3D2>a statue set up in honor of a critic.&quot; --Jean =
Sibelius</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>&gt; This kind of problem would happen in a multi CA =
products environment.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; To avoid this problem, interoperability test, =
operation, management</FONT>
<BR><FONT SIZE=3D2>&gt; among multi CA products should be done =
well,</FONT>
<BR><FONT SIZE=3D2>&gt; or a RP should check the status of intermediate =
self-signed </FONT>
<BR><FONT SIZE=3D2>&gt; certificates,</FONT>
<BR><FONT SIZE=3D2>&gt; or a CA which cross-certifies with other CAs =
should observe </FONT>
<BR><FONT SIZE=3D2>&gt; behavior of</FONT>
<BR><FONT SIZE=3D2>&gt; other CAs, etc...?</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C12B10.D5D40E80--


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f7MD4oS09984 for ietf-pkix-bks; Wed, 22 Aug 2001 06:04:50 -0700 (PDT)
Received: from edelweb.fr (edelweb.fr [212.234.46.16]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f7MD4lN09980 for <[e-mail]>; Wed, 22 Aug 2001 06:04:47 -0700 (PDT)
Received: from champagne.edelweb.fr (localhost.edelweb.fr [127.0.0.1]) by edelweb.fr with ESMTP id PAA06289 for <[e-mail]>; Wed, 22 Aug 2001 15:04:47 +0200 (MET DST)
Received: from champagne.edelweb.fr (champagne.edelweb.fr [193.51.14.161]) by edelweb.fr (nospam/1.3); Wed, 22 Aug 2001 15:04:48 +0200 (MET DST)
Received: from emeriau.edelweb.fr (emeriau.edelweb.fr [193.51.14.5]) by champagne.edelweb.fr (8.7.6/8.6.6) with ESMTP id PAA15396 for <[e-mail]>; Wed, 22 Aug 2001 15:04:46 +0200 (MET DST)
From: Peter Sylvester <[e-mail]>
Received: (sylvest@localhost) by emeriau.edelweb.fr (8.7.6/8.6.6) id PAA08679 for [e-mail]; Wed, 22 Aug 2001 15:04:46 +0200 (MET DST)
Date: Wed, 22 Aug 2001 15:04:46 +0200 (MET DST)
Message-Id: <[e-mail]>
To: [e-mail]
Subject: draft-ietf-pkix-new-part1-08
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>

Chapter 4.1.1.11 says:

   When applying restrictions of the form directoryName, an
   implementation MUST compare DN attributes.  At a minimum,
   implementations MUST perform the DN comparison rules specified in
   Section 4.1.2.4.  CAs issuing certificates with a restriction of the
   form directoryName SHOULD NOT rely on implementation of the full ISO
   DN name comparison algorithm.  This implies name restrictions shall
   be stated identically to the encoding used in the subject field or
   subjectAltName extension.

Does this mean that excludedSubtrees are practically unusable ? 


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f7MB2b802309 for ietf-pkix-bks; Wed, 22 Aug 2001 04:02:37 -0700 (PDT)
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f7MB2ZN02305 for <[e-mail]>; Wed, 22 Aug 2001 04:02:36 -0700 (PDT)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA29368; Wed, 22 Aug 2001 07:01:18 -0400 (EDT)
Message-Id: <[e-mail]>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: [e-mail]
From: [e-mail]
Reply-to: [e-mail]
Subject: I-D ACTION:draft-ietf-pkix-pkalgs-supp-00.txt
Date: Wed, 22 Aug 2001 07:01:17 -0400
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Public-Key Infrastructure (X.509) Working Group of the IETF.

	Title		: Supplemental Algorithms and Identifiers for the 
                          Internet X.509 Public Key Infrastructure Certificate 
                          and CRL Profile
	Author(s)	: A. Singer, W. Whyte
	Filename	: draft-ietf-pkix-pkalgs-supp-00.txt
	Pages		: 24
	Date		: 21-Aug-01
	
This document specifies algorithm identifiers and ASN.1 encoding 
formats for digital signatures and subject public keys, including 
NSS digital signatures and NTRU and NSS subject public keys used in 
the Internet X.509 Public Key Infrastructure (PKI).  Digital 
signatures are used to sign certificates and certificate revocation 
lists (CRLs).  Certificates include the public key of the named 
subject.  This document is intended to be a companion to draft-ietf-
pkix-ipki-pkalgs-03.txt [PKIX-ALGS] and may be merged with that 
document in future revisions if approved by the PKIX working group.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-pkix-pkalgs-supp-00.txt

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-pkix-pkalgs-supp-00.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[e-mail].
In the body type:
	"FILE /internet-drafts/draft-ietf-pkix-pkalgs-supp-00.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
		
		
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="[e-mail]"

Content-Type: text/plain
Content-ID:	<[e-mail]>

ENCODING mime
FILE /internet-drafts/draft-ietf-pkix-pkalgs-supp-00.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-pkix-pkalgs-supp-00.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<[e-mail]>

--OtherAccess--

--NextPart--




Received: by above.proper.com (8.11.3/8.11.3) id f7M9Jsc25052 for ietf-pkix-bks; Wed, 22 Aug 2001 02:19:54 -0700 (PDT)
Received: from firewall.andxor.it (firewall.andxor.it [195.223.2.2]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f7M9JpN25048 for <[e-mail]>; Wed, 22 Aug 2001 02:19:51 -0700 (PDT)
Received: from tho.andxor.com (tho.andxor.it [195.223.2.222]) by firewall.andxor.it (8.9.2/8.9.2) with ESMTP id LAA06615; Wed, 22 Aug 2001 11:19:50 +0200 (CEST) (envelope-from [e-mail])
Received: (from tho@localhost) by tho.andxor.com (8.9.3/8.9.3) id LAA24594; Wed, 22 Aug 2001 11:19:49 +0200 (CEST) (envelope-from tho)
Date: Wed, 22 Aug 2001 11:19:49 +0200
From: tho <[e-mail]>
To: Peter Gutmann <[e-mail]>
Cc: [e-mail], [e-mail]
Subject: Re: New test TSA available
Message-ID: <[e-mail]>
References: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2i
In-Reply-To: <[e-mail]>; from [e-mail] on Wed, Aug 22, 2001 at 12:03:49PM +1200
X-Operating-System: FreeBSD
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>

Peter Gutmann wrote:
> >since the encapsulated content type is set to id-data, version
> >field in SignedData is (`correctly' since (A)) set to 1 and not to 3
> 
> This one's deliberate, since CMS implementations are split 50/50 between
> ones which ignore the version entirely and ones which require it to be
> what PKCS #7 set it to, I always use the PKCS #7 version value because
> that means it'll work with everything.

i see the point, i also understand that version choice in SignedData is 
somewhat a minor issue, but it would be nice if we all stick to cms rfc 
rather than develop something broken just to permit interoperability with 
other broken implementations

the former should be read taking into account the fact that the number of 
tsp client at present is still rather small and developers are surely in 
time to fix their bugs  :)) 

my two bits, tho
-- 
(__)         
(oo)        
 \/-------\
  ||     | \  
  ||---W||  * 


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f7M5igC27606 for ietf-pkix-bks; Tue, 21 Aug 2001 22:44:42 -0700 (PDT)
Received: from mx01.melco.co.jp (mx01.melco.co.jp [192.218.140.41]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f7M5idN27600 for <[e-mail]>; Tue, 21 Aug 2001 22:44:40 -0700 (PDT)
Received: by mx01.melco.co.jp (mx01) id OAA28808; Wed, 22 Aug 2001 14:44:42 +0900 (JST)
Received: by mr02.melco.co.jp (mr02) id OAA12142; Wed, 22 Aug 2001 14:44:41 +0900 (JST)
Received: from elmail by elgw.isl.melco.co.jp (8.8.8/3.6W) id OAA13001; Wed, 22 Aug 2001 14:44:39 +0900 (JST)
Received: from iss.isl.melco.co.jp (iss.isl.melco.co.jp [10.74.5.60]) by elmail.isl.melco.co.jp (iPlanet Messaging Server 5.0 Patch 3 (built Mar 23 2001)) with ESMTP id <[e-mail]> for [e-mail]; Wed, 22 Aug 2001 14:44:36 +0900 (JST)
Received: from belize by iss.isl.melco.co.jp (8.8.8/3.6W) id OAA13443; Wed, 22 Aug 2001 14:44:36 +0900 (JST)
Date: Wed, 22 Aug 2001 14:50:44 +0900
From: Hiroyuki Sakakibara <[e-mail]>
Subject: Re: Recommended changes to draft-ietf-pkix-new-part1-08
To: "Housley, Russ" <[e-mail]>, Peter Hesse <[e-mail]>
Cc: [e-mail], [e-mail], [e-mail], [e-mail], [e-mail]
Message-id: <009b01c12ace$6277c310$[e-mail]>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
Content-type: text/plain; charset=iso-8859-1
Content-transfer-encoding: 7BIT
X-Priority: 3
X-MSMail-priority: Normal
References: <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>

Hello. I have a comment related to path validation with a self-signed
certificate.

I think that in 6.1  Basic Path Validation, it is not clear that whether
self-signed
NON trust certificates may be included in a path or not.
(namely intermediate self-signed certs, not oldWithNew, newWithOld)

Plese note that I am not talking about a self-signed certificate to begin a
path,
talking about self-signed certificates in the middle of a path.

For example,

CA1 cross certifies with BridgeCA
CA2 cross certifies with BridgeCA
CA2 issues Cert_EE.(EndEntity cert)
SelfSignedCert_CA1 is trust anchor.
BridgeCA has a selfsigned certificate(SelfSignedCert_BridgeCA).

Based on the relation ship between issuer and subject or AKI/SKI,
the following 2 paths would be constructed.

(1) SelfSignedCert_CA1 -> CrossCert_CA1toBridgeCA
     ->  CrossCert_BridgeCAtoCA2 -> Cert_EE

(2) SelfSigned_CA1 -> CrossCert_CA1toBridgeCA
    ->  SelfSignedCert_BridgeCA -> CrossCert_BridgeCAtoCA2 -> Cert_EE

I suppose that most validation softwares implement (1), simple one,
and it could be a minimum requirement for interoperability.

In case of  (2), there is an advantage that a validation software could
check
the status of SelfSignedCert_BridgeCA, shown in the appendix below.

So, I think that it should be clear that intermediate self-signed
certificates may be
included(optionally), or ignored,  in the document.
I think that (1) is mandatory, and (2) is optional(not inhibited).

Folks, what do you think about this issue ?


* About ISO/IEC 9594-8

According to current ISO/IEC 9594-8 document, in 8.1.5 Self-Issued
certificates
it seems that intermediate self-signed certificates shall be ignored in path
construction/validation.
However, considering  the advantage of checking intermediate self-signed
certificates shown below,
 I don't understand why they "shall be ignored",
because checking them would be meaningful from the point of view of
security.

I think that investigation of intermediate self-signed ceritificates may be
optional,
should not inhibited, so, "may be ignored" would be better.

This is not a mailing list for 9594-8, however RFC2459 related documents are
based on
9594-8, so, I will also send my opinioin about it.

-------------------- Advantage of  validation of path
(2) --------------------

If a validation software implements (2),
the software could check the validity status of SelfSignedCert_BridgeCA.

Assume that CA1 issues a cross certificate whose
notAfter excess notAfter of self-signed certificate of BridgeCA.

such as
notAfter of SelfSignedCert_BridgeCA is "2001/12/31"
notAfter of CrossCert_CA1toBridgeCA  is "2002/12/31" .

when BridgeCA inhibits such cross certificate, it will be an invalid
cross-certificate.

Useally, BridgeCA checks a cross-certificate from CA1 when issuance,
however, if CA1 is a rough CA, or a bug CA(including mis-operations),
after issuance of a valid cross certificate,
CA1 could issue an additional invalid certificate and distribute it to LDAP
etc...
without BrigeCA's permission .

( In this case, for a RP, CA1 is a trust anchor, so, CA1 must not be a rough
CA, however, this kind of rough operation would happen in another example.
for example,

CA1(has self-signed cert, trust anchor) -> CA2(has self-signed cert) -> CA3
-> CA4( has self-signed cert)  -> EE

CA3 issues an invalid cross certificate to CA4.
In this example, a trust anchor CA1 behaves properly, however,
CA3 does rough operations. )

RP could check the revocation status of Cert_BridgeCASelfsigned also.

This kind of problem would happen in a multi CA products environment.

To avoid this problem, interoperability test, operation, management
among multi CA products should be done well,
or a RP should check the status of intermediate self-signed certificates,
or a CA which cross-certifies with other CAs should observe behavior of
other CAs, etc...?

---------------------------------------
Hiroyuki Sakakibara
MITSUBISHI ELECTRIC CORPORATION
Information Technology R&D Center
5-1-1 Ofuna, Kamakura, Kanagawa, Japan
PHONE: [phone]
FAX:   [phone]
E-mail : [e-mail]




Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f7M04T919230 for ietf-pkix-bks; Tue, 21 Aug 2001 17:04:29 -0700 (PDT)
Received: from kakapo.cs.auckland.ac.nz (kakapo.cs.auckland.ac.nz [130.216.34.10]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f7M04RN19225 for <[e-mail]>; Tue, 21 Aug 2001 17:04:27 -0700 (PDT)
Received: from ruru.cs.auckland.ac.nz (firebird.cs.auckland.ac.nz [130.216.34.12]) by kakapo.cs.auckland.ac.nz (8.8.6/8.8.6/cs-master) with ESMTP id MAA05657; Wed, 22 Aug 2001 12:03:49 +1200 (NZST) (sender [e-mail])
Received: (from pgut001@localhost) by ruru.cs.auckland.ac.nz (8.9.3/8.8.6/cs-slave) id MAA281047; Wed, 22 Aug 2001 12:03:49 +1200 (NZST) (sender [e-mail])
Date: Wed, 22 Aug 2001 12:03:49 +1200 (NZST)
Message-ID: <[e-mail]>
From: [e-mail] (Peter Gutmann)
To: [e-mail], [e-mail]
Subject: Re: New test TSA available
Cc: [e-mail], [e-mail]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>

tho <[e-mail]> writes:

>(A) draft-ietf-pkix-time-stamp-15 states that eContentType for a time
>    stamping token should be id-ct-TSTInfo why is it instead set to
>    id-data ?

Probably because the implementation was done back when draft-06 or
something was current :-).  This is also why various other things
required by newer drafts aren't present, I'll fix this when I next
update the code (because of the environment it's in, there's a bit of
latency involved when making changes).

>since the encapsulated content type is set to id-data, version
>field in SignedData is (`correctly' since (A)) set to 1 and not to 3

This one's deliberate, since CMS implementations are split 50/50 between
ones which ignore the version entirely and ones which require it to be
what PKCS #7 set it to, I always use the PKCS #7 version value because
that means it'll work with everything.

>signatureAlgorithm in SignerInfo is rsaEncryption, shouldn't it be more
>likely sha1withRSAEncryption ?

Since the CMS signature splits the hash and signing algorithm, the first
OID is a pure hash (SHA-1) and the second is a pure signature algorithm
(RSA).

Peter.


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f7LMEOo17404 for ietf-pkix-bks; Tue, 21 Aug 2001 15:14:24 -0700 (PDT)
Received: from tholian.securitydynamics.com (mail.rsasecurity.com [204.167.112.129]) by above.proper.com (8.11.3/8.11.3) with SMTP id f7LMEMN17400 for <[e-mail]>; Tue, 21 Aug 2001 15:14:22 -0700 (PDT)
Received: from sdtihq24.securitydynamics.com by tholian.securitydynamics.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 21 Aug 2001 22:12:07 UT
Received: from tuna.rsa.com (tuna.rsa.com [10.80.211.153]) by sdtihq24.securid.com (Pro-8.9.3/Pro-8.9.3) with ESMTP id SAA20614 for <[e-mail]>; Tue, 21 Aug 2001 18:13:47 -0400 (EDT)
Received: from rsasecurity.com ([10.81.217.242]) by tuna.rsa.com (8.8.8+Sun/8.8.8) with ESMTP id PAA01725 for <[e-mail]>; Tue, 21 Aug 2001 15:16:22 -0700 (PDT)
Message-ID: <[e-mail]>
Date: Tue, 21 Aug 2001 15:12:26 -0700
From: Jeff Jacoby <[e-mail]>
Organization: RSA Security, Inc.
X-Mailer: Mozilla 4.75 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: "'[e-mail]'" <[e-mail]>
Subject: Re: Recommended changes to draft-ietf-pkix-new-part1-08
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>

To all,

Jumping on the bandwagon here...

There are three points I believe could use clarification (at least 
I'm having trouble grokking them).

Section 6.1.4 Preperation for certificate i+1, step (b)(1). the
second paragraph reads:

  "If no node of depth i in the valid_policy_tree has a
   valid_policy of ID-P but there is a node of depth i with a
   valid_policy of any-policy, then generate a child node of the
   node of depth i-1 that has a valid_policy of any-policy as
   follows:"

Should it really be:

  "If no node of depth i in the valid_policy_tree has a
   valid_policy of ID-P but there is a node of depth i-1 with a
   valid_policy of any-policy, then generate a child node of the
   node of depth i-1 that has a valid_policy of any-policy as
   follows:"

(note the difference in the first sentence, "i" vs "i-1").  Afterall,
the last sentence implies there must be a node of depth i-1 with a
valid_policy of any-policy.



Second issue is a simple typo.  The very last sentence in section 6.1.4
reads:

  "If (a), (k), (l), (n) and (o) have completed successfully, increment
   i and perform the basic certificate processing specified in 6.1.2."

it should be:

  "If (a), (k), (l), (n) and (o) have completed successfully, increment
   i and perform the basic certificate processing specified in 6.1.3."

(6.1.2 is Initialization)



Finally, in the wrap-up description, section 6.1.5 step (g)(iii) 1.
reads:

  "1.  Determine the set of policy nodes whose ancestor nodes
   have a valid_policy of any-policy.  This is the
valid_policy_node_set."

Since the root node (depth 0) has valid_policy of any-policy, and it is
an ancestor to every node in the tree, this would seem to mean (to me)
the whole tree is in the valid_policy_node_set.  Or does "ancestor node"
mean something different?

Thanks,

Jeff

-- 
Jeff Jacoby, Sr. Programmer                
RSA Security Inc., SMDC                    [e-mail]
2755 Campus Dr., Ste. 300                  [phone]
San Mateo, CA  94403


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f7LKt7g15768 for ietf-pkix-bks; Tue, 21 Aug 2001 13:55:07 -0700 (PDT)
Received: from tholian.securitydynamics.com (mail.rsasecurity.com [204.167.112.129]) by above.proper.com (8.11.3/8.11.3) with SMTP id f7LKt0N15763 for <[e-mail]>; Tue, 21 Aug 2001 13:55:00 -0700 (PDT)
Received: from sdtihq24.securid.com by tholian.securitydynamics.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 21 Aug 2001 20:52:45 UT
Received: from exna00.securitydynamics.com (ebola.securid.com [192.168.7.4]) by sdtihq24.securid.com (Pro-8.9.3/Pro-8.9.3) with ESMTP id QAA13071; Tue, 21 Aug 2001 16:54:01 -0400 (EDT)
Received: by exna00.securitydynamics.com with Internet Mail Service (5.5.2653.19) id <QTWCP8MV>; Tue, 21 Aug 2001 16:54:38 -0400
Received: from HOUSLEY-LAP.rsasecurity.com (HOUSLEY-LAP [10.3.1.134]) by exna00.securitydynamics.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id QTWCP8MP; Tue, 21 Aug 2001 16:54:32 -0400
From: "Housley, Russ" <[e-mail]>
To: Peter Hesse <[e-mail]>
Cc: [e-mail], [e-mail], [e-mail], [e-mail], [e-mail]
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.0.1
Date: Tue, 21 Aug 2001 16:54:22 -0400
Subject: RE: Recommended changes to draft-ietf-pkix-new-part1-08
In-Reply-To: <[e-mail]. com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>

Peter:

Thanks for providing the context for your comments.  Tim Polk is on 
vacation this week.  I will get with him when he returns, and add some 
clarifying editorial text.

Russ


At 04:32 PM 8/21/2001 -0400, Peter Hesse wrote:

>Russ,
>
>I agree with the fact that we must allow self-issued certificates to begin 
>the path.  However, I was saying self-signed, by which I meant "signed by 
>the private key that goes with the public key in the certificate".  I'm 
>not sure if there is a need to have the self-signed certificate in the 
>path, but I agree with Steve's point that we don't need to forbid it, we 
>should recommend against it.
>
>The idea with my second point was to let validation systems know that "all 
>certificates in the path" did not necessarily include the self-signed 
>trusted root certificate.
>
>The reason this all came up is that during the Bridge CA Phase II 
>demonstration, we had a PKI that was supposed to issue a name constraint 
>in their certificate issued to the Bridge, to limit the namespace for 
>their relying parties.  They placed this name constraint in their 
>self-signed certificate instead of the cross-certificate.  Their clients 
>were all fine with this processing, but when another party tried to 
>validate the same path using a different algorithm (that ignored the 
>self-signed certificate extensions) a different result was obtained.   It 
>is this lack of interoperability that I am striving to avoid with a little 
>more clarification text.
>
>If I need to be clearer please let me know and I'll try.
>
>--Peter
>
>----------------------------------------------------------------
>  Peter M. Hesse            CygnaCom Solutions, a division of
>  Phone: [phone]                   Entrust
>  ICQ:   1942828                 Securing the Internet
>----------------------------------------------------------------
>"Pay no attention to what the critics say; there has never been
>a statue set up in honor of a critic." --Jean Sibelius
>
>-----Original Message-----
>From: Housley, Russ 
>[<mailto:[e-mail]>mailto:[e-mail]]
>Sent: Tuesday, August 21, 2001 3:03 PM
>To: Peter Hesse
>Cc: [e-mail]; [e-mail]; [e-mail];
>[e-mail]; [e-mail]
>Subject: Re: Recommended changes to draft-ietf-pkix-new-part1-08
>
>
>Peter:
>
>I am not sure that I agree with your points, but maybe I do not fully
>understand your points.
>
>Regarding the first change, I believe that we must allow the first
>certificate to be self-issued.  How else can key roll over at a root
>authority be accomplished.  Several documents describe the
>old-signed-with-new and new-signed-with-old approach.  And, the certificate
>path validation algorithm includes several feature just to accommodate this
>key rollover technique.
>
>Regarding the second change, I think that section 6.1 provides the
>context.  There is even a ASCII-art flow chart in Figure 2.  I think that
>the text that goes with Figure 2 covers your point.  It says: "Step (2) is
>performed for all certificates in the path."  However, if other people
>think that a working change would make this point more clear, I am willing
>to make an editorial change.  The whole point is to communicate as clearly
>as possible.
>
>Russ
>
>At 10:24 AM 8/21/2001 -0400, Peter Hesse wrote:
>
> >All,
> >
> >I realize these comments are coming quite late in the process, and I hope
> >not to cause too much of a problem.  However, I feel that standards need
> >to be quite explicit in certain areas, and the current draft of the
> >Internet X.509 Public Key Infrastructure Certificate and CRL Profile (son
> >of 2459) is still a bit ambiguous when it comes to processing self-signed
> >trust anchor certificates.  I propose two changes in order to reduce this
> >ambiguity.  First I will quote from the current draft, section 6.1:
> >
> >--------------------------------------------------------------------------
> >    To meet this goal, the path validation process verifies, among other
> >    things, that a prospective certification path (a sequence of n
> >    certificates) satisfies the following conditions:
> >
> >       (a)  for all x in {1, ..., n-1}, the subject of certificate x is
> >       the issuer of certificate x+1;
> >
> >       (b)  certificate 1 is issued by the trust anchor;
> >
> >       (c)  certificate n is the certificate to be validated; and
> >
> >       (d)  for all x in {1, ..., n}, the certificate was valid at the
> >       time in question.
> >--------------------------------------------------------------------------
> >
> >In my opinion, (b) should be changed to explicity specify that certificate
> >1 is not a self-signed certificate issued by the trust anchor.
> >
> >The second change is needed because the logic of section 6.1 does not
> >specifically say what certificates are subject to the validation
> >processing other than the part quoted above.  My second recommendation is
> >to change the beginning of 6.1.3 to the following:
> >
> >--------------------------------------------------------------------------
> >The basic path processing actions to be performed for certificate i
> >(for all i in [1...n]) are listed below.
> >--------------------------------------------------------------------------
> >
> >These changes would allow certainty that
> >- certificate 1 is not the self-signed trust anchor certificate
> >- only certificates 1...n are processed, therefore explicitly not
> >processing a self-signed trust anchor certificate if one exists in the 
> path.
> >
> >Again, apologies for bringing this up so late, but I feel this issue is
> >quite important for interoperability between path validation 
> implementations.
> >
> >--Peter
> >
> >----------------------------------------------------------------
> >  Peter M. Hesse            CygnaCom Solutions, a division of
> >  Phone: [phone]                   Entrust
> >  ICQ:   1942828                 Securing the Internet
> >----------------------------------------------------------------
> >"Pay no attention to what the critics say; there has never been
> >a statue set up in honor of a critic." --Jean Sibelius


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f7LKieB15511 for ietf-pkix-bks; Tue, 21 Aug 2001 13:44:40 -0700 (PDT)
Received: from SOTTMXS01.entrust.com (gatekeeper.entrust.com [204.101.128.170]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f7LKibN15507 for <[e-mail]>; Tue, 21 Aug 2001 13:44:37 -0700 (PDT)
Received: by SOTTMXS01.entrust.com with Internet Mail Service (5.5.2650.21) id <Q8L2BWT1>; Tue, 21 Aug 2001 16:44:33 -0400
Message-ID: <[e-mail]>
From: Peter Hesse <[e-mail]>
To: "'Housley, Russ'" <[e-mail]>, Peter Hesse <[e-mail]>
Cc: [e-mail], [e-mail], [e-mail], [e-mail], [e-mail]
Subject: RE: Recommended changes to draft-ietf-pkix-new-part1-08
Date: Tue, 21 Aug 2001 16:32:44 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C12A80.6EFD7790"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C12A80.6EFD7790
Content-Type: text/plain

Russ,

I agree with the fact that we must allow self-issued certificates to begin
the path.  However, I was saying self-signed, by which I meant "signed by
the private key that goes with the public key in the certificate".  I'm not
sure if there is a need to have the self-signed certificate in the path, but
I agree with Steve's point that we don't need to forbid it, we should
recommend against it.

The idea with my second point was to let validation systems know that "all
certificates in the path" did not necessarily include the self-signed
trusted root certificate.

The reason this all came up is that during the Bridge CA Phase II
demonstration, we had a PKI that was supposed to issue a name constraint in
their certificate issued to the Bridge, to limit the namespace for their
relying parties.  They placed this name constraint in their self-signed
certificate instead of the cross-certificate.  Their clients were all fine
with this processing, but when another party tried to validate the same path
using a different algorithm (that ignored the self-signed certificate
extensions) a different result was obtained.   It is this lack of
interoperability that I am striving to avoid with a little more
clarification text.

If I need to be clearer please let me know and I'll try.

--Peter

---------------------------------------------------------------- 
 Peter M. Hesse            CygnaCom Solutions, a division of
 Phone: [phone]                   Entrust
 ICQ:   1942828                 Securing the Internet
---------------------------------------------------------------- 
"Pay no attention to what the critics say; there has never been 
a statue set up in honor of a critic." --Jean Sibelius


-----Original Message-----
From: Housley, Russ [mailto:[e-mail]]
Sent: Tuesday, August 21, 2001 3:03 PM
To: Peter Hesse
Cc: [e-mail]; [e-mail]; [e-mail];
[e-mail]; [e-mail]
Subject: Re: Recommended changes to draft-ietf-pkix-new-part1-08



Peter:

I am not sure that I agree with your points, but maybe I do not fully 
understand your points.

Regarding the first change, I believe that we must allow the first 
certificate to be self-issued.  How else can key roll over at a root 
authority be accomplished.  Several documents describe the 
old-signed-with-new and new-signed-with-old approach.  And, the certificate 
path validation algorithm includes several feature just to accommodate this 
key rollover technique.

Regarding the second change, I think that section 6.1 provides the 
context.  There is even a ASCII-art flow chart in Figure 2.  I think that 
the text that goes with Figure 2 covers your point.  It says: "Step (2) is 
performed for all certificates in the path."  However, if other people 
think that a working change would make this point more clear, I am willing 
to make an editorial change.  The whole point is to communicate as clearly 
as possible.

Russ


At 10:24 AM 8/21/2001 -0400, Peter Hesse wrote:

>All,
>
>I realize these comments are coming quite late in the process, and I hope 
>not to cause too much of a problem.  However, I feel that standards need 
>to be quite explicit in certain areas, and the current draft of the 
>Internet X.509 Public Key Infrastructure Certificate and CRL Profile (son 
>of 2459) is still a bit ambiguous when it comes to processing self-signed 
>trust anchor certificates.  I propose two changes in order to reduce this 
>ambiguity.  First I will quote from the current draft, section 6.1:
>
>--------------------------------------------------------------------------
>    To meet this goal, the path validation process verifies, among other
>    things, that a prospective certification path (a sequence of n
>    certificates) satisfies the following conditions:
>
>       (a)  for all x in {1, ..., n-1}, the subject of certificate x is
>       the issuer of certificate x+1;
>
>       (b)  certificate 1 is issued by the trust anchor;
>
>       (c)  certificate n is the certificate to be validated; and
>
>       (d)  for all x in {1, ..., n}, the certificate was valid at the
>       time in question.
>--------------------------------------------------------------------------
>
>In my opinion, (b) should be changed to explicity specify that certificate 
>1 is not a self-signed certificate issued by the trust anchor.
>
>The second change is needed because the logic of section 6.1 does not 
>specifically say what certificates are subject to the validation 
>processing other than the part quoted above.  My second recommendation is 
>to change the beginning of 6.1.3 to the following:
>
>--------------------------------------------------------------------------
>The basic path processing actions to be performed for certificate i
>(for all i in [1...n]) are listed below.
>--------------------------------------------------------------------------
>
>These changes would allow certainty that
>- certificate 1 is not the self-signed trust anchor certificate
>- only certificates 1...n are processed, therefore explicitly not 
>processing a self-signed trust anchor certificate if one exists in the
path.
>
>Again, apologies for bringing this up so late, but I feel this issue is 
>quite important for interoperability between path validation
implementations.
>
>--Peter
>
>----------------------------------------------------------------
>  Peter M. Hesse            CygnaCom Solutions, a division of
>  Phone: [phone]                   Entrust
>  ICQ:   1942828                 Securing the Internet
>----------------------------------------------------------------
>"Pay no attention to what the critics say; there has never been
>a statue set up in honor of a critic." --Jean Sibelius

------_=_NextPart_001_01C12A80.6EFD7790
Content-Type: text/html
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3DUS-ASCII">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2652.35">
<TITLE>RE: Recommended changes to draft-ietf-pkix-new-part1-08</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>Russ,</FONT>
</P>

<P><FONT SIZE=3D2>I agree with the fact that we must allow self-issued =
certificates to begin the path.&nbsp; However, I was saying =
self-signed, by which I meant &quot;signed by the private key that goes =
with the public key in the certificate&quot;.&nbsp; I'm not sure if =
there is a need to have the self-signed certificate in the path, but I =
agree with Steve's point that we don't need to forbid it, we should =
recommend against it.</FONT></P>

<P><FONT SIZE=3D2>The idea with my second point was to let validation =
systems know that &quot;all certificates in the path&quot; did not =
necessarily include the self-signed trusted root =
certificate.</FONT></P>

<P><FONT SIZE=3D2>The reason this all came up is that during the Bridge =
CA Phase II demonstration, we had a PKI that was supposed to issue a =
name constraint in their certificate issued to the Bridge, to limit the =
namespace for their relying parties.&nbsp; They placed this name =
constraint in their self-signed certificate instead of the =
cross-certificate.&nbsp; Their clients were all fine with this =
processing, but when another party tried to validate the same path =
using a different algorithm (that ignored the self-signed certificate =
extensions) a different result was obtained.&nbsp;&nbsp; It is this =
lack of interoperability that I am striving to avoid with a little more =
clarification text.</FONT></P>

<P><FONT SIZE=3D2>If I need to be clearer please let me know and I'll =
try.</FONT>
</P>

<P><FONT SIZE=3D2>--Peter</FONT>
</P>

<P><FONT =
SIZE=3D2>---------------------------------------------------------------=
- </FONT>
<BR><FONT SIZE=3D2>&nbsp;Peter M. =
Hesse&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
CygnaCom Solutions, a division of</FONT>
<BR><FONT SIZE=3D2>&nbsp;Phone: =
703-270-3523&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Entrust</FONT>
<BR><FONT SIZE=3D2>&nbsp;ICQ:&nbsp;&nbsp; =
1942828&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Securing the Internet</FONT>
<BR><FONT =
SIZE=3D2>---------------------------------------------------------------=
- </FONT>
<BR><FONT SIZE=3D2>&quot;Pay no attention to what the critics say; =
there has never been </FONT>
<BR><FONT SIZE=3D2>a statue set up in honor of a critic.&quot; --Jean =
Sibelius</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>-----Original Message-----</FONT>
<BR><FONT SIZE=3D2>From: Housley, Russ [<A =
HREF=3D"mailto:[e-mail]">mailto:[e-mail]=
</A>]</FONT>
<BR><FONT SIZE=3D2>Sent: Tuesday, August 21, 2001 3:03 PM</FONT>
<BR><FONT SIZE=3D2>To: Peter Hesse</FONT>
<BR><FONT SIZE=3D2>Cc: [e-mail]; [e-mail]; =
[e-mail];</FONT>
<BR><FONT SIZE=3D2>[e-mail]; [e-mail]</FONT>
<BR><FONT SIZE=3D2>Subject: Re: Recommended changes to =
draft-ietf-pkix-new-part1-08</FONT>
</P>
<BR>
<BR>

<P><FONT SIZE=3D2>Peter:</FONT>
</P>

<P><FONT SIZE=3D2>I am not sure that I agree with your points, but =
maybe I do not fully </FONT>
<BR><FONT SIZE=3D2>understand your points.</FONT>
</P>

<P><FONT SIZE=3D2>Regarding the first change, I believe that we must =
allow the first </FONT>
<BR><FONT SIZE=3D2>certificate to be self-issued.&nbsp; How else can =
key roll over at a root </FONT>
<BR><FONT SIZE=3D2>authority be accomplished.&nbsp; Several documents =
describe the </FONT>
<BR><FONT SIZE=3D2>old-signed-with-new and new-signed-with-old =
approach.&nbsp; And, the certificate </FONT>
<BR><FONT SIZE=3D2>path validation algorithm includes several feature =
just to accommodate this </FONT>
<BR><FONT SIZE=3D2>key rollover technique.</FONT>
</P>

<P><FONT SIZE=3D2>Regarding the second change, I think that section 6.1 =
provides the </FONT>
<BR><FONT SIZE=3D2>context.&nbsp; There is even a ASCII-art flow chart =
in Figure 2.&nbsp; I think that </FONT>
<BR><FONT SIZE=3D2>the text that goes with Figure 2 covers your =
point.&nbsp; It says: &quot;Step (2) is </FONT>
<BR><FONT SIZE=3D2>performed for all certificates in the =
path.&quot;&nbsp; However, if other people </FONT>
<BR><FONT SIZE=3D2>think that a working change would make this point =
more clear, I am willing </FONT>
<BR><FONT SIZE=3D2>to make an editorial change.&nbsp; The whole point =
is to communicate as clearly </FONT>
<BR><FONT SIZE=3D2>as possible.</FONT>
</P>

<P><FONT SIZE=3D2>Russ</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>At 10:24 AM 8/21/2001 -0400, Peter Hesse =
wrote:</FONT>
</P>

<P><FONT SIZE=3D2>&gt;All,</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;I realize these comments are coming quite late =
in the process, and I hope </FONT>
<BR><FONT SIZE=3D2>&gt;not to cause too much of a problem.&nbsp; =
However, I feel that standards need </FONT>
<BR><FONT SIZE=3D2>&gt;to be quite explicit in certain areas, and the =
current draft of the </FONT>
<BR><FONT SIZE=3D2>&gt;Internet X.509 Public Key Infrastructure =
Certificate and CRL Profile (son </FONT>
<BR><FONT SIZE=3D2>&gt;of 2459) is still a bit ambiguous when it comes =
to processing self-signed </FONT>
<BR><FONT SIZE=3D2>&gt;trust anchor certificates.&nbsp; I propose two =
changes in order to reduce this </FONT>
<BR><FONT SIZE=3D2>&gt;ambiguity.&nbsp; First I will quote from the =
current draft, section 6.1:</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT =
SIZE=3D2>&gt;-----------------------------------------------------------=
---------------</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp; To meet this goal, the path =
validation process verifies, among other</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp; things, that a prospective =
certification path (a sequence of n</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp; certificates) satisfies the =
following conditions:</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; (a)&nbsp; =
for all x in {1, ..., n-1}, the subject of certificate x is</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; the issuer =
of certificate x+1;</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; (b)&nbsp; =
certificate 1 is issued by the trust anchor;</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; (c)&nbsp; =
certificate n is the certificate to be validated; and</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; (d)&nbsp; =
for all x in {1, ..., n}, the certificate was valid at the</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; time in =
question.</FONT>
<BR><FONT =
SIZE=3D2>&gt;-----------------------------------------------------------=
---------------</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;In my opinion, (b) should be changed to =
explicity specify that certificate </FONT>
<BR><FONT SIZE=3D2>&gt;1 is not a self-signed certificate issued by the =
trust anchor.</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;The second change is needed because the logic of =
section 6.1 does not </FONT>
<BR><FONT SIZE=3D2>&gt;specifically say what certificates are subject =
to the validation </FONT>
<BR><FONT SIZE=3D2>&gt;processing other than the part quoted =
above.&nbsp; My second recommendation is </FONT>
<BR><FONT SIZE=3D2>&gt;to change the beginning of 6.1.3 to the =
following:</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT =
SIZE=3D2>&gt;-----------------------------------------------------------=
---------------</FONT>
<BR><FONT SIZE=3D2>&gt;The basic path processing actions to be =
performed for certificate i</FONT>
<BR><FONT SIZE=3D2>&gt;(for all i in [1...n]) are listed below.</FONT>
<BR><FONT SIZE=3D2>&gt;-------------------------------------------------=
-------------------------</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;These changes would allow certainty that</FONT>
<BR><FONT SIZE=3D2>&gt;- certificate 1 is not the self-signed trust =
anchor certificate</FONT>
<BR><FONT SIZE=3D2>&gt;- only certificates 1...n are processed, =
therefore explicitly not </FONT>
<BR><FONT SIZE=3D2>&gt;processing a self-signed trust anchor =
certificate if one exists in the path.</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;Again, apologies for bringing this up so late, =
but I feel this issue is </FONT>
<BR><FONT SIZE=3D2>&gt;quite important for interoperability between =
path validation implementations.</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;--Peter</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT =
SIZE=3D2>&gt;-----------------------------------------------------------=
-----</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; Peter M. =
Hesse&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
CygnaCom Solutions, a division of</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; Phone: =
703-270-3523&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Entrust</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; ICQ:&nbsp;&nbsp; =
1942828&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Securing the Internet</FONT>
<BR><FONT =
SIZE=3D2>&gt;-----------------------------------------------------------=
-----</FONT>
<BR><FONT SIZE=3D2>&gt;&quot;Pay no attention to what the critics say; =
there has never been</FONT>
<BR><FONT SIZE=3D2>&gt;a statue set up in honor of a critic.&quot; =
--Jean Sibelius</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C12A80.6EFD7790--


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f7LJ4g511090 for ietf-pkix-bks; Tue, 21 Aug 2001 12:04:42 -0700 (PDT)
Received: from tholian.securitydynamics.com (mail.rsasecurity.com [204.167.112.129]) by above.proper.com (8.11.3/8.11.3) with SMTP id f7LJ4eN11086 for <[e-mail]>; Tue, 21 Aug 2001 12:04:40 -0700 (PDT)
Received: from sdtihq24.securid.com by tholian.securitydynamics.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 21 Aug 2001 19:02:25 UT
Received: from exna00.securitydynamics.com (ebola.securid.com [192.168.7.4]) by sdtihq24.securid.com (Pro-8.9.3/Pro-8.9.3) with ESMTP id PAA03591; Tue, 21 Aug 2001 15:03:42 -0400 (EDT)
Received: by exna00.securitydynamics.com with Internet Mail Service (5.5.2653.19) id <QTWCP51F>; Tue, 21 Aug 2001 15:04:18 -0400
Received: from HOUSLEY-LAP.rsasecurity.com (HOUSLEY-LAP [10.3.1.36]) by exna00.securitydynamics.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id QTWCP5D6; Tue, 21 Aug 2001 15:04:06 -0400
From: "Housley, Russ" <[e-mail]>
To: Peter Hesse <[e-mail]>
Cc: [e-mail], [e-mail], [e-mail], [e-mail], [e-mail]
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.0.1
Date: Tue, 21 Aug 2001 15:02:49 -0400
Subject: Re: Recommended changes to draft-ietf-pkix-new-part1-08
In-Reply-To: <[e-mail]. com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>

Peter:

I am not sure that I agree with your points, but maybe I do not fully 
understand your points.

Regarding the first change, I believe that we must allow the first 
certificate to be self-issued.  How else can key roll over at a root 
authority be accomplished.  Several documents describe the 
old-signed-with-new and new-signed-with-old approach.  And, the certificate 
path validation algorithm includes several feature just to accommodate this 
key rollover technique.

Regarding the second change, I think that section 6.1 provides the 
context.  There is even a ASCII-art flow chart in Figure 2.  I think that 
the text that goes with Figure 2 covers your point.  It says: "Step (2) is 
performed for all certificates in the path."  However, if other people 
think that a working change would make this point more clear, I am willing 
to make an editorial change.  The whole point is to communicate as clearly 
as possible.

Russ


At 10:24 AM 8/21/2001 -0400, Peter Hesse wrote:

>All,
>
>I realize these comments are coming quite late in the process, and I hope 
>not to cause too much of a problem.  However, I feel that standards need 
>to be quite explicit in certain areas, and the current draft of the 
>Internet X.509 Public Key Infrastructure Certificate and CRL Profile (son 
>of 2459) is still a bit ambiguous when it comes to processing self-signed 
>trust anchor certificates.  I propose two changes in order to reduce this 
>ambiguity.  First I will quote from the current draft, section 6.1:
>
>--------------------------------------------------------------------------
>    To meet this goal, the path validation process verifies, among other
>    things, that a prospective certification path (a sequence of n
>    certificates) satisfies the following conditions:
>
>       (a)  for all x in {1, ..., n-1}, the subject of certificate x is
>       the issuer of certificate x+1;
>
>       (b)  certificate 1 is issued by the trust anchor;
>
>       (c)  certificate n is the certificate to be validated; and
>
>       (d)  for all x in {1, ..., n}, the certificate was valid at the
>       time in question.
>--------------------------------------------------------------------------
>
>In my opinion, (b) should be changed to explicity specify that certificate 
>1 is not a self-signed certificate issued by the trust anchor.
>
>The second change is needed because the logic of section 6.1 does not 
>specifically say what certificates are subject to the validation 
>processing other than the part quoted above.  My second recommendation is 
>to change the beginning of 6.1.3 to the following:
>
>--------------------------------------------------------------------------
>The basic path processing actions to be performed for certificate i
>(for all i in [1...n]) are listed below.
>--------------------------------------------------------------------------
>
>These changes would allow certainty that
>- certificate 1 is not the self-signed trust anchor certificate
>- only certificates 1...n are processed, therefore explicitly not 
>processing a self-signed trust anchor certificate if one exists in the path.
>
>Again, apologies for bringing this up so late, but I feel this issue is 
>quite important for interoperability between path validation implementations.
>
>--Peter
>
>----------------------------------------------------------------
>  Peter M. Hesse            CygnaCom Solutions, a division of
>  Phone: [phone]                   Entrust
>  ICQ:   1942828                 Securing the Internet
>----------------------------------------------------------------
>"Pay no attention to what the critics say; there has never been
>a statue set up in honor of a critic." --Jean Sibelius


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f7LHxTR09622 for ietf-pkix-bks; Tue, 21 Aug 2001 10:59:29 -0700 (PDT)
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f7LHxMN09618 for <[e-mail]>; Tue, 21 Aug 2001 10:59:22 -0700 (PDT)
Received: from sunlabs.East.Sun.COM ([129.148.75.250]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA27509; Tue, 21 Aug 2001 10:59:19 -0700 (PDT)
Received: from sun.com (dhcp75-167 [129.148.75.167]) by sunlabs.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA26525; Tue, 21 Aug 2001 13:59:11 -0400 (EDT)
Message-ID: <[e-mail]>
Date: Tue, 21 Aug 2001 13:58:33 -0400
From: Steve Hanna <[e-mail]>
Organization: Sun Microsystems, Inc.
X-Mailer: Mozilla 4.75 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Peter Hesse <[e-mail]>
CC: "'[e-mail]'" <[e-mail]>, "'[e-mail]'" <[e-mail]>, "'[e-mail]'" <[e-mail]>, "'[e-mail]'" <[e-mail]>, "'[e-mail]'" <[e-mail]>, "'[e-mail]'" <[e-mail]>
Subject: Re: Recommended changes to draft-ietf-pkix-new-part1-08
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>

The current document seems clear to me, but I've been working with it
for years! ;-) Making it clearer is certainly a good idea and I support
these changes. I believe they fall into the category of minor editorial
changes to clarify the meaning already present in the document and
agreed to by the working group. Therefore, I don't think there should be
any problem with making these changes, even at this late date.

Let me make a few minor comments and offer some specific text for the
first change so we have something specific to discuss.

> Peter Hesse wrote:
> --------------------------------------------------------------------------
> 
>    To meet this goal, the path validation process verifies, among
> other
>    things, that a prospective certification path (a sequence of n
>    certificates) satisfies the following conditions:
> 
>       (a)  for all x in {1, ..., n-1}, the subject of certificate x is
> 
>       the issuer of certificate x+1;
> 
>       (b)  certificate 1 is issued by the trust anchor;
> 
>       (c)  certificate n is the certificate to be validated; and
> 
>       (d)  for all x in {1, ..., n}, the certificate was valid at the
>       time in question.
> --------------------------------------------------------------------------
> 
> In my opinion, (b) should be changed to explicity specify that
> certificate 1 is not a self-signed certificate issued by the trust
> anchor.

Actually, certificate 1 *could* be the self-signed certificate if for
some reason the path actually happened to start with that certificate.
That would be unusual, but I do not think we should explicitly forbid
it. But I agree that it would be good to supply explicit guidance at
this point in the document that the trust anchor should not normally be
included in the path validation procedure.

In order to have a specific textual change to discuss, I'll suggest that
immediately following point (d) above, a sentence (a new paragraph, I
suppose) be added that says:

   When the trust anchor is provided in the form of a self-signed
   certificate, this certificate is not included as a part of the
   prospective certification path.

> The second change is needed because the logic of section 6.1 does not
> specifically say what certificates are subject to the validation
> processing other than the part quoted above.

Actually, section 6.1 says "Step (2) is performed for all certificates
in the path." Step (2) is defined elsewhere as Basic Certificate
Processing, which is discussed in section 6.1.3. And, in the section you
quoted above, it defines the "prospective certification path"  as "a
sequence of n certificates".

But I still think that your suggestion below is a good one. It's useful
to say the same thing two or three times to make sure there's no
misunderstanding, especially since this is a change from RFC 2459, where
the trust anchor *was* included in the path for validation purposes.

>  My second recommendation
> is to change the beginning of 6.1.3 to the following:
> 
> --------------------------------------------------------------------------
> 
> The basic path processing actions to be performed for certificate i
> (for all i in [1...n]) are listed below.
> --------------------------------------------------------------------------
> 
> These changes would allow certainty that
> - certificate 1 is not the self-signed trust anchor certificate
> - only certificates 1...n are processed, therefore explicitly not
> processing a self-signed trust anchor certificate if one exists in the
> path.
> 
> Again, apologies for bringing this up so late, but I feel this issue
> is quite important for interoperability between path validation
> implementations.

Thanks for bringing it up. It's good to make the document clearer. I
just hope we don't descend into a long debate now...

Steve Hanna
Sun Microsystems, Inc.


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f7LEefK28069 for ietf-pkix-bks; Tue, 21 Aug 2001 07:40:41 -0700 (PDT)
Received: from gto-mailer1.bbn.com (cam-mailer1.bbn.com [128.33.0.36]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f7LEecN28062 for <[e-mail]>; Tue, 21 Aug 2001 07:40:38 -0700 (PDT)
Received: from [128.33.84.34] (comsec.bbn.com [128.33.84.34]) by gto-mailer1.bbn.com (8.9.3+Sun/8.9.3) with ESMTP id KAA16952 for <[e-mail]>; Tue, 21 Aug 2001 10:42:49 -0400 (EDT)
Mime-Version: 1.0
X-Sender: [e-mail]
Message-Id: <p0501040bb7a8214adf35@[128.33.84.34]>
Date: Tue, 21 Aug 2001 10:36:04 -0400
To: [e-mail]
From: Stephen Kent <[e-mail]>
Subject: charter revisions
Content-Type: multipart/alternative; boundary="============_-1213717552==_ma============"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>

--============_-1213717552==_ma============
Content-Type: text/plain; charset="us-ascii" ; format="flowed"

Folks,

We were pinged about the need to update the PKIX WG charter, both 
during the meeting in London, and via a message the chairs received 
from the IETF Secretariat. So, here is a proposed revision to the 
charter that Tim and I have developed.  Please review it and provide 
comments by 8/28, so that we can post the revised charter by the end 
of the momth.

Thanks,

Steve
-------

Description of Working Group:

The PKIX Working Group was established in the Fall of 1995 with the 
intent of developing Internet standards needed to support an 
X.509-based PKI. The scope of PKIX work has expanded beyond this 
initial goal. PKIX not only profiles ITU PKI standards, but also 
develops new standards apropos to the use of X.509-based PKIs in the 
Internet.

PKIX has produced several informational and standards track documents 
in support of the original and revised scope of the WG. The first of 
these standards, RFC 2459, profiled X.509 version 3 certificates and 
version 2 CRLs for use in the Internet. Profiles for the use of LDAP 
v2 for certificate and CRL storage (RFC 2587), the Internet X.509 
Public Key Infrastructure Qualified Certificates Profile (RFC 2875), 
and the Internet X.509 Public Key Infrastructure Certificate Policy 
and certification Practices Framework (RFC 2527 - Informational) are 
in line with the initial scope.

The Certificate Management Protocol (CMP) (RFC 2510), the Online 
Certificate Status Protocol (OCSP) (RFC 2560), Certificate Management 
Request Format (CRMF) (RFC 2511),  Certificate Management Messages 
over CMS (RFC 2797),  Internet X.509 Public Key Infrastructure Time 
Stamp Protocols (RFC xxxx), and the use of FTP and HTTP for transport 
of PKI operations (RFC 2585) are representative of the expanded scope 
of PKIX, as these are new protocols developed in the working group, 
not profiles of ITU PKI standards.

A roadmap, providing a guide to the growing set of PKIX document, 
also has been developed as an informational RFC.

Ongoing PKIX Work items

An ongoing PKIX task is the progression of existing, standards track 
RFCs from PROPOSED to DRAFT. Also, to the extent that PKIX work 
relates to protocols from other areas, e.g., LDAP, it is necessary to 
track the evolution of the other protocols and produce updated RFCs. 
For example, the LDAP v2 documents from PKIX are evolving to address 
LDAP v3.

New Work items for PKIX

- production of a requirements RFC for delegated path discovery and 
path validation protocols (DPD/DPV) and subsequent production of RFCs 
for protocols that satisfy the requirements

- development of an RFC for a logotype extension for certificates

- development of a proxy certificate extension and associated processing rules

Not all of these items may become standards track RFCs. Some may 
become INFORMATIONAL or EXPERIMENTAL RFCs.

Goals and Milestones:

Done		PROPOSED Standard RFCs for public key and attribute 
certificate profiles, CMP, OCSP, CMC, CRMF, TSP, Qualified 
Certificates, LDAP v2 schema, use of FTP/HTTP, Diffie-Hellman POP
Done		INFORMATIONAL RFCs for X.509 PKI policies and 
practices, use of KEA
Done		Experimental RFC for Data Validation and 
Certification Server Protocols
8/01		Production of revised certificate and CRL syntax and 
processing RFC (son-of-2459)
10/01		Progression of CRMF, CMP, and CMP Transport to DRAFT Standard
12/01		Production of revised CMC RFCs (updates and split of 
CMC into several parts)
12/ 01		DPD/DVP Requirements RFC
12/01		Progression of OCSP to DRAFT Standard
3/02		DPV/DPD Protocols RFCs
3/02		Logotype Extension RFC
3/02		Proxy Certificate RFC
7/02		Progression of CMC RFCs to DRAFT Standard
--============_-1213717552==_ma============
Content-Type: text/html; charset="us-ascii"

<!doctype html public "-//W3C//DTD W3 HTML//EN">
<html><head><style type="text/css"><!--
blockquote, dl, ul, ol, li { margin-top: 0 ; margin-bottom: 0 }
 --></style><title>charter revisions</title></head><body>
<div>Folks,</div>
<div><br></div>
<div>We were pinged about the need to update the PKIX WG charter, both
during the meeting in London, and via a message the chairs received
from the IETF Secretariat. So, here is a proposed revision to the
charter that Tim and I have developed.&nbsp; Please review it and
provide comments by 8/28, so that we can post the revised charter by
the end of the momth.</div>
<div><br></div>
<div>Thanks,</div>
<div><br></div>
<div>Steve</div>
<div>-------</div>
<div><br></div>
<div><font face="Times New Roman" size="+5"
color="#000000"><b>Description of Working Group:<br>
<br>
</b></font><font face="Times New Roman" size="+3" color="#000000">The
PKIX Working Group was established in the Fall of 1995 with the intent
of developing Internet standards needed to support an X.509-based PKI.
The scope of PKIX work has expanded beyond this initial goal. PKIX not
only profiles ITU PKI standards, but also develops new standards
apropos to the use of X.509-based PKIs in the Internet.<br>
<br>
PKIX has produced several informational and standards track documents
in support of the original and revised scope of the WG. The first of
these standards, RFC 2459, profiled X.509 version 3 certificates and
version 2 CRLs for use in the Internet. Profiles for the use of LDAP
v2 for certificate and CRL storage (RFC 2587), the Internet X.509
Public Key Infrastructure Qualified Certificates Profile (RFC 2875),
and the Internet X.509 Public Key Infrastructure Certificate Policy
and certification Practices Framework (RFC 2527 - Informational) are
in line with the initial scope.<br>
<br>
The Certificate Management Protocol (CMP) (RFC 2510), the Online
Certificate Status Protocol (OCSP) (RFC 2560), Certificate Management
Request Format (CRMF) (RFC 2511),&nbsp; Certificate Management
Messages over CMS (RFC 2797),&nbsp; Internet X.509 Public Key
Infrastructure Time Stamp Protocols (RFC xxxx), and the use of FTP and
HTTP for transport of PKI operations (RFC 2585) are representative of
the expanded scope of PKIX, as these are new protocols developed in
the working group, not profiles of ITU PKI standards.<br>
<br>
A roadmap, providing a guide to the growing set of PKIX document, also
has been developed as an informational RFC.<br>
<br>
<b>Ongoing PKIX Work items<br>
<br>
</b>An ongoing PKIX task is the progression of existing, standards
track RFCs from PROPOSED to DRAFT. Also, to the extent that PKIX work
relates to protocols from other areas, e.g., LDAP, it is necessary to
track the evolution of the other protocols and produce updated RFCs.
For example, the LDAP v2 documents from PKIX are evolving to address
LDAP v3.<br>
<br>
<b>New Work items for PKIX<br>
<br>
</b>- production of a requirements RFC for delegated path discovery
and path validation protocols (DPD/DPV) and subsequent production of
RFCs for protocols that satisfy the requirements<br>
<br>
- development of an RFC for a logotype extension for certificates<br>
<br>
- development of a proxy certificate extension and associated
processing rules<br>
<br>
Not all of these items may become standards track RFCs. Some may
become INFORMATIONAL or EXPERIMENTAL RFCs.<br>
<br>
</font><font face="Times New Roman" size="+5" color="#000000"><b>Goals
and Milestones:<br>
<br>
</b></font><font face="Times New Roman" size="+3"
color="#000000">Done<x-tab>
</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</x-tab>PROPOSED Standard RFCs for public key and attribute
certificate profiles, CMP, OCSP, CMC, CRMF, TSP, Qualified
Certificates, LDAP v2 schema, use of FTP/HTTP, Diffie-Hellman POP<br>
Done<x-tab>&nbsp;&nbsp;&nbsp;
</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</x-tab>INFORMATIONAL RFCs for X.509 PKI policies and practices, use
of KEA<br>
Done<x-tab> </x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</x-tab>Experimental RFC for Data Validation and Certification Server
Protocols<br>
8/01<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;
</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</x-tab>Production of revised certificate and CRL syntax and
processing RFC (son-of-2459)<br>
10/01<x-tab>&nbsp;
</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</x-tab>Progression of CRMF, CMP, and CMP Transport to DRAFT
Standard<br>
12/01<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</x-tab>Production of revised CMC RFCs (updates and split of CMC into
several parts)<br>
12/ 01<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</x-tab>DPD/DVP Requirements RFC<br>
12/01<x-tab>&nbsp;&nbsp;
</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</x-tab>Progression of OCSP to DRAFT Standard<br>
3/02<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</x-tab>DPV/DPD Protocols RFCs<br>
3/02<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</x-tab>Logotype Extension RFC<br>
3/02<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</x-tab>Proxy Certificate RFC<br>
7/02<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</x-tab>Progression of CMC RFCs to DRAFT Standard</font></div>
</body>
</html>
--============_-1213717552==_ma============--


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f7LEa1I27839 for ietf-pkix-bks; Tue, 21 Aug 2001 07:36:01 -0700 (PDT)
Received: from SOTTMXS01.entrust.com (gatekeeper.entrust.com [204.101.128.170]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f7LEZwN27833 for <[e-mail]>; Tue, 21 Aug 2001 07:35:59 -0700 (PDT)
Received: by SOTTMXS01.entrust.com with Internet Mail Service (5.5.2650.21) id <Q8L2BQ41>; Tue, 21 Aug 2001 10:35:53 -0400
Message-ID: <[e-mail]>
From: Peter Hesse <[e-mail]>
To: "'[e-mail]'" <[e-mail]>, "'[e-mail]'" <[e-mail]>, "'[e-mail]'" <[e-mail]>, "'[e-mail]'" <[e-mail]>
Cc: "'[e-mail]'" <[e-mail]>, "'[e-mail]'" <[e-mail]>
Subject: Recommended changes to draft-ietf-pkix-new-part1-08
Date: Tue, 21 Aug 2001 10:24:08 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C12A4C.F09F3010"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C12A4C.F09F3010
Content-Type: text/plain;
	charset="iso-8859-1"

All,

I realize these comments are coming quite late in the process, and I hope
not to cause too much of a problem.  However, I feel that standards need to
be quite explicit in certain areas, and the current draft of the Internet
X.509 Public Key Infrastructure Certificate and CRL Profile (son of 2459) is
still a bit ambiguous when it comes to processing self-signed trust anchor
certificates.  I propose two changes in order to reduce this ambiguity.
First I will quote from the current draft, section 6.1:

--------------------------------------------------------------------------
   To meet this goal, the path validation process verifies, among other
   things, that a prospective certification path (a sequence of n
   certificates) satisfies the following conditions:

      (a)  for all x in {1, ..., n-1}, the subject of certificate x is
      the issuer of certificate x+1;

      (b)  certificate 1 is issued by the trust anchor;

      (c)  certificate n is the certificate to be validated; and

      (d)  for all x in {1, ..., n}, the certificate was valid at the
      time in question.
--------------------------------------------------------------------------

In my opinion, (b) should be changed to explicity specify that certificate 1
is not a self-signed certificate issued by the trust anchor.  

The second change is needed because the logic of section 6.1 does not
specifically say what certificates are subject to the validation processing
other than the part quoted above.  My second recommendation is to change the
beginning of 6.1.3 to the following: 

--------------------------------------------------------------------------
The basic path processing actions to be performed for certificate i 
(for all i in [1...n]) are listed below.
--------------------------------------------------------------------------

These changes would allow certainty that 
- certificate 1 is not the self-signed trust anchor certificate
- only certificates 1...n are processed, therefore explicitly not processing
a self-signed trust anchor certificate if one exists in the path.

Again, apologies for bringing this up so late, but I feel this issue is
quite important for interoperability between path validation
implementations.

--Peter

---------------------------------------------------------------- 
 Peter M. Hesse            CygnaCom Solutions, a division of
 Phone: [phone]                   Entrust
 ICQ:   1942828                 Securing the Internet
---------------------------------------------------------------- 
"Pay no attention to what the critics say; there has never been 
a statue set up in honor of a critic." --Jean Sibelius

------_=_NextPart_001_01C12A4C.F09F3010
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2652.35">
<TITLE>Recommended changes to draft-ietf-pkix-new-part1-08</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>All,</FONT>
</P>

<P><FONT SIZE=3D2>I realize these comments are coming quite late in the =
process, and I hope not to cause too much of a problem.&nbsp; However, =
I feel that standards need to be quite explicit in certain areas, and =
the current draft of the Internet X.509 Public Key Infrastructure =
Certificate and CRL Profile (son of 2459) is still a bit ambiguous when =
it comes to processing self-signed trust anchor certificates.&nbsp; I =
propose two changes in order to reduce this ambiguity.&nbsp; First I =
will quote from the current draft, section 6.1:</FONT></P>

<P><FONT =
SIZE=3D2>---------------------------------------------------------------=
-----------</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp; To meet this goal, the path validation =
process verifies, among other</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp; things, that a prospective =
certification path (a sequence of n</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp; certificates) satisfies the following =
conditions:</FONT>
</P>

<P><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; (a)&nbsp; for all x in =
{1, ..., n-1}, the subject of certificate x is</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; the issuer of =
certificate x+1;</FONT>
</P>

<P><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; (b)&nbsp; certificate =
1 is issued by the trust anchor;</FONT>
</P>

<P><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; (c)&nbsp; certificate =
n is the certificate to be validated; and</FONT>
</P>

<P><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; (d)&nbsp; for all x in =
{1, ..., n}, the certificate was valid at the</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; time in =
question.</FONT>
<BR><FONT =
SIZE=3D2>---------------------------------------------------------------=
-----------</FONT>
</P>

<P><FONT SIZE=3D2>In my opinion, (b) should be changed to explicity =
specify that certificate 1 is not a self-signed certificate issued by =
the trust anchor.&nbsp; </FONT></P>

<P><FONT SIZE=3D2>The second change is needed because the logic of =
section 6.1 does not specifically say what certificates are subject to =
the validation processing other than the part quoted above.&nbsp; My =
second recommendation is to change the beginning of 6.1.3 to the =
following: </FONT></P>

<P><FONT =
SIZE=3D2>---------------------------------------------------------------=
-----------</FONT>
<BR><FONT SIZE=3D2>The basic path processing actions to be performed =
for certificate i </FONT>
<BR><FONT SIZE=3D2>(for all i in [1...n]) are listed below.</FONT>
<BR><FONT =
SIZE=3D2>---------------------------------------------------------------=
-----------</FONT>
</P>

<P><FONT SIZE=3D2>These changes would allow certainty that </FONT>
<BR><FONT SIZE=3D2>- certificate 1 is not the self-signed trust anchor =
certificate</FONT>
<BR><FONT SIZE=3D2>- only certificates 1...n are processed, therefore =
explicitly not processing a self-signed trust anchor certificate if one =
exists in the path.</FONT></P>

<P><FONT SIZE=3D2>Again, apologies for bringing this up so late, but I =
feel this issue is quite important for interoperability between path =
validation implementations.</FONT></P>

<P><FONT SIZE=3D2>--Peter</FONT>
</P>

<P><FONT =
SIZE=3D2>---------------------------------------------------------------=
- </FONT>
<BR><FONT SIZE=3D2>&nbsp;Peter M. =
Hesse&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
CygnaCom Solutions, a division of</FONT>
<BR><FONT SIZE=3D2>&nbsp;Phone: =
703-270-3523&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Entrust</FONT>
<BR><FONT SIZE=3D2>&nbsp;ICQ:&nbsp;&nbsp; =
1942828&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Securing the Internet</FONT>
<BR><FONT =
SIZE=3D2>---------------------------------------------------------------=
- </FONT>
<BR><FONT SIZE=3D2>&quot;Pay no attention to what the critics say; =
there has never been </FONT>
<BR><FONT SIZE=3D2>a statue set up in honor of a critic.&quot; --Jean =
Sibelius</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C12A4C.F09F3010--


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f7LEVFt27695 for ietf-pkix-bks; Tue, 21 Aug 2001 07:31:15 -0700 (PDT)
Received: from gto-mailer1.bbn.com (cam-mailer1.bbn.com [128.33.0.36]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f7LEVEN27691 for <[e-mail]>; Tue, 21 Aug 2001 07:31:14 -0700 (PDT)
Received: from [128.33.84.34] (comsec.bbn.com [128.33.84.34]) by gto-mailer1.bbn.com (8.9.3+Sun/8.9.3) with ESMTP id KAA14345 for <[e-mail]>; Tue, 21 Aug 2001 10:33:18 -0400 (EDT)
Mime-Version: 1.0
X-Sender: [e-mail]
Message-Id: <p0501040ab7a82046a22a@[128.33.84.34]>
Date: Tue, 21 Aug 2001 10:31:37 -0400
To: [e-mail]
From: Stephen Kent <[e-mail]>
Subject: draft minutes
Content-Type: multipart/alternative; boundary="============_-1213718119==_ma============"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>

--============_-1213718119==_ma============
Content-Type: text/plain; charset="us-ascii" ; format="flowed"

Folks,

Please review the meeting minutes and get back to me with any 
corrections by 8/28, so that I can submit them to the IETF 
secretariat by the end of the month.

Thanks,

Steve
--------

PKIX WG Meeting 8/6/01
Edited by Steve Kent (WG co-chairs)

The PKIX WG met once during the 51st IETF. A total of approximately 153
individuals participated in the meeting.


Tim quickly reviewed the agenda and document status, noting that there are many
I-Ds in progress. (see slides)

Two new RFCs in the editor's queue:
	RFC xxxx	Timestamp Protocol
	RFC xxxx	Attribute Certificate Profile

In the IESG Review Process:
	PKIX Certificate and CRL Profile (a.k.a., son-of-2459)
	Public Key Algorithms and Identifiers for the PKIX Certificate profile

Soon to be Submitted to IESG:
	PKIX Roadmap
	Repository Locator Service

In WG Last Call:
	none

Close to WG last call:
	Certificate Management Protocol (RFC 2510bis)
	Certificate Request Message Framework (RFC 2511bis)
	Transport Protocols for CMP
	Online Certificate Status Protocol (OCSP v2)

New Work:


Logotype Certificates - Stefan Santesson (AddTrust)
	Notion is to embed references to logos in certificates, for
CAs or for EEs,  to allow display of the logo as part of certificate
processing. Argument is that people relate to logos in the physical
world, and don't display certificate contents, so this is a way to
bring branding into PKIs. Major concern is that people could be
mislead by certificates issued by a CA that binds inappropriate logos
to certificates it issues, e.g., there is no way to constrain logo
references the same way we can constrain names. Proposal is to create
a new extension for carrying a pointer (URL) to the logo image, an
indication of the image type, and a hash of the image. (see slides)

Supplemental Algorithms - Ari Singer (NTRU)
	New work item, to contain specs for a set of algorithms that
COULD be used with PKIX data structures. Support for these algorithms
is not mandated, but this document will provide a reference for these
supplemental algorithms. Note need to include appropriate
intellectual property warnings for proprietary algorithms, and to
distinguish between algorithms that are standards, vs, proprietary.
(see slides)

PKI Disaster Recovery - Denis Pinkas (Integris)
	The goal of this new work is to create an informational RFC
which addresses how to deal with compromise or loss of use of a CA,
AA, or TSA key. Different requirements arise for EE signature keys
vs. EE encryption keys, and these are addressed separately. (see
slides)

Using DNS for PKI Support- Simon Josephson (RSA)
	ID published as a personal draft. Focuses on using DNS to
hold certificates and CRLs. Works especially well for S/MINE, given
typical DNS lookup re MX records. Question is whether PKIX should
adopt this as a work item? Will discuss this on the list. (no slides)


Ongoing Work:

LDAP V3 Profile and Certificate Matching Rules - David Chadwick (Univ
of Salford)
	Profile going well, looking for feedback before publishing as
RFC. Matching rules work not as far along, but implementation work
now funded at Salford, which will help progress.

CMC Update - Jim Schaad (Soaring Hawk Consulting)
	Core functions largely unchanged, e.g., ASN syntax and
processing rules wil be static. New set of CMC documents being
issued, breaking into multiple pieces to allow easier progression of
pieces, e.g., transport, archive (also used by S/MIME), compliance
document. VeriSign hosted interoperability testing covering a large
number of protocol features. Several issues were uncovered during
testing. (see slides)

CMP Update - Carlisle Adams (Entrust)
	Interoperability testing yielded clarifications and the
document is now ready to go to Draft Standard status.

Proxy Certificates - Stephen Tuecke (Argonne Labs)
	Revised ID has been published. Related draft in TLS WG. Not
many attendees have read this draft, according to a show of hands.
Because it requires changes to certificate path validation, there is
a significant question about whether these changes should be part of
the base standards, or if this processing is a separate step to be
performed after standard path validation processing. (see slides)

OCSPv2 - Michael Myers (VeriSign)
	Authors have decided to publish as experimental for now. (no slides)

SCVP - Ambarish Malpani (ValiCert)
	No significant changes for now. (no slides)

DPD/DPV - Denis Pinkas (Integris)
	New ID posed to list. Incorporate new approach to DPV/DPD,
using 3 protocols: DPV, DPD, and a separate protocol for management
of policy data used for validation or discovery. This allows the DPD
and DPV protocols to be smaller and simpler, because the management
of parameters used for DPD/DPV is part of a separate protocol. The
management protocol might not be implemented on many clients, e.g.,
thin clients. References to the parameters (policy) used for
validation are OIDs, and there is a provision for a client to NOT
specify a policy, but have a server employ a default policy and
return that to the user. Extensive use of hashes of ancillary values
to keep messages brief, but allow checking by client. DPV proposal
allows for validation re current time, or past time (re-validation).
DPV can return four answers, reflecting level of knowledge available
to the server, especially with regard to revocation data. DPD and
management protocol also presented in detail. (see slides)

Policy Requirements for Timestamping  Authorities- Denis Pinkas (Integris)
	Discussion of this ETSI document and solicitation of
comments. (see slides)
--============_-1213718119==_ma============
Content-Type: text/html; charset="us-ascii"

<!doctype html public "-//W3C//DTD W3 HTML//EN">
<html><head><style type="text/css"><!--
blockquote, dl, ul, ol, li { margin-top: 0 ; margin-bottom: 0 }
 --></style><title>draft minutes</title></head><body>
<div><font color="#000000">Folks,</font></div>
<div><font color="#000000"><br></font></div>
<div><font color="#000000">Please review the meeting minutes and get
back to me with any corrections by 8/28, so that I can submit them to
the IETF secretariat by the end of the month.</font></div>
<div><font color="#000000"><br></font></div>
<div><font color="#000000">Thanks,</font></div>
<div><font color="#000000"><br></font></div>
<div><font color="#000000">Steve</font></div>
<div><font color="#000000">--------</font></div>
<div><font face="Courier" size="+2" color="#000000"><br></font></div>
<div><font face="Courier" size="+2" color="#000000">PKIX WG Meeting
8/6/01<br>
Edited by Steve Kent (WG co-chairs)<br>
<br>
The PKIX WG met once during the 51st IETF. A total of approximately
153<br>
individuals participated in the meeting.<br>
<br>
<br>
Tim quickly reviewed the agenda and document status, noting that there
are many<br>
I-Ds in progress. (see slides)<br>
<br>
Two new RFCs in the editor's queue:<br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </x-tab>RFC
xxxx<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</x-tab>Timestamp Protocol<br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </x-tab>RFC
xxxx<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</x-tab>Attribute Certificate Profile<br>
<br>
In the IESG Review Process:<br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </x-tab>PKIX
Certificate and CRL Profile (a.k.a., son-of-2459)<br>
<x-tab>&nbsp; </x-tab>Public Key Algorithms and Identifiers for the
PKIX Certificate profile<br>
<br>
Soon to be Submitted to IESG:<br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp; </x-tab>PKIX Roadmap<br>
<x-tab>&nbsp;&nbsp;&nbsp; </x-tab>Repository Locator Service<br>
<br>
In WG Last Call:<br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </x-tab>none<br>
<br>
Close to WG last call:<br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </x-tab>Certificate Management
Protocol (RFC 2510bis)<br>
<x-tab>&nbsp;&nbsp; </x-tab>Certificate Request Message Framework (RFC
2511bis)<br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp; </x-tab>Transport Protocols for
CMP<br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp; </x-tab>Online Certificate Status
Protocol (OCSP v2)<br>
<br>
New Work:<br>
<br>
<br>
Logotype Certificates - Stefan Santesson (AddTrust)<br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </x-tab>Notion is to
embed references to logos in certificates, for<br>
CAs or for EEs,&nbsp; to allow display of the logo as part of
certificate<br>
processing. Argument is that people relate to logos in the
physical<br>
world, and don't display certificate contents, so this is a way to<br>
bring branding into PKIs. Major concern is that people could be<br>
mislead by certificates issued by a CA that binds inappropriate
logos<br>
to certificates it issues, e.g., there is no way to constrain logo<br>
references the same way we can constrain names. Proposal is to
create<br>
a new extension for carrying a pointer (URL) to the logo image, an<br>
indication of the image type, and a hash of the image. (see
slides)<br>
<br>
Supplemental Algorithms - Ari Singer (NTRU)<br>
<x-tab> </x-tab>New work item, to contain specs for a set of
algorithms that<br>
COULD be used with PKIX data structures. Support for these
algorithms<br>
is not mandated, but this document will provide a reference for
these<br>
supplemental algorithms. Note need to include appropriate<br>
intellectual property warnings for proprietary algorithms, and to<br>
distinguish between algorithms that are standards, vs,
proprietary.<br>
(see slides)<br>
<br>
PKI Disaster Recovery - Denis Pinkas (Integris)<br>
<x-tab>&nbsp; </x-tab>The goal of this new work is to create an
informational RFC<br>
which addresses how to deal with compromise or loss of use of a
CA,<br>
AA, or TSA key. Different requirements arise for EE signature keys<br>
vs. EE encryption keys, and these are addressed separately. (see<br>
slides)<br>
<br>
Using DNS for PKI Support- Simon Josephson (RSA)<br>
<x-tab> </x-tab>ID published as a personal draft. Focuses on using DNS
to<br>
hold certificates and CRLs. Works especially well for S/MINE,
given<br>
typical DNS lookup re MX records. Question is whether PKIX should<br>
adopt this as a work item? Will discuss this on the list. (no
slides)<br>
<br>
<br>
Ongoing Work:<br>
<br>
LDAP V3 Profile and Certificate Matching Rules - David Chadwick
(Univ<br>
of Salford)<br>
<x-tab> </x-tab>Profile going well, looking for feedback before
publishing as<br>
RFC. Matching rules work not as far along, but implementation work<br>
now funded at Salford, which will help progress.<br>
<br>
CMC Update - Jim Schaad (Soaring Hawk Consulting)<br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </x-tab>Core
functions largely unchanged, e.g., ASN syntax and<br>
processing rules wil be static. New set of CMC documents being<br>
issued, breaking into multiple pieces to allow easier progression
of<br>
pieces, e.g., transport, archive (also used by S/MIME), compliance<br>
document. VeriSign hosted interoperability testing covering a
large<br>
number of protocol features. Several issues were uncovered during<br>
testing. (see slides)<br>
<br>
CMP Update - Carlisle Adams (Entrust)<br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</x-tab>Interoperability testing yielded clarifications and the<br>
document is now ready to go to Draft Standard status.<br>
<br>
Proxy Certificates - Stephen Tuecke (Argonne Labs)<br>
<x-tab>&nbsp; </x-tab>Revised ID has been published. Related draft in
TLS WG. Not<br>
many attendees have read this draft, according to a show of hands.<br>
Because it requires changes to certificate path validation, there
is</font></div>
<div><font face="Courier" size="+2" color="#000000">a significant
question about whether these changes should be part of<br>
the base standards, or if this processing is a separate step to be<br>
performed after standard path validation processing. (see slides)<br>
<br>
OCSPv2 - Michael Myers (VeriSign)<br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </x-tab>Authors have
decided to publish as experimental for now. (no slides)<br>
<br>
SCVP - Ambarish Malpani (ValiCert)<br>
<x-tab>&nbsp; </x-tab>No significant changes for now. (no slides)<br>
<br>
DPD/DPV - Denis Pinkas (Integris)<br>
<x-tab>&nbsp;&nbsp;&nbsp; </x-tab>New ID posed to list. Incorporate
new approach to DPV/DPD,<br>
using 3 protocols: DPV, DPD, and a separate protocol for
management<br>
of policy data used for validation or discovery. This allows the
DPD<br>
and DPV protocols to be smaller and simpler, because the
management<br>
of parameters used for DPD/DPV is part of a separate protocol. The<br>
management protocol might not be implemented on many clients,
e.g.,<br>
thin clients. References to the parameters (policy) used for<br>
validation are OIDs, and there is a provision for a client to NOT<br>
specify a policy, but have a server employ a default policy and<br>
return that to the user. Extensive use of hashes of ancillary
values<br>
to keep messages brief, but allow checking by client. DPV proposal<br>
allows for validation re current time, or past time
(re-validation).<br>
DPV can return four answers, reflecting level of knowledge
available<br>
to the server, especially with regard to revocation data. DPD and<br>
management protocol also presented in detail. (see slides)<br>
<br>
Policy Requirements for Timestamping&nbsp; Authorities- Denis Pinkas
(Integris)<br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </x-tab>Discussion
of this ETSI document and solicitation of<br>
comments. (see slides)</font></div>
</body>
</html>
--============_-1213718119==_ma============--


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f7LCMhP22314 for ietf-pkix-bks; Tue, 21 Aug 2001 05:22:43 -0700 (PDT)
Received: from firewall.andxor.it (firewall.andxor.it [195.223.2.2]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f7LCMeN22308 for <[e-mail]>; Tue, 21 Aug 2001 05:22:40 -0700 (PDT)
Received: from tho.andxor.com (tho.andxor.it [195.223.2.222]) by firewall.andxor.it (8.9.2/8.9.2) with ESMTP id OAA02473; Tue, 21 Aug 2001 14:22:40 +0200 (CEST) (envelope-from [e-mail])
Received: (from tho@localhost) by tho.andxor.com (8.9.3/8.9.3) id OAA21703; Tue, 21 Aug 2001 14:23:22 +0200 (CEST) (envelope-from tho)
Date: Tue, 21 Aug 2001 14:23:22 +0200
From: tho <[e-mail]>
To: [e-mail], Peter Sylvester <[e-mail]>
Cc: [e-mail], [e-mail]
Subject: Re: New test TSA available
Message-ID: <[e-mail]>
References: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2i
In-Reply-To: <[e-mail]>; from [e-mail] on Tue, Aug 21, 2001 at 01:41:55PM +0200
X-Operating-System: FreeBSD
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>

hello peter(s),

there is another point which i've missed in the previous mail that is 
concerned with the TSA certificate: it should contain one (and sole)
extended key usage field with value id-kp-timeStamping so that the only
keyUsage set to nonRepudiation is not enough...

i'm growing more and more pedantic, excuse me :)

tho
-- 
(__)         
(oo)        
 \/-------\
  ||     | \  
  ||---W||  * 


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f7LBg7i20586 for ietf-pkix-bks; Tue, 21 Aug 2001 04:42:07 -0700 (PDT)
Received: from edelweb.fr (edelweb.fr [212.234.46.16]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f7LBg5N20576 for <[e-mail]>; Tue, 21 Aug 2001 04:42:05 -0700 (PDT)
Received: from champagne.edelweb.fr (localhost.edelweb.fr [127.0.0.1]) by edelweb.fr with ESMTP id NAA01403; Tue, 21 Aug 2001 13:41:57 +0200 (MET DST)
Received: from champagne.edelweb.fr (champagne.edelweb.fr [193.51.14.161]) by edelweb.fr (nospam/1.3); Tue, 21 Aug 2001 13:41:57 +0200 (MET DST)
Received: from emeriau.edelweb.fr (emeriau.edelweb.fr [193.51.14.5]) by champagne.edelweb.fr (8.7.6/8.6.6) with ESMTP id NAA11935; Tue, 21 Aug 2001 13:41:56 +0200 (MET DST)
From: Peter Sylvester <[e-mail]>
Received: (sylvest@localhost) by emeriau.edelweb.fr (8.7.6/8.6.6) id NAA08284; Tue, 21 Aug 2001 13:41:55 +0200 (MET DST)
Date: Tue, 21 Aug 2001 13:41:55 +0200 (MET DST)
Message-Id: <[e-mail]>
To: [e-mail], [e-mail]
Subject: Re: New test TSA available
Cc: [e-mail], [e-mail]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>

> ::content type::
> 
>  (A) draft-ietf-pkix-time-stamp-15 states that eContentType for a time
>      stamping token should be id-ct-TSTInfo why is it instead set to
>      id-data ?
> 
>  since the encapsulated content type is set to id-data, version
>  field in SignedData is (`correctly' since (A)) set to 1 and not to 3


> 
version 3 seems correct for another reason:
>From CMS:

      version is the syntax version number.  If the SignerIdentifier is
      the CHOICE issuerAndSerialNumber, then the version shall be 1.  If
      the SignerIdentifier is subjectKeyIdentifier, then the version
      shall be 3.


151 31  119:         SET {
 153 30  117:           SEQUENCE {
 155 02    1:             INTEGER 3
 158 80   20:             [0]
            :               6F 68 B0 B9 90 36 9F 63 4E 96 45 BE A4 9B E7 E3
            :               64 38 B9 55

      SignerInfo ::= SEQUENCE {
        version CMSVersion,
        sid SignerIdentifier,

      SignerIdentifier ::= CHOICE {
        issuerAndSerialNumber IssuerAndSerialNumber,
        subjectKeyIdentifier [0] SubjectKeyIdentifier }


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f7LABpJ14764 for ietf-pkix-bks; Tue, 21 Aug 2001 03:11:51 -0700 (PDT)
Received: from firewall.andxor.it (firewall.andxor.it [195.223.2.2]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f7LABkN14760 for <[e-mail]>; Tue, 21 Aug 2001 03:11:47 -0700 (PDT)
Received: from tho.andxor.com (tho.andxor.it [195.223.2.222]) by firewall.andxor.it (8.9.2/8.9.2) with ESMTP id MAA01789; Tue, 21 Aug 2001 12:11:44 +0200 (CEST) (envelope-from [e-mail])
Received: (from tho@localhost) by tho.andxor.com (8.9.3/8.9.3) id MAA21240; Tue, 21 Aug 2001 12:12:26 +0200 (CEST) (envelope-from tho)
Date: Tue, 21 Aug 2001 12:12:26 +0200
From: tho <[e-mail]>
To: Peter Gutmann <[e-mail]>
Cc: [e-mail], [e-mail]
Subject: Re: New test TSA available
Message-ID: <[e-mail]>
References: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2i
In-Reply-To: <[e-mail]>; from [e-mail] on Tue, Aug 21, 2001 at 12:15:35PM +1200
X-Operating-System: FreeBSD
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>

hello peter,

i've tried a couple of requests to cryptoapps tsa and this is what i've
found: 


::content type::

 (A) draft-ietf-pkix-time-stamp-15 states that eContentType for a time
     stamping token should be id-ct-TSTInfo why is it instead set to
     id-data ?

 since the encapsulated content type is set to id-data, version
 field in SignedData is (`correctly' since (A)) set to 1 and not to 3

::signed attributes::

 draft-ietf-pkix-time-stamp-15 states that The certificate identifier
 (ESSCertID) of the TSA certificate MUST be included as a signerInfo
 attribute inside a SigningCertificate attribute, and here it is missing

 since (A) ContentType attribute in signedAttrs inside SignerInfo is set
 to id-data

::signature algorithm::

 signatureAlgorithm in SignerInfo is rsaEncryption, shouldn't it be more
 likely sha1withRSAEncryption ?


thank you, tho
--
(__)         
(oo)        
 \/-------\
  ||     | \  
  ||---W||  * 


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f7L0FdJ04965 for ietf-pkix-bks; Mon, 20 Aug 2001 17:15:39 -0700 (PDT)
Received: from kakapo.cs.auckland.ac.nz (kakapo.cs.auckland.ac.nz [130.216.34.10]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f7L0FbN04959 for <[e-mail]>; Mon, 20 Aug 2001 17:15:37 -0700 (PDT)
Received: from ruru.cs.auckland.ac.nz (firebird.cs.auckland.ac.nz [130.216.34.12]) by kakapo.cs.auckland.ac.nz (8.8.6/8.8.6/cs-master) with ESMTP id MAA19324 for <[e-mail]>; Tue, 21 Aug 2001 12:15:35 +1200 (NZST) (sender [e-mail])
Received: (from pgut001@localhost) by ruru.cs.auckland.ac.nz (8.9.3/8.8.6/cs-slave) id MAA256633 for [e-mail]; Tue, 21 Aug 2001 12:15:35 +1200 (NZST) (sender [e-mail])
Date: Tue, 21 Aug 2001 12:15:35 +1200 (NZST)
Message-ID: <[e-mail]>
From: [e-mail] (Peter Gutmann)
To: [e-mail]
Subject: New test TSA available
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>

There's a new TSA available at tsa.cryptoapps.com:3318, running in a FIPS 140-1
level 4 device (it's just a demo which runs single-threaded, so if you throw
a huge number of concurrent requests at it you may get some refused 
connections, although I doubt it'll be a big issue for now).  There will also 
be an OCSP responder at ocsp.cryptoapps.com and a CMP server at 
cmp.cryptoapps.com in the near future running on the same hardware, at the
moment I think the ports are still blocked so you won't be able to get to them.

Peter.



Received: by above.proper.com (8.11.3/8.11.3) id f7JMt7o01517 for ietf-pkix-bks; Sun, 19 Aug 2001 15:55:07 -0700 (PDT)
Received: from tholian.securitydynamics.com (mail.rsasecurity.com [204.167.112.129]) by above.proper.com (8.11.3/8.11.3) with SMTP id f7JMt1N01513 for <[e-mail]>; Sun, 19 Aug 2001 15:55:01 -0700 (PDT)
Received: from sdtihq24.securitydynamics.com by tholian.securitydynamics.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 19 Aug 2001 22:52:49 UT
Received: from exna00.securitydynamics.com (ebola.securid.com [192.168.7.4]) by sdtihq24.securid.com (Pro-8.9.3/Pro-8.9.3) with ESMTP id SAA05315 for <[e-mail]>; Sun, 19 Aug 2001 18:54:29 -0400 (EDT)
Received: by exna00.securitydynamics.com with Internet Mail Service (5.5.2653.19) id <QTWC397D>; Sun, 19 Aug 2001 18:55:03 -0400
Received: from HOUSLEY-LAP.rsasecurity.com (10.3.1.121 [10.3.1.121]) by exna00.securitydynamics.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id QTWC397B; Sun, 19 Aug 2001 18:55:00 -0400
From: "Housley, Russ" <[e-mail]>
To: Hideyuki Odahara <[e-mail]>
Cc: [e-mail]
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.0.1
Date: Sun, 19 Aug 2001 18:05:33 -0400
Subject: Re: draft-ietf-pkix-ac509prof-09  ASN.1 "IMPLICIT"
In-Reply-To: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>

I am not sure whether the reponse was posted to this query or not.  Please 
excuse the redundancy if it has already been answered.

The change was made to align with the ITU-T/ISO document.  The PKIX 
document was EXPLICT, and the ITU-T/ISO one was IMPLICIT.  Clearly, they 
should have been the same from the start.

The module OID was not changed because the error only existed in 
Internet-Draft documents.  One should expect changes to such documents.

Russ


At 02:23 PM 8/7/2001 +0900, Hideyuki Odahara wrote:
>Why did "EXPLICIT" change to "IMPLICIT".
>There is no reason and no description about
>chainging at Appendix C:Change History.
>
>Please tell me.


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f7JMi7Q01401 for ietf-pkix-bks; Sun, 19 Aug 2001 15:44:07 -0700 (PDT)
Received: from thunder.dstc.qut.edu.au (thunder.dstc.qut.edu.au [131.181.71.1]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f7JMi5N01397 for <[e-mail]>; Sun, 19 Aug 2001 15:44:05 -0700 (PDT)
Received: from dstc.qut.edu.au (garnet.dstc.qut.edu.au [131.181.71.36]) by thunder.dstc.qut.edu.au (8.10.1/8.10.1) with ESMTP id f7JMi7m15293 for <[e-mail]>; Mon, 20 Aug 2001 08:44:07 +1000 (EST)
Message-Id: <[e-mail]>
X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4
From: [e-mail]
To: [e-mail]
Subject: Suggestion for Logotypes draft
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Mon, 20 Aug 2001 08:44:06 +1000
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>

Firstly, just like to say that I support Stefan's proposal more or less as
it stands.  I think he has done a good job of thinking about the problem
and coming up with a pragmatic solution.

Just one suggestion.  One of the comments made in London was a general
desire to reduce the size of Certificates.  By making the digest algorithm
identifier optional and omitting it when it is the same algorithm used to
sign the Certificate you would save about 10-15 bytes.  Not much but
perhaps worth doing if you have multiple logotypes.

Cheers.
Dean.




Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f7HKQGg05871 for ietf-pkix-bks; Fri, 17 Aug 2001 13:26:16 -0700 (PDT)
Received: from sentry.gw.tislabs.com ([e-mail] [192.94.214.100]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f7HKQFN05863 for <[e-mail]>; Fri, 17 Aug 2001 13:26:15 -0700 (PDT)
Received: by sentry.gw.tislabs.com; id QAA00826; Fri, 17 Aug 2001 16:30:42 -0400 (EDT)
Received: from clipper.gw.tislabs.com(10.33.1.2) by sentry.gw.tislabs.com via smap (V5.5) id xma000811; Fri, 17 Aug 01 16:29:58 -0400
Received: (from balenson@localhost) by clipper.gw.tislabs.com (8.9.3/8.9.1) id QAA09015 for [e-mail]; Fri, 17 Aug 2001 16:25:32 -0400 (EDT)
Date: Fri, 17 Aug 2001 16:25:32 -0400 (EDT)
From: "David M. Balenson" <[e-mail]>
Message-Id: <[e-mail]>
To: [e-mail]
Subject: CFP: Submission deadline for NDSS'02 extended to Aug 29th
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>

Due to the unusually large number of requests for an extension,
the submissions deadline for NDSS'02 has been extended to 
Wednesday August 29, 9:00am EST (U.S. east coast time).
 
Paul Van Oorschot  and Virgil Gligor
Co-Chairs, NDSS'02


                             C A L L   F O R   P A P E R S

Internet Society's 2002 Network and Distributed System Security Symposium  (NDSS'02)

Catamaran Resort - San Diego, California
February 6-8, 2002

IMPORTANT DATES
Paper and panel submissions due August 22, 2001
Author notification October 17, 2001
Final version of papers and panels due November 20, 2001

GOAL: The symposium fosters information exchange among research scientists and practitioners of network and distributed system security services. The target audience includes those interested in practical aspects of network and distributed system security, with a focus on actual system design and implementation (rather than theory). A major goal is to encourage and enable the Internet community to apply, deploy, and advance the state of available security technology. The proceedings are published by the Internet Society.

GENERAL CHAIR: 
Clifford Neuman, USC Information Sciences Institute

PROGRAM CO-CHAIRS:
Paul Van Oorschot, Entrust Technologies
Virgil Gligor, University of Maryland

TUTORIAL CHAIR:
Eric Harder, National Security Agency

LOCAL ARRANGEMENTS CHAIR:
Thomas Hutton, San Diego Supercomputer Center

PUBLICATIONS CHAIR:
Mahesh Tripunitara, Purdue University

PUBLICITY CHAIR:
David Balenson, NAI Labs, Network Associates

LOGISTICS CHAIR:
Terry Weigler, Internet Society

PROGRAM COMMITTEE:
Steve Bellovin, AT&T Labs Research
Dan Boneh, Stanford University
Bill Cheswick, Lumeta Corporation
Li Gong, Sun Microsystems
Peter Gutmann, Univ. of Auckland, N.Z.
Charlie Kaufman, Iris Associates
Steve Kent, BBN Technologies
Markus Kuhn, Univ. of Cambridge, U.K.
Douglas Maughan, DARPA
Kevin McCurley, IBM Almaden Research
Gary McGraw, Cigital
Fabian Monrose, Bell Labs
Sandra Murphy, Network Associates
Radha Poovendran, Univ. of Washington 
Michael Roe, Microsoft Research, U.K. 
Christoph Schuba, Sun Microsystems
Clay Shields, Purdue University
Jonathan Trostle, Cisco Systems
Dan Wallach, Rice University

OUTSTANDING PAPER AWARD: There will be an Outstanding Paper award. The award will be presented at the symposium to the authors of an outstanding paper, as selected by the Program Committee.

SUBMISSIONS: Both technical papers and panel proposals are solicited. Technical papers must include a main body of at most 12 pages, with any additional details in clearly marked appendices for a combined total of at most 20 pages. Technical papers will appear in the proceedings. Panel proposals should be one page and must describe the topic, identify the panel chair, explain the panel format, and list three to four potential panelists. A description of each panel will appear in the proceedings, and may, at the discretion of the panel chair, include written position statements from the panelists.

Submissions are solicited in, but not limited to, the following areas:
* Integrating security in Internet protocols: routing, naming, TCP/IP, multicast, network management, and the Web.
* Intrusion avoidance, detection, and response: systems, experiences and architectures.
* Attack-resistant protocols and services.
* Network perimeter controls: firewalls, packet filters, application gateways.
* Virtual private networks.
* Public key infrastructure, key management, certification, and revocation.
* Secure electronic commerce: e.g., payment, barter, EDI, notarization, timestamping, endorsement, and licensing.
* Supporting security mechanisms and APIs; audit trails; accountability.
* Implementation, deployment and management of network security policies.
* Intellectual property protection: protocols, schemas, implementations, metering, watermarking, digital rights management.
* Fundamental services on network and distributed systems: authentication, data integrity, confidentiality, authorization, non-repudiation, and availability.
* Integrating security services with system and application security facilities and protocols: e.g., message handling, file transport/access, directories, time synchronization, data base management, boot services, mobile computing.
* Security for emerging technologies: sensor networks, specialized testbeds, wireless/mobile (and ad hoc) networks, personal communication systems, and large heterogeneous distributed systems.
* Special problems and case studies: e.g., interplay and tradeoffs between security and efficiency, usability, reliability and cost.
* Security for collaborative applications and services: teleconferencing and video-conferencing, groupwork, etc.

Each submission must contain a separate Submission Overview specifying the submission type (paper or panel), the title or topic, author names with organizational affiliations, and must specify a contact author along with corresponding phone number, FAX number, postal address and email address.

Submissions must be received by August 22, 2001, and must be made electronically in either printable PostScript or PDF. Each submission will be acknowledged by e-mail; if acknowledgment is not received within seven days, contact a program co-chair (see above). Authors and panelists will be notified of acceptance by October 17, 2001, and given instructions for preparing the camera-ready copy. The camera-ready copy must be received by November 20, 2001. 

FURTHER INFORMATION: Official dates, the final call for papers, the advance program, and registration information will be available shortly at http://www.isoc.org/ndss2002. For official submission information, visit http://www.isoc.org/ndss2002/cfp.

Internet Society 

11150 Sunset Hills Road, Suite 100
Reston, VA  20191  USA
Tel:  [phone]
Fax:  [phone]
www.isoc.org

4, rue des Falaises
CH-1205 Geneva
Switzerland
Tel:  [phone]
Fax:  [phone]
www.isoc.org


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f7FJOcQ08540 for ietf-pkix-bks; Wed, 15 Aug 2001 12:24:38 -0700 (PDT)
Received: from po1.bbn.com (PO1.BBN.COM [192.1.50.38]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f7FJObN08536 for <[e-mail]>; Wed, 15 Aug 2001 12:24:37 -0700 (PDT)
Received: from [128.33.238.53] (TC053.BBN.COM [128.33.238.53]) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id PAA25407 for <[e-mail]>; Wed, 15 Aug 2001 15:24:32 -0400 (EDT)
Mime-Version: 1.0
X-Sender: [e-mail] (Unverified)
Message-Id: <p05010400b7a021225f3d@[128.33.238.92]>
Date: Wed, 15 Aug 2001 08:57:11 -0400
To: [e-mail]
From: Stephen Kent <[e-mail]>
Subject: slides
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>

Everyone who used slides in presentations at the PKIX WG meeting last 
week should send a copy of the slides (in PPT format) to me for 
forwarding to the IETF Secretariat.  Thanks to Denis Pinkas, Steve 
Tuecke, Jim Schaad, and Stefan Santesson, who have already sent their 
slides.

A draft copy of the meeting minutes will be available later this week.

Steve


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f7FEDEt21376 for ietf-pkix-bks; Wed, 15 Aug 2001 07:13:14 -0700 (PDT)
Received: from brot.celocom.de (brot.celocom.de [212.78.104.200]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f7FEDDN21372 for <[e-mail]>; Wed, 15 Aug 2001 07:13:13 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by brot.celocom.de (Postfix) with ESMTP id 2C31F3000E; Wed, 15 Aug 2001 16:13:10 +0200 (CEST)
Received: from frolic.celocom.de (frolic.celocom.de [212.78.104.90]) by brot.celocom.de (Postfix) with ESMTP id 25AB63000D; Wed, 15 Aug 2001 16:13:08 +0200 (CEST)
Message-ID: <[e-mail]>
Date: Wed, 15 Aug 2001 16:13:00 +0200
From: Bernd Matthes <[e-mail]>
Organization: Celo Communications -- a Gemplus Company
X-Mailer: Mozilla 4.75 [en] (WinNT; U)
X-Accept-Language: de,en
MIME-Version: 1.0
To: [e-mail]
Cc: [e-mail]
Subject: Re: Timestamping server
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: by AMaViS perl-11
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>

"S.T. Wong" wrote:
> 
> Hello,
> 
> I'm writing a simple timestamping client program to implement the new
> timestamping draft (15).  I'd like to know if there's any timestamping server
> available for public to test.
> 
> Would anyone please help?
> 
> Thanks in advance.
> Regards,
> ST Wong

Look here for an experimental HTTP server:
	http://pcardtest.celocom.de:4242/index.html

Look at first with a browser for informations.
Feel free for comments.

with regards
-- 
Mors certa, hora incerta. In dubio pro mille.
--------------------------------------------------------------------
Bernd Matthes                   Celo Communications GmbH
Senior Software Engineer    	     - a Gemplus Company
Dipl.-Ing.(FH)                  mailto:[e-mail]
--------------------------------------------------------------------
If they can't talk SMTP, they can't expect to talk with me.


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f7EB2kN04306 for ietf-pkix-bks; Tue, 14 Aug 2001 04:02:46 -0700 (PDT)
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f7EB2jN04302 for <[e-mail]>; Tue, 14 Aug 2001 04:02:45 -0700 (PDT)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA26173; Tue, 14 Aug 2001 07:01:34 -0400 (EDT)
Message-Id: <[e-mail]>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: [e-mail]
From: [e-mail]
Reply-to: [e-mail]
Subject: I-D ACTION:draft-ietf-pkix-proxy-01.txt
Date: Tue, 14 Aug 2001 07:01:33 -0400
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Public-Key Infrastructure (X.509) Working Group of the IETF.

	Title		: Internet X.509 Public Key Infrastructure Proxy 
                          Certificate Profile
	Author(s)	: S. Tuecke et al.
	Filename	: draft-ietf-pkix-proxy-01.txt
	Pages		: 32
	Date		: 13-Aug-01
	
This document forms a certificate profile for Proxy Certificates, 
based on X.509 PKI certificates as defined in draft-ietf-pkix-new-
part1-08.txt (the draft update to RFC 2459), for use in the 
Internet.  The term Proxy Certificate is used to describe a 
certificate that is derived from, and signed by, a normal X.509 
Public Key End Entity Certificate or by another Proxy Certificate 
for the purpose of providing restricted impersonation within a PKI 
based authentication system.  This draft replaces draft-ietf-pkix-
impersonation-00.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-pkix-proxy-01.txt

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-pkix-proxy-01.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[e-mail].
In the body type:
	"FILE /internet-drafts/draft-ietf-pkix-proxy-01.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
		
		
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="[e-mail]"

Content-Type: text/plain
Content-ID:	<[e-mail]>

ENCODING mime
FILE /internet-drafts/draft-ietf-pkix-proxy-01.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-pkix-proxy-01.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<[e-mail]>

--OtherAccess--

--NextPart--




Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f7DETe021772 for ietf-pkix-bks; Mon, 13 Aug 2001 07:29:40 -0700 (PDT)
Received: from dolk.extundo.com (dolk.extundo.com [195.42.214.242]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f7DETbN21767 for <[e-mail]>; Mon, 13 Aug 2001 07:29:37 -0700 (PDT)
Received: from barbar.josefsson.org (slipsten.extundo.com [195.42.214.241]) (authenticated) by dolk.extundo.com (8.11.3/8.11.3) with ESMTP id f7DETgw21569; Mon, 13 Aug 2001 16:29:43 +0200
To: Stefan Santesson <[e-mail]>
Cc: [e-mail]
Subject: Re: Logotype images
References: <[e-mail]>
From: Simon Josefsson <[e-mail]>
In-Reply-To: <[e-mail]> (Stefan Santesson's message of "Mon, 13 Aug 2001 11:08:19 +0200")
Date: Mon, 13 Aug 2001 16:29:35 +0200
Message-ID: <[e-mail]>
Lines: 48
User-Agent: Gnus/5.090004 (Oort Gnus v0.04) Emacs/21.0.104
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>

Stefan Santesson <[e-mail]> writes:

> Since logotypes in certificates now is an approved PKIX work item
> there are some practical aspects to deal with.
>
> 1) Logotype image size or scalable images.
>
> We probably need to define a standard size for logotype images or find
> another way to define scalable logotypes in order to enhance
> homogeneous display of certificates.
>
> The alternative is to allow scalable logotypes but I have been told
> that there are no easy and appropriate ways to do this.
>
> 2) Colour and B&W images.
>
> Some clients, such as mobile phones does not have colour display and
> colour images may not work in B&W.
> We probably need a convension that allows inclusion of 2 images for
> each logotype (colour and B&W).
> Possible solotions are either a convension defined in the ASN.1
> structure or just a file naming convension for the image files.
>
> Any suggestions?

Did you consider W3C's Scalable Vector Graphics (SVG) format?  Two
resource pagees:

http://www.w3.org/Graphics/SVG/Overview.htm8

There is W3C note on accessibility features of SVG that apply to
constraint devices as well:

http://www.w3.org/TR/SVG-access/

Abstract

Scalable Vector Graphics (SVG) offers a number of features to make
graphics on the Web more accessible than is currently possible, to a
wider group of users. Users who benefit include users with low vision,
color blind or blind users, and users of assistive technologies.  A
number of these SVG features can also increase usability of content
for many users without disabilities, such as users of personal digital
assistants, mobile phones or other non-traditional Web access devices.

Accessibility requires that the features offered by SVG are correctly
used and supported.  This Note describes the SVG features that support
accessibility and illustrates their use with examples.



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f7DD2Ox19082 for ietf-pkix-bks; Mon, 13 Aug 2001 06:02:24 -0700 (PDT)
Received: from claudio.bib.co.uk (gateway.bib.co.uk [195.171.24.2]) by above.proper.com (8.11.3/8.11.3) with SMTP id f7DD2MN19078 for <[e-mail]>; Mon, 13 Aug 2001 06:02:23 -0700 (PDT)
Received: from 127.0.0.1 by claudio.bib.co.uk (InterScan E-Mail VirusWall NT); Mon, 13 Aug 2001 14:01:34 +0100
Received: by claudio with Internet Mail Service (5.5.2653.19) id <QALMP5NZ>; Mon, 13 Aug 2001 14:01:34 +0100
Message-ID: <36086CC80304D3119B040008C75DF596095F20C5@claudio>
From: "Bland, Graham" <[e-mail]>
To: "'John Lowry'" <[e-mail]>, "Bland, Graham" <[e-mail]>, "'Stefan Santesson'" <[e-mail]>, [e-mail]
Subject: RE: Logotype images
Date: Mon, 13 Aug 2001 14:01:33 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/mixed; boundary="------------InterScan_NT_MIME_Boundary"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>

This is a multi-part message in MIME format.

--------------InterScan_NT_MIME_Boundary
Content-Type: text/plain;
	charset="iso-8859-1"

I agree with the second sentiment.

However as the purpose is to allow the display of a recognisable graphic
logo the type of logo included is going to be the whole specification.

If the logo is not defined then it is just another non critical extension
where the contents are relatively? undefined.

I just thought of another issue, if a standard size is defined then what
about the aspect ratio, organisations have different shaped logos and would
probably not like to see them truncated or surrounded by a coloured band if
whitespace is carried in the image.

Graham


> -----Original Message-----
> From: John Lowry [mailto:[e-mail]]
> Sent: 13 August 2001 13:54
> To: Bland, Graham; 'Stefan Santesson'; [e-mail]
> Subject: RE: Logotype images
> 
> 
> Surely this is an application-specific function ?
> We don't worry about how text gets translated into
> various fonts - do we ?
> 
> Of course, the easiest and best solution would be
> to get rid of the logotype entirely  :-)
> 
> > -----Original Message-----
> > From: [e-mail]
> > [mailto:[e-mail]]On Behalf Of Bland, Graham
> > Sent: Monday, August 13, 2001 8:23 AM
> > To: 'Stefan Santesson'; [e-mail]
> > Subject: RE: Logotype images
> >
> >
> > B&W is not quite that simple, nor is colour.
> >
> > For B&W how many greys are supported, 2 to 256 seems the likely
> > range, also
> > for colour what colour palettes are supported.  There is 
> also the issue of
> > screen resolution, if the size is to be standard expressed as 1"
> > x 0.5" then
> > displays must scale the image depending on the pixels 
> included, or if the
> > size is expressed in pixels then it will be very small on a high
> > resolution
> > screen display and cover the whole screen on a WAP Phone.
> >
> > As another consideration, what are the minimum display
> > resolutions allowed,
> > I presume this would depend on the image, Can the image be 
> displayed in 5
> > pixels by 3 pixels (an extreme case but what is the limit).
> >
> > Should the image be a standard format such as a JPEG in 
> which case scaling
> > becomes easier as long as the device supports the image type.
> >
> >
> > Graham Bland
> >
> >
> > > -----Original Message-----
> > > From: Stefan Santesson [mailto:[e-mail]]
> > > Sent: 13 August 2001 10:08
> > > To: [e-mail]
> > > Subject: Logotype images
> > >
> > >
> > >
> > > Since logotypes in certificates now is an approved PKIX work
> > > item there are
> > > some practical aspects to deal with.
> > >
> > > 1) Logotype image size or scalable images.
> > >
> > > We probably need to define a standard size for logotype
> > > images or find
> > > another way to define scalable logotypes in order to enhance
> > > homogeneous
> > > display of certificates.
> > >
> > > The alternative is to allow scalable logotypes but I have
> > > been told that
> > > there are no easy and appropriate ways to do this.
> > >
> > > 2) Colour and B&W images.
> > >
> > > Some clients, such as mobile phones does not have colour
> > > display and colour
> > > images may not work in B&W.
> > > We probably need a convension that allows inclusion of 2
> > > images for each
> > > logotype (colour and B&W).
> > > Possible solotions are either a convension defined in the
> > > ASN.1 structure
> > > or just a file naming convension for the image files.
> > >
> > > Any suggestions?
> > >
> > > /Stefan
> > >
> >
> 

--------------InterScan_NT_MIME_Boundary
Content-Type: text/plain;
	name="Open_Interactive_Disclaimer.txt"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
	filename="Open_Interactive_Disclaimer.txt"

This message is confidential and is intended for the addressee only; unless clearly 
stated that this disclaimer should not apply, this e-mail is not intended to create legally
 binding commitments on behalf of any company in the British Interactive Broadcasting 
Holding Limited group, nor do its contents reflect the corporate views or policies of any 
such company. Any unauthorised disclosure, use or dissemination, either whole or 
partial, is prohibited. If you are not the intended recipient of the message, please notify 
the sender immediately.

--------------InterScan_NT_MIME_Boundary--


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f7DCscp18872 for ietf-pkix-bks; Mon, 13 Aug 2001 05:54:38 -0700 (PDT)
Received: from gto-mailer1.bbn.com (cam-mailer1.bbn.com [128.33.0.36]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f7DCsaN18868 for <[e-mail]>; Mon, 13 Aug 2001 05:54:36 -0700 (PDT)
Received: from JLOWRY1 (dhcp33-085-176.bbn.com [128.33.85.176]) by gto-mailer1.bbn.com (8.9.3+Sun/8.9.3) with SMTP id IAA25380; Mon, 13 Aug 2001 08:55:58 -0400 (EDT)
From: "John Lowry" <[e-mail]>
To: "Bland, Graham" <[e-mail]>, "'Stefan Santesson'" <[e-mail]>, <[e-mail]>
Subject: RE: Logotype images
Date: Mon, 13 Aug 2001 08:53:43 -0400
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
In-Reply-To: <36086CC80304D3119B040008C75DF596095F20C3@claudio>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2462.0000
Importance: Normal
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>

Surely this is an application-specific function ?
We don't worry about how text gets translated into
various fonts - do we ?

Of course, the easiest and best solution would be
to get rid of the logotype entirely  :-)

> -----Original Message-----
> From: [e-mail]
> [mailto:[e-mail]]On Behalf Of Bland, Graham
> Sent: Monday, August 13, 2001 8:23 AM
> To: 'Stefan Santesson'; [e-mail]
> Subject: RE: Logotype images
>
>
> B&W is not quite that simple, nor is colour.
>
> For B&W how many greys are supported, 2 to 256 seems the likely
> range, also
> for colour what colour palettes are supported.  There is also the issue of
> screen resolution, if the size is to be standard expressed as 1"
> x 0.5" then
> displays must scale the image depending on the pixels included, or if the
> size is expressed in pixels then it will be very small on a high
> resolution
> screen display and cover the whole screen on a WAP Phone.
>
> As another consideration, what are the minimum display
> resolutions allowed,
> I presume this would depend on the image, Can the image be displayed in 5
> pixels by 3 pixels (an extreme case but what is the limit).
>
> Should the image be a standard format such as a JPEG in which case scaling
> becomes easier as long as the device supports the image type.
>
>
> Graham Bland
>
>
> > -----Original Message-----
> > From: Stefan Santesson [mailto:[e-mail]]
> > Sent: 13 August 2001 10:08
> > To: [e-mail]
> > Subject: Logotype images
> >
> >
> >
> > Since logotypes in certificates now is an approved PKIX work
> > item there are
> > some practical aspects to deal with.
> >
> > 1) Logotype image size or scalable images.
> >
> > We probably need to define a standard size for logotype
> > images or find
> > another way to define scalable logotypes in order to enhance
> > homogeneous
> > display of certificates.
> >
> > The alternative is to allow scalable logotypes but I have
> > been told that
> > there are no easy and appropriate ways to do this.
> >
> > 2) Colour and B&W images.
> >
> > Some clients, such as mobile phones does not have colour
> > display and colour
> > images may not work in B&W.
> > We probably need a convension that allows inclusion of 2
> > images for each
> > logotype (colour and B&W).
> > Possible solotions are either a convension defined in the
> > ASN.1 structure
> > or just a file naming convension for the image files.
> >
> > Any suggestions?
> >
> > /Stefan
> >
>



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f7DCNgg17985 for ietf-pkix-bks; Mon, 13 Aug 2001 05:23:42 -0700 (PDT)
Received: from claudio.bib.co.uk (gateway.bib.co.uk [195.171.24.2]) by above.proper.com (8.11.3/8.11.3) with SMTP id f7DCNeN17980 for <[e-mail]>; Mon, 13 Aug 2001 05:23:40 -0700 (PDT)
Received: from 127.0.0.1 by claudio.bib.co.uk (InterScan E-Mail VirusWall NT); Mon, 13 Aug 2001 13:22:58 +0100
Received: by claudio with Internet Mail Service (5.5.2653.19) id <QALMPZ01>; Mon, 13 Aug 2001 13:22:58 +0100
Message-ID: <36086CC80304D3119B040008C75DF596095F20C3@claudio>
From: "Bland, Graham" <[e-mail]>
To: "'Stefan Santesson'" <[e-mail]>, [e-mail]
Subject: RE: Logotype images
Date: Mon, 13 Aug 2001 13:22:57 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/mixed; boundary="------------InterScan_NT_MIME_Boundary"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>

This is a multi-part message in MIME format.

--------------InterScan_NT_MIME_Boundary
Content-Type: text/plain;
	charset="iso-8859-1"

B&W is not quite that simple, nor is colour.

For B&W how many greys are supported, 2 to 256 seems the likely range, also
for colour what colour palettes are supported.  There is also the issue of
screen resolution, if the size is to be standard expressed as 1" x 0.5" then
displays must scale the image depending on the pixels included, or if the
size is expressed in pixels then it will be very small on a high resolution
screen display and cover the whole screen on a WAP Phone.

As another consideration, what are the minimum display resolutions allowed,
I presume this would depend on the image, Can the image be displayed in 5
pixels by 3 pixels (an extreme case but what is the limit).

Should the image be a standard format such as a JPEG in which case scaling
becomes easier as long as the device supports the image type.


Graham Bland


> -----Original Message-----
> From: Stefan Santesson [mailto:[e-mail]]
> Sent: 13 August 2001 10:08
> To: [e-mail]
> Subject: Logotype images
> 
> 
> 
> Since logotypes in certificates now is an approved PKIX work 
> item there are 
> some practical aspects to deal with.
> 
> 1) Logotype image size or scalable images.
> 
> We probably need to define a standard size for logotype 
> images or find 
> another way to define scalable logotypes in order to enhance 
> homogeneous 
> display of certificates.
> 
> The alternative is to allow scalable logotypes but I have 
> been told that 
> there are no easy and appropriate ways to do this.
> 
> 2) Colour and B&W images.
> 
> Some clients, such as mobile phones does not have colour 
> display and colour 
> images may not work in B&W.
> We probably need a convension that allows inclusion of 2 
> images for each 
> logotype (colour and B&W).
> Possible solotions are either a convension defined in the 
> ASN.1 structure 
> or just a file naming convension for the image files.
> 
> Any suggestions?
> 
> /Stefan 
> 

--------------InterScan_NT_MIME_Boundary
Content-Type: text/plain;
	name="Open_Interactive_Disclaimer.txt"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
	filename="Open_Interactive_Disclaimer.txt"

This message is confidential and is intended for the addressee only; unless clearly 
stated that this disclaimer should not apply, this e-mail is not intended to create legally
 binding commitments on behalf of any company in the British Interactive Broadcasting 
Holding Limited group, nor do its contents reflect the corporate views or policies of any 
such company. Any unauthorised disclosure, use or dissemination, either whole or 
partial, is prohibited. If you are not the intended recipient of the message, please notify 
the sender immediately.

--------------InterScan_NT_MIME_Boundary--


Received: by above.proper.com (8.11.3/8.11.3) id f7D98OG05227 for ietf-pkix-bks; Mon, 13 Aug 2001 02:08:24 -0700 (PDT)
Received: from exafix.addtrust.com ([212.112.175.83]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f7D98LN05222 for <[e-mail]>; Mon, 13 Aug 2001 02:08:22 -0700 (PDT)
Received: from santesson.addtrust.com ([192.168.101.114]) by exafix.addtrust.com with Microsoft SMTPSVC(5.0.2195.1600); Mon, 13 Aug 2001 11:07:43 +0200
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.0
Date: Mon, 13 Aug 2001 11:08:19 +0200
To: [e-mail]
From: Stefan Santesson <[e-mail]>
Subject: Logotype images
In-Reply-To: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
X-OriginalArrivalTime: 13 Aug 2001 09:07:43.0411 (UTC) FILETIME=[69445030:01C123D7]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>

Since logotypes in certificates now is an approved PKIX work item there are 
some practical aspects to deal with.

1) Logotype image size or scalable images.

We probably need to define a standard size for logotype images or find 
another way to define scalable logotypes in order to enhance homogeneous 
display of certificates.

The alternative is to allow scalable logotypes but I have been told that 
there are no easy and appropriate ways to do this.

2) Colour and B&W images.

Some clients, such as mobile phones does not have colour display and colour 
images may not work in B&W.
We probably need a convension that allows inclusion of 2 images for each 
logotype (colour and B&W).
Possible solotions are either a convension defined in the ASN.1 structure 
or just a file naming convension for the image files.

Any suggestions?

/Stefan 



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f7A8h0C03749 for ietf-pkix-bks; Fri, 10 Aug 2001 01:43:00 -0700 (PDT)
Received: from phnxpop5.phnx.uswest.net (phnxpop5.phnx.uswest.net [206.80.192.5]) by above.proper.com (8.11.3/8.11.3) with SMTP id f7A8gwN03743 for <[e-mail]>; Fri, 10 Aug 2001 01:42:59 -0700 (PDT)
Received: (qmail 43131 invoked by uid 0); 10 Aug 2001 08:42:57 -0000
Received: from ajdialup184.phnx.uswest.net (HELO ?192.168.0.3?) (63.225.199.184) by phnxpop5.phnx.uswest.net with SMTP; 10 Aug 2001 08:42:57 -0000
Date: Fri, 10 Aug 2001 01:40:50 -0700
Message-Id: <a05100307b7994dd75bd9@[192.168.0.3]>
From: "Hoyt L. Kesterson II" <[e-mail]>
To: "X.509": ;
Mime-Version: 1.0
X-Sender: [e-mail]
Subject: corrected URL to the revised announcement
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>

The agenda for the meeting in Flagstaff has been changed such that 
work on X.509 will be on Tuesday and Wednesday, 25 and 26 September, 
instead of Wednesday and Thursday as originally scheduled. The 
complete revised agenda can be found in the revised announcement at

   ftp://ftp.bull.com/pub/OSIdirectory/Flagstaff2001/announcementRev1.pdf


I have been told that Netscape 4.6 works (but by a person who works 
for Bull). I was using 4.77 and the Netscape support person tried 
4.78 and 6.1

    hoyt


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f7A7nFP00576 for ietf-pkix-bks; Fri, 10 Aug 2001 00:49:15 -0700 (PDT)
Received: from phnxpop3.phnx.uswest.net (phnxpop3.phnx.uswest.net [206.80.192.3]) by above.proper.com (8.11.3/8.11.3) with SMTP id f7A7nEN00569 for <[e-mail]>; Fri, 10 Aug 2001 00:49:14 -0700 (PDT)
Received: (qmail 1268 invoked by uid 0); 10 Aug 2001 07:49:08 -0000
Received: from azdialup204.phnx.uswest.net (HELO ?192.168.0.3?) (63.225.215.204) by phnxpop3.phnx.uswest.net with SMTP; 10 Aug 2001 07:49:08 -0000
Date: Fri, 10 Aug 2001 00:48:35 -0700
Message-Id: <a05100303b7993a0bb51e@[192.168.0.3]>
From: "Hoyt L. Kesterson II" <[e-mail]>
To: "X.509": ;
Mime-Version: 1.0
X-Sender: [e-mail]
Subject: Canadian contribution on enhancements to public-key and attribute certificates
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>

The Canadian contribution on SC06 N 11987 Revised Working Document on 
Enhancements to Public-key and Attribute Certificates has been 
distributed by the SSC6 Secretariat as SC06 N 12011

It can be found at

 
ftp://ftp.bull.com/pub/OSIdirectory/Flagstaff2001/InputDocuments/6N12011CanadaOnCertWD.pdf


The agenda for the meeting in Flagstaff has been changed such that 
work on X.509 will be on Tuesday and Wednesday, 25 and 26 September, 
instead of Wednesday and Thursday as originally scheduled. The 
complete revised agenda can be found in the revised announcement at

   ftp://ftp.bull.com/pub/OSIdirectory/Flagstaff2001/announcementRev1.doc


The worm that is munching its way through the internet has caused the 
administrator of the ftp.bull.com system to tighten up its port 
control. Unfortunately, the Netscape browser wants to use a port that 
is blocked. The result is that use of the URLs above results in no 
response from the server. I was told that IE works and so does my old 
rock solid VersaTerm FTP Link application.

I spent $30 to hear a Netscape support person tell me that although 
he had confirmed that neither current release of Netscape would work 
and that although his IE browser would work, the fact that one server 
could not be accessed was not important enough to spend time on.

Therefore, I have not been able to check, as i normally do, that the 
URLs are correct. Please let me know if you have a problem. Meanwhile 
I am out looking for a browser that will run on a MAC and support FTP 
in a directory browsing mode. Recommendations gratefully accepted.

    hoyt


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f79Iswf29816 for ietf-pkix-bks; Thu, 9 Aug 2001 11:54:58 -0700 (PDT)
Received: from email.nist.gov (email.nist.gov [129.6.2.7]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f79IsuN29812; Thu, 9 Aug 2001 11:54:56 -0700 (PDT)
Received: (from nobody@localhost) by email.nist.gov (8.9.3/8.9.3) id OAA18429; Thu, 9 Aug 2001 14:55:09 -0400 (EDT)
From: C Michael Chernick <[e-mail]>
To: [e-mail], [e-mail]
Subject: Draft NIST S/MIME Profile available (Comment Period Extended)
Message-ID: <[e-mail]>
Date: Thu, 09 Aug 2001 14:55:09 -0400 (EDT)
Cc: [e-mail], [e-mail]
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
User-Agent: IMP/PHP IMAP webmail program 2.2.5
X-Originating-IP: 217.33.146.249
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>

FYI,

At yesterday's SMIME session at the London IETF, it was suggested that
NIST extend the deadline for comments on the Draft NIST S/MIME V3 Client
Profile.  Also, it was suggested that this notice be sent to the PKIX list
as well as the SMIME list. Thus, I am resending the announcement sent out
by Tim Polk on Monday, 2 July 2001 to the SMIME list.  The deadline for 
comments has been extended until 17 September 2001.

Thanks,
   Mike Chernick


---------Original Message Sent by Tim Polk to SMIME List on 2 July---------
FYI,

I have attached below the announcement for a recently released NIST draft 
document concerning S/MIME V3.  The document is intended to define an 
appropriate subset of the S/MIME standards for broad application in the U.S. 
Federal Government.  NIST will be supporting this document through the 
development of an automated conformance testing tool.  We hope the deployment 
of this tool will ease the development of conformant S/MIME V3 clients!

We are very interested in comments from both developers and the user 
community.  Please take the time to review the draft profile and NIST's plans 
for the automated testing facility.  We would appreciate comments on the 
profile by 17 August 2001 (now extended to 17 September).  Please send  
comments to Mike Chernick (NIST's S/MIME project leader) at <[e-mail]>.

BTW, Mike will be presenting an overview of this project in the S/MIME WG 
during the London IETF meeting.  Both Mike and I will be there all week, and 
will be available to discuss this project.

Thanks!

Tim Polk


----------------------

The U.S. National Institute of Standards and Technology (NIST) has recently 
released a draft S/MIME V3 Client Profile. This profile was produced as 
guidance in the development and procurement of commercial-off-the-shelf (COTS) 
S/MIME-compliant products. This profile document identifies requirements for a 
secure and interoperable S/MIME V3 client implementation. The profile cites 
requirements for sending and receiving both signed and encrypted messages, as 
well as requirements for signed receipt processing.

Although the S/MIME specifications were designed to promote interoperable 
secure electronic mail, implementations may support different optional services
and the specifications may unintentionally allow multiple interpretations. As a
result, different implementations of S/MIME may not be fully interoperable or 
provide the desired level of security. Conformance to this proposed profile 
will help to assure that S/MIME implementations will be able to interoperate 
and provide reasonable security assurance to users.

The Draft Profile is available (in PDF format) for public comment at: 
http://csrc.ncsl.nist.gov/pki/smime/draft_SMIMEProfile.pdf

Comments are requested by (**was 17 August 2001**) *****NOW EXTENDED TO 
17 September 2001***** and should be sent to [e-mail].

NIST is developing tests and testing tools to determine the level of 
conformance of an S/MIME V3 client implementation with this profile. It is 
planned that within the next several months, NIST will have a remote testing 
facility on-line which will allow S/MIME V3 messages to be sent to the NIST 
test site for processing to determine if the remotely generated messages 
conform to the profile. In addition, messages may be sent to the test site to 
cause the NIST site to emit S/MIME V3 messages so that a remote system may 
receive S/MIME V3 messages, and verify that remote system can process the 
messages correctly.

Further information on the NIST S/MIME Program may be obtained at
http://csrc.ncsl.nist.gov/pki/smime/welcome.htm or by
contacting Michael Chernick  at <[e-mail]>.

--------------------------------------------------------------------------------
C. Michael Chernick
[phone]   [e-mail]
Computer Security Division 
National Institute of Standards and Technology (NIST)
--------------------------------------------------------------------------------

 


Received: by above.proper.com (8.11.3/8.11.3) id f79G7q226116 for ietf-pkix-bks; Thu, 9 Aug 2001 09:07:52 -0700 (PDT)
Received: from thalia.fm.intel.com (fmfdns02.fm.intel.com [132.233.247.11]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f79G7pN26111 for <[e-mail]>; Thu, 9 Aug 2001 09:07:51 -0700 (PDT)
Received: from fmsmsxvs040.fm.intel.com (fmsmsxv040-1.fm.intel.com [132.233.48.108]) by thalia.fm.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.41 2001/07/09 21:06:22 root Exp $) with SMTP id QAA18028 for <[e-mail]>; Thu, 9 Aug 2001 16:07:53 GMT
Received: from fmsmsx17.intel.com ([132.233.48.17]) by fmsmsxvs040.fm.intel.com (NAVGW 2.5.1.6) with SMTP id M2001080909073318167 for <[e-mail]>; Thu, 09 Aug 2001 09:07:33 -0700
Received: by fmsmsx17.fm.intel.com with Internet Mail Service (5.5.2653.19) id <QML695TY>; Thu, 9 Aug 2001 09:08:37 -0700
Message-ID: <[e-mail]>
From: "Eissa, Mohamed" <[e-mail]>
To: [e-mail]
Cc: "Treleaven, Russell" <[e-mail]>
Subject: pki alt-subject and unstructured name
Date: Thu, 9 Aug 2001 09:07:47 -0700 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>

Hi,

I am trying to locate the authoritative document regarding alt-subject and
unstructured name fields in x509 certificates.

What I'm trying to find out is how they are used to map enrollment requests
from one scep server to multiple ca's?

Sincerely,

Mohamed Eissa
Intel Canada


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f79Args05611 for ietf-pkix-bks; Thu, 9 Aug 2001 03:53:42 -0700 (PDT)
Received: from btclick.com (mta01.btfusion.com [62.172.195.11]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f79AmQN05331; Thu, 9 Aug 2001 03:48:37 -0700 (PDT)
Received: from JOHNVARSYSTEM ([213.123.188.215]) by btclick.com (Netscape Messaging Server 4.05) with SMTP id GHSRBP05.F0I; Thu, 9 Aug 2001 11:47:49 +0100 
From: "John Ross" <[e-mail]>
To: <[e-mail]>, <[e-mail]>, "XMLSigWG" <[e-mail]>
Subject: Comments requested on ETSI Draft TR "XML format for signature policies"
Date: Thu, 9 Aug 2001 11:49:28 +0100
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700
Importance: Normal
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>

Request for comments on draft ETSI TR on XML based Signature Policies:

This draft ETSI technical report defines Signature Policies using XML which
are based on the ASN.1 Signature Policies defined in ETSI TS 101 733 and RFC
3125.

This draft TR is offered as a starting point for discussion on XML based
Signature Policies. All comments received will help to determine the future
direction this work item will take in ETSI. This draft technical report is
being made publicly available for review and comment by any company,
individual or organisation with interest in this area.  A copy can be
obtained through the ETSI El Sign web site (see below).

Comments are requested by 14th September.


Background

The development of this technical report

"XML format for signature policies"

is one of the tasks the ETSI Electronic Signature and Infrastructure Working
Group is progressing within the European Electronic Signature
Standardisation
Initiative (EESSI). The ETSI El Sign Web-site (see below) provides further
information about the ETSI activities and the EESSI program.

REQUESTED ACTION

Please send your comments and suggestions not later than 14 September to the
ETSI El Sign e-mail list [e-mail], with copy to the editor on
[e-mail] .   Please put "ETSI-XML-SigPol" at the front of the
Subject
field of all submissions to the e-mail list on this topic.

To register with the EL-SIGN list and download the draft document
(STF178Task3DraftTR.pdf) see:

http://www.etsi.org/sec/el-sign.htm


The purpose of the open e-mail list is to stimulate discussion of the
published comments and contributions. Therefore, early submissions are
welcome. We expect that discussions will go on through the open e-mail list
under and after the comments period.


With regards

Juan  Carlos Cruellas (Universitat Politecnica de Catalunya)
Editor - XML format for signature policies

[e-mail]

and

György Endersz, Telia Research AB
Chair ETSI ESI Working Group
[e-mail]




Received: by above.proper.com (8.11.3/8.11.3) id f779PFe22537 for ietf-pkix-bks; Tue, 7 Aug 2001 02:25:15 -0700 (PDT)
Received: from p-mail1.cnet.fr (p-mail1.rd.francetelecom.fr [193.49.124.31]) by above.proper.com (8.11.3/8.11.3) with SMTP id f779PDN22533 for <[e-mail]>; Tue, 7 Aug 2001 02:25:13 -0700 (PDT)
Received: by p-biset.rd.francetelecom.fr with Internet Mail Service (5.5.2653.19) id <QFRKAJY5>; Tue, 7 Aug 2001 11:07:29 +0200
Received: from francetelecom.com (lsun607.rd.francetelecom.fr [161.104.14.41]) by l-mhs1.rd.francetelecom.fr with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id QN9SBDLT; Tue, 7 Aug 2001 11:06:49 +0200
Message-ID: <[e-mail]>
Date: Tue, 07 Aug 2001 11:09:22 +0200
From: Olivier DUBUISSON <[e-mail]>
Organization: France Telecom R&D
X-Mailer: Mozilla 4.51 [en] (X11; I; SunOS 5.8 sun4u)
X-Accept-Language: fr-FR, en
MIME-Version: 1.0
To: Hideyuki Odahara <[e-mail]>
CC: [e-mail]
Subject: Re: draft-ietf-pkix-ac509prof-09  ASN.1 "IMPLICIT"
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>

Hideyuki Odahara wrote:
> 
> I've read the draft-ietf-pkix-ac509prof-09 and
> the draft-ietf-pkix-ac509prof-06.
> And I found the difference about ASN.1 Notation.
> It was "IMPLICIT".
> 
> draft-ietf-pkix-ac509prof-09 wrote:
> ------------------------------------
> Appendix B: ASN.1 Module
> 
>  PKIXAttributeCertificate {iso(1) identified-organization(3) dod(6)
>               internet(1) security(5) mechanisms(5) pkix(7) id-mod(0)
>               id-mod-attribute-cert(12)}
> 
>     DEFINITIONS IMPLICIT TAGS ::=
>                 ^^^^^^^^
>     BEGIN
> 
>     -- EXPORTS ALL --
> -------------------------------------
> 
> draft-ietf-pkix-ac509prof-06 wrote:
> -------------------------------------
> Appendix B: ASN.1 Module
> 
>  PKIXAttributeCertificate {iso(1) identified-organization(3) dod(6)
>               internet(1) security(5) mechanisms(5) pkix(7) id-mod(0)
>               id-mod-attribute-cert(12)}
> 
>     DEFINITIONS EXPLICIT TAGS ::=
>                 ^^^^^^^^
>     BEGIN
> 
>     -- EXPORTS ALL --
> -------------------------------------
> 
> Why did "EXPLICIT" change to "IMPLICIT".
> There is no reason and no description about
> chainging at Appendix C:Change History.
> 
> Please tell me.

I remember Phil Griffin pointing this mistake (at least to me) some months
ago. I'm not involved in the history of PKIX, but to me, the biggest mistake
above is to keep the same OID for two modules that are not compatible as
far as encoding goes.
-- 
Olivier DUBUISSON
france telecom R&D
     _                 DTL/MSV - 22307 Lannion Cedex - France
    ( )           tel: [phone] - fax: [phone]
    /.\/               --------------------------------------
    \_/\               Site ASN.1 : http://asn1.elibel.tm.fr/


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f775Mn224907 for ietf-pkix-bks; Mon, 6 Aug 2001 22:22:49 -0700 (PDT)
Received: from tama3.tas.ntt.co.jp (tama3.tas.ntt.co.jp [192.68.248.40]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f775MkN24903 for <[e-mail]>; Mon, 6 Aug 2001 22:22:47 -0700 (PDT)
Received: from nttmail.ecl.ntt.co.jp (nttmail.tas.ntt.co.jp [192.68.248.11]) by tama3.tas.ntt.co.jp (8.9.3+3.2W/3.7W/01/21/00) with ESMTP id OAA24125 for <[e-mail]>; Tue, 7 Aug 2001 14:22:44 +0900 (JST) (envelope-from [e-mail])
Received: from dsa.isl.ntt.co.jp by nttmail.ecl.ntt.co.jp (8.9.3+3.2W/3.7W/03/21/01) with ESMTP id OAA15559 for <[e-mail]>; Tue, 7 Aug 2001 14:22:43 +0900 (JST) (envelope-from [e-mail])
Received: from cats by dsa.isl.ntt.co.jp (8.11.5/isl-2.0) id f775Mgm60121; Tue, 7 Aug 2001 14:22:42 +0900 (JST)
Date: Tue, 07 Aug 2001 14:23:53 +0900
From: Hideyuki Odahara <[e-mail]>
To: [e-mail]
Subject: draft-ietf-pkix-ac509prof-09  ASN.1 "IMPLICIT"
Message-Id: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="ISO-2022-JP"
Content-Transfer-Encoding: 7bit
X-Mailer: Becky! ver. 2.00.03
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>

I've read the draft-ietf-pkix-ac509prof-09 and 
the draft-ietf-pkix-ac509prof-06.
And I found the difference about ASN.1 Notation.
It was "IMPLICIT".


draft-ietf-pkix-ac509prof-09 wrote:
------------------------------------
Appendix B: ASN.1 Module

 PKIXAttributeCertificate {iso(1) identified-organization(3) dod(6)
              internet(1) security(5) mechanisms(5) pkix(7) id-mod(0)
              id-mod-attribute-cert(12)}


    DEFINITIONS IMPLICIT TAGS ::=
                ^^^^^^^^
    BEGIN

    -- EXPORTS ALL --
-------------------------------------

draft-ietf-pkix-ac509prof-06 wrote:
-------------------------------------
Appendix B: ASN.1 Module

 PKIXAttributeCertificate {iso(1) identified-organization(3) dod(6)
              internet(1) security(5) mechanisms(5) pkix(7) id-mod(0)
              id-mod-attribute-cert(12)}


    DEFINITIONS EXPLICIT TAGS ::=
                ^^^^^^^^
    BEGIN

    -- EXPORTS ALL --
-------------------------------------


Why did "EXPLICIT" change to "IMPLICIT".
There is no reason and no description about
chainging at Appendix C:Change History.

Please tell me.

regards



----------
  Hideyuki Odahara $B!'(B [e-mail]



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f763gmr21328 for ietf-pkix-bks; Sun, 5 Aug 2001 20:42:48 -0700 (PDT)
Received: from e1.ny.us.ibm.com (e1.ny.us.ibm.com [32.97.182.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f763gks21324 for <[e-mail]>; Sun, 5 Aug 2001 20:42:46 -0700 (PDT)
Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.117.200.22]) by e1.ny.us.ibm.com (8.9.3/8.9.3) with ESMTP id XAA194050; Sun, 5 Aug 2001 23:40:40 -0400
Received: from d01ml062.pok.ibm.com (d01ml062.pok.ibm.com [9.117.250.163]) by northrelay02.pok.ibm.com (8.11.1m3/NCO v4.97) with ESMTP id f763Yum09490; Sun, 5 Aug 2001 23:34:56 -0400
Importance: Normal
Subject: Re: Verifying Certificates when CA key update
To: li yunfeng <[e-mail]>
Cc: [e-mail]
X-Mailer: Lotus Notes Release 5.0.3 (Intl) 21 March 2000
Message-ID: <[e-mail]>
From: "Tom Gindin" <[e-mail]>
Date: Sun, 5 Aug 2001 23:22:21 -0400
X-MIMETrack: Serialize by Router on D01ML062/01/M/IBM(Release 5.0.8 SPR #MIAS4UTJ8H |June 21, 2001) at 08/05/2001 11:42:43 PM
MIME-Version: 1.0
Content-type: text/plain; charset=gb2312
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from base64 to 8bit by above.proper.com id f763gks21325
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>

     I must not have been clear enough.  IMO the check which improves
security is that the issuer and subject names are equivalent.  Setting
these certificates to v1has independent value only if the RP knows that all
other certificates issued by this CA are v3, which cannot generally be the
case.  Good luck with your implementation.

          Tom Gindin

li yunfeng <[e-mail]> on 08/04/2001 03:34:56 AM

To:   Tom Gindin <[e-mail]>
cc:   [e-mail]
Subject:  Re: Verifying Certificates when CA key update


Thank Tom Gindin for answer me. I think if a attacker
can requre a cross certificate form a CA,then he can
spool as a CA.This is based on the opinion of RFC2510
that when CA update its own key for sign certificate,
it will publish the oldwithnwe ,newwithold,and
newwithnew certificate. If the CA publish the
oldwithold certificate at the same time we can prevent
the attacker's spooling. Because we can trust the
public key in oldwithold certificate not trust the
public key in oldwithnew certificate.
All in all thanks Tom Gindin for giving me these
insturct and i will implement the software as you
teach me that set the version of oldwithnew to v1.

 --- Tom Gindin <[e-mail]> µÄÕýÎÄ£º>
>
>      While I'm not sure what you mean by "chived"
> here (perhaps
> "spoofed"?), an OldWithNew certificate should be
> distinguishable from
> end-user certificates by several means.  First, the
> subject name and the
> issuer name should match each other.  Second, it
> should IMO be either a v1
> certificate or contain a CA flag in a basic
> constraints extension - I would
> prefer the latter but it would be wise to find out
> from the actual
> implementors which they're using.  The second check
> does not protect
> against an attack by the subject of a cross
> certificate, but the first
> does.
>      Do we need to add to point 1 of 2.4.2.2 (of
> rfc2510bis-04) at least
> the first of these checks?  If so, do we need to
> make the same change in
> 2.4.2.3?  I would think that we do, so thank you for
> bringing this up.
>
>           Tom Gindin
>
>
> li yunfeng <[e-mail]>@mail.imc.org on
> 08/02/2001 12:05:15 AM
>
> Sent by:  [e-mail]
>
>
> To:   [e-mail]
> cc:
> Subject:  Verifying Certificates when CA key update
>
>
>
> In the document "Inernet X.509 Public Key
> Infrastructure Certificate Management Protocols
> <draft-ietf-pkix-rfc2510bits-03.txt>" 2.4.2segment
> says that when CA key update the verifier can verify
> other person's certificate using OLDwhithNEW
> certificate.
> If we use this methord , we will be chived by other
> who get a certificate from CA and say this is old
> with
> new certificate.
>
>
_________________________________________________________
> Do You Yahoo!? µÇ¼Ãâ·ÑÑÅ»¢µçÓÊ!
> http://mail.yahoo.com.cn
>
> <font
>
color=#6666FF>ÎÞÁÄ£¿ÓôÃÆ£¿¸ßÐË£¿Ã»ÀíÓÉ£¿¶¼À´ÁÄÌì°É£¡</font>¡ª¡ª
> ÑÅ»¢È«ÐÂÁÄÌìÊÒ!
> http://cn.chat.yahoo.com/c/roomlist.html
>
>

_________________________________________________________
Do You Yahoo!? µÇ¼Ãâ·ÑÑÅ»¢µçÓÊ! http://mail.yahoo.com.cn

<font color=#6666FF>ÎÞÁÄ£¿ÓôÃÆ£¿¸ßÐË£¿Ã»ÀíÓÉ£¿¶¼À´ÁÄÌì°É£¡</font>¡ª¡ª
ÑÅ»¢È«ÐÂÁÄÌìÊÒ! http://cn.chat.yahoo.com/c/roomlist.html




Received: by above.proper.com (8.11.3/8.11.3) id f747ZPu28840 for ietf-pkix-bks; Sat, 4 Aug 2001 00:35:25 -0700 (PDT)
Received: from web13703.mail.yahoo.com (web13703.mail.yahoo.com [216.136.175.136]) by above.proper.com (8.11.3/8.11.3) with SMTP id f747ZOs28832 for <[e-mail]>; Sat, 4 Aug 2001 00:35:24 -0700 (PDT)
Message-ID: <[e-mail]>
Received: from [61.139.82.216] by web13703.mail.yahoo.com; Sat, 04 Aug 2001 15:34:56 CST
Date: Sat, 4 Aug 2001 15:34:56 +0800 (CST)
From: =?gb2312?q?li=20yunfeng?= <[e-mail]>
Subject: Re: Verifying Certificates when CA key update
To: Tom Gindin <[e-mail]>
Cc: [e-mail]
In-Reply-To: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=gb2312
Content-Transfer-Encoding: 8bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>

Thank Tom Gindin for answer me. I think if a attacker
can requre a cross certificate form a CA,then he can
spool as a CA.This is based on the opinion of RFC2510
that when CA update its own key for sign certificate,
it will publish the oldwithnwe ,newwithold,and
newwithnew certificate. If the CA publish the
oldwithold certificate at the same time we can prevent
the attacker's spooling. Because we can trust the
public key in oldwithold certificate not trust the
public key in oldwithnew certificate. 
All in all thanks Tom Gindin for giving me these
insturct and i will implement the software as you
teach me that set the version of oldwithnew to v1.

 --- Tom Gindin <[e-mail]> µÄÕýÎÄ£º> 
> 
>      While I'm not sure what you mean by "chived"
> here (perhaps
> "spoofed"?), an OldWithNew certificate should be
> distinguishable from
> end-user certificates by several means.  First, the
> subject name and the
> issuer name should match each other.  Second, it
> should IMO be either a v1
> certificate or contain a CA flag in a basic
> constraints extension - I would
> prefer the latter but it would be wise to find out
> from the actual
> implementors which they're using.  The second check
> does not protect
> against an attack by the subject of a cross
> certificate, but the first
> does.
>      Do we need to add to point 1 of 2.4.2.2 (of
> rfc2510bis-04) at least
> the first of these checks?  If so, do we need to
> make the same change in
> 2.4.2.3?  I would think that we do, so thank you for
> bringing this up.
> 
>           Tom Gindin
> 
> 
> li yunfeng <[e-mail]>@mail.imc.org on
> 08/02/2001 12:05:15 AM
> 
> Sent by:  [e-mail]
> 
> 
> To:   [e-mail]
> cc:
> Subject:  Verifying Certificates when CA key update
> 
> 
> 
> In the document "Inernet X.509 Public Key
> Infrastructure Certificate Management Protocols
> <draft-ietf-pkix-rfc2510bits-03.txt>" 2.4.2segment
> says that when CA key update the verifier can verify
> other person's certificate using OLDwhithNEW
> certificate.
> If we use this methord , we will be chived by other
> who get a certificate from CA and say this is old
> with
> new certificate.
> 
>
_________________________________________________________
> Do You Yahoo!? µÇ¼Ãâ·ÑÑÅ»¢µçÓÊ!
> http://mail.yahoo.com.cn
> 
> <font
>
color=#6666FF>ÎÞÁÄ£¿ÓôÃÆ£¿¸ßÐË£¿Ã»ÀíÓÉ£¿¶¼À´ÁÄÌì°É£¡</font>¡ª¡ª
> ÑÅ»¢È«ÐÂÁÄÌìÊÒ!
> http://cn.chat.yahoo.com/c/roomlist.html
> 
>  

_________________________________________________________
Do You Yahoo!? µÇ¼Ãâ·ÑÑÅ»¢µçÓÊ! http://mail.yahoo.com.cn

<font color=#6666FF>ÎÞÁÄ£¿ÓôÃÆ£¿¸ßÐË£¿Ã»ÀíÓÉ£¿¶¼À´ÁÄÌì°É£¡</font>¡ª¡ª 
ÑÅ»¢È«ÐÂÁÄÌìÊÒ! http://cn.chat.yahoo.com/c/roomlist.html


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f738t1O05123 for ietf-pkix-bks; Fri, 3 Aug 2001 01:55:01 -0700 (PDT)
Received: from postoffice.sarnoff.com (postoffice.sarnoff.com [130.33.10.147]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f738sxs05115 for <[e-mail]>; Fri, 3 Aug 2001 01:54:59 -0700 (PDT)
Received: from postoffice.sarnoff.com ([127.0.0.1]) by postoffice.sarnoff.com (Netscape Messaging Server 4.15) with SMTP id GHHFE600.1PM for <[e-mail]>; Fri, 3 Aug 2001 03:56:30 -0400 
Received: from nova.sarnoff.com ([130.33.8.27]) by postoffice.sarnoff.com (Netscape Messaging Server 4.15) with ESMTP id GH5T1B00.PI2; Fri, 27 Jul 2001 21:19:59 -0400 
Received: from loki.ietf.org (loki.ietf.org [132.151.1.177]) by nova.sarnoff.com (8.9.2/8.9.2) with ESMTP id OAA22847; Tue, 24 Jul 2001 14:28:31 -0400 (EDT)
Received: (from adm@localhost) by loki.ietf.org (8.9.1b+Sun/8.9.1) id OAA20104 for [e-mail]; Tue, 24 Jul 2001 14:15:01 -0400 (EDT)
Received: from ietf.org (odin.ietf.org [10.27.2.28]) by loki.ietf.org (8.9.1b+Sun/8.9.1) with ESMTP id GAA12905 for <[e-mail]>; Tue, 24 Jul 2001 06:33:00 -0400 (EDT)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA06577; Tue, 24 Jul 2001 06:32:59 -0400 (EDT)
Message-Id: <[e-mail]>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: [e-mail]
From: [e-mail]
Reply-to: [e-mail]
Subject: I-D ACTION:draft-ietf-pkix-cmc-compl-00.txt
Date: Tue, 24 Jul 2001 06:32:59 -0400
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Public-Key Infrastructure (X.509) Working Group of the IETF.

	Title		: CMC Compliance Document
	Author(s)	: M. Myers et al.
	Filename	: draft-ietf-pkix-cmc-compl-00.txt
	Pages		: 
	Date		: 23-Jul-01
	
This document provides a set of compliance statements about the CMC
enrollment protocol.  The documents [CMC-STRUCT] and [CMC-TRANS]
provide the definitions of the structure and transport protocols
defined for CMC.  This document provides the information needed to
make a compliant version of CMC.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-pkix-cmc-compl-00.txt

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-pkix-cmc-compl-00.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[e-mail].
In the body type:
	"FILE /internet-drafts/draft-ietf-pkix-cmc-compl-00.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
		
		
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="[e-mail]"

Content-Type: text/plain
Content-ID:	<[e-mail]>

ENCODING mime
FILE /internet-drafts/draft-ietf-pkix-cmc-compl-00.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-pkix-cmc-compl-00.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<[e-mail]>

--OtherAccess--

--NextPart--




Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f738t0T05117 for ietf-pkix-bks; Fri, 3 Aug 2001 01:55:00 -0700 (PDT)
Received: from postoffice.sarnoff.com (postoffice.sarnoff.com [130.33.10.147]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f738sws05107 for <[e-mail]>; Fri, 3 Aug 2001 01:54:59 -0700 (PDT)
Received: from postoffice.sarnoff.com ([127.0.0.1]) by postoffice.sarnoff.com (Netscape Messaging Server 4.15) with SMTP id GHHFE500.DQL for <[e-mail]>; Fri, 3 Aug 2001 03:56:29 -0400 
Received: from nova.sarnoff.com ([130.33.8.27]) by postoffice.sarnoff.com (Netscape Messaging Server 4.15) with ESMTP id GH5SZQ00.OGH; Fri, 27 Jul 2001 21:19:02 -0400 
Received: from loki.ietf.org (loki.ietf.org [132.151.1.177]) by nova.sarnoff.com (8.9.2/8.9.2) with ESMTP id OAA23552; Tue, 24 Jul 2001 14:47:45 -0400 (EDT)
Received: (from adm@localhost) by loki.ietf.org (8.9.1b+Sun/8.9.1) id OAA20451 for [e-mail]; Tue, 24 Jul 2001 14:35:01 -0400 (EDT)
Received: from ietf.org (odin.ietf.org [10.27.2.28]) by loki.ietf.org (8.9.1b+Sun/8.9.1) with ESMTP id GAA12919 for <[e-mail]>; Tue, 24 Jul 2001 06:33:05 -0400 (EDT)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA06589; Tue, 24 Jul 2001 06:33:04 -0400 (EDT)
Message-Id: <[e-mail]>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: [e-mail]
From: [e-mail]
Reply-to: [e-mail]
Subject: I-D ACTION:draft-ietf-pkix-cmc-archive-00.txt
Date: Tue, 24 Jul 2001 06:33:04 -0400
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Public-Key Infrastructure (X.509) Working Group of the IETF.

	Title		: CMC Extensions: Server Side Key Generation and Key 
                          Archival
	Author(s)	: J. Schaad
	Filename	: draft-ietf-pkix-cmc-archive-00.txt
	Pages		: 17
	Date		: 23-Jul-01
	
This document defines a set of extensions to [CMC] that address the
desire for having two additional services:  Server generation of
keys, and server-side archival and subsequent recovery of key
material by the server.  These services are provided by the
definition of additional control statements within the CMC
architecture.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-pkix-cmc-archive-00.txt

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-pkix-cmc-archive-00.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[e-mail].
In the body type:
	"FILE /internet-drafts/draft-ietf-pkix-cmc-archive-00.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
		
		
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="[e-mail]"

Content-Type: text/plain
Content-ID:	<[e-mail]>

ENCODING mime
FILE /internet-drafts/draft-ietf-pkix-cmc-archive-00.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-pkix-cmc-archive-00.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<[e-mail]>

--OtherAccess--

--NextPart--




Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f738sxk05110 for ietf-pkix-bks; Fri, 3 Aug 2001 01:54:59 -0700 (PDT)
Received: from postoffice.sarnoff.com (postoffice.sarnoff.com [130.33.10.147]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f738svs05098 for <[e-mail]>; Fri, 3 Aug 2001 01:54:57 -0700 (PDT)
Received: from postoffice.sarnoff.com ([127.0.0.1]) by postoffice.sarnoff.com (Netscape Messaging Server 4.15) with SMTP id GHHFDT00.KQL for <[e-mail]>; Fri, 3 Aug 2001 03:56:17 -0400 
Received: from nova.sarnoff.com ([130.33.8.27]) by postoffice.sarnoff.com (Netscape Messaging Server 4.15) with ESMTP id GH5SW300.1H9; Fri, 27 Jul 2001 21:16:51 -0400 
Received: from loki.ietf.org (loki.ietf.org [132.151.1.177]) by nova.sarnoff.com (8.9.2/8.9.2) with ESMTP id OAA23921; Tue, 24 Jul 2001 14:56:45 -0400 (EDT)
Received: (from adm@localhost) by loki.ietf.org (8.9.1b+Sun/8.9.1) id OAA20606 for [e-mail]; Tue, 24 Jul 2001 14:45:01 -0400 (EDT)
Received: from ietf.org (odin.ietf.org [10.27.2.28]) by loki.ietf.org (8.9.1b+Sun/8.9.1) with ESMTP id GAA12927 for <[e-mail]>; Tue, 24 Jul 2001 06:33:11 -0400 (EDT)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA06602; Tue, 24 Jul 2001 06:33:11 -0400 (EDT)
Message-Id: <[e-mail]>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: [e-mail]
From: [e-mail]
Reply-to: [e-mail]
Subject: I-D ACTION:draft-ietf-pkix-cmc-trans-00.txt
Date: Tue, 24 Jul 2001 06:33:10 -0400
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Public-Key Infrastructure (X.509) Working Group of the IETF.

	Title		: CMC Transport
	Author(s)	: M. Myers et al.
	Filename	: draft-ietf-pkix-cmc-trans-00.txt
	Pages		: 
	Date		: 23-Jul-01
	
This document defines a number of transport mechanisms that are used
to move [CMC] messages.  The transport mechanisms described in this
document are: HTTP, file, mail and TCP.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-pkix-cmc-trans-00.txt

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-pkix-cmc-trans-00.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[e-mail].
In the body type:
	"FILE /internet-drafts/draft-ietf-pkix-cmc-trans-00.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
		
		
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="[e-mail]"

Content-Type: text/plain
Content-ID:	<[e-mail]>

ENCODING mime
FILE /internet-drafts/draft-ietf-pkix-cmc-trans-00.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-pkix-cmc-trans-00.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<[e-mail]>

--OtherAccess--

--NextPart--




Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f738sxn05111 for ietf-pkix-bks; Fri, 3 Aug 2001 01:54:59 -0700 (PDT)
Received: from postoffice.sarnoff.com (postoffice.sarnoff.com [130.33.10.147]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f738sws05103 for <[e-mail]>; Fri, 3 Aug 2001 01:54:58 -0700 (PDT)
Received: from postoffice.sarnoff.com ([127.0.0.1]) by postoffice.sarnoff.com (Netscape Messaging Server 4.15) with SMTP id GHHFDW00.TQT for <[e-mail]>; Fri, 3 Aug 2001 03:56:20 -0400 
Received: from nova.sarnoff.com ([130.33.8.27]) by postoffice.sarnoff.com (Netscape Messaging Server 4.15) with ESMTP id GH5SW500.PHO; Fri, 27 Jul 2001 21:16:53 -0400 
Received: from loki.ietf.org (loki.ietf.org [132.151.1.177]) by nova.sarnoff.com (8.9.2/8.9.2) with ESMTP id PAA24409; Tue, 24 Jul 2001 15:10:56 -0400 (EDT)
Received: (from adm@localhost) by loki.ietf.org (8.9.1b+Sun/8.9.1) id OAA20781 for [e-mail]; Tue, 24 Jul 2001 14:55:01 -0400 (EDT)
Received: from ietf.org (odin.ietf.org [10.27.2.28]) by loki.ietf.org (8.9.1b+Sun/8.9.1) with ESMTP id GAA12934 for <[e-mail]>; Tue, 24 Jul 2001 06:33:16 -0400 (EDT)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA06614; Tue, 24 Jul 2001 06:33:16 -0400 (EDT)
Message-Id: <[e-mail]>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: [e-mail]
From: [e-mail]
Reply-to: [e-mail]
Subject: I-D ACTION:draft-ietf-pkix-ipki-new-rfc2527-00.txt
Date: Tue, 24 Jul 2001 06:33:15 -0400
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Public-Key Infrastructure (X.509) Working Group of the IETF.

	Title		: Internet X.509 Public Key Infrastructure Certificate 
                          Policy and Certification Practices Framework
	Author(s)	: S. Chokhani et al.
	Filename	: draft-ietf-pkix-ipki-new-rfc2527-00.txt
	Pages		: 54
	Date		: 23-Jul-01
	
This document presents a framework to assist the writers of 
certificate policies or certification practice statements for 
participants within public key infrastructures, such as 
certification authorities, policy authorities, and communities of 
interest that wish to rely on certificates.  In particular, the 
framework provides a comprehensive list of topics that potentially 
(at the writer's discretion) need to be covered in a certificate 
policy or a certification practice statement.  This document is 
being submitted to the RFC Editor with a request for publication as 
an Informational RFC.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-pkix-ipki-new-rfc2527-00.txt

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-pkix-ipki-new-rfc2527-00.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[e-mail].
In the body type:
	"FILE /internet-drafts/draft-ietf-pkix-ipki-new-rfc2527-00.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
		
		
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="[e-mail]"

Content-Type: text/plain
Content-ID:	<[e-mail]>

ENCODING mime
FILE /internet-drafts/draft-ietf-pkix-ipki-new-rfc2527-00.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-pkix-ipki-new-rfc2527-00.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<[e-mail]>

--OtherAccess--

--NextPart--




Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f738st405082 for ietf-pkix-bks; Fri, 3 Aug 2001 01:54:55 -0700 (PDT)
Received: from postoffice.sarnoff.com (postoffice.sarnoff.com [130.33.10.147]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f738srs05075 for <[e-mail]>; Fri, 3 Aug 2001 01:54:54 -0700 (PDT)
Received: from postoffice.sarnoff.com ([127.0.0.1]) by postoffice.sarnoff.com (Netscape Messaging Server 4.15) with SMTP id GHHF4O00.0Q9 for <[e-mail]>; Fri, 3 Aug 2001 03:50:48 -0400 
Received: from nova.sarnoff.com ([130.33.8.27]) by postoffice.sarnoff.com (Netscape Messaging Server 4.15) with ESMTP id GH5C7V00.T0A; Fri, 27 Jul 2001 15:16:43 -0400 
Received: from loki.ietf.org (loki.ietf.org [132.151.1.177]) by nova.sarnoff.com (8.9.2/8.9.2) with ESMTP id OAA10298; Fri, 27 Jul 2001 14:17:26 -0400 (EDT)
Received: (from adm@localhost) by loki.ietf.org (8.9.1b+Sun/8.9.1) id NAA19129 for [e-mail]; Fri, 27 Jul 2001 13:55:01 -0400 (EDT)
Received: from ietf.org (odin.ietf.org [10.27.2.28]) by loki.ietf.org (8.9.1b+Sun/8.9.1) with ESMTP id HAA13144 for <[e-mail]>; Fri, 27 Jul 2001 07:22:52 -0400 (EDT)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA07700; Fri, 27 Jul 2001 07:22:50 -0400 (EDT)
Message-Id: <[e-mail]>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: [e-mail]
From: [e-mail]
Reply-to: [e-mail]
Subject: I-D ACTION:draft-ietf-pkix-logotypes-00.txt
Date: Fri, 27 Jul 2001 07:22:49 -0400
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Public-Key Infrastructure (X.509) Working Group of the IETF.

	Title		: Internet X.509 Public Key Infrastructure Logotypes in 
                          X.509 certificates
	Author(s)	: S. Santesson
	Filename	: draft-ietf-pkix-logotypes-00.txt
	Pages		: 
	Date		: 26-Jul-01
	
This document contains an initial outline of a standard for inclusion
of logotypes in certificates. The draft includes background
discussions around different aspects of problems and solutions,
forming a starting point for the creation of a complete standard.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-pkix-logotypes-00.txt

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-pkix-logotypes-00.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[e-mail].
In the body type:
	"FILE /internet-drafts/draft-ietf-pkix-logotypes-00.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
		
		
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="[e-mail]"

Content-Type: text/plain
Content-ID:	<[e-mail]>

ENCODING mime
FILE /internet-drafts/draft-ietf-pkix-logotypes-00.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-pkix-logotypes-00.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<[e-mail]>

--OtherAccess--

--NextPart--




Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f732BFH04548 for ietf-pkix-bks; Thu, 2 Aug 2001 19:11:15 -0700 (PDT)
Received: from postoffice.sarnoff.com (postoffice.sarnoff.com [130.33.10.147]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f732BEs04541 for <[e-mail]>; Thu, 2 Aug 2001 19:11:14 -0700 (PDT)
Received: from postoffice.sarnoff.com ([127.0.0.1]) by postoffice.sarnoff.com (Netscape Messaging Server 4.15) with SMTP id GHGZ3W00.TDR for <[e-mail]>; Thu, 2 Aug 2001 22:04:44 -0400 
Received: from nova.sarnoff.com ([130.33.8.27]) by postoffice.sarnoff.com (Netscape Messaging Server 4.15) with ESMTP id GH5T1B00.PI2; Fri, 27 Jul 2001 21:19:59 -0400 
Received: from loki.ietf.org (loki.ietf.org [132.151.1.177]) by nova.sarnoff.com (8.9.2/8.9.2) with ESMTP id OAA22847; Tue, 24 Jul 2001 14:28:31 -0400 (EDT)
Received: (from adm@localhost) by loki.ietf.org (8.9.1b+Sun/8.9.1) id OAA20104 for [e-mail]; Tue, 24 Jul 2001 14:15:01 -0400 (EDT)
Received: from ietf.org (odin.ietf.org [10.27.2.28]) by loki.ietf.org (8.9.1b+Sun/8.9.1) with ESMTP id GAA12905 for <[e-mail]>; Tue, 24 Jul 2001 06:33:00 -0400 (EDT)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA06577; Tue, 24 Jul 2001 06:32:59 -0400 (EDT)
Message-Id: <[e-mail]>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: [e-mail]
From: [e-mail]
Reply-to: [e-mail]
Subject: I-D ACTION:draft-ietf-pkix-cmc-compl-00.txt
Date: Tue, 24 Jul 2001 06:32:59 -0400
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Public-Key Infrastructure (X.509) Working Group of the IETF.

	Title		: CMC Compliance Document
	Author(s)	: M. Myers et al.
	Filename	: draft-ietf-pkix-cmc-compl-00.txt
	Pages		: 
	Date		: 23-Jul-01
	
This document provides a set of compliance statements about the CMC
enrollment protocol.  The documents [CMC-STRUCT] and [CMC-TRANS]
provide the definitions of the structure and transport protocols
defined for CMC.  This document provides the information needed to
make a compliant version of CMC.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-pkix-cmc-compl-00.txt

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-pkix-cmc-compl-00.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[e-mail].
In the body type:
	"FILE /internet-drafts/draft-ietf-pkix-cmc-compl-00.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
		
		
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="[e-mail]"

Content-Type: text/plain
Content-ID:	<[e-mail]>

ENCODING mime
FILE /internet-drafts/draft-ietf-pkix-cmc-compl-00.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-pkix-cmc-compl-00.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<[e-mail]>

--OtherAccess--

--NextPart--




Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f732BFn04543 for ietf-pkix-bks; Thu, 2 Aug 2001 19:11:15 -0700 (PDT)
Received: from postoffice.sarnoff.com (postoffice.sarnoff.com [130.33.10.147]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f732BDs04536 for <[e-mail]>; Thu, 2 Aug 2001 19:11:13 -0700 (PDT)
Received: from postoffice.sarnoff.com ([127.0.0.1]) by postoffice.sarnoff.com (Netscape Messaging Server 4.15) with SMTP id GHGZ3S00.0DA for <[e-mail]>; Thu, 2 Aug 2001 22:04:40 -0400 
Received: from nova.sarnoff.com ([130.33.8.27]) by postoffice.sarnoff.com (Netscape Messaging Server 4.15) with ESMTP id GH5SZQ00.OGH; Fri, 27 Jul 2001 21:19:02 -0400 
Received: from loki.ietf.org (loki.ietf.org [132.151.1.177]) by nova.sarnoff.com (8.9.2/8.9.2) with ESMTP id OAA23552; Tue, 24 Jul 2001 14:47:45 -0400 (EDT)
Received: (from adm@localhost) by loki.ietf.org (8.9.1b+Sun/8.9.1) id OAA20451 for [e-mail]; Tue, 24 Jul 2001 14:35:01 -0400 (EDT)
Received: from ietf.org (odin.ietf.org [10.27.2.28]) by loki.ietf.org (8.9.1b+Sun/8.9.1) with ESMTP id GAA12919 for <[e-mail]>; Tue, 24 Jul 2001 06:33:05 -0400 (EDT)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA06589; Tue, 24 Jul 2001 06:33:04 -0400 (EDT)
Message-Id: <[e-mail]>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: [e-mail]
From: [e-mail]
Reply-to: [e-mail]
Subject: I-D ACTION:draft-ietf-pkix-cmc-archive-00.txt
Date: Tue, 24 Jul 2001 06:33:04 -0400
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Public-Key Infrastructure (X.509) Working Group of the IETF.

	Title		: CMC Extensions: Server Side Key Generation and Key 
                          Archival
	Author(s)	: J. Schaad
	Filename	: draft-ietf-pkix-cmc-archive-00.txt
	Pages		: 17
	Date		: 23-Jul-01
	
This document defines a set of extensions to [CMC] that address the
desire for having two additional services:  Server generation of
keys, and server-side archival and subsequent recovery of key
material by the server.  These services are provided by the
definition of additional control statements within the CMC
architecture.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-pkix-cmc-archive-00.txt

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-pkix-cmc-archive-00.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[e-mail].
In the body type:
	"FILE /internet-drafts/draft-ietf-pkix-cmc-archive-00.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
		
		
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="[e-mail]"

Content-Type: text/plain
Content-ID:	<[e-mail]>

ENCODING mime
FILE /internet-drafts/draft-ietf-pkix-cmc-archive-00.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-pkix-cmc-archive-00.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<[e-mail]>

--OtherAccess--

--NextPart--




Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f732BEX04537 for ietf-pkix-bks; Thu, 2 Aug 2001 19:11:14 -0700 (PDT)
Received: from postoffice.sarnoff.com (postoffice.sarnoff.com [130.33.10.147]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f732BCs04531 for <[e-mail]>; Thu, 2 Aug 2001 19:11:12 -0700 (PDT)
Received: from postoffice.sarnoff.com ([127.0.0.1]) by postoffice.sarnoff.com (Netscape Messaging Server 4.15) with SMTP id GHGZ3K00.GD4 for <[e-mail]>; Thu, 2 Aug 2001 22:04:32 -0400 
Received: from nova.sarnoff.com ([130.33.8.27]) by postoffice.sarnoff.com (Netscape Messaging Server 4.15) with ESMTP id GH5SW500.PHO; Fri, 27 Jul 2001 21:16:53 -0400 
Received: from loki.ietf.org (loki.ietf.org [132.151.1.177]) by nova.sarnoff.com (8.9.2/8.9.2) with ESMTP id PAA24409; Tue, 24 Jul 2001 15:10:56 -0400 (EDT)
Received: (from adm@localhost) by loki.ietf.org (8.9.1b+Sun/8.9.1) id OAA20781 for [e-mail]; Tue, 24 Jul 2001 14:55:01 -0400 (EDT)
Received: from ietf.org (odin.ietf.org [10.27.2.28]) by loki.ietf.org (8.9.1b+Sun/8.9.1) with ESMTP id GAA12934 for <[e-mail]>; Tue, 24 Jul 2001 06:33:16 -0400 (EDT)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA06614; Tue, 24 Jul 2001 06:33:16 -0400 (EDT)
Message-Id: <[e-mail]>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: [e-mail]
From: [e-mail]
Reply-to: [e-mail]
Subject: I-D ACTION:draft-ietf-pkix-ipki-new-rfc2527-00.txt
Date: Tue, 24 Jul 2001 06:33:15 -0400
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Public-Key Infrastructure (X.509) Working Group of the IETF.

	Title		: Internet X.509 Public Key Infrastructure Certificate 
                          Policy and Certification Practices Framework
	Author(s)	: S. Chokhani et al.
	Filename	: draft-ietf-pkix-ipki-new-rfc2527-00.txt
	Pages		: 54
	Date		: 23-Jul-01
	
This document presents a framework to assist the writers of 
certificate policies or certification practice statements for 
participants within public key infrastructures, such as 
certification authorities, policy authorities, and communities of 
interest that wish to rely on certificates.  In particular, the 
framework provides a comprehensive list of topics that potentially 
(at the writer's discretion) need to be covered in a certificate 
policy or a certification practice statement.  This document is 
being submitted to the RFC Editor with a request for publication as 
an Informational RFC.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-pkix-ipki-new-rfc2527-00.txt

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-pkix-ipki-new-rfc2527-00.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[e-mail].
In the body type:
	"FILE /internet-drafts/draft-ietf-pkix-ipki-new-rfc2527-00.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
		
		
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="[e-mail]"

Content-Type: text/plain
Content-ID:	<[e-mail]>

ENCODING mime
FILE /internet-drafts/draft-ietf-pkix-ipki-new-rfc2527-00.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-pkix-ipki-new-rfc2527-00.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<[e-mail]>

--OtherAccess--

--NextPart--




Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f732BDF04533 for ietf-pkix-bks; Thu, 2 Aug 2001 19:11:13 -0700 (PDT)
Received: from postoffice.sarnoff.com (postoffice.sarnoff.com [130.33.10.147]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f732BBs04525 for <[e-mail]>; Thu, 2 Aug 2001 19:11:12 -0700 (PDT)
Received: from postoffice.sarnoff.com ([127.0.0.1]) by postoffice.sarnoff.com (Netscape Messaging Server 4.15) with SMTP id GHGZ3H00.7CR for <[e-mail]>; Thu, 2 Aug 2001 22:04:29 -0400 
Received: from nova.sarnoff.com ([130.33.8.27]) by postoffice.sarnoff.com (Netscape Messaging Server 4.15) with ESMTP id GH5SW300.1H9; Fri, 27 Jul 2001 21:16:51 -0400 
Received: from loki.ietf.org (loki.ietf.org [132.151.1.177]) by nova.sarnoff.com (8.9.2/8.9.2) with ESMTP id OAA23921; Tue, 24 Jul 2001 14:56:45 -0400 (EDT)
Received: (from adm@localhost) by loki.ietf.org (8.9.1b+Sun/8.9.1) id OAA20606 for [e-mail]; Tue, 24 Jul 2001 14:45:01 -0400 (EDT)
Received: from ietf.org (odin.ietf.org [10.27.2.28]) by loki.ietf.org (8.9.1b+Sun/8.9.1) with ESMTP id GAA12927 for <[e-mail]>; Tue, 24 Jul 2001 06:33:11 -0400 (EDT)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA06602; Tue, 24 Jul 2001 06:33:11 -0400 (EDT)
Message-Id: <[e-mail]>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: [e-mail]
From: [e-mail]
Reply-to: [e-mail]
Subject: I-D ACTION:draft-ietf-pkix-cmc-trans-00.txt
Date: Tue, 24 Jul 2001 06:33:10 -0400
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Public-Key Infrastructure (X.509) Working Group of the IETF.

	Title		: CMC Transport
	Author(s)	: M. Myers et al.
	Filename	: draft-ietf-pkix-cmc-trans-00.txt
	Pages		: 
	Date		: 23-Jul-01
	
This document defines a number of transport mechanisms that are used
to move [CMC] messages.  The transport mechanisms described in this
document are: HTTP, file, mail and TCP.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-pkix-cmc-trans-00.txt

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-pkix-cmc-trans-00.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[e-mail].
In the body type:
	"FILE /internet-drafts/draft-ietf-pkix-cmc-trans-00.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
		
		
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="[e-mail]"

Content-Type: text/plain
Content-ID:	<[e-mail]>

ENCODING mime
FILE /internet-drafts/draft-ietf-pkix-cmc-trans-00.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-pkix-cmc-trans-00.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<[e-mail]>

--OtherAccess--

--NextPart--




Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f732B7s04505 for ietf-pkix-bks; Thu, 2 Aug 2001 19:11:07 -0700 (PDT)
Received: from postoffice.sarnoff.com (postoffice.sarnoff.com [130.33.10.147]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f732B5s04499 for <[e-mail]>; Thu, 2 Aug 2001 19:11:06 -0700 (PDT)
Received: from postoffice.sarnoff.com ([127.0.0.1]) by postoffice.sarnoff.com (Netscape Messaging Server 4.15) with SMTP id GHGYIQ00.OD0 for <[e-mail]>; Thu, 2 Aug 2001 21:52:02 -0400 
Received: from nova.sarnoff.com ([130.33.8.27]) by postoffice.sarnoff.com (Netscape Messaging Server 4.15) with ESMTP id GH5C7V00.T0A; Fri, 27 Jul 2001 15:16:43 -0400 
Received: from loki.ietf.org (loki.ietf.org [132.151.1.177]) by nova.sarnoff.com (8.9.2/8.9.2) with ESMTP id OAA10298; Fri, 27 Jul 2001 14:17:26 -0400 (EDT)
Received: (from adm@localhost) by loki.ietf.org (8.9.1b+Sun/8.9.1) id NAA19129 for [e-mail]; Fri, 27 Jul 2001 13:55:01 -0400 (EDT)
Received: from ietf.org (odin.ietf.org [10.27.2.28]) by loki.ietf.org (8.9.1b+Sun/8.9.1) with ESMTP id HAA13144 for <[e-mail]>; Fri, 27 Jul 2001 07:22:52 -0400 (EDT)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA07700; Fri, 27 Jul 2001 07:22:50 -0400 (EDT)
Message-Id: <[e-mail]>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: [e-mail]
From: [e-mail]
Reply-to: [e-mail]
Subject: I-D ACTION:draft-ietf-pkix-logotypes-00.txt
Date: Fri, 27 Jul 2001 07:22:49 -0400
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Public-Key Infrastructure (X.509) Working Group of the IETF.

	Title		: Internet X.509 Public Key Infrastructure Logotypes in 
                          X.509 certificates
	Author(s)	: S. Santesson
	Filename	: draft-ietf-pkix-logotypes-00.txt
	Pages		: 
	Date		: 26-Jul-01
	
This document contains an initial outline of a standard for inclusion
of logotypes in certificates. The draft includes background
discussions around different aspects of problems and solutions,
forming a starting point for the creation of a complete standard.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-pkix-logotypes-00.txt

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-pkix-logotypes-00.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[e-mail].
In the body type:
	"FILE /internet-drafts/draft-ietf-pkix-logotypes-00.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
		
		
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="[e-mail]"

Content-Type: text/plain
Content-ID:	<[e-mail]>

ENCODING mime
FILE /internet-drafts/draft-ietf-pkix-logotypes-00.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-pkix-logotypes-00.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<[e-mail]>

--OtherAccess--

--NextPart--




Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f72Btib07116 for ietf-pkix-bks; Thu, 2 Aug 2001 04:55:44 -0700 (PDT)
Received: from e1.ny.us.ibm.com (e1.ny.us.ibm.com [32.97.182.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f72Btgs07110 for <[e-mail]>; Thu, 2 Aug 2001 04:55:42 -0700 (PDT)
Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.117.200.22]) by e1.ny.us.ibm.com (8.9.3/8.9.3) with ESMTP id HAA417208; Thu, 2 Aug 2001 07:53:15 -0400
Received: from d01ml062.pok.ibm.com (d01ml062.pok.ibm.com [9.117.250.163]) by northrelay02.pok.ibm.com (8.11.1m3/NCO v4.97) with ESMTP id f72BlV609554; Thu, 2 Aug 2001 07:47:32 -0400
Importance: Normal
Subject: Re: Verifying Certificates when CA key update
To: li yunfeng <[e-mail]>
Cc: [e-mail]
X-Mailer: Lotus Notes Release 5.0.3 (Intl) 21 March 2000
Message-ID: <[e-mail]>
From: "Tom Gindin" <[e-mail]>
Date: Thu, 2 Aug 2001 07:54:39 -0400
X-MIMETrack: Serialize by Router on D01ML062/01/M/IBM(Release 5.0.8 SPR #MIAS4UTJ8H |June 21, 2001) at 08/02/2001 07:55:16 AM
MIME-Version: 1.0
Content-type: text/plain; charset=gb2312
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from base64 to 8bit by above.proper.com id f72Bths07111
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>

     While I'm not sure what you mean by "chived" here (perhaps
"spoofed"?), an OldWithNew certificate should be distinguishable from
end-user certificates by several means.  First, the subject name and the
issuer name should match each other.  Second, it should IMO be either a v1
certificate or contain a CA flag in a basic constraints extension - I would
prefer the latter but it would be wise to find out from the actual
implementors which they're using.  The second check does not protect
against an attack by the subject of a cross certificate, but the first
does.
     Do we need to add to point 1 of 2.4.2.2 (of rfc2510bis-04) at least
the first of these checks?  If so, do we need to make the same change in
2.4.2.3?  I would think that we do, so thank you for bringing this up.

          Tom Gindin


li yunfeng <[e-mail]>@mail.imc.org on 08/02/2001 12:05:15 AM

Sent by:  [e-mail]


To:   [e-mail]
cc:
Subject:  Verifying Certificates when CA key update



In the document "Inernet X.509 Public Key
Infrastructure Certificate Management Protocols
<draft-ietf-pkix-rfc2510bits-03.txt>" 2.4.2segment
says that when CA key update the verifier can verify
other person's certificate using OLDwhithNEW
certificate.
If we use this methord , we will be chived by other
who get a certificate from CA and say this is old with
new certificate.

_________________________________________________________
Do You Yahoo!? µÇ¼Ãâ·ÑÑÅ»¢µçÓÊ! http://mail.yahoo.com.cn

<font color=#6666FF>ÎÞÁÄ£¿ÓôÃÆ£¿¸ßÐË£¿Ã»ÀíÓÉ£¿¶¼À´ÁÄÌì°É£¡</font>¡ª¡ª
ÑÅ»¢È«ÐÂÁÄÌìÊÒ! http://cn.chat.yahoo.com/c/roomlist.html




Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f7245C927602 for ietf-pkix-bks; Wed, 1 Aug 2001 21:05:12 -0700 (PDT)
Received: from web13707.mail.yahoo.com (web13707.mail.yahoo.com [216.136.175.140]) by above.proper.com (8.11.3/8.11.3) with SMTP id f7245Bs27597 for <[e-mail]>; Wed, 1 Aug 2001 21:05:11 -0700 (PDT)
Message-ID: <[e-mail]>
Received: from [61.139.85.150] by web13707.mail.yahoo.com; Thu, 02 Aug 2001 12:05:15 CST
Date: Thu, 2 Aug 2001 12:05:15 +0800 (CST)
From: =?gb2312?q?li=20yunfeng?= <[e-mail]>
Subject: Verifying Certificates when CA key update
To: [e-mail]
MIME-Version: 1.0
Content-Type: text/plain; charset=gb2312
Content-Transfer-Encoding: 8bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>

In the document "Inernet X.509 Public Key
Infrastructure Certificate Management Protocols
<draft-ietf-pkix-rfc2510bits-03.txt>" 2.4.2segment
says that when CA key update the verifier can verify
other person's certificate using OLDwhithNEW
certificate.
If we use this methord , we will be chived by other
who get a certificate from CA and say this is old with
new certificate.

_________________________________________________________
Do You Yahoo!? µÇ¼Ãâ·ÑÑÅ»¢µçÓÊ! http://mail.yahoo.com.cn

<font color=#6666FF>ÎÞÁÄ£¿ÓôÃÆ£¿¸ßÐË£¿Ã»ÀíÓÉ£¿¶¼À´ÁÄÌì°É£¡</font>¡ª¡ª 
ÑÅ»¢È«ÐÂÁÄÌìÊÒ! http://cn.chat.yahoo.com/c/roomlist.html