Changing the IETF (was Re: Validation policy in DPV/DPD rqmts)

[Paul Hoffman / IMC <[e-mail]>]

At 2:56 PM -0800 2/28/02, todd glassey wrote:
>I have done exactly that - but POISED has been shut down so I have no choice
>but to bring my petitions for reform of the IETF (and thus this WG) back
>inside this WG...

Wrong. The poised mailing list is still up and happening and the 
proper place to bring IETF procedural discussions. The list is at 
[e-mail], subscribe at 
[e-mail].

Todd, I'll join the chorus of people asking you to stop this thread 
on this mailing list. So far, no one has agreed with you, which 
should give you some indication of the low usefulness of your 
messages.

--Paul Hoffman, Director
--Internet Mail Consortium



Received: by above.proper.com (8.11.6/8.11.3) id g1SNcHS21006 for ietf-pkix-bks; Thu, 28 Feb 2002 15:38:17 -0800 (PST)
Received: from [165.227.249.20] (165-227-249-20.client.dsl.net [165.227.249.20]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1SNcCi21001; Thu, 28 Feb 2002 15:38:12 -0800 (PST)
Mime-Version: 1.0
X-Sender: [e-mail]
Message-Id: <p05101402b8a46e1e33fc@[165.227.249.20]>
In-Reply-To: <058c01c1c0ab$2c86d8e0$020aff0c@tsg1>
References: <20020228012927.CFKS2951.rwcrmhc53.attbi.com@rwcrwbc57> <04ae01c1c061$5f401340$020aff0c@tsg1> <p05100301b8a3f455959c@[128.89.88.34]> <050101c1c074$e8b722e0$020aff0c@tsg1> <p05100305b8a4171bc0f9@[128.89.88.34]> <054b01c1c09e$646263e0$020aff0c@tsg1> <p05100315b8a4527cb463@[128.89.88.34]> <058c01c1c0ab$2c86d8e0$020aff0c@tsg1>
Date: Thu, 28 Feb 2002 15:38:02 -0800
To: "todd glassey" <[e-mail]>, [e-mail]
From: Paul Hoffman / IMC <[e-mail]>
Subject: Changing the IETF (was Re: Validation policy in DPV/DPD rqmts)
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>

At 2:56 PM -0800 2/28/02, todd glassey wrote:
>I have done exactly that - but POISED has been shut down so I have no choice
>but to bring my petitions for reform of the IETF (and thus this WG) back
>inside this WG...

Wrong. The poised mailing list is still up and happening and the 
proper place to bring IETF procedural discussions. The list is at 
[e-mail], subscribe at 
[e-mail].

Todd, I'll join the chorus of people asking you to stop this thread 
on this mailing list. So far, no one has agreed with you, which 
should give you some indication of the low usefulness of your 
messages.

--Paul Hoffman, Director
--Internet Mail Consortium


Received: by above.proper.com (8.11.6/8.11.3) id g1SMvHG20196 for ietf-pkix-bks; Thu, 28 Feb 2002 14:57:17 -0800 (PST)
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 g1SMvFi20191 for <[e-mail]>; Thu, 28 Feb 2002 14:57:15 -0800 (PST)
Received: from tsg1 ([12.81.71.216]) by mtiwmhc23.worldnet.att.net (InterMail vM.4.01.03.27 201-229-121-127-20010626) with SMTP id <20020228225702.OIMN11747.mtiwmhc23.worldnet.att.net@tsg1>; Thu, 28 Feb 2002 22:57:02 +0000
Message-ID: <058c01c1c0ab$2c86d8e0$020aff0c@tsg1>
From: "todd glassey" <[e-mail]>
To: "Stephen Kent" <[e-mail]>, "LISTS - IETF-PKIX" <[e-mail]>
Cc: "Al Arsenault" <[e-mail]>
References: <20020228012927.CFKS2951.rwcrmhc53.attbi.com@rwcrwbc57> <04ae01c1c061$5f401340$020aff0c@tsg1> <p05100301b8a3f455959c@[128.89.88.34]> <050101c1c074$e8b722e0$020aff0c@tsg1> <p05100305b8a4171bc0f9@[128.89.88.34]> <054b01c1c09e$646263e0$020aff0c@tsg1> <p05100315b8a4527cb463@[128.89.88.34]>
Subject: Re: Validation policy in DPV/DPD rqmts
Date: Thu, 28 Feb 2002 14:56:34 -0800
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 6.00.2600.0000
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
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>

Steve

----- Original Message -----
From: "Stephen Kent" <[e-mail]>
To: "todd glassey" <[e-mail]>
Cc: <[e-mail]>
Sent: Thursday, February 28, 2002 1:37 PM
Subject: Re: Validation policy in DPV/DPD rqmts


> At 1:24 PM -0800 2/28/02, todd glassey wrote:
> >And Steve how many years have you been the WG Chair of this WG?
> >
> >Todd
> >
>
> I've chaired PKIX since it's inception.

My point exactly

> For comparison, the duration
> of my role as chair is less than the amount of time that John Linn
> has chaired CAT.

Not a good comparison - CAT is not building technologies to be used in
commercial transaction standards and you and your WG are, so the work PKIX
is doing has more than just communications value, it has intrinsic value as
part of the transaction infrastructrue itself and that is why PKIX is
different than the other WG's.

>  also chaired the PEM WG prior to PKIX, chaired
> the PSRG in the IRTF for about 10 years, and served on the IAB for
> about 10 years.

with the amount of time that you have spent already in this, I have to ask -
is this is a career for you?

>
> There are no term limits for WG chairs.

WG Chairs are also not voted positions which is equally disturbing and why
is that do you think? They are in virtually every other formal standards org
on the planet. So I have to ask - Why not the IETF? is it beyond
accountability here.

> If you want to suggest term
> limits, bring the topic up on POISED, where the topic is within scope.
>

I have done exactly that - but POISED has been shut down so I have no choice
but to bring my petitions for reform of the IETF (and thus this WG) back
inside this WG...  see the http://www.ietf.org/html.charters/OLD/index.html
link for evidence of this.

> Steve
>



Received: by above.proper.com (8.11.6/8.11.3) id g1SMKbD19514 for ietf-pkix-bks; Thu, 28 Feb 2002 14:20:37 -0800 (PST)
Received: from geos.coastside.net (mail.coastside.net [207.213.212.6]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1SMKZi19510 for <[e-mail]>; Thu, 28 Feb 2002 14:20:35 -0800 (PST)
Received: from laptop (dsl-63-194-153-52.coastside.net [63.194.153.52]) by geos.coastside.net (8.11.0/8.11.3) with SMTP id g1SMGii14181; Thu, 28 Feb 2002 14:16:47 -0800 (PST)
From: "Michael Myers" <[e-mail]>
To: "Housley, Russ" <[e-mail]>
Cc: <[e-mail]>
Subject: RE: Validation policy in DPV/DPD rqmts
Date: Thu, 28 Feb 2002 14:14:17 -0800
Message-ID: <[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 IMO, Build 9.0.2416 (9.0.2911.0)
In-Reply-To: <[e-mail]>
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
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>

Russ,

Section 7.1 addresses the issues but not in my opinion to useful
degree of clarity.  Additional work in this area might improve
the document.

Mike



Michael Myers
t: +415.819.1362
e: mailto:[e-mail]
w: http://www.traceroutesecurity.com

> -----Original Message-----
> From: Housley, Russ [mailto:[e-mail]]
> Sent: Thursday, February 28, 2002 12:39 PM
> To: Michael Myers
> Cc: [e-mail]
> Subject: RE: Validation policy in DPV/DPD rqmts
>
>
> Mike:
>
> >OK, I get it now.  It's basically a roots issue.
> >
> >Then perhaps the I-D could include some informative text that
> >expands on what a rational validation policy might likely
> >address.
>
> Is this really something that needs to be in the
> requirements document?
>
> Russ
>



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g1SLvdA18832 for ietf-pkix-bks; Thu, 28 Feb 2002 13:57:39 -0800 (PST)
Received: from vulcan.rsasecurity.com (vulcan.rsasecurity.com [204.167.114.130] (may be forged)) by above.proper.com (8.11.6/8.11.3) with SMTP id g1SLvci18828 for <[e-mail]>; Thu, 28 Feb 2002 13:57:38 -0800 (PST)
Received: from no.name.available by vulcan.rsasecurity.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 28 Feb 2002 21:57:22 UT
Received: from ebola.securitydynamics.com (ebola.securid.com [192.80.211.4]) by sdtihq24.securid.com (Pro-8.9.3/Pro-8.9.3) with ESMTP id QAA17516 for <[e-mail]>; Thu, 28 Feb 2002 16:57:29 -0500 (EST)
Received: from exna00.securitydynamics.com (localhost [127.0.0.1]) by ebola.securitydynamics.com (8.10.2+Sun/8.9.1) with ESMTP id g1SLvdV15988 for <[e-mail]>; Thu, 28 Feb 2002 16:57:39 -0500 (EST)
Received: by exna00.securitydynamics.com with Internet Mail Service (5.5.2653.19) id <F4N5NVVD>; Thu, 28 Feb 2002 16:55:29 -0500
Received: from HOUSLEY-LAP.rsasecurity.com (HOUSLEY-LAP [10.3.1.99]) by exna00.securitydynamics.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id F4N5NV46; Thu, 28 Feb 2002 16:55:20 -0500
From: "Housley, Russ" <[e-mail]>
To: Michael Myers <[e-mail]>
Cc: [e-mail]
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Thu, 28 Feb 2002 15:38:59 -0500
Subject: RE: Validation policy in DPV/DPD rqmts
In-Reply-To: <[e-mail]>
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>

Mike:

>OK, I get it now.  It's basically a roots issue.
>
>Then perhaps the I-D could include some informative text that
>expands on what a rational validation policy might likely
>address.

Is this really something that needs to be in the requirements document?

Russ


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g1SLd9s18435 for ietf-pkix-bks; Thu, 28 Feb 2002 13:39:09 -0800 (PST)
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 g1SLd7i18431 for <[e-mail]>; Thu, 28 Feb 2002 13:39:07 -0800 (PST)
Received: from [128.89.88.34] (comsec.bbn.com [128.89.88.34]) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id QAA12944; Thu, 28 Feb 2002 16:39:03 -0500 (EST)
Mime-Version: 1.0
X-Sender: [e-mail]
Message-Id: <p05100315b8a4527cb463@[128.89.88.34]>
In-Reply-To: <054b01c1c09e$646263e0$020aff0c@tsg1>
References: <20020228012927.CFKS2951.rwcrmhc53.attbi.com@rwcrwbc57> <04ae01c1c061$5f401340$020aff0c@tsg1> <p05100301b8a3f455959c@[128.89.88.34]> <050101c1c074$e8b722e0$020aff0c@tsg1> <p05100305b8a4171bc0f9@[128.89.88.34]> <054b01c1c09e$646263e0$020aff0c@tsg1>
Date: Thu, 28 Feb 2002 16:37:07 -0500
To: "todd glassey" <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: Re: Validation policy in DPV/DPD rqmts
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>

At 1:24 PM -0800 2/28/02, todd glassey wrote:
>And Steve how many years have you been the WG Chair of this WG?
>
>Todd
>

I've chaired PKIX since it's inception. For comparison, the duration 
of my role as chair is less than the amount of time that John Linn 
has chaired CAT.  I also chaired the PEM WG prior to PKIX, chaired 
the PSRG in the IRTF for about 10 years, and served on the IAB for 
about 10 years.

There are no term limits for WG chairs. If you want to suggest term 
limits, bring the topic up on POISED, where the topic is within scope.

Steve


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g1SLPi618128 for ietf-pkix-bks; Thu, 28 Feb 2002 13:25:44 -0800 (PST)
Received: from mtiwmhc22.worldnet.att.net (mtiwmhc22.worldnet.att.net [204.127.131.47]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1SLPhi18121 for <[e-mail]>; Thu, 28 Feb 2002 13:25:43 -0800 (PST)
Received: from tsg1 ([12.81.71.216]) by mtiwmhc22.worldnet.att.net (InterMail vM.4.01.03.27 201-229-121-127-20010626) with SMTP id <20020228212531.NPJE13933.mtiwmhc22.worldnet.att.net@tsg1>; Thu, 28 Feb 2002 21:25:31 +0000
Message-ID: <054b01c1c09e$646263e0$020aff0c@tsg1>
From: "todd glassey" <[e-mail]>
To: "Stephen Kent" <[e-mail]>
Cc: <[e-mail]>
References: <20020228012927.CFKS2951.rwcrmhc53.attbi.com@rwcrwbc57> <04ae01c1c061$5f401340$020aff0c@tsg1> <p05100301b8a3f455959c@[128.89.88.34]> <050101c1c074$e8b722e0$020aff0c@tsg1> <p05100305b8a4171bc0f9@[128.89.88.34]>
Subject: Re: Validation policy in DPV/DPD rqmts
Date: Thu, 28 Feb 2002 13:24:06 -0800
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 6.00.2600.0000
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
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>

And Steve how many years have you been the WG Chair of this WG?


Todd

----- Original Message -----
From: "Stephen Kent" <[e-mail]>
To: "todd glassey" <[e-mail]>
Cc: <[e-mail]>
Sent: Thursday, February 28, 2002 12:00 PM
Subject: Re: Validation policy in DPV/DPD rqmts


> At 8:28 AM -0800 2/28/02, todd glassey wrote:
> >----- Original Message -----
> >From: "Stephen Kent" <[e-mail]>
> >To: "todd glassey" <[e-mail]>
> >Cc: <[e-mail]>
> >Sent: Thursday, February 28, 2002 7:20 AM
> >Subject: Re: Validation policy in DPV/DPD rqmts
> >
> >
> >>  >hey all -
> >>  >This is yet another example with the problems of this WG - The fact
that
> >a
> >>  >bunch of technologists have gotten together to create solutions for
> >problems
> >>  >that don't exist and that may never.
> >>  >
> >>  >If you want the Business World to accept PKI then you have to address
> >their
> >>  >problems and they are relatively simple. Much simpler than 99% of
what's
> >>  >going on in  what this PKIX represents.
> >>  >
> >>  >The real issue is that commerce needs some reliable method(s) of
> >>  >
> >>  >     1)    making decisions regarding identity and rights of the
> >participants
> >>  >
> >>  >     2)    making decisions on the integrity of the systems that are
> >>  >processing the transactions
> >>  >
> >>  >     3)    proving that all was done as it was professed. i.e
evidentiary
> >>  >services.
> >>  >
> >>  >With that said - how many ways do you need to verify the same F$#^*NG
> >>  >signature in an X509 cert?
> >>  >
> >>  >This is the issue. PKI is so complex and there is so little thread
> >running
> >>  >between the components that they are essentially impossible or very
> >>  >expensive to use. This says it all since no one outside of the PKI
> >companies
> >>  >seem be working in this PKI realm. And what that means is that this
> >business
> >>  >is about selling components of this HUGE infrastructure to other
> >component
> >>  >level manufacturers.
> >>  >
> >>  >What PKIX needs to do is stop making the problem worse and force a
> >>  >convergence in the processes such that they are readily adoptable by
> >>  >Industry and its Auditors. That means that they all follow similar or
the
> >>  >same operations models, and that BCP's are available for their use in
> >>  >commercial processes.
> >>  >
> >>  >Otherwise this WG is producing a lot OS hand waving and very little
> >usable
> >>  >substance.
> >>  >
> >>  >Tim and Steve any retort since you are responsible for what this
group
> >does?
> >>  >
> >>  >
> >>  >Todd Glassey
> >>
> >>  Todd,
> >>
> >>  Because PKIX creates standards that provide a foundation for a wide
> >>  range of PKI users, it's usually not possible to focus only on the
> >>  needs of a specific set of potential users when creating these
> >>  standards. This is in contrast to groups like the ANSI X9 committee,
> >>  for example, that explicitly focuses on the financial community.
> >>  Certs are used today in a variety of applications, some of which
> >>  support non-repudiation, and others do not. The cert status checking
> >>  requirements of these different applications vary, accordingly, and
> >>  thus a single standard that encompasses a broad set of apps will, of
> >>  necessity, be more complex than a more narrowly focused set of
> >>  standards, each of which addresses a more narrow set of requirements.
> >>  Historically, the IETF has pursued standards that try to support a
> >>  wide range of applications (which often makes the standards more
> >>  complex); the approach we are pursuing in PKIX is consistent with
> >>  that philosophy.
> >
> >Then Steve you run the risk of producing garbage. Wares that actually
make
> >the problems more difficult to address. So much of PKIX's arrogance about
> >what it is going to provide to the world is just that, PKIX's arrogance.
> >
> >PKI is a set of cruptographic tools and what Commercial Business needs
(you
> >know them, the people that pay your salary) is something more than just
your
> >basic pipe and plumbing assembly.  Otherwise there is no reason for PKIX
to
> >exist as this all should be being done by Applications Developers.
> >
> >This basic disagreement in the philosophy is why I have asked you to step
> >down.
> >
> Todd,
>
> The philosophy I articulated is consistent with the general approach
> adopted in the IETF.  I've had the privilege of working on a variety
> of Internet protocol standards for over 20 years, since before there
> was an IETF.  I'm generally pleased with the results of the work I
> and others have conducted in this area, although I admit that not all
> of our outputs are uniformly successful. (You can blame me and others
> for 32 bit IP addresses, for example.)
>
> In contrast, you have harassed and threatened folks with litigation
> when your proposals have been rejected, but its hard to identify what
> substantive contributions you have made in the IETF.  Tim and I serve
> as WG chairs at the discretion of the Security Area Directors and the
> IESG. If they decide that we are not doing a good job, we will step
> down. Absent that, we will continue to do out best, despite your
> comments.
>
> Steve
>



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g1SK9Nu16132 for ietf-pkix-bks; Thu, 28 Feb 2002 12:09:23 -0800 (PST)
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 g1SK9Mi16123 for <[e-mail]>; Thu, 28 Feb 2002 12:09:22 -0800 (PST)
Received: from [128.89.88.34] (comsec.bbn.com [128.89.88.34]) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id PAA29145; Thu, 28 Feb 2002 15:09:16 -0500 (EST)
Mime-Version: 1.0
X-Sender: [e-mail]
Message-Id: <p05100305b8a4171bc0f9@[128.89.88.34]>
In-Reply-To: <050101c1c074$e8b722e0$020aff0c@tsg1>
References: <20020228012927.CFKS2951.rwcrmhc53.attbi.com@rwcrwbc57> <04ae01c1c061$5f401340$020aff0c@tsg1> <p05100301b8a3f455959c@[128.89.88.34]> <050101c1c074$e8b722e0$020aff0c@tsg1>
Date: Thu, 28 Feb 2002 15:00:26 -0500
To: "todd glassey" <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: Re: Validation policy in DPV/DPD rqmts
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>

At 8:28 AM -0800 2/28/02, todd glassey wrote:
>----- Original Message -----
>From: "Stephen Kent" <[e-mail]>
>To: "todd glassey" <[e-mail]>
>Cc: <[e-mail]>
>Sent: Thursday, February 28, 2002 7:20 AM
>Subject: Re: Validation policy in DPV/DPD rqmts
>
>
>>  >hey all -
>>  >This is yet another example with the problems of this WG - The fact that
>a
>>  >bunch of technologists have gotten together to create solutions for
>problems
>>  >that don't exist and that may never.
>>  >
>>  >If you want the Business World to accept PKI then you have to address
>their
>>  >problems and they are relatively simple. Much simpler than 99% of what's
>>  >going on in  what this PKIX represents.
>>  >
>>  >The real issue is that commerce needs some reliable method(s) of
>>  >
>>  >     1)    making decisions regarding identity and rights of the
>participants
>>  >
>>  >     2)    making decisions on the integrity of the systems that are
>>  >processing the transactions
>>  >
>>  >     3)    proving that all was done as it was professed. i.e evidentiary
>>  >services.
>>  >
>>  >With that said - how many ways do you need to verify the same F$#^*NG
>>  >signature in an X509 cert?
>>  >
>>  >This is the issue. PKI is so complex and there is so little thread
>running
>>  >between the components that they are essentially impossible or very
>>  >expensive to use. This says it all since no one outside of the PKI
>companies
>>  >seem be working in this PKI realm. And what that means is that this
>business
>>  >is about selling components of this HUGE infrastructure to other
>component
>>  >level manufacturers.
>>  >
>>  >What PKIX needs to do is stop making the problem worse and force a
>>  >convergence in the processes such that they are readily adoptable by
>>  >Industry and its Auditors. That means that they all follow similar or the
>>  >same operations models, and that BCP's are available for their use in
>>  >commercial processes.
>>  >
>>  >Otherwise this WG is producing a lot OS hand waving and very little
>usable
>>  >substance.
>>  >
>>  >Tim and Steve any retort since you are responsible for what this group
>does?
>>  >
>>  >
>>  >Todd Glassey
>>
>>  Todd,
>>
>>  Because PKIX creates standards that provide a foundation for a wide
>>  range of PKI users, it's usually not possible to focus only on the
>>  needs of a specific set of potential users when creating these
>>  standards. This is in contrast to groups like the ANSI X9 committee,
>>  for example, that explicitly focuses on the financial community.
>>  Certs are used today in a variety of applications, some of which
>>  support non-repudiation, and others do not. The cert status checking
>>  requirements of these different applications vary, accordingly, and
>>  thus a single standard that encompasses a broad set of apps will, of
>>  necessity, be more complex than a more narrowly focused set of
>>  standards, each of which addresses a more narrow set of requirements.
>>  Historically, the IETF has pursued standards that try to support a
>>  wide range of applications (which often makes the standards more
>>  complex); the approach we are pursuing in PKIX is consistent with
>>  that philosophy.
>
>Then Steve you run the risk of producing garbage. Wares that actually make
>the problems more difficult to address. So much of PKIX's arrogance about
>what it is going to provide to the world is just that, PKIX's arrogance.
>
>PKI is a set of cruptographic tools and what Commercial Business needs (you
>know them, the people that pay your salary) is something more than just your
>basic pipe and plumbing assembly.  Otherwise there is no reason for PKIX to
>exist as this all should be being done by Applications Developers.
>
>This basic disagreement in the philosophy is why I have asked you to step
>down.
>
Todd,

The philosophy I articulated is consistent with the general approach 
adopted in the IETF.  I've had the privilege of working on a variety 
of Internet protocol standards for over 20 years, since before there 
was an IETF.  I'm generally pleased with the results of the work I 
and others have conducted in this area, although I admit that not all 
of our outputs are uniformly successful. (You can blame me and others 
for 32 bit IP addresses, for example.)

In contrast, you have harassed and threatened folks with litigation 
when your proposals have been rejected, but its hard to identify what 
substantive contributions you have made in the IETF.  Tim and I serve 
as WG chairs at the discretion of the Security Area Directors and the 
IESG. If they decide that we are not doing a good job, we will step 
down. Absent that, we will continue to do out best, despite your 
comments.

Steve


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g1SJDJA14888 for ietf-pkix-bks; Thu, 28 Feb 2002 11:13:19 -0800 (PST)
Received: from geos.coastside.net (mail.coastside.net [207.213.212.6]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1SJDHi14884 for <[e-mail]>; Thu, 28 Feb 2002 11:13:17 -0800 (PST)
Received: from laptop (dsl-63-194-153-52.coastside.net [63.194.153.52]) by geos.coastside.net (8.11.0/8.11.3) with SMTP id g1SJCdi23476; Thu, 28 Feb 2002 11:12:39 -0800 (PST)
From: "Michael Myers" <[e-mail]>
To: "Denis Pinkas" <[e-mail]>
Cc: <[e-mail]>
Subject: RE: Validation policy in DPV/DPD rqmts
Date: Thu, 28 Feb 2002 11:10:10 -0800
Message-ID: <[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 IMO, Build 9.0.2416 (9.0.2911.0)
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
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>

> -----Original Message-----
> From: Denis Pinkas [mailto:[e-mail]]
>
> Take a look at section 7.1. Validation Policy

Denis,

I read that part.  I'm not arguing with anything said there.
But the text of that section is so full of MAYs and
tutorial-like advice that it's unclear what this document is
actually establishing with respect to the constituent elements
of a validation policy other than the MUST with respect to a
root.

I had expected something with a bit more or structural bite to
it, roughly in line with RFC 2527 as that document guides the
production of CPs and CPSs, although considerably reduced.
Something along the lines of "A validation policy SHOULD at a
minimum assert: <element 1>, <element 2>, <element 3>" and so
on.  Maybe even elevate that to a SHALL.

That's why I was digging into the DEFAULT policy issue, in order
to bring to the surface our collective thinking on that meta
structure.  I think we all know more or less what it is.  I
think we should write that down in a more structured fashion
than currently expressed by Section 7.1.

Is that possible?

Mike





Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g1SJ7Kn14697 for ietf-pkix-bks; Thu, 28 Feb 2002 11:07:20 -0800 (PST)
Received: from geos.coastside.net (mail.coastside.net [207.213.212.6]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1SJ7Ii14693 for <[e-mail]>; Thu, 28 Feb 2002 11:07:18 -0800 (PST)
Received: from laptop (dsl-63-194-153-52.coastside.net [63.194.153.52]) by geos.coastside.net (8.11.0/8.11.3) with SMTP id g1SJ7Ai22875; Thu, 28 Feb 2002 11:07:11 -0800 (PST)
From: "Michael Myers" <[e-mail]>
To: "todd glassey" <[e-mail]>, "Stephen Kent" <[e-mail]>
Cc: <[e-mail]>
Subject: RE: Validation policy in DPV/DPD rqmts
Date: Thu, 28 Feb 2002 11:04:42 -0800
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.50.4133.2400
Importance: Normal
In-Reply-To: <050101c1c074$e8b722e0$020aff0c@tsg1>
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>

Todd,

As a member of this WG I for one am getting a bit tired of this.
Please constrain yourself to contributions that add value or at
least bear a vague resemblance of an attempt to do so.

Mike



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g1SISMx13868 for ietf-pkix-bks; Thu, 28 Feb 2002 10:28:22 -0800 (PST)
Received: from geos.coastside.net (mail.coastside.net [207.213.212.6]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1SISJi13864 for <[e-mail]>; Thu, 28 Feb 2002 10:28:20 -0800 (PST)
Received: from laptop (dsl-63-194-153-52.coastside.net [63.194.153.52]) by geos.coastside.net (8.11.0/8.11.3) with SMTP id g1SIOWi18028; Thu, 28 Feb 2002 10:24:33 -0800 (PST)
From: "Michael Myers" <[e-mail]>
To: "Housley, Russ" <[e-mail]>
Cc: <[e-mail]>
Subject: RE: Validation policy in DPV/DPD rqmts
Date: Thu, 28 Feb 2002 10:22:04 -0800
Message-ID: <[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 IMO, Build 9.0.2416 (9.0.2911.0)
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
In-Reply-To: <[e-mail]>
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>

Russ, Denis:

After further thought, I see that what I was actually hunting
for was that set of requirements leading to, among other things,
assurance of the existence of path validation logic conformant
to RFC 2459 among *any* technical specification claiming
conformance to this requirements specification.

I would count among those, for example, an XML-based approach
towards satisfying these requirements.  While that technology
platform is at present out of PKIX' scope, the existence of this
document enables such claims from a PICS-like perspective.

But if "valid" means whatever the policy OID says it means, we
could see NULL policies, or something along the lines of "that
individual is no longer in our customer directory, thus the
certificate is invalid" without any path checking
whatsoever--basically treating a certificate hash as nothing
more than a database index. Or scenarios where a certificate may
have a NULL subject DN, a non-conformant practice according to
RFC 2459, but is nonetheless "valid".

I don't think we want that, but I see no requirements that
prohibit such practices.  I you'd like, I can draft up some
text.

Mike



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g1SH9WH10079 for ietf-pkix-bks; Thu, 28 Feb 2002 09:09:32 -0800 (PST)
Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1SH9Ui10075 for <[e-mail]>; Thu, 28 Feb 2002 09:09:30 -0800 (PST)
Received: from lvn-m002.frlv.bull.fr (lvn-m002.frlv.bull.fr [129.184.62.72]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id SAA19586; Thu, 28 Feb 2002 18:10:07 +0100
Received: from bull.net ([129.184.37.97]) by lvn-m002.frlv.bull.fr (Lotus Domino Release 5.0.8) with ESMTP id 2002022818074249:104 ; Thu, 28 Feb 2002 18:07:42 +0100 
Message-ID: <[e-mail]>
Date: Thu, 28 Feb 2002 18:07:41 +0100
From: Denis Pinkas <[e-mail]>
Organization: Integris. A Bull Company
X-Mailer: Mozilla 4.7 [fr] (Win98; I)
X-Accept-Language: fr
MIME-Version: 1.0
To: Ambarish Malpani <[e-mail]>
CC: "'[e-mail]'" <[e-mail]>
Subject: Re: Comments on the DPV-DPD req doc
References: <[e-mail]>
X-MIMETrack: Itemize by SMTP Server on LVN-M002/FR/BULL(Release 5.0.8 |June 18, 2001) at 28/02/2002 18:07:42, Serialize by Router on LVN-M002/FR/BULL(Release 5.0.8 |June 18, 2001) at 28/02/2002 18:08:14, Serialize complete at 28/02/2002 18:08:14
Content-Transfer-Encoding: 7bit
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>

Ambarish,

Just before leaving on holidays for 10 days, my last response for the day.

> Hi Denis, Russ,

> Here are a set of comments on the DPV-DPD requirements doc.
> Denis, some of these are repeats of comments I had sent you
> earlier (off the list):


[COMMENT 10]

1. Section 4 2nd paragraph

If a client is asking a server to validate a certificate at
a particular time, that means "was the certificate valid at that
time" (based on information available at that time or information
obtained later). I don't think we should allow it to mean multiple
things.

[Answer 10]

The question is what means the sentence: "Is the certificate valid 
at a time T ? ".  Does it mean:

1) valid when compared to the revocation status information that is
   available at that time T (which may not be up to date) ? , or

2) valid for the time T, where the key was used ? 

These two times are not always identical and thus the response is 
dependant upon the meaning of that time which is left to the policy. 


[COMMENT 11]

2. Section 4 3rd paragraph

The requirements document should not forbid specification
of the policy with a request. If the protocol writers find that
specifying the policy (or a subset of the policy) with the
request is too burdensome, let them make that decision. Allowing
a client to specify a frequently changing part of the policy
with every request wouldn't be a bad decision

[Answer 11]

Validation policies are usually not defined by end-users but by
administrators. So why a separate protocol should be used, the policy is not
locally defined. Clients should not define policies. As we know, policy
parameters are quite complex.

[COMMENT 12]

3. Section 4 6th paragraph

You say that if the client doesn't provide the full certificate,
the server MUST use the unambiguous reference provided by the client
to get that certificate.

Again, this is not a requirement. If the server could devine
that certificate by sticking its thumb in the air, that should be
fine - as long as the server verifies that it is the certificate
the client specified

[Answer 12]

No. "The text says" that if the client doesn't provide the full certificate,
the server MUST use the unambiguous reference provided by the client
to get that certificate.

Since "MUST" is used, this is indeed a requirement.

In order for a server to verify that it is the certificate the client
specified, the reference which is provided must be ambiguous. As soon as a
client wants a signed response, it may wish to prove to some one that he got
a right answer. The unambiguous reference is there as a protection in case
of a CA key compromise where a certificate with the same serial number but a
different content would be created. 

[COMMENT 13]

3. Section 4 8th paragraph

You say that a client MUST verify the policy used by the server
is appropriate

Would you allow for the case where a client doesn't understand
much about policies and is willing accept that the server chose the
right policy for it? Kind of like a NULL verification?

[Answer 13]

There has been plenty of discussions on this topic already these past days,
please refer to that thread.

[COMMENT 14]

5. Section 4 return states

I agree with Mike - it is unclear why 3 and 4 are different. 
I believe you are planning to change this already

[Answer 14]

It can be changed to three states or even two sates: Yes, No.
The summary provided by Mike is fair. The text will be changed.

[COMMENT 15]

4. Section 4 2nd last paragraph

You say "All the parameters needed to prove that the response
conforms to a request SHALL be copied from the request into the
response, so that a response is self-sufficient proof."

This is not an appropriate requirement. At the most all you
should require in this document is that there be a way to show
that a response corresponds to a particular request. Whether this
is done by copying the request in the response, or just including
its hash is the protocol designers prerogative.

[Answer 15]

See the response to the [COMMENT 1] posted today.

[COMMENT 16]

7. Section 7.1 7th para onwards

I thought the group had recommended against the "cautionary
period". Are you planning to get rid of these paragraphs?
 
[Answer 16]

This section is related to your first comment. This is what makes the
difference between the time T1, where the key was used and the time T2 where
the revocation information is available. I would guess that the next IETF
meeting will be the right place to discuss this issue, ... in corridors
first. 

[COMMENT 17]

8. Section 8.1.4

More cautionary period stuff

[Answer 17]

Same.

[COMMENT 18]

9. Section 9

Any need to talk about DSV in this document? You aren't really
saying much about it - why mention it?

[Answer 18]

When the text was saying more, some people have been asking to say less.
Since now the text is saying less, you are suggesting more text ? :-)

Denis


> Sorry for the long mail.
> 
> Regards,
> Ambarish
> 
> ---------------------------------------------------------------------
> Ambarish Malpani
> Chief Architect                                          650.567.5457
> ValiCert, Inc.                                  [e-mail]
> 339 N. Bernardo Ave.                          http://www.valicert.com
> Mountain View, CA 94043


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g1SH2Fw09934 for ietf-pkix-bks; Thu, 28 Feb 2002 09:02:15 -0800 (PST)
Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1SH2Ei09930 for <[e-mail]>; Thu, 28 Feb 2002 09:02:14 -0800 (PST)
Received: from lvn-m002.frlv.bull.fr (lvn-m002.frlv.bull.fr [129.184.62.72]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id SAA12578; Thu, 28 Feb 2002 18:04:03 +0100
Received: from bull.net ([129.184.37.97]) by lvn-m002.frlv.bull.fr (Lotus Domino Release 5.0.8) with ESMTP id 2002022818013860:103 ; Thu, 28 Feb 2002 18:01:38 +0100 
Message-ID: <[e-mail]>
Date: Thu, 28 Feb 2002 18:01:37 +0100
From: Denis Pinkas <[e-mail]>
Organization: Integris. A Bull Company
X-Mailer: Mozilla 4.7 [fr] (Win98; I)
X-Accept-Language: fr
MIME-Version: 1.0
To: Michael Myers <[e-mail]>
CC: [e-mail]
Subject: Re: Validation policy in DPV/DPD rqmts
References: <[e-mail]>
X-MIMETrack: Itemize by SMTP Server on LVN-M002/FR/BULL(Release 5.0.8 |June 18, 2001) at 28/02/2002 18:01:38, Serialize by Router on LVN-M002/FR/BULL(Release 5.0.8 |June 18, 2001) at 28/02/2002 18:02:10, Serialize complete at 28/02/2002 18:02:10
Content-Transfer-Encoding: 7bit
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>

Michael,

> Steve, Russ:
> 
> OK, I get it now.  It's basically a roots issue.
> 
> Then perhaps the I-D could include some informative text that
> expands on what a rational validation policy might likely
> address.

Some text is already there. 

Take a look at section 7.1. Validation Policy

Denis
 
> Mike
> 
> Michael Myers
> t: +415.819.1362
> e: mailto:[e-mail]
> w: http://www.traceroutesecurity.com


Received: by above.proper.com (8.11.6/8.11.3) id g1SGsRm09080 for ietf-pkix-bks; Thu, 28 Feb 2002 08:54:27 -0800 (PST)
Received: from ocasey.baltimore.com (ocasey.baltimore.com [193.41.17.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1SGsPi09074 for <[e-mail]>; Thu, 28 Feb 2002 08:54:25 -0800 (PST)
Received: from Baltimore-FW1 ([172.19.1.1]) by ocasey.baltimore.com (8.11.6/8.9.3) with SMTP id g1SGsQJ24081 for <[e-mail]>; Thu, 28 Feb 2002 16:54:26 GMT
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, 28 Feb 2002 16:49:31 +0000
Received: from baltimore.ie (wks140-4.ie.baltimore.com [10.153.4.140]) by bobcat.baltimore.ie (8.9.3/8.9.3) with ESMTP id QAA22055; Thu, 28 Feb 2002 16:54:23 GMT
Message-ID: <[e-mail]>
Date: Thu, 28 Feb 2002 16:54:24 +0000
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: Denis Pinkas <[e-mail]>
CC: Peter Sylvester <[e-mail]>, Petra Barzin <[e-mail]>, [e-mail]
Subject: Re: "Potentially valid" response state in DPV/DPD rqmts I-D
References: <[e-mail]> <[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>

Denis,

> [Answer 1] The requirements are different whether the requester simply wants
> an authenticated response or a signed response. For a signed response the
> inclusion of the important elements from the request is needed, so that a
> response can be individually tested against what has been requested. For an
> authenticated response, the hash of the request is sufficient. To summarize:
> 
> - for signed responses, the important elements from the request
>   must be present.
> 
> - for authenticated responses, either the hash of the request or the
>   important elements from the request must be present.

I'd love to know why this is the case, given that signing involves
hashing and use of a private key. Is a 2nd hash a bad thing or
something? (Note: I agree that a protocol could follow this rule,
but copying should not be a requirement on a protocol).

Stephen.

-- 
____________________________________________________________
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 g1SGiFK08668 for ietf-pkix-bks; Thu, 28 Feb 2002 08:44:15 -0800 (PST)
Received: from edelweb.fr (edelweb.fr [212.234.46.16]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1SGiCi08664 for <[e-mail]>; Thu, 28 Feb 2002 08:44:12 -0800 (PST)
Received: from champagne.edelweb.fr (localhost.edelweb.fr [127.0.0.1]) by edelweb.fr with ESMTP id RAA27860; Thu, 28 Feb 2002 17:44:04 +0100 (MET)
Received: from champagne.edelweb.fr (champagne.edelweb.fr [193.51.14.161]) by edelweb.fr (nospam/1.3); Thu, 28 Feb 2002 17:44:04 +0100 (MET)
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 RAA06526; Thu, 28 Feb 2002 17:44:03 +0100 (MET)
From: Peter Sylvester <[e-mail]>
Received: (sylvest@localhost) by emeriau.edelweb.fr (8.7.6/8.6.6) id RAA20327; Thu, 28 Feb 2002 17:44:02 +0100 (MET)
Date: Thu, 28 Feb 2002 17:44:02 +0100 (MET)
Message-Id: <[e-mail]>
To: [e-mail], [e-mail], [e-mail]
Subject: Re: "Potentially valid" response state in DPV/DPD rqmts I-D
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>

Thanks for the response. 

> 
> [COMMENT 1]
> 
> - a hash of the request MUST be included in the response.
> This may allow the client to check if his request was maliciously
> modified (if the response is signed) and helps to associate the
> response with his request when using connectionless protocols.
> 
> [Answer 1] The requirements are different whether the requester simply wants
> an authenticated response or a signed response. For a signed response the
> inclusion of the important elements from the request is needed, so that a
> response can be individually tested against what has been requested. For an
> authenticated response, the hash of the request is sufficient. To summarize: 
> 
> - for signed responses, the important elements from the request 
>   must be present.
> 
> - for authenticated responses, either the hash of the request or the
>   important elements from the request must be present.

This is describing a particular solution of the requirement. I think I 
agree with the description of Ambarish: 
    "At the most all you
     should require in this document is that there be a way to show
     that a response corresponds to a particular request. Whether this
     is done by copying the request in the response, or just including
     its hash is the protocol designers prerogative."

> [COMMENT 2]
> 
> - a random number MAY be included in the request.
> This allows replay protection when the client has no clock.
> The random number doesn't have to be repeated in the response
> if the response contains a hash of the request.
> 
> [Answer 2] Replay protection is so obvious that it has been omitted. We
> could certainly add some text. The nonce cryptographically binds a request
> and a response to prevent replay attacks. However when you say: "The random
> number doesn't have to be repeated in the response *if* the response
> contains a hash of the request". This sentence is in contradiction with your
> first comment where you say: "a hash of the request MUST be included in the
> response". A choice needs to me made.  :-)
> 
> I believe that the nonce should be in the response as well, just because it
> is easier for the client to compute the hash over all the fields from the
> response instead of saying: "after the item X, I need to copy the nonce from
> the request".

Ambarish's remark can be adapted to this case: "In some cases, it may be
necessary that some explicit mecanism for replay mecanism is necessary,
a protocol should provide for such a means. This can be done for example by
exchanging random nonce values". 


> 
> COMMENTS FROM PETER SYLVESTER
> 
> 
> [COMMENT 5]
> 
> - a method to authenticate a server before sending any request
>    (for example this can be achieved by SSL).
>    (Another example would be using encryption.)
> 
> [Answer 5]. This is covered under the following wording: "In order to be
> able to be confident that the validation of the certificate has correctly
> been done, the client only requires an authenticated response". No change is
> necessary.

This statement covers authentication of a response, I am asking for
authentication of the service before sending a request. Regarding
your response to the next comment, yes, this can be implemented by
a transport mecanism, but there is still a requirement. 

> 
> 
> [COMMENT 6]
> 
> - a method to ensure confidentiality of the transport.
> 
> [Answer 6] There is nothing here in that protocol that mandates
> confidentiality like protecting the value of a private key or a secret key.
> The transport can provide confidentiality in support of environments that do
> not wish to reveal requests or responses contents, e.g. using TLS or S/MIME.

Basically You agree that there is a requirement for confidentiality. Whether
it can be supported by a transport mecanism is a solution. 

> No change is necessary.
I Disagree.

> 
> 
> [COMMENT 7]
> 
> - a method that client and server provide their identity
>    in the requests and responses: 'You, the client X, has
>    asked me, the server Y, the following question, and
>    I, the server Y, with the help of server Z respond.'
> 
> This allows to be able to determine the participating entities
> without having access to whatever particular authentication
> method information.
> 
> [Answer 7] Actually, we already include the identity of the server in the
> response. The request could also be optionally signed. This allows 
> the server to authenticate the client, and this authentication allows the 
> server to only support a selective community if desired. An option to be
> able to sign the request may be added.
> 
> The following requirements may be used for example in case of
> validation of an encryption certificate before usage.

There is a difference between authentication and identification.
The request is that the identification is independant from the
authentication methods and the transports. 

A signing entity (the one identified in a signerinfo or a certificate)
may or may not be the same as the one declared in the request/response.
you may have separation of roles or other situations. 

"The President of the United States declares, ... signed by JWB".

Another example is in relaying as follows: 

Your company service delares that I can use Your encrytion cert,
and the response is signed by my local service. 

> 
> 
> [COMMENT 8]
> 
> One may resume the relaying requirements into one:
> 
> - The protocol MUST provide a means to allow (visible) relaying
>    of requests and responses.
> 
> - Relaying requirements:
> 
> - depending on policy, a server may just impersonate another
>    server, i.e., take the responses of another server, and create
>    its own response out of them.
> 
> - a server should be able to include the response of a relayed
>    server into his response.
> 
> - a server should be able to simple add another authentication
>    scheme to a response from another server (for example by
>    using a second signature or a counter signature.)
> 
> - a server that acts as a relay should be able to tell to the
>    next server that it is acting on behalf of a end user, and
>    the final server should be able to note this in the response.
> 
> - For relaying, the protocol MUST provide an efficient means
>    to detect loops.
> 
> [Answer 8] Clients trust some dedicated servers. They don't care how the
> information that is provided has been established: there is a single server
> that is responsible: the one which provides the answer. If the response is
> signed by the expected private key, then it is acceptable, otherwise it is
> not. There are not requirements for chaining or referral services. Relaying
> between
> servers is not the topic of this document. No change is necessary.

There is already a requirement that a service returns all information obtained
from other services. There may be OCSP responses, crls, etc. Relaying of one
request (for example of an encryption certificate before its usage) to 
another DPV service seems a possible implementation. 

If I would follow Your logic, then the DPV server never needs to return
anything else than a authenticable YES/NO/DONTKNOW. 

There are requirements for relaying etc. 

> [COMMENT 9]
> 
> - Requirements for incomplete answers:
> 
> - a server may indicate an incomplete response,
>    and provide a method to update the response later.
> 
> [Answer 9] This would create the maintenance of state information which
> should be avoided. There has been plenty of discussion on the list regarding
> the number of states.  People clearly want the fewest possible number. The
> client may query again later on. No change is necessary.

You are accepting the requirement as such but You propose not to 
include it in the document because of some implementation detail. 

You always have state in a server (maintaing a TCP connection for example.)

The fact that this requirement requires some particular feature in
an implementation does not mean that the requirement doesn't exist.

It does neither mean that a particular implementation of the protocol
MUST implement for example given a first online response and sending
a later mail. 



Peter




Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g1SGSjt08222 for ietf-pkix-bks; Thu, 28 Feb 2002 08:28:45 -0800 (PST)
Received: from mtiwmhc22.worldnet.att.net (mtiwmhc22.worldnet.att.net [204.127.131.47]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1SGShi08218 for <[e-mail]>; Thu, 28 Feb 2002 08:28:43 -0800 (PST)
Received: from tsg1 ([12.81.71.235]) by mtiwmhc22.worldnet.att.net (InterMail vM.4.01.03.27 201-229-121-127-20010626) with SMTP id <20020228162833.EMKG13933.mtiwmhc22.worldnet.att.net@tsg1>; Thu, 28 Feb 2002 16:28:33 +0000
Message-ID: <050101c1c074$e8b722e0$020aff0c@tsg1>
From: "todd glassey" <[e-mail]>
To: "Stephen Kent" <[e-mail]>
Cc: <[e-mail]>
References: <20020228012927.CFKS2951.rwcrmhc53.attbi.com@rwcrwbc57> <04ae01c1c061$5f401340$020aff0c@tsg1> <p05100301b8a3f455959c@[128.89.88.34]>
Subject: Re: Validation policy in DPV/DPD rqmts
Date: Thu, 28 Feb 2002 08:28:08 -0800
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 6.00.2600.0000
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
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>

----- Original Message -----
From: "Stephen Kent" <[e-mail]>
To: "todd glassey" <[e-mail]>
Cc: <[e-mail]>
Sent: Thursday, February 28, 2002 7:20 AM
Subject: Re: Validation policy in DPV/DPD rqmts


> >hey all -
> >This is yet another example with the problems of this WG - The fact that
a
> >bunch of technologists have gotten together to create solutions for
problems
> >that don't exist and that may never.
> >
> >If you want the Business World to accept PKI then you have to address
their
> >problems and they are relatively simple. Much simpler than 99% of what's
> >going on in  what this PKIX represents.
> >
> >The real issue is that commerce needs some reliable method(s) of
> >
> >     1)    making decisions regarding identity and rights of the
participants
> >
> >     2)    making decisions on the integrity of the systems that are
> >processing the transactions
> >
> >     3)    proving that all was done as it was professed. i.e evidentiary
> >services.
> >
> >With that said - how many ways do you need to verify the same F$#^*NG
> >signature in an X509 cert?
> >
> >This is the issue. PKI is so complex and there is so little thread
running
> >between the components that they are essentially impossible or very
> >expensive to use. This says it all since no one outside of the PKI
companies
> >seem be working in this PKI realm. And what that means is that this
business
> >is about selling components of this HUGE infrastructure to other
component
> >level manufacturers.
> >
> >What PKIX needs to do is stop making the problem worse and force a
> >convergence in the processes such that they are readily adoptable by
> >Industry and its Auditors. That means that they all follow similar or the
> >same operations models, and that BCP's are available for their use in
> >commercial processes.
> >
> >Otherwise this WG is producing a lot OS hand waving and very little
usable
> >substance.
> >
> >Tim and Steve any retort since you are responsible for what this group
does?
> >
> >
> >Todd Glassey
>
> Todd,
>
> Because PKIX creates standards that provide a foundation for a wide
> range of PKI users, it's usually not possible to focus only on the
> needs of a specific set of potential users when creating these
> standards. This is in contrast to groups like the ANSI X9 committee,
> for example, that explicitly focuses on the financial community.
> Certs are used today in a variety of applications, some of which
> support non-repudiation, and others do not. The cert status checking
> requirements of these different applications vary, accordingly, and
> thus a single standard that encompasses a broad set of apps will, of
> necessity, be more complex than a more narrowly focused set of
> standards, each of which addresses a more narrow set of requirements.
> Historically, the IETF has pursued standards that try to support a
> wide range of applications (which often makes the standards more
> complex); the approach we are pursuing in PKIX is consistent with
> that philosophy.

Then Steve you run the risk of producing garbage. Wares that actually make
the problems more difficult to address. So much of PKIX's arrogance about
what it is going to provide to the world is just that, PKIX's arrogance.

PKI is a set of cruptographic tools and what Commercial Business needs (you
know them, the people that pay your salary) is something more than just your
basic pipe and plumbing assembly.  Otherwise there is no reason for PKIX to
exist as this all should be being done by Applications Developers.

This basic disagreement in the philosophy is why I have asked you to step
down.

>
>
> Steve
>



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g1SFtJZ07329 for ietf-pkix-bks; Thu, 28 Feb 2002 07:55:19 -0800 (PST)
Received: from geos.coastside.net (mail.coastside.net [207.213.212.6]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1SFtEi07325 for <[e-mail]>; Thu, 28 Feb 2002 07:55:18 -0800 (PST)
Received: from laptop (dsl-63-194-153-52.coastside.net [63.194.153.52]) by geos.coastside.net (8.11.0/8.11.3) with SMTP id g1SFpQi02224; Thu, 28 Feb 2002 07:51:26 -0800 (PST)
From: "Michael Myers" <[e-mail]>
To: "Housley, Russ" <[e-mail]>
Cc: <[e-mail]>
Subject: RE: Validation policy in DPV/DPD rqmts
Date: Thu, 28 Feb 2002 07:48:58 -0800
Message-ID: <[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 IMO, Build 9.0.2416 (9.0.2911.0)
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
In-Reply-To: <[e-mail]>
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>

Steve, Russ:

OK, I get it now.  It's basically a roots issue.

Then perhaps the I-D could include some informative text that
expands on what a rational validation policy might likely
address.

Mike

Michael Myers
t: +415.819.1362
e: mailto:[e-mail]
w: http://www.traceroutesecurity.com



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g1SFcSM06944 for ietf-pkix-bks; Thu, 28 Feb 2002 07:38:28 -0800 (PST)
Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1SFcQi06940 for <[e-mail]>; Thu, 28 Feb 2002 07:38:26 -0800 (PST)
Received: from lvn-m002.frlv.bull.fr (lvn-m002.frlv.bull.fr [129.184.62.72]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id QAA13324; Thu, 28 Feb 2002 16:40:17 +0100
Received: from bull.net ([129.184.37.97]) by lvn-m002.frlv.bull.fr (Lotus Domino Release 5.0.8) with ESMTP id 2002022816375121:89 ; Thu, 28 Feb 2002 16:37:51 +0100 
Message-ID: <[e-mail]>
Date: Thu, 28 Feb 2002 16:37:50 +0100
From: Denis Pinkas <[e-mail]>
Organization: Integris. A Bull Company
X-Mailer: Mozilla 4.7 [fr] (Win98; I)
X-Accept-Language: fr
MIME-Version: 1.0
To: Peter Sylvester <[e-mail]>, Petra Barzin <[e-mail]>
CC: [e-mail]
Subject: Re: "Potentially valid" response state in DPV/DPD rqmts I-D
References: <[e-mail]>
X-MIMETrack: Itemize by SMTP Server on LVN-M002/FR/BULL(Release 5.0.8 |June 18, 2001) at 28/02/2002 16:37:51, Serialize by Router on LVN-M002/FR/BULL(Release 5.0.8 |June 18, 2001) at 28/02/2002 16:38:23, Serialize complete at 28/02/2002 16:38:23
Content-Transfer-Encoding: 7bit
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>

Petra and Peter,

Please find below responses to your comments.


COMMENTS FROM PETRA BARZIN

I would like to propose some more requirements to be included
in the DPV/DPD requirements draft:


[COMMENT 1]

- a hash of the request MUST be included in the response.
This may allow the client to check if his request was maliciously
modified (if the response is signed) and helps to associate the
response with his request when using connectionless protocols.

[Answer 1] The requirements are different whether the requester simply wants
an authenticated response or a signed response. For a signed response the
inclusion of the important elements from the request is needed, so that a
response can be individually tested against what has been requested. For an
authenticated response, the hash of the request is sufficient. To summarize: 

- for signed responses, the important elements from the request 
  must be present.

- for authenticated responses, either the hash of the request or the
  important elements from the request must be present.


[COMMENT 2]

- a random number MAY be included in the request.
This allows replay protection when the client has no clock.
The random number doesn't have to be repeated in the response
if the response contains a hash of the request.

[Answer 2] Replay protection is so obvious that it has been omitted. We
could certainly add some text. The nonce cryptographically binds a request
and a response to prevent replay attacks. However when you say: "The random
number doesn't have to be repeated in the response *if* the response
contains a hash of the request". This sentence is in contradiction with your
first comment where you say: "a hash of the request MUST be included in the
response". A choice needs to me made.  :-)

I believe that the nonce should be in the response as well, just because it
is easier for the client to compute the hash over all the fields from the
response instead of saying: "after the item X, I need to copy the nonce from
the request".


[COMMENT 3]

- add one more component to a validation policy: algorithm requirements
They identify the minimum key length of the signature key or
untrusted hash- and signature algorithms.

[Answer 3] I guess that you mean requirements only for the public key
contained in the end-entity certificate to be validated. I am not sure that
this is relevant. If you trust the certificate policy under which the
end-entity certificate has been issued, then you trust the CA to certify
public keys that have the right algorithm and key length. So I believe that
your concern is already solved by specifying certificate policies.


[COMMENT 4]

- add another request/response pair to obtain the definition of a
specific, the default or all validation policies defined on the server.
So far only the references of a validation policies can be returned.
But it might be necessary to retrieve the definition of a validation policy,
too (e.g. for archiving).

[Answer 4] You did not say where you wanted this addition. The server may
support validation policies that have been locally set up, so there may not
be a formal definition that matches the policy. So at least for these one,
this will be impossible. I would like the current request/response pair to
be usable,
without the need to support the request/response pair allowing a remote
definition of the policy. So I would keep the section 6 unchanged.

However, supporting this as part of section 7 - PDP (Policy Definition
Protocol) can certainly be considered.

COMMENTS FROM PETER SYLVESTER

There are some comments for DPV that have been ignored.

The last three blocks in chapter 4 talk about security
requirements, but the following two are not mentioned
(unless I miss something).

- Security requirements


[COMMENT 5]

- a method to authenticate a server before sending any request
   (for example this can be achieved by SSL).
   (Another example would be using encryption.)

[Answer 5]. This is covered under the following wording: "In order to be
able to be confident that the validation of the certificate has correctly
been done, the client only requires an authenticated response". No change is
necessary.


[COMMENT 6]

- a method to ensure confidentiality of the transport.

[Answer 6] There is nothing here in that protocol that mandates
confidentiality like protecting the value of a private key or a secret key.
The transport can provide confidentiality in support of environments that do
not wish to reveal requests or responses contents, e.g. using TLS or S/MIME.
No change is necessary.


[COMMENT 7]

- a method that client and server provide their identity
   in the requests and responses: 'You, the client X, has
   asked me, the server Y, the following question, and
   I, the server Y, with the help of server Z respond.'

This allows to be able to determine the participating entities
without having access to whatever particular authentication
method information.

[Answer 7] Actually, we already include the identity of the server in the
response. The request could also be optionally signed. This allows 
the server to authenticate the client, and this authentication allows the 
server to only support a selective community if desired. An option to be
able to sign the request may be added.

The following requirements may be used for example in case of
validation of an encryption certificate before usage.


[COMMENT 8]

One may resume the relaying requirements into one:

- The protocol MUST provide a means to allow (visible) relaying
   of requests and responses.

- Relaying requirements:

- depending on policy, a server may just impersonate another
   server, i.e., take the responses of another server, and create
   its own response out of them.

- a server should be able to include the response of a relayed
   server into his response.

- a server should be able to simple add another authentication
   scheme to a response from another server (for example by
   using a second signature or a counter signature.)

- a server that acts as a relay should be able to tell to the
   next server that it is acting on behalf of a end user, and
   the final server should be able to note this in the response.

- For relaying, the protocol MUST provide an efficient means
   to detect loops.

[Answer 8] Clients trust some dedicated servers. They don't care how the
information that is provided has been established: there is a single server
that is responsible: the one which provides the answer. If the response is
signed by the expected private key, then it is acceptable, otherwise it is
not. There are not requirements for chaining or referral services. Relaying
between
servers is not the topic of this document. No change is necessary.


[COMMENT 9]

- Requirements for incomplete answers:

- a server may indicate an incomplete response,
   and provide a method to update the response later.

[Answer 9] This would create the maintenance of state information which
should be avoided. There has been plenty of discussion on the list regarding
the number of states.  People clearly want the fewest possible number. The
client may query again later on. No change is necessary.

Regards,

Denis


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g1SFK9S04097 for ietf-pkix-bks; Thu, 28 Feb 2002 07:20:09 -0800 (PST)
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 g1SFK8i04090 for <[e-mail]>; Thu, 28 Feb 2002 07:20:08 -0800 (PST)
Received: from [128.89.88.34] (comsec.bbn.com [128.89.88.34]) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id KAA08676; Thu, 28 Feb 2002 10:19:54 -0500 (EST)
Mime-Version: 1.0
X-Sender: [e-mail]
Message-Id: <p05100301b8a3f455959c@[128.89.88.34]>
In-Reply-To: <04ae01c1c061$5f401340$020aff0c@tsg1>
References: <20020228012927.CFKS2951.rwcrmhc53.attbi.com@rwcrwbc57> <04ae01c1c061$5f401340$020aff0c@tsg1>
Date: Thu, 28 Feb 2002 10:20:23 -0500
To: "todd glassey" <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: Re: Validation policy in DPV/DPD rqmts
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>

>hey all -
>This is yet another example with the problems of this WG - The fact that a
>bunch of technologists have gotten together to create solutions for problems
>that don't exist and that may never.
>
>If you want the Business World to accept PKI then you have to address their
>problems and they are relatively simple. Much simpler than 99% of what's
>going on in  what this PKIX represents.
>
>The real issue is that commerce needs some reliable method(s) of
>
>     1)    making decisions regarding identity and rights of the participants
>
>     2)    making decisions on the integrity of the systems that are
>processing the transactions
>
>     3)    proving that all was done as it was professed. i.e evidentiary
>services.
>
>With that said - how many ways do you need to verify the same F$#^*NG
>signature in an X509 cert?
>
>This is the issue. PKI is so complex and there is so little thread running
>between the components that they are essentially impossible or very
>expensive to use. This says it all since no one outside of the PKI companies
>seem be working in this PKI realm. And what that means is that this business
>is about selling components of this HUGE infrastructure to other component
>level manufacturers.
>
>What PKIX needs to do is stop making the problem worse and force a
>convergence in the processes such that they are readily adoptable by
>Industry and its Auditors. That means that they all follow similar or the
>same operations models, and that BCP's are available for their use in
>commercial processes.
>
>Otherwise this WG is producing a lot OS hand waving and very little usable
>substance.
>
>Tim and Steve any retort since you are responsible for what this group does?
>
>
>Todd Glassey

Todd,

Because PKIX creates standards that provide a foundation for a wide 
range of PKI users, it's usually not possible to focus only on the 
needs of a specific set of potential users when creating these 
standards. This is in contrast to groups like the ANSI X9 committee, 
for example, that explicitly focuses on the financial community. 
Certs are used today in a variety of applications, some of which 
support non-repudiation, and others do not. The cert status checking 
requirements of these different applications vary, accordingly, and 
thus a single standard that encompasses a broad set of apps will, of 
necessity, be more complex than a more narrowly focused set of 
standards, each of which addresses a more narrow set of requirements. 
Historically, the IETF has pursued standards that try to support a 
wide range of applications (which often makes the standards more 
complex); the approach we are pursuing in PKIX is consistent with 
that philosophy.


Steve


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g1SFAPg03603 for ietf-pkix-bks; Thu, 28 Feb 2002 07:10:25 -0800 (PST)
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 g1SFANi03599 for <[e-mail]>; Thu, 28 Feb 2002 07:10:23 -0800 (PST)
Received: from [128.89.88.34] (comsec.bbn.com [128.89.88.34]) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id KAA07048; Thu, 28 Feb 2002 10:10:00 -0500 (EST)
Mime-Version: 1.0
X-Sender: [e-mail]
Message-Id: <p05100302b8a3f63405e9@[128.89.88.34]>
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Date: Thu, 28 Feb 2002 10:04:08 -0500
To: "Michael Myers" <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: RE: Validation policy in DPV/DPD rqmts
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>

At 4:37 PM -0800 2/27/02, Michael Myers wrote:
>Russ,
>
>Good to hear from you.  Apologies for making things difficult.
>Responses embedded below.
>
>Mike
>
>
>>  -----Original Message-----
>>  From: Housley, Russ [mailto:[e-mail]]
>>  Sent: Wednesday, February 27, 2002 2:31 PM
>>  To: Michael Myers
>>  Cc: [e-mail]
>>  Subject: RE: Validation policy in DPV/DPD rqmts
>>
>>
>>  Mike:
>>
>>  I think that each server will have a default, but I
>>  do not think that each server will have the same
>>  policy as the default.
>
>I agree.  Probably so.
>
>But I strongly suspect that those defaults will all identify
>precisely the same logic.  Namely:  1) the path is checked; 2)
>no revocation exists among the path's certificates; and, 3)the
>path terminates in a locally trusted root.  Thus, modulo WG
>consensus, I continue to advocate that PKIX define an OID that
>identifies, among other elements, compliance to PKIX' own RFC
>2459 as a defining characteristic of what it means for a
>certificate to valid.  Maybe it's just me, but I'm having a very
>hard time trying to understand why that might not be the case
>given all the cycles the WG has put into this stuff over the
>years.

The local policy will need to reflect which roots are being used and 
what additional data is associated with each (for example, name 
constraints, policy mapping, etc.). It doesn't seem feasible to 
represent all of that with a common, default OID given the 
site-to-site variability that will ensue.

>
>>  To that end, I do not  think that it is useful to have the
>>  request specify  at the default should be used.
>
>In the I-D there exists no requirement (to my reading) that a
>client MUST specify in its *request* use of a default.  It MAY
>do so, but there is no MUST.  The critical MUST is on the server
>side.  A server MUST indicate the policy used in performing
>delegated path validation.
>
>My concern is, given that server-side MUST, in the case when an
>environment hasn't the organizational bandwidth to fully
>consider all the issues, can we, and indeed should we, define
>for them a minimal baseline?  Especially given all the work the
>WG has been doing related to that issue.  What does it mean for
>an X.509 certificate to be "valid".
>
>>  I would like the response to state the policy that was
>actually
>>  used.  If there is not an OID defined that means my default,
>then
>>  the issue is avoided.
>
>This entire issue can be quickly resolved by simply changing
>that server-side MUST to a MAY.

I would think the best approach would be for an organization to tell 
its users what the local, default OID is, via some out of band means. 
Then they can pass in this policy and the server need not pass back 
the policy info.  However, in the absence of distribution of this 
info, I worry that users might get unexpected results, and no 
appropriate feedback.

Steve


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g1SEP0P00890 for ietf-pkix-bks; Thu, 28 Feb 2002 06:25:00 -0800 (PST)
Received: from vulcan.rsasecurity.com (vulcan.rsasecurity.com [204.167.114.130] (may be forged)) by above.proper.com (8.11.6/8.11.3) with SMTP id g1SEOwi00886 for <[e-mail]>; Thu, 28 Feb 2002 06:24:58 -0800 (PST)
Received: from no.name.available by vulcan.rsasecurity.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 28 Feb 2002 14:24:41 UT
Received: from ebola.securitydynamics.com (ebola.securid.com [192.80.211.4]) by sdtihq24.securid.com (Pro-8.9.3/Pro-8.9.3) with ESMTP id JAA14421 for <[e-mail]>; Thu, 28 Feb 2002 09:24:48 -0500 (EST)
Received: from exna00.securitydynamics.com (localhost [127.0.0.1]) by ebola.securitydynamics.com (8.10.2+Sun/8.9.1) with ESMTP id g1SEOvl09285 for <[e-mail]>; Thu, 28 Feb 2002 09:24:57 -0500 (EST)
Received: by exna00.securitydynamics.com with Internet Mail Service (5.5.2653.19) id <F4N5NN4V>; Thu, 28 Feb 2002 09:22:47 -0500
Received: from HOUSLEY-LAP.rsasecurity.com (HOUSLEY-LAP [10.3.1.92]) by exna00.securitydynamics.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id F4N5NN4T; Thu, 28 Feb 2002 09:22:45 -0500
From: "Housley, Russ" <[e-mail]>
To: Michael Myers <[e-mail]>
Cc: [e-mail]
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Thu, 28 Feb 2002 09:24:46 -0500
Subject: RE: Validation policy in DPV/DPD rqmts
In-Reply-To: <[e-mail]>
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>

Mike:

My concern is "locally trusted roots."  Specifying those roots should be an 
element of the policy.

Russ


At 04:37 PM 2/27/2002 -0800, Michael Myers wrote:
>Russ,
>
>Good to hear from you.  Apologies for making things difficult.
>Responses embedded below.
>
>Mike
>
>
> > -----Original Message-----
> > From: Housley, Russ [mailto:[e-mail]]
> > Sent: Wednesday, February 27, 2002 2:31 PM
> > To: Michael Myers
> > Cc: [e-mail]
> > Subject: RE: Validation policy in DPV/DPD rqmts
> >
> >
> > Mike:
> >
> > I think that each server will have a default, but I
> > do not think that each server will have the same
> > policy as the default.
>
>I agree.  Probably so.
>
>But I strongly suspect that those defaults will all identify
>precisely the same logic.  Namely:  1) the path is checked; 2)
>no revocation exists among the path's certificates; and, 3)the
>path terminates in a locally trusted root.  Thus, modulo WG
>consensus, I continue to advocate that PKIX define an OID that
>identifies, among other elements, compliance to PKIX' own RFC
>2459 as a defining characteristic of what it means for a
>certificate to valid.  Maybe it's just me, but I'm having a very
>hard time trying to understand why that might not be the case
>given all the cycles the WG has put into this stuff over the
>years.
>
> > To that end, I do not  think that it is useful to have the
> > request specify  at the default should be used.
>
>In the I-D there exists no requirement (to my reading) that a
>client MUST specify in its *request* use of a default.  It MAY
>do so, but there is no MUST.  The critical MUST is on the server
>side.  A server MUST indicate the policy used in performing
>delegated path validation.
>
>My concern is, given that server-side MUST, in the case when an
>environment hasn't the organizational bandwidth to fully
>consider all the issues, can we, and indeed should we, define
>for them a minimal baseline?  Especially given all the work the
>WG has been doing related to that issue.  What does it mean for
>an X.509 certificate to be "valid".
>
> > I would like the response to state the policy that was
>actually
> > used.  If there is not an OID defined that means my default,
>then
> > the issue is avoided.
>
>This entire issue can be quickly resolved by simply changing
>that server-side MUST to a MAY.
>
>
>Mike


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g1SEKXq00806 for ietf-pkix-bks; Thu, 28 Feb 2002 06:20:33 -0800 (PST)
Received: from stingray.missi.ncsc.mil (stingray.missi.ncsc.mil [144.51.50.20]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1SEKWi00801 for <[e-mail]>; Thu, 28 Feb 2002 06:20:32 -0800 (PST)
Received: from stingray.missi.ncsc.mil (root@localhost) by stingray.missi.ncsc.mil with ESMTP id g1SEInr19132; Thu, 28 Feb 2002 09:18:49 -0500 (EST)
Message-ID: <[e-mail]>
From: "Fillingham,  David W." <[e-mail]>
To: "PKIX (E-mail)" <[e-mail]>, "Federal PKI TWG (E-mail)" <[e-mail]>, "TWG-BWG Mail List (E-mail)" <[e-mail]>, "DOD BCA Integration (E-mail) (E-mail)" <[e-mail]>, "Bridge CA Mail List (E-mail)" <[e-mail]>
Cc: "Dunshee, Diane M." <[e-mail]>, "Essman, Kristine R." <[e-mail]>, "Redgraves, Michael R." <[e-mail]>, "Lake, Barry A." <[e-mail]>, "John Pawling (E-mail)" <[e-mail]>
Subject: Free Public Key Enabled Application Test Suite Available
Date: Thu, 28 Feb 2002 09:19:04 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="ISO-8859-1"
X-H-S-Loop-Check-Ejzfr: 
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>

This message announces the availability of free and openly available test
resources to facilitate vendor development of secure, interoperable Public
Key Enabled applications.  The US Department of Defense recently completed
the Bridge Certification Authority (BCA) Technology Demonstration Phase II.

The BCA Interoperability Test Suite (BITS) is now available from:

http://bcatest.atl.getronicsgov.com. 

It provides a standard set of test data that can be used to determine a
product's degree of interoperability (including error conditions) with the
BCA Technology Demonstration Phase II architecture including: 

*   discovery and validation of X.509 certification paths in a
cross-certified Public Key Infrastructure (PKI) environment; 

* relying party processing of Certificate Policies and Certificate Policy
Mapping extensions to accept or reject X.509 certification paths based on
assurance level in a policy-heterogeneous PKI;

* relying party processing of Name Constraints extensions to limit
transitive trust of X.509 certification paths;

* certificate revocation using Certificate Revocation Lists (CRL);

* demonstration of cryptographic algorithm agility within X.509
certification paths; and

* transfer of signed and encrypted S/MIME messages between applications
constructing X.509 certification paths that include the BCA.

The BITS includes X.509 Certificates, CRLs, and CrossCertificatePairs that
are equivalent to those created by the products for the BCA Demonstration
Phase II. This test data is available via the Lightweight Directory Access
Protocol (LDAP) from: 

ldap://bcatest.atl.getronicsgov.com

This single LDAP directory includes a directory information tree equivalent
to that hosted on the directory servers used for the BCA Demonstration Phase
II. This directory can be used to test a product's ability to use LDAP to
retrieve the data required to build and validate X.509 certification paths
composed of certificates from multiple PKIs.

The X.509 Certificates, CRLs, CrossCertificatePairs, S/MIME messages, and
Public-Key Cryptography Standard (PKCS) #12 files (containing test private
keys required to process the test S/MIME messages) are available in a zip
file from: 

http://bcatest.atl.getronicsgov.com/. 

The initial BITS goal is to support the testing of S/MIME applications, but
it is designed to serve as a general X.509 certification path discovery and
validation test suite that can be used to test any PKI-enabled application.

The "BCA Interoperability Test Description" documents the BITS test cases,
procedures, and data. The BITS exercises all of the BCA Demonstration Phase
II features except for attribute certificates, rule-based access control,
and border directory concept. Getronics will assist vendors with executing
BITS tests, answering technical questions, and providing troubleshooting
hints. 

Getronics used the open source, freeware Certificate Management Library and
S/MIME Freeware Library (both available from:

http://www.getronicsgov.com/hot/sec_libraries.htm 

to successfully validate the BITS test data.

The BCA Demonstration Phase II final report is available from:

http://www.anassoc.com/BCA.html

It describes the BCA concepts, PKI architecture, cross-certification
relationships, test cases, and test results for the demonstration.


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g1SE8ol00429 for ietf-pkix-bks; Thu, 28 Feb 2002 06:08:50 -0800 (PST)
Received: from mtiwmhc21.worldnet.att.net (mtiwmhc21.worldnet.att.net [204.127.131.46]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1SE8mi00424 for <[e-mail]>; Thu, 28 Feb 2002 06:08:48 -0800 (PST)
Received: from tsg1 ([12.81.71.235]) by mtiwmhc21.worldnet.att.net (InterMail vM.4.01.03.27 201-229-121-127-20010626) with SMTP id <20020228140841.XNIL28073.mtiwmhc21.worldnet.att.net@tsg1>; Thu, 28 Feb 2002 14:08:41 +0000
Message-ID: <04ae01c1c061$5f401340$020aff0c@tsg1>
From: "todd glassey" <[e-mail]>
To: <[e-mail]>
Cc: <[e-mail]>
References: <20020228012927.CFKS2951.rwcrmhc53.attbi.com@rwcrwbc57>
Subject: Re: Validation policy in DPV/DPD rqmts
Date: Thu, 28 Feb 2002 06:08:13 -0800
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 6.00.2600.0000
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
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>

hey all -
This is yet another example with the problems of this WG - The fact that a
bunch of technologists have gotten together to create solutions for problems
that don't exist and that may never.

If you want the Business World to accept PKI then you have to address their
problems and they are relatively simple. Much simpler than 99% of what's
going on in  what this PKIX represents.

The real issue is that commerce needs some reliable method(s) of

    1)    making decisions regarding identity and rights of the participants

    2)    making decisions on the integrity of the systems that are
processing the transactions

    3)    proving that all was done as it was professed. i.e evidentiary
services.

With that said - how many ways do you need to verify the same F$#^*NG
signature in an X509 cert?

This is the issue. PKI is so complex and there is so little thread running
between the components that they are essentially impossible or very
expensive to use. This says it all since no one outside of the PKI companies
seem be working in this PKI realm. And what that means is that this business
is about selling components of this HUGE infrastructure to other component
level manufacturers.

What PKIX needs to do is stop making the problem worse and force a
convergence in the processes such that they are readily adoptable by
Industry and its Auditors. That means that they all follow similar or the
same operations models, and that BCP's are available for their use in
commercial processes.

Otherwise this WG is producing a lot OS hand waving and very little usable
substance.

Tim and Steve any retort since you are responsible for what this group does?



Todd Glassey


----- Original Message -----
From: <[e-mail]>
To: "Michael Myers" <[e-mail]>
Cc: <[e-mail]>
Sent: Wednesday, February 27, 2002 5:29 PM
Subject: RE: Validation policy in DPV/DPD rqmts


>
> >
> > Denis,
> >
> > (and anybody else with an opinion on the matter)
> >
> > Do you agree that defining an OID indicating use of a
> DEFAULT
> > policy is useful?
> >
>
> Michael,
> If I understand your recommendation correctly, you are
> suggesting that this working group define what a TTP
> means by sending a given signal to a relying party.
>
> IMHO this is not appropriate.  This is because the
> complete meaning of the signal most likely contains
> business and legal elements as well.

Who then is supposed to use this technology - You personally - If that is
true then there is no reason to have this WG here. Business is the end user
and its needs are very well defined.

> For example a
> reponse singaling that a certificate is invalid is
> typically not saying merely that.

No you are wrong - thats esactly what the existing protocols are saying
becuase that's all they can say.

>  It is also saying
> things like: I stand behind the assertion to the tune of
> n dollars; my window of tolerance is n minutes; this
> signal may not be relied upon in life and death matters
> and is for commercial use only; interpretation of the
> assertion is goverened by contract/validation policy
> document such and such; jurisdiction is x; and so on.

Aggggggggggghhhhhhhhh - No its not - the current protocols ignore policy and
its negotiation as an inline function. Thus policy envelope surrounding the
transactionmust be defined somehow out of band. Which makes the use of PKI
somewhat questionable - I can get the same feature-based decision support by
reading rights state data from some Master DB..

>
> Indeed I dont' believe there should be something like a
> default policy at all.

The damn well needs to be one as well as a Transaction Policy Negotiation
process.

>
> If however, what you are saying is that there should be
> a prescribed default behavior of the technology
> components and further that such behavior should be
> assigned an OID... that would seem more doable /
> reasonable.  Although the benefits of assigning this
> behavior an OID don't seem compelling.
>
> That at any rate is my $0.02.
>
> Khaja
>
> > If so, then the next question is what constitutes the elements
> > of that policy.  But if not, then I have some further thoughts.
> > Apologies to all for the length of this but I will not be able
> > to attend Minneapolis to argue these points in person so I'll
> > use the list to present my opinions.
> >
> > We should not be forcing every environment wishing to use the
> > core functionality of delegated path validation to take on the
> > added burden of establishing a validation policy advisory board
> > or writing a validation policy practices statement or submitting
> > a proposed validation policy to some sort of validation policy
> > police or all that other predictable hoo-hah just because
> > there's this OID slot that needs filling.
> >
> > Certainly there exists environments where such customized
> > diligence is justified. We should take care to enable them to do
> > so. But I'm pretty sure PKIX can define what it means for a
> > certificate to be "valid" in the DEFAULT case and with respect
> > to PKIX' own work products.
> >
> > This default definition would be useful in ensuring not only a
> > uniformity of deployed functionality, but it would also
> > establish a floor on operational use with very little impact to
> > those environments who find the definition acceptable.
> >
> > Specification of a default definition of "valid" would also
> > force into existence known minimal functionality on servers and
> > clients, most if not all of which is already in place.  Else
> > what is someone who wishes to design and code a DPV server and
> > DPV-enabled client to do?  What code to write?  Requirements
> > should be actionable and testable.
> >
> > The real question is, what are the elements, the requirements,
> > of that default validation policy?  In essence, this reduces
> > down to what is running code minimally supposed to do when it's
> > running?
> >
> > Since this is the PKIX working group, I have hard time believing
> > that compliance to 2459's path validation logic would not be
> > incorporated into that thinking.  The WG has worked hard and
> > long on this point.  Clearly one needs some sort of checking
> > against revocation data. In addition, reference has been made to
> > the public key of the CA, the CA's name, path constraints and
> > selection of a most-trusted CA.
> >
> > I propose the working group establish that, in the DEFAULT case
> > and specifically with respect to delegated path validation
> > requirements, a certificate SHALL be considered valid if:
> >
> > 1. The path chosen by a delegated path validator satisfies the
> > path validation logic defined by RFC 2459 (or more likely its
> > immediate antecedent now in process), which algorithm is defined
> > to consider, among other things, path constraints, should any
> > exist;
> >
> > 2. Is neither revoked nor suspended;
> >
> > 3. Nor are any of the certificates in the path revoked or
> > suspended; and
> >
> > 4. The path terminates in a trusted CA certificate, which
> > certificate is or may be established as a consequence of local
> > policy.
> >
> > Denis, I must confess that I'm having a very hard time trying to
> > translate your statements regarding what a "policy" actually is
> > into actionable requirements that relate directly to the
> > production of running code.  As to what a "policy" actually is
> > in this proposed default context, well, I suppose it could be
> > one's policy simply to accept the default.  But that is an
> > operational issue, not a bits on the  wire issue.
> >
> > Or that policy could go on to superset the above baseline with
> > externally specified trust anchors or hubs, clever use of
> > subject directory attributes extension, reference to
> > specifically identified external authorities, or whatever else
> > might be relevant to local needs.
> >
> > That localized policy could go on to indicate SAS/70 or BS 7799
> > etc. type auditing of related ancillary technical practices, the
> > security of physical premises and background checks on trusted
> > employees.  However, in those cases I again don't see any impact
> > to a bits on the wire specification of a protocol.
> >
> > I strongly suspect that the above four factors, or some
> > variation, will always be at the core of any deployment of
> > delegated path validation.  Thus it only makes sense to allocate
> > a PKIX OID identifying this technical practice as the default in
> > order to establish a floor on the trustworthiness of any
> > deployment of delegated path validation.
> >
> > What harm is there in doing so?
> >
> > Mike
> >
> >
> > Michael Myers
> > t: +415.819.1362
> > e: mailto:[e-mail]
> > w: http://www.traceroutesecurity.com
> >
> >



Received: by above.proper.com (8.11.6/8.11.3) id g1SC8Hx23657 for ietf-pkix-bks; Thu, 28 Feb 2002 04:08:17 -0800 (PST)
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1SC8Gi23653 for <[e-mail]>; Thu, 28 Feb 2002 04:08:16 -0800 (PST)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA18318; Thu, 28 Feb 2002 07:08:14 -0500 (EST)
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-x509-ipaddr-as-extn-00.txt
Date: Thu, 28 Feb 2002 07:08:13 -0500
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>

--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		: X.509 Extensions for IP Addresses and AS Identifiers
	Author(s)	: C. Lynn et al.
	Filename	: draft-ietf-pkix-x509-ipaddr-as-extn-00.txt
	Pages		: 20
	Date		: 27-Feb-02
	
This document defines two private X.509 v3 certificate extensions.
The first binds a list of IP address blocks, or prefixes, to the
subject of a certificate.  The second binds a list of Autonomous
System Identifiers to the subject of a certificate.  These extensions
may be used to convey the authorization of the subject to use the IP
addresses and Autonomous System identifiers contained in the
extensions.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-pkix-x509-ipaddr-as-extn-00.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

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-x509-ipaddr-as-extn-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-x509-ipaddr-as-extn-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-x509-ipaddr-as-extn-00.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-pkix-x509-ipaddr-as-extn-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.6/8.11.3) id g1SAdHu18998 for ietf-pkix-bks; Thu, 28 Feb 2002 02:39:17 -0800 (PST)
Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1SAdFi18989 for <[e-mail]>; Thu, 28 Feb 2002 02:39:16 -0800 (PST)
Received: from lvn-m002.frlv.bull.fr (lvn-m002.frlv.bull.fr [129.184.62.72]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id LAA14368; Thu, 28 Feb 2002 11:40:36 +0100
Received: from bull.net ([129.184.37.97]) by lvn-m002.frlv.bull.fr (Lotus Domino Release 5.0.8) with ESMTP id 2002022811383640:39 ; Thu, 28 Feb 2002 11:38:36 +0100 
Message-ID: <[e-mail]>
Date: Thu, 28 Feb 2002 11:38:35 +0100
From: Denis Pinkas <[e-mail]>
Organization: Integris. A Bull Company
X-Mailer: Mozilla 4.7 [fr] (Win98; I)
X-Accept-Language: fr
MIME-Version: 1.0
To: Michael Myers <[e-mail]>
CC: "Housley, Russ" <[e-mail]>, [e-mail]
Subject: Re: Validation policy in DPV/DPD rqmts
References: <[e-mail]> <[e-mail]>
X-MIMETrack: Itemize by SMTP Server on LVN-M002/FR/BULL(Release 5.0.8 |June 18, 2001) at 28/02/2002 11:38:36, Serialize by Router on LVN-M002/FR/BULL(Release 5.0.8 |June 18, 2001) at 28/02/2002 11:38:46, Serialize complete at 28/02/2002 11:38:46
Content-Transfer-Encoding: 7bit
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>

Mike,

Russ gave you the right answer (copied below).

> I think that each server will have a default, but I do not think that each
> server will have the same policy as the default.  To that end, I do not
> think that it is useful to have the request specify at the default should
> be used.  I would like the response to state the policy that was actually
> used.  If there is not an OID defined that means my default, then the issue
> is avoided.

The requirements are simple, if the client does not indicate the policy to 
be used in his request then the default policy of the server will be used, 
and the response will indicate the policy that was actually used.

(...)

> >Denis, I must confess that I'm having a very hard time trying to
> >translate your statements regarding what a "policy" actually is
> >into actionable requirements that relate directly to the
> >production of running code.  

Since you confessed, you are forgiven. :-)

There is a difference between :

1) the logic of an algorithm (RFC 2459 describes one algorithm) and 
2) both the logic of an algorithm and the parameters used by that logic 
   (i.e. what a validation policy is).

The parameters are well decribed in the document. Without values for these
parameters, you cannot apply a policy nor know which policy has been used.

In your answer to Russ you said: "This entire issue can be quickly resolved
by simply changing that server-side MUST to a MAY." I would not agree.

A server may first support one policy, so it is the default. Three months
later, a new policy is supported and then it becomes the default. The
previous one is still supported. If you store two signed responses from two
different times, it would not be possible to directly know which policy has
been used. Making the reference of the validation policy mandatory in the 
response, solves the problem.

I hope we can now close this issue.

Denis


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g1S1TUX12247 for ietf-pkix-bks; Wed, 27 Feb 2002 17:29:30 -0800 (PST)
Received: from rwcrmhc53.attbi.com (rwcrmhc53.attbi.com [204.127.198.39]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1S1TTi12243 for <[e-mail]>; Wed, 27 Feb 2002 17:29:29 -0800 (PST)
Received: from rwcrwbc57 ([204.127.198.46]) by rwcrmhc53.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with SMTP id <20020228012927.CFKS2951.rwcrmhc53.attbi.com@rwcrwbc57>; Thu, 28 Feb 2002 01:29:27 +0000
Received: from [64.172.38.74] by rwcrwbc57; Thu, 28 Feb 2002 01:29:26 +0000
From: [e-mail]
To: "Michael Myers" <[e-mail]>
Cc: <[e-mail]>
Subject: RE: Validation policy in DPV/DPD rqmts
Date: Thu, 28 Feb 2002 01:29:26 +0000
X-Mailer: AT&T Message Center Version 1 (Nov 29 2001)
Message-Id: <20020228012927.CFKS2951.rwcrmhc53.attbi.com@rwcrwbc57>
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>

> 
> Denis,
> 
> (and anybody else with an opinion on the matter)
> 
> Do you agree that defining an OID indicating use of a 
DEFAULT
> policy is useful?
> 

Michael, 
If I understand your recommendation correctly, you are 
suggesting that this working group define what a TTP 
means by sending a given signal to a relying party. 

IMHO this is not appropriate.  This is because the 
complete meaning of the signal most likely contains 
business and legal elements as well.  For example a 
reponse singaling that a certificate is invalid is 
typically not saying merely that.  It is also saying 
things like: I stand behind the assertion to the tune of 
n dollars; my window of tolerance is n minutes; this 
signal may not be relied upon in life and death matters 
and is for commercial use only; interpretation of the 
assertion is goverened by contract/validation policy 
document such and such; jurisdiction is x; and so on.

Indeed I dont' believe there should be something like a 
default policy at all.  

If however, what you are saying is that there should be 
a prescribed default behavior of the technology 
components and further that such behavior should be 
assigned an OID... that would seem more doable / 
reasonable.  Although the benefits of assigning this 
behavior an OID don't seem compelling.  

That at any rate is my $0.02.  

Khaja

> If so, then the next question is what constitutes the elements
> of that policy.  But if not, then I have some further thoughts.
> Apologies to all for the length of this but I will not be able
> to attend Minneapolis to argue these points in person so I'll
> use the list to present my opinions.
> 
> We should not be forcing every environment wishing to use the
> core functionality of delegated path validation to take on the
> added burden of establishing a validation policy advisory board
> or writing a validation policy practices statement or submitting
> a proposed validation policy to some sort of validation policy
> police or all that other predictable hoo-hah just because
> there's this OID slot that needs filling.
> 
> Certainly there exists environments where such customized
> diligence is justified. We should take care to enable them to do
> so. But I'm pretty sure PKIX can define what it means for a
> certificate to be "valid" in the DEFAULT case and with respect
> to PKIX' own work products.
> 
> This default definition would be useful in ensuring not only a
> uniformity of deployed functionality, but it would also
> establish a floor on operational use with very little impact to
> those environments who find the definition acceptable.
> 
> Specification of a default definition of "valid" would also
> force into existence known minimal functionality on servers and
> clients, most if not all of which is already in place.  Else
> what is someone who wishes to design and code a DPV server and
> DPV-enabled client to do?  What code to write?  Requirements
> should be actionable and testable.
> 
> The real question is, what are the elements, the requirements,
> of that default validation policy?  In essence, this reduces
> down to what is running code minimally supposed to do when it's
> running?
> 
> Since this is the PKIX working group, I have hard time believing
> that compliance to 2459's path validation logic would not be
> incorporated into that thinking.  The WG has worked hard and
> long on this point.  Clearly one needs some sort of checking
> against revocation data. In addition, reference has been made to
> the public key of the CA, the CA's name, path constraints and
> selection of a most-trusted CA.
> 
> I propose the working group establish that, in the DEFAULT case
> and specifically with respect to delegated path validation
> requirements, a certificate SHALL be considered valid if:
> 
> 1. The path chosen by a delegated path validator satisfies the
> path validation logic defined by RFC 2459 (or more likely its
> immediate antecedent now in process), which algorithm is defined
> to consider, among other things, path constraints, should any
> exist;
> 
> 2. Is neither revoked nor suspended;
> 
> 3. Nor are any of the certificates in the path revoked or
> suspended; and
> 
> 4. The path terminates in a trusted CA certificate, which
> certificate is or may be established as a consequence of local
> policy.
> 
> Denis, I must confess that I'm having a very hard time trying to
> translate your statements regarding what a "policy" actually is
> into actionable requirements that relate directly to the
> production of running code.  As to what a "policy" actually is
> in this proposed default context, well, I suppose it could be
> one's policy simply to accept the default.  But that is an
> operational issue, not a bits on the  wire issue.
> 
> Or that policy could go on to superset the above baseline with
> externally specified trust anchors or hubs, clever use of
> subject directory attributes extension, reference to
> specifically identified external authorities, or whatever else
> might be relevant to local needs.
> 
> That localized policy could go on to indicate SAS/70 or BS 7799
> etc. type auditing of related ancillary technical practices, the
> security of physical premises and background checks on trusted
> employees.  However, in those cases I again don't see any impact
> to a bits on the wire specification of a protocol.
> 
> I strongly suspect that the above four factors, or some
> variation, will always be at the core of any deployment of
> delegated path validation.  Thus it only makes sense to allocate
> a PKIX OID identifying this technical practice as the default in
> order to establish a floor on the trustworthiness of any
> deployment of delegated path validation.
> 
> What harm is there in doing so?
> 
> Mike
> 
> 
> Michael Myers
> t: +415.819.1362
> e: mailto:[e-mail]
> w: http://www.traceroutesecurity.com
> 
> 


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g1S0i8C11255 for ietf-pkix-bks; Wed, 27 Feb 2002 16:44:08 -0800 (PST)
Received: from geos.coastside.net (mail.coastside.net [207.213.212.6]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1S0i7i11251 for <[e-mail]>; Wed, 27 Feb 2002 16:44:07 -0800 (PST)
Received: from laptop (dsl-63-194-153-52.coastside.net [63.194.153.52]) by geos.coastside.net (8.11.0/8.11.3) with SMTP id g1S0eEi03394; Wed, 27 Feb 2002 16:40:15 -0800 (PST)
From: "Michael Myers" <[e-mail]>
To: "Housley, Russ" <[e-mail]>
Cc: <[e-mail]>
Subject: RE: Validation policy in DPV/DPD rqmts
Date: Wed, 27 Feb 2002 16:37:47 -0800
Message-ID: <[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 IMO, Build 9.0.2416 (9.0.2911.0)
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
In-Reply-To: <[e-mail]>
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>

Russ,

Good to hear from you.  Apologies for making things difficult.
Responses embedded below.

Mike


> -----Original Message-----
> From: Housley, Russ [mailto:[e-mail]]
> Sent: Wednesday, February 27, 2002 2:31 PM
> To: Michael Myers
> Cc: [e-mail]
> Subject: RE: Validation policy in DPV/DPD rqmts
>
>
> Mike:
>
> I think that each server will have a default, but I
> do not think that each server will have the same
> policy as the default.

I agree.  Probably so.

But I strongly suspect that those defaults will all identify
precisely the same logic.  Namely:  1) the path is checked; 2)
no revocation exists among the path's certificates; and, 3)the
path terminates in a locally trusted root.  Thus, modulo WG
consensus, I continue to advocate that PKIX define an OID that
identifies, among other elements, compliance to PKIX' own RFC
2459 as a defining characteristic of what it means for a
certificate to valid.  Maybe it's just me, but I'm having a very
hard time trying to understand why that might not be the case
given all the cycles the WG has put into this stuff over the
years.

> To that end, I do not  think that it is useful to have the
> request specify  at the default should be used.

In the I-D there exists no requirement (to my reading) that a
client MUST specify in its *request* use of a default.  It MAY
do so, but there is no MUST.  The critical MUST is on the server
side.  A server MUST indicate the policy used in performing
delegated path validation.

My concern is, given that server-side MUST, in the case when an
environment hasn't the organizational bandwidth to fully
consider all the issues, can we, and indeed should we, define
for them a minimal baseline?  Especially given all the work the
WG has been doing related to that issue.  What does it mean for
an X.509 certificate to be "valid".

> I would like the response to state the policy that was
actually
> used.  If there is not an OID defined that means my default,
then
> the issue is avoided.

This entire issue can be quickly resolved by simply changing
that server-side MUST to a MAY.


Mike



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g1S0F5H10730 for ietf-pkix-bks; Wed, 27 Feb 2002 16:15:05 -0800 (PST)
Received: from ext-mail.valicert.com ([66.206.205.11]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1S0F4i10726 for <[e-mail]>; Wed, 27 Feb 2002 16:15:04 -0800 (PST)
Received: from CONVERSION-DAEMON by ext-mail.valicert.com (PMDF V5.2-33 #46613) id <[e-mail]> for [e-mail]; Wed, 27 Feb 2002 16:14:47 -0800 (PST)
Received: from polaris.valicert.com ([192.168.2.34]) by ext-mail.valicert.com (PMDF V5.2-33 #46613) with ESMTP id <[e-mail]> for [e-mail]; Wed, 27 Feb 2002 16:14:47 -0800 (PST)
Received: by exchange.valicert.com with Internet Mail Service (5.5.2653.19) id <FW60F384>; Wed, 27 Feb 2002 16:15:01 -0800
Content-return: allowed
Date: Wed, 27 Feb 2002 16:15:00 -0800
From: Ambarish Malpani <[e-mail]>
Subject: Comments on the DPV-DPD req doc
To: "'[e-mail]'" <[e-mail]>
Message-id: <[e-mail]>
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>

Hi Denis, Russ,
    Here are a set of comments on the DPV-DPD requirements doc.
Denis, some of these are repeats of comments I had sent you
earlier (off the list):

1. Section 4 2nd paragraph
    If a client is asking a server to validate a certificate at
a particular time, that means "was the certificate valid at that
time" (based on information available at that time or information
obtained later). I don't think we should allow it to mean multiple
things

2. Section 4 3rd paragraph
    The requirements document should not forbid specification
of the policy with a request. If the protocol writers find that
specifying the policy (or a subset of the policy) with the
request is too burdensome, let them make that decision. Allowing
a client to specify a frequently changing part of the policy
with every request wouldn't be a bad decision

3. Section 4 6th paragraph
    You say that if the client doesn't provide the full certificate,
the server MUST use the unambiguous reference provided by the client
to get that certificate.
    Again, this is not a requirement. If the server could devine
that certificate by sticking its thumb in the air, that should be
fine - as long as the server verifies that it is the certificate
the client specified

4. Section 4 8th paragraph
    You say that a client MUST verify the policy used by the server
is appropriate
    Would you allow for the case where a client doesn't understand
much about policies and is willing accept that the server chose the
right policy for it? Kind of like a NULL verification?

5. Section 4 return states
    I agree with Mike - it is unclear why 3 and 4 are different. I
believe you are planning to change this already

6. Section 4 2nd last paragraph
    You say "All the parameters needed to prove that the response
conforms to a request SHALL be copied from the request into the
response, so that a response is self-sufficient proof."
    This is not an appropriate requirement. At the most all you
should require in this document is that there be a way to show
that a response corresponds to a particular request. Whether this
is done by copying the request in the response, or just including
its hash is the protocol designers prerogative.

7. Section 7.1 7th para onwards
    I thought the group had recommended against the "cautionary
period". Are you planning to get rid of these paragraphs?

8. Section 8.1.4
    More cautionary period stuff

9. Section 9
    Any need to talk about DSV in this document? You aren't really
saying much about it - why mention it?


Sorry for the long mail.

Regards,
Ambarish


---------------------------------------------------------------------
Ambarish Malpani
Chief Architect                                          650.567.5457
ValiCert, Inc.                                  [e-mail]
339 N. Bernardo Ave.                          http://www.valicert.com
Mountain View, CA 94043


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g1RMf7J08672 for ietf-pkix-bks; Wed, 27 Feb 2002 14:41:07 -0800 (PST)
Received: from vulcan.rsasecurity.com (vulcan.rsasecurity.com [204.167.114.130] (may be forged)) by above.proper.com (8.11.6/8.11.3) with SMTP id g1RMf5i08667 for <[e-mail]>; Wed, 27 Feb 2002 14:41:05 -0800 (PST)
Received: from no.name.available by vulcan.rsasecurity.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 27 Feb 2002 22:40:50 UT
Received: from ebola.securitydynamics.com (ebola.securid.com [192.80.211.4]) by sdtihq24.securid.com (Pro-8.9.3/Pro-8.9.3) with ESMTP id RAA18259 for <[e-mail]>; Wed, 27 Feb 2002 17:40:58 -0500 (EST)
Received: from exna00.securitydynamics.com (localhost [127.0.0.1]) by ebola.securitydynamics.com (8.10.2+Sun/8.9.1) with ESMTP id g1RMf6d04648 for <[e-mail]>; Wed, 27 Feb 2002 17:41:06 -0500 (EST)
Received: by exna00.securitydynamics.com with Internet Mail Service (5.5.2653.19) id <F4N5NH4Y>; Wed, 27 Feb 2002 17:38:55 -0500
Received: from HOUSLEY-LAP.rsasecurity.com (HOUSLEY-LAP [10.3.1.50]) by exna00.securitydynamics.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id F4N5NH44; Wed, 27 Feb 2002 17:38:49 -0500
From: "Housley, Russ" <[e-mail]>
To: Michael Myers <[e-mail]>
Cc: [e-mail]
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Wed, 27 Feb 2002 17:31:05 -0500
Subject: RE: Validation policy in DPV/DPD rqmts
In-Reply-To: <[e-mail]>
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>

Mike:

I think that each server will have a default, but I do not think that each 
server will have the same policy as the default.  To that end, I do not 
think that it is useful to have the request specify at the default should 
be used.  I would like the response to state the policy that was actually 
used.  If there is not an OID defined that means my default, then the issue 
is avoided.

Russ

At 12:02 PM 2/27/2002 -0800, Michael Myers wrote:

>Denis,
>
>(and anybody else with an opinion on the matter)
>
>Do you agree that defining an OID indicating use of a DEFAULT
>policy is useful?
>
>If so, then the next question is what constitutes the elements
>of that policy.  But if not, then I have some further thoughts.
>Apologies to all for the length of this but I will not be able
>to attend Minneapolis to argue these points in person so I'll
>use the list to present my opinions.
>
>We should not be forcing every environment wishing to use the
>core functionality of delegated path validation to take on the
>added burden of establishing a validation policy advisory board
>or writing a validation policy practices statement or submitting
>a proposed validation policy to some sort of validation policy
>police or all that other predictable hoo-hah just because
>there's this OID slot that needs filling.
>
>Certainly there exists environments where such customized
>diligence is justified. We should take care to enable them to do
>so. But I'm pretty sure PKIX can define what it means for a
>certificate to be "valid" in the DEFAULT case and with respect
>to PKIX' own work products.
>
>This default definition would be useful in ensuring not only a
>uniformity of deployed functionality, but it would also
>establish a floor on operational use with very little impact to
>those environments who find the definition acceptable.
>
>Specification of a default definition of "valid" would also
>force into existence known minimal functionality on servers and
>clients, most if not all of which is already in place.  Else
>what is someone who wishes to design and code a DPV server and
>DPV-enabled client to do?  What code to write?  Requirements
>should be actionable and testable.
>
>The real question is, what are the elements, the requirements,
>of that default validation policy?  In essence, this reduces
>down to what is running code minimally supposed to do when it's
>running?
>
>Since this is the PKIX working group, I have hard time believing
>that compliance to 2459's path validation logic would not be
>incorporated into that thinking.  The WG has worked hard and
>long on this point.  Clearly one needs some sort of checking
>against revocation data. In addition, reference has been made to
>the public key of the CA, the CA's name, path constraints and
>selection of a most-trusted CA.
>
>I propose the working group establish that, in the DEFAULT case
>and specifically with respect to delegated path validation
>requirements, a certificate SHALL be considered valid if:
>
>1. The path chosen by a delegated path validator satisfies the
>path validation logic defined by RFC 2459 (or more likely its
>immediate antecedent now in process), which algorithm is defined
>to consider, among other things, path constraints, should any
>exist;
>
>2. Is neither revoked nor suspended;
>
>3. Nor are any of the certificates in the path revoked or
>suspended; and
>
>4. The path terminates in a trusted CA certificate, which
>certificate is or may be established as a consequence of local
>policy.
>
>Denis, I must confess that I'm having a very hard time trying to
>translate your statements regarding what a "policy" actually is
>into actionable requirements that relate directly to the
>production of running code.  As to what a "policy" actually is
>in this proposed default context, well, I suppose it could be
>one's policy simply to accept the default.  But that is an
>operational issue, not a bits on the  wire issue.
>
>Or that policy could go on to superset the above baseline with
>externally specified trust anchors or hubs, clever use of
>subject directory attributes extension, reference to
>specifically identified external authorities, or whatever else
>might be relevant to local needs.
>
>That localized policy could go on to indicate SAS/70 or BS 7799
>etc. type auditing of related ancillary technical practices, the
>security of physical premises and background checks on trusted
>employees.  However, in those cases I again don't see any impact
>to a bits on the wire specification of a protocol.
>
>I strongly suspect that the above four factors, or some
>variation, will always be at the core of any deployment of
>delegated path validation.  Thus it only makes sense to allocate
>a PKIX OID identifying this technical practice as the default in
>order to establish a floor on the trustworthiness of any
>deployment of delegated path validation.
>
>What harm is there in doing so?
>
>Mike
>
>
>Michael Myers
>t: +415.819.1362
>e: mailto:[e-mail]
>w: http://www.traceroutesecurity.com


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g1RK4mb04638 for ietf-pkix-bks; Wed, 27 Feb 2002 12:04:48 -0800 (PST)
Received: from geos.coastside.net (mail.coastside.net [207.213.212.6]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1RK4l304633 for <[e-mail]>; Wed, 27 Feb 2002 12:04:47 -0800 (PST)
Received: from laptop (dsl-63-194-153-52.coastside.net [63.194.153.52]) by geos.coastside.net (8.11.0/8.11.3) with SMTP id g1RK4Wi01792 for <[e-mail]>; Wed, 27 Feb 2002 12:04:32 -0800 (PST)
From: "Michael Myers" <[e-mail]>
To: <[e-mail]>
Subject: RE: Validation policy in DPV/DPD rqmts
Date: Wed, 27 Feb 2002 12:02:05 -0800
Message-ID: <[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 IMO, Build 9.0.2416 (9.0.2911.0)
In-reply-to: <[e-mail]>
X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
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>

Denis,

(and anybody else with an opinion on the matter)

Do you agree that defining an OID indicating use of a DEFAULT
policy is useful?

If so, then the next question is what constitutes the elements
of that policy.  But if not, then I have some further thoughts.
Apologies to all for the length of this but I will not be able
to attend Minneapolis to argue these points in person so I'll
use the list to present my opinions.

We should not be forcing every environment wishing to use the
core functionality of delegated path validation to take on the
added burden of establishing a validation policy advisory board
or writing a validation policy practices statement or submitting
a proposed validation policy to some sort of validation policy
police or all that other predictable hoo-hah just because
there's this OID slot that needs filling.

Certainly there exists environments where such customized
diligence is justified. We should take care to enable them to do
so. But I'm pretty sure PKIX can define what it means for a
certificate to be "valid" in the DEFAULT case and with respect
to PKIX' own work products.

This default definition would be useful in ensuring not only a
uniformity of deployed functionality, but it would also
establish a floor on operational use with very little impact to
those environments who find the definition acceptable.

Specification of a default definition of "valid" would also
force into existence known minimal functionality on servers and
clients, most if not all of which is already in place.  Else
what is someone who wishes to design and code a DPV server and
DPV-enabled client to do?  What code to write?  Requirements
should be actionable and testable.

The real question is, what are the elements, the requirements,
of that default validation policy?  In essence, this reduces
down to what is running code minimally supposed to do when it's
running?

Since this is the PKIX working group, I have hard time believing
that compliance to 2459's path validation logic would not be
incorporated into that thinking.  The WG has worked hard and
long on this point.  Clearly one needs some sort of checking
against revocation data. In addition, reference has been made to
the public key of the CA, the CA's name, path constraints and
selection of a most-trusted CA.

I propose the working group establish that, in the DEFAULT case
and specifically with respect to delegated path validation
requirements, a certificate SHALL be considered valid if:

1. The path chosen by a delegated path validator satisfies the
path validation logic defined by RFC 2459 (or more likely its
immediate antecedent now in process), which algorithm is defined
to consider, among other things, path constraints, should any
exist;

2. Is neither revoked nor suspended;

3. Nor are any of the certificates in the path revoked or
suspended; and

4. The path terminates in a trusted CA certificate, which
certificate is or may be established as a consequence of local
policy.

Denis, I must confess that I'm having a very hard time trying to
translate your statements regarding what a "policy" actually is
into actionable requirements that relate directly to the
production of running code.  As to what a "policy" actually is
in this proposed default context, well, I suppose it could be
one's policy simply to accept the default.  But that is an
operational issue, not a bits on the  wire issue.

Or that policy could go on to superset the above baseline with
externally specified trust anchors or hubs, clever use of
subject directory attributes extension, reference to
specifically identified external authorities, or whatever else
might be relevant to local needs.

That localized policy could go on to indicate SAS/70 or BS 7799
etc. type auditing of related ancillary technical practices, the
security of physical premises and background checks on trusted
employees.  However, in those cases I again don't see any impact
to a bits on the wire specification of a protocol.

I strongly suspect that the above four factors, or some
variation, will always be at the core of any deployment of
delegated path validation.  Thus it only makes sense to allocate
a PKIX OID identifying this technical practice as the default in
order to establish a floor on the trustworthiness of any
deployment of delegated path validation.

What harm is there in doing so?

Mike


Michael Myers
t: +415.819.1362
e: mailto:[e-mail]
w: http://www.traceroutesecurity.com




Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g1RDYCr18767 for ietf-pkix-bks; Wed, 27 Feb 2002 05:34:12 -0800 (PST)
Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1RDYB318763 for <[e-mail]>; Wed, 27 Feb 2002 05:34:11 -0800 (PST)
Received: from lvn-m002.frlv.bull.fr (lvn-m002.frlv.bull.fr [129.184.62.72]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id OAA31128; Wed, 27 Feb 2002 14:36:01 +0100
Received: from bull.net ([129.184.37.97]) by lvn-m002.frlv.bull.fr (Lotus Domino Release 5.0.8) with ESMTP id 2002022714333773:497 ; Wed, 27 Feb 2002 14:33:37 +0100 
Message-ID: <[e-mail]>
Date: Wed, 27 Feb 2002 14:33:34 +0100
From: Denis Pinkas <[e-mail]>
Organization: Integris. A Bull Company
X-Mailer: Mozilla 4.7 [fr] (Win98; I)
X-Accept-Language: fr
MIME-Version: 1.0
To: Michael Myers <[e-mail]>
CC: [e-mail]
Subject: Validation policy in DPV/DPD rqmts
References: <[e-mail]>
X-MIMETrack: Itemize by SMTP Server on LVN-M002/FR/BULL(Release 5.0.8 |June 18, 2001) at 27/02/2002 14:33:37, Serialize by Router on LVN-M002/FR/BULL(Release 5.0.8 |June 18, 2001) at 27/02/2002 14:34:09, Serialize complete at 27/02/2002 14:34:09
Content-Transfer-Encoding: 7bit
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>

Michael,

This is my answer on the second thread.

> Since the server MUST indicate a validation policy, provision
> should be made in the I-D for a DEFAULT validation policy that
> indicates compliance to RFC 2459 or whatever RFC # is to follow
> that work.  The DPV/DPD rqmts I-D is probably the best place to
> define that OID.

The principles of path validation contained in RFC 2459, are a set of 
rules which by themselves are insufficient to be considered as a 
validation policy. RFC 2459 "describes an *algorithm* for validating 
certification paths", but not a validation *policy*.

The text also says:

" The algorithm requires the public key of the CA, the CA's name, and any
constraints upon the set of paths which may be validated using this key.
The selection of a "most-trusted CA" is a matter of policy."

Without that minimal information, there is no validation policy possible.

So I do not think that a DEFAULT validation policy, as being proposed, 
is possible.

> The next issue is going to be articulating some standard subset
> of reason codes for invalid and unknown.  Since validation
> policies may be arbitrarily complex and dynamically produced,
> perhaps just addressing the DEFAULT policy is the best that can
> be done.

This is unrelated.

> For "invalid" in the DEFAULT context one would have to a first
> degree either a failure in cert chaining per 2459 or revocation
> (including suspension) somewhere along that chain.

Once again unrelated.

> For "unknown" in the DEFAULT case one would have: an
> unrecognized subject certificate; failure to acquire the
> relevant intermediate or root certificates; and failure to
> acquire the relevant revocation information.

Once again unrelated.

Denis

 
> Mike
> 
> Michael Myers
> t: +415.819.1362
> e: mailto:[e-mail]
> w: http://www.traceroutesecurity.com


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g1RDKBE18023 for ietf-pkix-bks; Wed, 27 Feb 2002 05:20:11 -0800 (PST)
Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1RDK9318018 for <[e-mail]>; Wed, 27 Feb 2002 05:20:09 -0800 (PST)
Received: from lvn-m002.frlv.bull.fr (lvn-m002.frlv.bull.fr [129.184.62.72]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id OAA18138; Wed, 27 Feb 2002 14:21:25 +0100
Received: from bull.net ([129.184.37.97]) by lvn-m002.frlv.bull.fr (Lotus Domino Release 5.0.8) with ESMTP id 2002022714192091:494 ; Wed, 27 Feb 2002 14:19:20 +0100 
Message-ID: <[e-mail]>
Date: Wed, 27 Feb 2002 14:19:17 +0100
From: Denis Pinkas <[e-mail]>
Organization: Integris. A Bull Company
X-Mailer: Mozilla 4.7 [fr] (Win98; I)
X-Accept-Language: fr
MIME-Version: 1.0
To: Michael Myers <[e-mail]>
CC: [e-mail]
Subject: Re: "Potentially valid" response state in DPV/DPD rqmts I-D
References: <[e-mail]>
X-MIMETrack: Itemize by SMTP Server on LVN-M002/FR/BULL(Release 5.0.8 |June 18, 2001) at 27/02/2002 14:19:20, Serialize by Router on LVN-M002/FR/BULL(Release 5.0.8 |June 18, 2001) at 27/02/2002 14:19:34, Serialize complete at 27/02/2002 14:19:34
Content-Transfer-Encoding: 7bit
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>

Michael,

> Denis,
 
> Okay, if I may summarize at a high level my current
> understanding:
 
> We are now effectively back to {valid, invalid, unknown}.  All
> responses MUST indicate the relevant validation policy. This
> policy MAY be established out of band.  An "invalid" response
> MAY contain reason codes or similar information that aids a
> client in determining the likelihood that the same request sent
> at a later time would return "valid". An "unknown" response MAY
> contain reason codes or similar information that indicates a
> failure to acquire all relevant data.
 
> Is that a fair summary?  

Yes, indeed it is.

> If so, a few more thoughts:

It is also fair to address one topic at a time. This is a different topic, 
I will respond to it separately using a different thread title.

Denis

> Since the server MUST indicate a validation policy, provision
> should be made in the I-D for a DEFAULT validation policy that
> indicates compliance to RFC 2459 or whatever RFC # is to follow
> that work.  The DPV/DPD rqmts I-D is probably the best place to
> define that OID.
> 
> The next issue is going to be articulating some standard subset
> of reason codes for invalid and unknown.  Since validation
> policies may be arbitrarily complex and dynamically produced,
> perhaps just addressing the DEFAULT policy is the best that can
> be done.
> 
> For "invalid" in the DEFAULT context one would have to a first
> degree either a failure in cert chaining per 2459 or revocation
> (including suspension) somewhere along that chain.
> 
> For "unknown" in the DEFAULT case one would have: an
> unrecognized subject certificate; failure to acquire the
> relevant intermediate or root certificates; and failure to
> acquire the relevant revocation information.
> 
> Mike
> 
> Michael Myers
> t: +415.819.1362
> e: mailto:[e-mail]
> w: http://www.traceroutesecurity.com
> 
> > -----Original Message-----
> > From: [e-mail]
> > [mailto:[e-mail]]On Behalf Of Denis Pinkas
> > Sent: Tuesday, February 26, 2002 1:51 AM
> >
> > So I would propose the following fix:
> >
> > The DPV response MAY indicate one of three status
> > alternatives:
> >
> > 1) the certificate is valid according to the
> > validation policy.
> >
> > 2) the certificate is invalid according to the
> > validation policy. A secondary status MAY indicate
> > that the certificate is definitively invalid or
> > potentially valid.
> >
> > In the former case, if another request was made
> > later on, the certificate will still be determined
> > as invalid.
> >
> > In the later case, if another request could
> > made later on, the certificate could possibly
> > be determined as valid. This condition will
> > occur before a certificate validity period has
> > begun, while a certificate is suspended, or
> > when, at the time the server generated the
> > response, all conditions of the
> > validation policy could not be met.
> >
> > 3) the server cannot determine the validity of the
> > certificate. This condition will occur when a
> > certification path cannot be constructed or
> > some revocation information is unavailable.
> >
> > Denis


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g1QGXMU14026 for ietf-pkix-bks; Tue, 26 Feb 2002 08:33:22 -0800 (PST)
Received: from geos.coastside.net (mail.coastside.net [207.213.212.6]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1QGXL314016 for <[e-mail]>; Tue, 26 Feb 2002 08:33:21 -0800 (PST)
Received: from laptop (dsl-63-194-153-52.coastside.net [63.194.153.52]) by geos.coastside.net (8.11.0/8.11.3) with SMTP id g1QGXFh09316; Tue, 26 Feb 2002 08:33:15 -0800 (PST)
From: "Michael Myers" <[e-mail]>
To: "Denis Pinkas" <[e-mail]>
Cc: <[e-mail]>
Subject: RE: "Potentially valid" response state in DPV/DPD rqmts I-D
Date: Tue, 26 Feb 2002 08:30:48 -0800
Message-ID: <[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 IMO, Build 9.0.2416 (9.0.2911.0)
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
In-reply-to: <[e-mail]>
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>

Denis,

Okay, if I may summarize at a high level my current
understanding:

We are now effectively back to {valid, invalid, unknown}.  All
responses MUST indicate the relevant validation policy. This
policy MAY be established out of band.  An "invalid" response
MAY contain reason codes or similar information that aids a
client in determining the likelihood that the same request sent
at a later time would return "valid". An "unknown" response MAY
contain reason codes or similar information that indicates a
failure to acquire all relevant data.

Is that a fair summary?  If so, a few more thoughts:

Since the server MUST indicate a validation policy, provision
should be made in the I-D for a DEFAULT validation policy that
indicates compliance to RFC 2459 or whatever RFC # is to follow
that work.  The DPV/DPD rqmts I-D is probably the best place to
define that OID.

The next issue is going to be articulating some standard subset
of reason codes for invalid and unknown.  Since validation
policies may be arbitrarily complex and dynamically produced,
perhaps just addressing the DEFAULT policy is the best that can
be done.

For "invalid" in the DEFAULT context one would have to a first
degree either a failure in cert chaining per 2459 or revocation
(including suspension) somewhere along that chain.

For "unknown" in the DEFAULT case one would have: an
unrecognized subject certificate; failure to acquire the
relevant intermediate or root certificates; and failure to
acquire the relevant revocation information.


Mike



Michael Myers
t: +415.819.1362
e: mailto:[e-mail]
w: http://www.traceroutesecurity.com

> -----Original Message-----
> From: [e-mail]
> [mailto:[e-mail]]On Behalf Of Denis Pinkas
> Sent: Tuesday, February 26, 2002 1:51 AM
>
> So I would propose the following fix:
>
> The DPV response MAY indicate one of three status
> alternatives:
>
> 1) the certificate is valid according to the
> validation policy.
>
> 2) the certificate is invalid according to the
> validation policy. A secondary status MAY indicate
> that the certificate is definitively invalid or
> potentially valid.
>
> In the former case, if another request was made
> later on, the certificate will still be determined
> as invalid.
>
> In the later case, if another request could
> made later on, the certificate could possibly
> be determined as valid. This condition will
> occur before a certificate validity period has
> begun, while a certificate is suspended, or
> when, at the time the server generated the
> response, all conditions of the
> validation policy could not be met.
>
> 3) the server cannot determine the validity of the
> certificate. This condition will occur when a
> certification path cannot be constructed or
> some revocation information is unavailable.
>
> Denis




Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g1QGPbf13762 for ietf-pkix-bks; Tue, 26 Feb 2002 08:25:37 -0800 (PST)
Received: from edelweb.fr (edelweb.fr [212.234.46.16]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1QGPZ313758 for <[e-mail]>; Tue, 26 Feb 2002 08:25:35 -0800 (PST)
Received: from champagne.edelweb.fr (localhost.edelweb.fr [127.0.0.1]) by edelweb.fr with ESMTP id RAA16148; Tue, 26 Feb 2002 17:25:12 +0100 (MET)
Received: from champagne.edelweb.fr (champagne.edelweb.fr [193.51.14.161]) by edelweb.fr (nospam/1.3); Tue, 26 Feb 2002 17:25:13 +0100 (MET)
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 RAA27156; Tue, 26 Feb 2002 17:25:09 +0100 (MET)
From: Peter Sylvester <[e-mail]>
Received: (sylvest@localhost) by emeriau.edelweb.fr (8.7.6/8.6.6) id RAA19586; Tue, 26 Feb 2002 17:25:08 +0100 (MET)
Date: Tue, 26 Feb 2002 17:25:08 +0100 (MET)
Message-Id: <[e-mail]>
To: [e-mail], [e-mail]
Subject: Re: "Potentially valid" response state in DPV/DPD rqmts I-D
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>

> 
> Good question !
> 
> 
> However, you don't propose a solution.
You were supposed to answer my question. 

> 
> One way to fix the problem would be to say:
> 
>    3) the server cannot determine the validity of the certificate.
>       This condition will occur when a certification path cannot be
>       constructed.
This is as unclear as before, is this a temporary or a permanent condition.

If it is a permanent condition, then the certificat is invalid.

> 
> In fact what is important for an application is:
> 
> a) valid,
> b) (definitively) invalid; no need to try later, it will remain invalid,
> c) (temporarily) invalid; if you tried later, then it could be valid,
> d) no idea whether it is valid, definitively invalid or temporarily invalid: 
>    there is not enough information currently available to determine.
> 

Do I agree with Mike by saying the following?

1 - a cert is valid according a policy
2 - it is invalid
3 - you have a temporary service error because of a dos or two planes.

The service gives details about why a cert is invalid/valid.

regards
Peter

May I remind You to consider to respond with 1, 2, 3 to the requirement 
validation requests that I have send yesterday. Thanks in advance.


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g1QCnJv02541 for ietf-pkix-bks; Tue, 26 Feb 2002 04:49:19 -0800 (PST)
Received: from mystic1.trustcenter.de (mystic1.trustcenter.de [193.194.157.34]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1QCnI302533 for <[e-mail]>; Tue, 26 Feb 2002 04:49:18 -0800 (PST)
Received: (from root@localhost) by mystic1.trustcenter.de (8.10.2+Sun/8.10.2) id g1QCmaE01694; Tue, 26 Feb 2002 13:48:36 +0100 (MET)
Received: from venus.trustcenter.de(192.168.200.233) by mystic1.trustcenter.de via csmap (V6.0) id srcAAAQTaOtd; Tue, 26 Feb 02 13:48:35 +0100
Received: from trustcenter.de (titan.trustcenter.de [192.168.200.244]) by venus.trustcenter.de (8.11.0/8.11.0) with ESMTP id g1QCmYV16832; Tue, 26 Feb 2002 13:48:35 +0100 (MET)
Message-ID: <[e-mail]>
Date: Tue, 26 Feb 2002 13:48:34 +0100
From: Juergen Brauckmann <[e-mail]>
Organization: TC TrustCenter AG
X-Mailer: Mozilla 4.75 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Peter Gutmann <[e-mail]>
CC: [e-mail]
Subject: Re: Candidate for moving OCSP to a Draft Standard
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>

Hi Peter.

Peter Gutmann wrote:
> CertificateOK
> 
> The CertOK extension sidesteps the limitations of the CRL-based semantics of
> the standard OCSP response and provides a straightforward indication of whether
> a certificate is OK or not.  "OK" in this sense is the equivalent of the
> banking assertion that an account is in good standing, namely that the
> identified certificate was issued and is currently valid.  Further information
> on why a certificate may not be OK can be found in the standard OCSP response.
> 
>   id-certOK OBJECT IDENTIFIER ::= { 1 3 6 1 4 1 3029 3 1 2 }
> 
>   CertOK ::= BOOLEAN

In the ISISMTT stuff there is a similar OCSP extension which is intended
to allow the server to send the hash of the certificatein question back
to the client.

The problem with a simple boolean is IMO that it's not sure whether
server and client are talking about the same certificate. If we worry
about certificates with a valid signature that may not be issued by a
CA, than it should be possible for the client to check somehow that the
server knows not only about a certificate which happen to have an
IssuerDN and a serialnumber identical to that the client has, but that
is entirely identical to it. This can be achieved by a server which
sends a hash of a certificate back to the client, and the client then
checking this hash.

Standard disclaimer: In a normal PKIX way of doing status checking and
path validation, you don't need to worry about never issued
certificates.

Regards,
    Juergen


Received: by above.proper.com (8.11.6/8.11.3) id g1QB6AZ26497 for ietf-pkix-bks; Tue, 26 Feb 2002 03:06:10 -0800 (PST)
Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1QB68326492 for <[e-mail]>; Tue, 26 Feb 2002 03:06:08 -0800 (PST)
Received: from lvn-m002.frlv.bull.fr (lvn-m002.frlv.bull.fr [129.184.62.72]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id MAA24764; Tue, 26 Feb 2002 12:05:52 +0100
Received: from bull.net ([129.184.37.97]) by lvn-m002.frlv.bull.fr (Lotus Domino Release 5.0.8) with ESMTP id 2002022612035359:351 ; Tue, 26 Feb 2002 12:03:53 +0100 
Message-ID: <[e-mail]>
Date: Tue, 26 Feb 2002 12:03:52 +0100
From: Denis Pinkas <[e-mail]>
Organization: Integris. A Bull Company
X-Mailer: Mozilla 4.7 [fr] (Win98; I)
X-Accept-Language: fr
MIME-Version: 1.0
To: Peter Sylvester <[e-mail]>
CC: [e-mail], [e-mail]
Subject: Re: "Potentially valid" response state in DPV/DPD rqmts I-D
References: <[e-mail]>
X-MIMETrack: Itemize by SMTP Server on LVN-M002/FR/BULL(Release 5.0.8 |June 18, 2001) at 26/02/2002 12:03:53, Serialize by Router on LVN-M002/FR/BULL(Release 5.0.8 |June 18, 2001) at 26/02/2002 12:04:00, Serialize complete at 26/02/2002 12:04:00
Content-Transfer-Encoding: 7bit
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>

Peter,

> > The DPV response MAY indicate one of three status alternatives:
> >
> >    1) the certificate is valid according to the validation policy.
> >
> >    2) the certificate is invalid according to the validation policy.
> >       A secondary status MAY indicate that the certificate is
> >       definitively invalid or potentially valid.
> >
> >       In the former case, if another request was made later on,
> >       the certificate will still be determined as invalid.
> >
> >       In the later case, if another request could made later on,
> >       the certificate could possibly be determined as valid. This
> >       condition will occur before a certificate validity period has
> >       begun, while a certificate is suspended, or when, at the time
> >       the server generated the response, all conditions of the
> >       validation policy could not be met.
> >
> >    3) the server cannot determine the validity of the certificate.
> >       This condition will occur when a certification path cannot be
> >       constructed or some revocation information is unavailable.

> Does 3 indicate a temporary or permanent error?

Good question !

> In case of a tempary access problem to a CRl repository, one can
> respond corresponding to 'some revocation information is unavailable'
> or 'all conditions of the validation policy could not be met'.
> 
> The problem sounds similar to the 'unknown' case of OCSP. Does
> it mean 'temporarily not available, try later', or 'status is not
> available because the cert is not part of the managed CAs.'

However, you don't propose a solution.

One way to fix the problem would be to say:

   3) the server cannot determine the validity of the certificate.
      This condition will occur when a certification path cannot be
      constructed.

In fact what is important for an application is:

a) valid,
b) (definitively) invalid; no need to try later, it will remain invalid,
c) (temporarily) invalid; if you tried later, then it could be valid,
d) no idea whether it is valid, definitively invalid or temporarily invalid: 
   there is not enough information currently available to determine.

Now, translating this into four, three or even two major statuses is 
a matter of taste.

Denis


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g1QAoMF25942 for ietf-pkix-bks; Tue, 26 Feb 2002 02:50:22 -0800 (PST)
Received: from edelweb.fr (edelweb.fr [212.234.46.16]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1QAoJ325938 for <[e-mail]>; Tue, 26 Feb 2002 02:50:20 -0800 (PST)
Received: from champagne.edelweb.fr (localhost.edelweb.fr [127.0.0.1]) by edelweb.fr with ESMTP id LAA14937; Tue, 26 Feb 2002 11:49:08 +0100 (MET)
Received: from champagne.edelweb.fr (champagne.edelweb.fr [193.51.14.161]) by edelweb.fr (nospam/1.3); Tue, 26 Feb 2002 11:49:08 +0100 (MET)
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 LAA26223; Tue, 26 Feb 2002 11:49:06 +0100 (MET)
From: Peter Sylvester <[e-mail]>
Received: (sylvest@localhost) by emeriau.edelweb.fr (8.7.6/8.6.6) id LAA19488; Tue, 26 Feb 2002 11:49:05 +0100 (MET)
Date: Tue, 26 Feb 2002 11:49:05 +0100 (MET)
Message-Id: <[e-mail]>
To: [e-mail], [e-mail]
Subject: Re: "Potentially valid" response state in DPV/DPD rqmts I-D
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>

> 
> The DPV response MAY indicate one of three status alternatives:
> 
>    1) the certificate is valid according to the validation policy.
> 
>    2) the certificate is invalid according to the validation policy. 
>       A secondary status MAY indicate that the certificate is 
>       definitively invalid or potentially valid. 
> 
>       In the former case, if another request was made later on, 
>       the certificate will still be determined as invalid.
> 
>       In the later case, if another request could made later on, 
>       the certificate could possibly be determined as valid. This 
>       condition will occur before a certificate validity period has 
>       begun, while a certificate is suspended, or when, at the time 
>       the server generated the response, all conditions of the 
>       validation policy could not be met.
> 
>    3) the server cannot determine the validity of the certificate.
>       This condition will occur when a certification path cannot be 
>       constructed or some revocation information is unavailable.
> 

Does 3 indicate a temporary or permanent error?

In case of a tempary access problem to a CRl repository, one can
respond corresponding to 'some revocation information is unavailable'
or 'all conditions of the validation policy could not be met'. 

The problem sounds similar to the 'unknown' case of OCSP. Does
it mean 'temporarily not available, try later', or 'status is not
available because the cert is not part of the managed CAs.' 


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g1Q9pH020113 for ietf-pkix-bks; Tue, 26 Feb 2002 01:51:17 -0800 (PST)
Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1Q9pF320109 for <[e-mail]>; Tue, 26 Feb 2002 01:51:15 -0800 (PST)
Received: from lvn-m002.frlv.bull.fr (lvn-m002.frlv.bull.fr [129.184.62.72]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id KAA25132; Tue, 26 Feb 2002 10:52:49 +0100
Received: from bull.net ([129.184.37.97]) by lvn-m002.frlv.bull.fr (Lotus Domino Release 5.0.8) with ESMTP id 2002022610504779:336 ; Tue, 26 Feb 2002 10:50:47 +0100 
Message-ID: <[e-mail]>
Date: Tue, 26 Feb 2002 10:50:47 +0100
From: Denis Pinkas <[e-mail]>
Organization: Integris. A Bull Company
X-Mailer: Mozilla 4.7 [fr] (Win98; I)
X-Accept-Language: fr
MIME-Version: 1.0
To: Michael Myers <[e-mail]>
CC: [e-mail]
Subject: Re: "Potentially valid" response state in DPV/DPD rqmts I-D
References: <[e-mail]>
X-MIMETrack: Itemize by SMTP Server on LVN-M002/FR/BULL(Release 5.0.8 |June 18, 2001) at 26/02/2002 10:50:47, Serialize by Router on LVN-M002/FR/BULL(Release 5.0.8 |June 18, 2001) at 26/02/2002 10:50:58, Serialize complete at 26/02/2002 10:50:58
Content-Transfer-Encoding: 7bit
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>

Michael,

> Denis,

> Thank you for your quick response.  However, I remain convinced
> that the requirement should be eliminated for three reasons.

The matter of the discussion is not to eliminate that state but more 
on how to express that state.

We have experienced this in the past with the suspension state, where we
have not defined a separate state for suspension but defined suspension as a
refinement of "revoked". Suspension has been invented much later that the
revoked state and since most people where only doing real time checking at
that time, there was not difference to be done on the treatment of suspended
or revoked. When validating a signature, this is different.

We could do the same as we do for CRLs, consider only three states, as long
as we allow to discriminate the reason of the "invalid" state, which will
then have a secondary state saying more: definitively invalid and
temporarily invalid.

So I would propose the following fix:

The DPV response MAY indicate one of three status alternatives:

   1) the certificate is valid according to the validation policy.

   2) the certificate is invalid according to the validation policy. 
      A secondary status MAY indicate that the certificate is 
      definitively invalid or potentially valid. 

      In the former case, if another request was made later on, 
      the certificate will still be determined as invalid.

      In the later case, if another request could made later on, 
      the certificate could possibly be determined as valid. This 
      condition will occur before a certificate validity period has 
      begun, while a certificate is suspended, or when, at the time 
      the server generated the response, all conditions of the 
      validation policy could not be met.

   3) the server cannot determine the validity of the certificate.
      This condition will occur when a certification path cannot be 
      constructed or some revocation information is unavailable.

Denis
 
> 1.  Either a certificate is valid in the time context of the
> request or it isn't.
> 
> Conditions for validity are well documented elsewhere. Fail in
> any one and the certificate is, by definition, "not valid".
> We've been working on this for years.  Not so the notion of
> "potentially valid".  The scope of the DPV/DPD requirements
> document should limit itself to that which can be replicated in
> other contexts.  In particular, to my knowledge the notion of a
> separate state of "potentially valid" does not present itself in
> the work of the X.509 group, with whom PKIX' charter is vitally
> linked.
> 
> 2.  At the systems level, this requirement is broke on the face
> of it.  It is ambiguous, open-ended and untestable in practice.
> 
> As such I fear it will lead to non-interoperable
> implementations.  Here's an example:  a certificate could be
> considered "potentially valid" if a server timed out in its
> query to a repository of revocation data simply because that
> data may have shown the certificate not to be revoked.  This can
> go on and on ad nauseum.  And because it is difficult if not
> impossible to exhaustively document such conditions due to the
> requirement's open-endedness, one application's "invalid" could
> be another's "potentially valid".
> 
> 3. The function "try again later and maybe get a different
> response" is already there.
> 
> It's there implicitly.  The app can simply try again, receiving
> a string of "invalid" responses until it receives "valid", or
> just give up.  Which is the same systems-level behavior that
> "potentially valid" would cause with no added value.
> 
> Again, I strongly urge elimination of this requirement prior to
> the WG recommending this document to the IESG.  These online
> certificate status mechanisms we've been working on had at their
> initiation and continue to have as their primary goal the
> simplification of X.509-based PKI while maintaining all the
> security benefits that practice enables.  PKI is already hard
> enough.  Let's not make it even more difficult by inventing new
> concepts at this late date.
> 
> Mike
> 
> Michael Myers
> t: +415.819.1362
> e: mailto:[e-mail]
> w: http://www.traceroutesecurity.com


Received: by above.proper.com (8.11.6/8.11.3) id g1PMChC11351 for ietf-pkix-bks; Mon, 25 Feb 2002 14:12:43 -0800 (PST)
Received: from gateway.secude.com (linux.secude.com [141.12.207.27]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1PMCf311347 for <[e-mail]>; Mon, 25 Feb 2002 14:12:41 -0800 (PST)
Received: from remus.secude.com (remus.intranet.secude.com [192.168.2.2]) by gateway.secude.com (Postfix) with ESMTP id D27E11B999; Mon, 25 Feb 2002 23:12:38 +0100 (CET)
Received: from secude.com (obelix.intranet.secude.com [192.168.1.3]) by remus.secude.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id FFR01BK3; Mon, 25 Feb 2002 23:12:38 +0100
Message-ID: <[e-mail]>
Date: Mon, 25 Feb 2002 23:14:58 +0100
From: Petra Barzin <[e-mail]>
X-Mailer: Mozilla 4.73 [de]C-CCK-MCD DT  (Win95; U)
X-Accept-Language: de
MIME-Version: 1.0
To: Michael Myers <[e-mail]>
Cc: [e-mail]
Subject: Re: "Potentially valid" response state in DPV/DPD rqmts I-D
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>

I also agree with Michael. We are right now working on a so called
PKI server. I took Denis DPV/DPD draft (because I liked it the best
compared to  SCVP, OCSP-V2, RFC3029 and it met most of our
requirements). But we agreed that the response type conditionally valid
will not be supported for the same reasons as stated by Michael.

Petra

Michael Myers schrieb:

> Denis,
>
> Thank you for your quick response.  However, I remain convinced
> that the requirement should be eliminated for three reasons.
>
> 1.  Either a certificate is valid in the time context of the
> request or it isn't.
>
> Conditions for validity are well documented elsewhere. Fail in
> any one and the certificate is, by definition, "not valid".
> We've been working on this for years.  Not so the notion of
> "potentially valid".  The scope of the DPV/DPD requirements
> document should limit itself to that which can be replicated in
> other contexts.  In particular, to my knowledge the notion of a
> separate state of "potentially valid" does not present itself in
> the work of the X.509 group, with whom PKIX' charter is vitally
> linked.
>
> 2.  At the systems level, this requirement is broke on the face
> of it.  It is ambiguous, open-ended and untestable in practice.
>
> As such I fear it will lead to non-interoperable
> implementations.  Here's an example:  a certificate could be
> considered "potentially valid" if a server timed out in its
> query to a repository of revocation data simply because that
> data may have shown the certificate not to be revoked.  This can
> go on and on ad nauseum.  And because it is difficult if not
> impossible to exhaustively document such conditions due to the
> requirement's open-endedness, one application's "invalid" could
> be another's "potentially valid".
>
> 3. The function "try again later and maybe get a different
> response" is already there.
>
> It's there implicitly.  The app can simply try again, receiving
> a string of "invalid" responses until it receives "valid", or
> just give up.  Which is the same systems-level behavior that
> "potentially valid" would cause with no added value.
>
> Again, I strongly urge elimination of this requirement prior to
> the WG recommending this document to the IESG.  These online
> certificate status mechanisms we've been working on had at their
> initiation and continue to have as their primary goal the
> simplification of X.509-based PKI while maintaining all the
> security benefits that practice enables.  PKI is already hard
> enough.  Let's not make it even more difficult by inventing new
> concepts at this late date.
>
> Mike
>
> Michael Myers
> t: +415.819.1362
> e: mailto:[e-mail]
> w: http://www.traceroutesecurity.com



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g1PKTEu08277 for ietf-pkix-bks; Mon, 25 Feb 2002 12:29:14 -0800 (PST)
Received: from wfhqex03.gfgsi.com (netva01.getronicsgov.com [67.105.229.98]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1PKTD308273; Mon, 25 Feb 2002 12:29:13 -0800 (PST)
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0
Subject: v1.3 R8 Enhanced SNACC Freeware Now Available
Date: Mon, 25 Feb 2002 15:29:03 -0500
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: v1.3 R8 Enhanced SNACC Freeware Now Available
Thread-Index: AcG+PAdHt68nl6ieT1mtbbNlAvBOvA==
From: "Pawling, John" <[e-mail]>
To: "ietf-pkix@imc. org (E-mail)" <[e-mail]>, "SMIME WG (E-mail)" <[e-mail]>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id g1PKTD408274
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>

All,

Getronics Government Solutions has delivered the v1.3 R8 Enhanced SNACC
Abstract Syntax Notation One (ASN.1) Compiler, C++ library and C library
source code compilable for Linux, Sun Solaris 2.8 and Microsoft (MS) 
Windows NT/98/2000/XP.  The Enhanced SNACC software is freely available
to everyone from: <http://www.getronicsgov.com/hot/snacc_home.htm>.  The
v1.3 R8 Enhanced SNACC release fixes bugs present in the v1.3 R7
release.
 
The Enhanced SNACC ASN.1 software can be used to ASN.1 encode and decode
objects.  In past releases, Getronics enhanced the original SNACC ASN.1 
C++ library to implement the Distinguished Encoding Rules (DER), support

large ASN.1 INTEGERs, and improve memory usage.    

v1.3 R8 Enhanced SNACC ASN.1 Library enhancements (compared to v1.3 R7):

 1) Fixed bug in processing of BMP strings on UNIX platforms.  

 2) Removed dependencies on SNACC config.h in distributed includes/libs.


 3) Developed a test driver and successfully tested the Enhanced SNACC
C ASN.1 Library.  We corrected bugs in the C Library DER code.  

 4) Corrected bug in sm_vdasnacc.cpp (line 303) regarding setting the
length value for indefinite length decodings. 

 5) Corrected AsnOcts to use inherited CSM_Buffer Length() member
function instead of AsnOcts maintaining it's own length data member.  

 6) Corrected memory management bug in AsnOid::PutChar in asn-oid.cpp.

 7) Tested with v2.0.1 S/MIME Freeware Library (SFL) 
<http://www.getronicsgov.com/hot/sfl_home.htm> that uses the Enhanced
SNACC ASN.1 software to encode and decode the IETF S/MIME v3 
Cryptographic Message Syntax (RFC 2630) and Enhanced Security 
Services for S/MIME (RFC 2634) security protocol.  

 8) Tested with freeware v2.0.1 Certificate Management Library (CML)
<http://www.getronicsgov.com/hot/cml_home.htm> that uses the Enhanced
SNACC ASN.1 software to encode and decode X.509 certificates, 
attribute certificates and Certificate Revocation Lists as specified
in the 2000 X.509 Recommendation.

 9) Tested with freeware v2.0.1 Access Control Library (ACL)
<http://www.getronicsgov.com/hot/acl_home.htm> that uses the Enhanced
SNACC ASN.1 software to encode and decode security labels and other 
objects (such as Security Policy Information Files) required to
provide rule based automated access control as specified in SDN.801.

The aforementioned bug fixes improved the multi-threaded performance
of the Enhanced SNACC ASN.1 C++ Library.

The Enhanced SNACC ASN.1 software implements the majority of the 
ASN.1 encoding/decoding rules as specified in the 1988 X.209 
Recommendation.  It implements the DER as specified in the 1994 
X.690 Recommendation.  It does not support all of the latest ASN.1
features, but there are strategies that allow it to be used to 
produce ASN.1 hex encodings that are identical to those produced by
ASN.1 libraries that do support the latest ASN.1 features.  Also note
that many of the PKIX specs, such as RFC 2459 and RFC 2630, include 
1988-compliant ASN.1 syntax modules which can be compiled using the
Enhanced SNACC compiler.

The Enhanced SNACC ASN.1 library is totally unencumbered as stated 
in the Enhanced SNACC Software Public License.  All source code for
the Enhanced SNACC software is being provided at no cost and with no
financial limitations regarding its use and distribution.  
Organizations can use the Enhanced SNACC software without paying
any royalties or licensing fees.  

The Internet Mail Consortium (IMC) has established an Enhanced SNACC
web page <http://www.imc.org/imc-snacc/>.  The IMC has established 
an Enhanced SNACC mail list which is used to: distribute information 
regarding Enhanced SNACC releases; discuss related issues; and 
provide a means for integrators to provide feedback, comments,
bug reports, etc.  Subscription information for the imc-snacc
mail list is at the IMC web site listed above.

We welcome all feedback regarding the Enhanced SNACC software.
If bugs are reported, then we will investigate each reported
bug and, if required, will produce a patch or an updated
release of the software to repair the bug. 

This release announcement was sent to several mail lists,
but please send all messages regarding the Enhanced SNACC 
software to the imc-snacc mail list ONLY.  Please do not send 
messages regarding the Enhanced SNACC software to any of the 
IETF mail lists.  We will respond to all messages sent to the
imc-snacc mail list.

===========================================
John Pawling, [e-mail]
Getronics Government Solutions, LLC
===========================================


Received: by above.proper.com (8.11.6/8.11.3) id g1PK91607651 for ietf-pkix-bks; Mon, 25 Feb 2002 12:09:01 -0800 (PST)
Received: from vulcan.rsasecurity.com (vulcan.rsasecurity.com [204.167.114.130]) by above.proper.com (8.11.6/8.11.3) with SMTP id g1PK8w307638 for <[e-mail]>; Mon, 25 Feb 2002 12:08:58 -0800 (PST)
Received: from no.name.available by vulcan.rsasecurity.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 25 Feb 2002 20:08:46 UT
Received: from ebola.securitydynamics.com (ebola.securid.com [192.80.211.4]) by sdtihq24.securid.com (Pro-8.9.3/Pro-8.9.3) with ESMTP id PAA17551 for <[e-mail]>; Mon, 25 Feb 2002 15:08:54 -0500 (EST)
Received: from exna00.securitydynamics.com (localhost [127.0.0.1]) by ebola.securitydynamics.com (8.10.2+Sun/8.9.1) with ESMTP id g1PK8wU04473 for <[e-mail]>; Mon, 25 Feb 2002 15:08:58 -0500 (EST)
Received: by exna00.securitydynamics.com with Internet Mail Service (5.5.2653.19) id <F4N5MGVX>; Mon, 25 Feb 2002 15:06:48 -0500
Received: from HOUSLEY-LAP.rsasecurity.com (HOUSLEY-LAP [10.3.1.66]) by exna00.securitydynamics.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id F4N5MGVT; Mon, 25 Feb 2002 15:06:46 -0500
From: "Housley, Russ" <[e-mail]>
To: Hiro <[e-mail]>
Cc: [e-mail]
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Mon, 25 Feb 2002 13:58:10 -0500
Subject: Re: not required to support IDP?
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>

Hiro:

Implementations are not required to support the extension.  However, if a 
CRL issuer chooses to support it, then it must mare it critical.  Thus, any 
client that does not support it will reject the CRL.

Russ


At 10:57 PM 2/20/2002 +0900, Hiro wrote:


>Hi,
>I have one question about Issuing Distribution Point Extension.
>In RFC2459 and draft-ietf-pkix-new-part1-12.txt, about this extension
>
>    "Although the extension is critical, conforming implementations
>     are not required to support this extension."
>
>I cannot understand.
>I think it is not only conflicting with critical flag concept, but also,
>if a CA is issuing CRL/ARL(not complete CRL) and it happen the CRL 
>substitution attack
>on the directory, EE should be find this attack.
>So I think this extension must be supported.
>
>Does anyone answer for this question?
>
>Regard,
>
>
>
>--
>Hiro
>[e-mail]


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g1PIQvd05035 for ietf-pkix-bks; Mon, 25 Feb 2002 10:26:57 -0800 (PST)
Received: from edelweb.fr (edelweb.fr [212.234.46.16]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1PIQt305030 for <[e-mail]>; Mon, 25 Feb 2002 10:26:55 -0800 (PST)
Received: from champagne.edelweb.fr (localhost.edelweb.fr [127.0.0.1]) by edelweb.fr with ESMTP id TAA11753 for <[e-mail]>; Mon, 25 Feb 2002 19:26:55 +0100 (MET)
Received: from champagne.edelweb.fr (champagne.edelweb.fr [193.51.14.161]) by edelweb.fr (nospam/1.3); Mon, 25 Feb 2002 19:26:55 +0100 (MET)
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 TAA23428 for <[e-mail]>; Mon, 25 Feb 2002 19:26:54 +0100 (MET)
From: Peter Sylvester <[e-mail]>
Received: (sylvest@localhost) by emeriau.edelweb.fr (8.7.6/8.6.6) id TAA19183 for [e-mail]; Mon, 25 Feb 2002 19:26:54 +0100 (MET)
Date: Mon, 25 Feb 2002 19:26:54 +0100 (MET)
Message-Id: <[e-mail]>
To: [e-mail]
Subject: Re: agenda topics, WG last call for DPV requirements
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>

There are some comments for DPV that have been ignored.

The last three blocks in chapter 4 talk about security
requirements, but the following two are not mentioned
(unless I miss something).

>
>- Security requirements
>
>   - a method to authenticate a server before sending any request
>     (for example this can be achieved by SSL).
      (Another example would be using encryption.)
>
>   - a method to ensure confidentiality of the transport
>
>   - a method that client and server provide their identity
>     in the requests and responses: 'You, the client X, has
>     asked me, the server Y, the following question, and
>     I, the server Y, with the help of server Z respond.'
This allows to be able to determine the participating entities
without having access to whatever particular authentication 
method information.


The following requirements may be used for example in case of
validation of an encryption certificate before usage.

One may resume the relaying requirements into one: 

- The protocol MUST provide a means to allow (visible) relaying
  of requests and responses. 

>
>- Relaying requirements:
>
>   - depending on policy, a server may just impersonate another
>     server, i.e., take the responses of another server, and create
>     its own reponse out of them.
>
>   - a server should be able to include the response of a relayed
>     server into his response.
>
>   - a server should be able to simple add another authentication
>     scheme to a response from another server (for example by
>     using a second signature or a counter signature.)
>
>   - a server that acts as a relay should be able to tell to the
>     next server that it is acting on behalf of a end user, and
>     the final server should be able to note this in the response.
>
>   - For relaying, the protocol MUST provide an efficient means
>     to detect loops.
>


>
>- Requirements for incomplete answers:
>
>   - a server may indicate an incomplete response,
>     and provide a method to update the response later.
>





Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g1PHLKb03281 for ietf-pkix-bks; Mon, 25 Feb 2002 09:21:20 -0800 (PST)
Received: from geos.coastside.net (mail.coastside.net [207.213.212.6]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1PHLJ303277 for <[e-mail]>; Mon, 25 Feb 2002 09:21:19 -0800 (PST)
Received: from laptop (dsl-63-194-153-52.coastside.net [63.194.153.52]) by geos.coastside.net (8.11.0/8.11.3) with SMTP id g1PHLG619329; Mon, 25 Feb 2002 09:21:16 -0800 (PST)
From: "Michael Myers" <[e-mail]>
To: "Denis Pinkas" <[e-mail]>
Cc: <[e-mail]>
Subject: RE: "Potentially valid" response state in DPV/DPD rqmts I-D
Date: Mon, 25 Feb 2002 09:18:50 -0800
Message-ID: <[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 IMO, Build 9.0.2416 (9.0.2911.0)
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
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>

Denis,

Thank you for your quick response.  However, I remain convinced
that the requirement should be eliminated for three reasons.

1.  Either a certificate is valid in the time context of the
request or it isn't.

Conditions for validity are well documented elsewhere. Fail in
any one and the certificate is, by definition, "not valid".
We've been working on this for years.  Not so the notion of
"potentially valid".  The scope of the DPV/DPD requirements
document should limit itself to that which can be replicated in
other contexts.  In particular, to my knowledge the notion of a
separate state of "potentially valid" does not present itself in
the work of the X.509 group, with whom PKIX' charter is vitally
linked.

2.  At the systems level, this requirement is broke on the face
of it.  It is ambiguous, open-ended and untestable in practice.

As such I fear it will lead to non-interoperable
implementations.  Here's an example:  a certificate could be
considered "potentially valid" if a server timed out in its
query to a repository of revocation data simply because that
data may have shown the certificate not to be revoked.  This can
go on and on ad nauseum.  And because it is difficult if not
impossible to exhaustively document such conditions due to the
requirement's open-endedness, one application's "invalid" could
be another's "potentially valid".

3. The function "try again later and maybe get a different
response" is already there.

It's there implicitly.  The app can simply try again, receiving
a string of "invalid" responses until it receives "valid", or
just give up.  Which is the same systems-level behavior that
"potentially valid" would cause with no added value.


Again, I strongly urge elimination of this requirement prior to
the WG recommending this document to the IESG.  These online
certificate status mechanisms we've been working on had at their
initiation and continue to have as their primary goal the
simplification of X.509-based PKI while maintaining all the
security benefits that practice enables.  PKI is already hard
enough.  Let's not make it even more difficult by inventing new
concepts at this late date.

Mike

Michael Myers
t: +415.819.1362
e: mailto:[e-mail]
w: http://www.traceroutesecurity.com



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g1PEWBo19806 for ietf-pkix-bks; Mon, 25 Feb 2002 06:32:11 -0800 (PST)
Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1PEWA319801 for <[e-mail]>; Mon, 25 Feb 2002 06:32:10 -0800 (PST)
Received: from lvn-m002.frlv.bull.fr (lvn-m002.frlv.bull.fr [129.184.62.72]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id PAA16582; Mon, 25 Feb 2002 15:33:57 +0100
Received: from bull.net ([129.184.37.97]) by lvn-m002.frlv.bull.fr (Lotus Domino Release 5.0.8) with ESMTP id 2002022515313602:274 ; Mon, 25 Feb 2002 15:31:36 +0100 
Message-ID: <[e-mail]>
Date: Mon, 25 Feb 2002 15:31:32 +0100
From: Denis Pinkas <[e-mail]>
Organization: Integris. A Bull Company
X-Mailer: Mozilla 4.7 [fr] (Win98; I)
X-Accept-Language: fr
MIME-Version: 1.0
To: Michael Myers <[e-mail]>
CC: [e-mail]
Subject: Re: "Potentially valid" response state in DPV/DPD rqmts I-D
References: <[e-mail]>
X-MIMETrack: Itemize by SMTP Server on LVN-M002/FR/BULL(Release 5.0.8 |June 18, 2001) at 25/02/2002 15:31:36, Serialize by Router on LVN-M002/FR/BULL(Release 5.0.8 |June 18, 2001) at 25/02/2002 15:32:07, Serialize complete at 25/02/2002 15:32:07
Content-Transfer-Encoding: 7bit
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>

Michael,

> Russ, Denis:
 
> Item #3 of the definition of DPV response status requirements
> states that a server must be able to produce a value indicating:
> 
>    "3) the certificate is not yet valid at this time. If another
>       request could made later on, the certificate could
>       possibly be determined as valid. This condition will occur 
>       before a certificate validity period has begun, while a 
>       certificate is suspended, or when, at the time the server 
>       generated the response, all conditions of the validation 
>       policy could not be met."
> 
> I translate this to a "potentially valid" state vs. the more
> conclusive "valid", "invalid" or "unknown" states.

Fine. We could rename that status: "potentially valid".

> I'm a bit wary of this semantic.  It's not at all clear to me
> how one would define a protocol or write code to comply with
> this requirement.

Some applications can take advantage of that information, 
e.g. by querying again later on. For those that may not take 
advantage of it, they could apply the same treatment as they would 
with "invalid".

Denis

> This requirement should be eliminated.  A certificate is either
> valid or it isn't in the time context of the request.
> 
> Mike


Received: by above.proper.com (8.11.6/8.11.3) id g1PE0in17461 for ietf-pkix-bks; Mon, 25 Feb 2002 06:00:44 -0800 (PST)
Received: from marte.ifxnw.cl (marte.ifxnw.cl [216.241.0.152]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1PE0g317457 for <[e-mail]>; Mon, 25 Feb 2002 06:00:42 -0800 (PST)
Received: from ropazo (unverified [216.241.20.226]) by marte.ifxnw.cl (Rockliffe SMTPRA 3.4.7) with SMTP id <[e-mail]>; Mon, 25 Feb 2002 10:56:27 -0400
From: "Roberto Opazo Gazmuri" <[e-mail]>
To: "Khaja E. Ahmed" <[e-mail]>, "Michael Myers" <[e-mail]>, <[e-mail]>
Subject: RE: "Potentially valid" response state in DPV/DPD rqmts I-D
Date: Mon, 25 Feb 2002 10:50:41 -0300
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-Priority: 1 (Highest)
X-MSMail-Priority: High
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
Importance: High
In-Reply-To: <[e-mail]>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
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>

I agree with eliminating this state.

I think there is a big difference with a certificate that is “still not
valid” with another that is “suspended”. The first one will probably be
valid while the second one is probably going to be invalid.

If not, I would prefer to separate this state.

Roberto

> -----Mensaje original-----
> De: [e-mail] [mailto:[e-mail]]En
> nombre de Khaja E. Ahmed
> Enviado el: sábado, 23 de febrero de 2002 4:27
> Para: Michael Myers; [e-mail]
> Asunto: RE: "Potentially valid" response state in DPV/DPD rqmts I-D
>
>
>
> I am inclined to agree with Michael.  I can see the benefit of
> being able to
> communicate such complex states but in practice this benefit will
> be hard to
> realize and is just the type of thing that causes
> interoperability problems.
> The best thing might be to, as Michaels suggests, drop this requirement.
> The next best thing would be to make it optional - a MAY rather
> than a MUST.
>
> Khaja
>
> > -----Original Message-----
> > From: [e-mail]
> > [mailto:[e-mail]]On Behalf Of Michael Myers
> > Sent: Friday, February 22, 2002 7:30 PM
> > To: [e-mail]
> > Subject: "Potentially valid" response state in DPV/DPD rqmts I-D
> >
> >
> >
> > Russ, Denis:
> >
> > Item #3 of the definition of DPV response status requirements
> > states that a server must be able to produce a value indicating:
> >
> >    "3) the certificate is not yet valid at this time. If another
> >       request could made later on, the certificate could
> > possibly be
> >       determined as valid. This condition will occur before a
> >       certificate validity period has begun, while a certificate
> > is
> >       suspended, or when, at the time the server generated the
> >       response, all conditions of the validation policy could
> > not be
> >       met."
> >
> > I translate this to a "potentially valid" state vs. the more
> > conclusive "valid", "invalid" or "unknown" states.
> >
> > I'm a bit wary of this semantic.  It's not at all clear to me
> > how one would define a protocol or write code to comply with
> > this requirement.
> >
> > This requirement should be eliminated.  A certificate is either
> > valid or it isn't in the time context of the request.
> >
> > Mike
> >



Received: by above.proper.com (8.11.6/8.11.3) id g1PDnvA17234 for ietf-pkix-bks; Mon, 25 Feb 2002 05:49:57 -0800 (PST)
Received: from nebula.x509.com (nebula.x509.com [199.175.150.19]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1PDnp317230 for <[e-mail]>; Mon, 25 Feb 2002 05:49:55 -0800 (PST)
Received: from crack.x509.com (mail.x509.com [199.175.150.1]) by nebula.x509.com (8.11.6/XCERT) with ESMTP id g1PDnYG07635; Mon, 25 Feb 2002 05:49:34 -0800 (PST)
Received: from exna00.securitydynamics.com ([10.100.8.217]) by crack.x509.com (8.11.6/XCERT) with ESMTP id g1PDnVT01131; Mon, 25 Feb 2002 05:49:32 -0800 (PST)
Received: by exna00.securitydynamics.com with Internet Mail Service (5.5.2653.19) id <F3ML6T17>; Mon, 25 Feb 2002 08:47:21 -0500
Received: from HOUSLEY-LAP.rsasecurity.com (HOUSLEY-LAP [10.3.1.74]) by exna00.securitydynamics.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id F3ML6T1Z; Mon, 25 Feb 2002 08:47:17 -0500
From: "Housley, Russ" <[e-mail]>
To: Roberto Opazo Gazmuri <[e-mail]>
Cc: [e-mail], [e-mail], [e-mail]
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Tue, 19 Feb 2002 10:42:03 -0500
Subject: RE: Comment on RFC 2459
In-Reply-To: <[e-mail]>
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>

Roberto:

Many years ago, PKIX rejected the idea of empty issuer distinguished 
names.  This was done for two reasons.  There may be more reasons.  Since 
we found these two compelling, we did not look for any more.

First, CRLs identify revoked certificates using issuer DN and serial 
number.  If the issuer DN is empty, then the CRL processing would have to 
consider issuer alt names, adding undesirable complexity.

Second, S/MIMEv2 encryption identifies the recipient public key using 
issuer DN and serial number.  SMIMEv3 continues to support this convention 
for backward compatibility, and it also supports the use of subject key 
identifiers.  The second approach was added because it is significantly 
shorter than most cases of issuer DN and serial number.

Russ
At 08:09 PM 2/15/2002 -0300, Roberto Opazo Gazmuri wrote:
>Russ,
>
>It is a little detail, but may be you could consider an equivalent treat of
>issuer v/s subject and issuerAltName v/s subjectAltName fields.
>
>In the PI discussion I said than the scope of the new syntax should be for
>subjectAltName and for issuerAltName. I believe this attributes are plenty
>equivalent, not only for their type, but for their purpose.
>
>1.- A certificate has no meaning if you do not know the issuer and the
>subject, so they are both equally critical information.
>
>2.- In practice, naming an entity is equivalent than naming the special type
>of entity that is the issuer.
>
>At this time, it is difficult to imagine a certificate with an empty issuer
>field (as it is with an empty subject field), but I think in the future PI
>could be a better way to name entities when you are not interested in
>building a directory tree. So it could be used for chaining purpose too.
>
>At this time, the only clear is there is no reason to treat in different
>ways issuer and subject fields, to see the future we have some time (I
>hope).
>
>Best regards,
>
>Opazo, Roberto ([e-mail])
>CEO - www.acepta.com
>Certification Authority for Chile
>
>Notes:
>
>Page 19
>The issuer field MUST contain a non-empty distinguished name (DN)
>
>Page 24
>The subject name MAY be carried in the subject field and/or the
>subjectAltName extension.


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g1N7Slb02428 for ietf-pkix-bks; Fri, 22 Feb 2002 23:28:47 -0800 (PST)
Received: from rwcrmhc54.attbi.com (rwcrmhc54.attbi.com [216.148.227.87]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1N7Sk302423 for <[e-mail]>; Fri, 22 Feb 2002 23:28:46 -0800 (PST)
Received: from C707777B ([12.232.94.141]) by rwcrmhc54.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with SMTP id <20020223072836.TBWA1214.rwcrmhc54.attbi.com@C707777B>; Sat, 23 Feb 2002 07:28:36 +0000
From: "Khaja E. Ahmed" <[e-mail]>
To: "Michael Myers" <[e-mail]>, <[e-mail]>
Subject: RE: "Potentially valid" response state in DPV/DPD rqmts I-D
Date: Fri, 22 Feb 2002 23:27:20 -0800
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)
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
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>

I am inclined to agree with Michael.  I can see the benefit of being able to
communicate such complex states but in practice this benefit will be hard to
realize and is just the type of thing that causes interoperability problems.
The best thing might be to, as Michaels suggests, drop this requirement.
The next best thing would be to make it optional - a MAY rather than a MUST.

Khaja

> -----Original Message-----
> From: [e-mail]
> [mailto:[e-mail]]On Behalf Of Michael Myers
> Sent: Friday, February 22, 2002 7:30 PM
> To: [e-mail]
> Subject: "Potentially valid" response state in DPV/DPD rqmts I-D
>
>
>
> Russ, Denis:
>
> Item #3 of the definition of DPV response status requirements
> states that a server must be able to produce a value indicating:
>
>    "3) the certificate is not yet valid at this time. If another
>       request could made later on, the certificate could
> possibly be
>       determined as valid. This condition will occur before a
>       certificate validity period has begun, while a certificate
> is
>       suspended, or when, at the time the server generated the
>       response, all conditions of the validation policy could
> not be
>       met."
>
> I translate this to a "potentially valid" state vs. the more
> conclusive "valid", "invalid" or "unknown" states.
>
> I'm a bit wary of this semantic.  It's not at all clear to me
> how one would define a protocol or write code to comply with
> this requirement.
>
> This requirement should be eliminated.  A certificate is either
> valid or it isn't in the time context of the request.
>
> Mike
>



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g1N3WJr22466 for ietf-pkix-bks; Fri, 22 Feb 2002 19:32:19 -0800 (PST)
Received: from geos.coastside.net (mail.coastside.net [207.213.212.6]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1N3WI322462 for <[e-mail]>; Fri, 22 Feb 2002 19:32:18 -0800 (PST)
Received: from laptop (dsl-63-194-153-52.coastside.net [63.194.153.52]) by geos.coastside.net (8.11.0/8.11.3) with SMTP id g1N3WKS01040 for <[e-mail]>; Fri, 22 Feb 2002 19:32:20 -0800 (PST)
From: "Michael Myers" <[e-mail]>
To: <[e-mail]>
Subject: "Potentially valid" response state in DPV/DPD rqmts I-D
Date: Fri, 22 Feb 2002 19:29:55 -0800
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)
Importance: Normal
In-Reply-To: <[e-mail]>
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
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>

Russ, Denis:

Item #3 of the definition of DPV response status requirements
states that a server must be able to produce a value indicating:

   "3) the certificate is not yet valid at this time. If another
      request could made later on, the certificate could
possibly be
      determined as valid. This condition will occur before a
      certificate validity period has begun, while a certificate
is
      suspended, or when, at the time the server generated the
      response, all conditions of the validation policy could
not be
      met."

I translate this to a "potentially valid" state vs. the more
conclusive "valid", "invalid" or "unknown" states.

I'm a bit wary of this semantic.  It's not at all clear to me
how one would define a protocol or write code to comply with
this requirement.

This requirement should be eliminated.  A certificate is either
valid or it isn't in the time context of the request.

Mike



Received: by above.proper.com (8.11.6/8.11.3) id g1LBUeM05876 for ietf-pkix-bks; Thu, 21 Feb 2002 03:30:40 -0800 (PST)
Received: from gateway.secude.com (linux.secude.com [141.12.207.27]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1LBUd305870 for <[e-mail]>; Thu, 21 Feb 2002 03:30:39 -0800 (PST)
Received: from remus.secude.com (remus.intranet.secude.com [192.168.2.2]) by gateway.secude.com (Postfix) with ESMTP id 51FE61AF7B; Thu, 21 Feb 2002 12:30:33 +0100 (CET)
Received: from secude.com (obelix.intranet.secude.com [192.168.1.3]) by remus.secude.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id FFR0D0J1; Thu, 21 Feb 2002 12:30:32 +0100
Message-ID: <[e-mail]>
Date: Thu, 21 Feb 2002 12:32:48 +0100
From: Petra Barzin <[e-mail]>
X-Mailer: Mozilla 4.73 [de]C-CCK-MCD DT  (Win95; U)
X-Accept-Language: de
MIME-Version: 1.0
To: Stephen Kent <[e-mail]>
Cc: pkix <[e-mail]>
Subject: Re: agenda topics, WG last call for DPV requirements
References: <p0510030bb896d6068fab@[128.89.88.34]>
Content-Type: text/html; 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>

<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
I would like to propose some more requirements to be included
<br>in the DPV/DPD requirements draft:
<p>- a hash of the request MUST be included in the response.
<br>This may allow the client to check if his request was maliciously
<br>modified (if the response is signed) and helps to associate the
<br>response with his request when using connectionless protocols.
<p>- a random number MAY be included in the request.
<br>This allows replay protection when the client has no clock.
<br>The random number doesn't have to be repeated in the response
<br>if the response contains a hash of the request.
<p>- add one more component to a validation policy: algorithm requirements
<br>They identify the minimum key length of the signature key or
<br>untrusted hash- and signature algorithms.
<p>- add another request/response pair to obtain the definition of a
<br>specific, the default or all validation policies defined on the server.
<br>So far only the references of a validation policies can be returned.
<br>But it might be necessary to retrieve the definition of a validation
policy,
<br>too (e.g. for archiving).
<p>- Petra
<p>Stephen Kent schrieb:
<blockquote TYPE=CITE><style type="text/css"><!--
blockquote, dl, ul, ol, li { padding-top: 0 ; padding-bottom: 0 }
 --></style>
Folks,&nbsp;We
are preparing the PKIX WG meeting agenda for March and thus soliciting
requests for slots. Please send requests to both Tim and to me.&nbsp;The
current version of the DPV requirements ID has been posted:&nbsp;(<font face="Courier New"><font color="#000000"><font size=+3>draft-ietf-pkix-dpv-dpd-req-02.txt</font></font></font>)&nbsp;This
version reflects changes based on comments since the last IETF meeting,
where we announced that the document would go to WG last call.&nbsp; So,
let's begin the last call process today, and complete it by Monday, March
4.&nbsp;Thanks,&nbsp;Steve</blockquote>
</html>



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g1KNMCD20648 for ietf-pkix-bks; Wed, 20 Feb 2002 15:22:12 -0800 (PST)
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 g1KNMB320644 for <[e-mail]>; Wed, 20 Feb 2002 15:22:11 -0800 (PST)
Received: from CONVERSION-DAEMON by ext-mail.valicert.com (PMDF V5.2-33 #46613) id <[e-mail]> for [e-mail]; Wed, 20 Feb 2002 15:22:13 -0800 (PST)
Received: from polaris.valicert.com ([192.168.2.34]) by ext-mail.valicert.com (PMDF V5.2-33 #46613) with ESMTP id <[e-mail]>; Wed, 20 Feb 2002 15:22:13 -0800 (PST)
Received: by exchange.valicert.com with Internet Mail Service (5.5.2653.19) id <FHF3D89A>; Wed, 20 Feb 2002 15:22:08 -0800
Content-return: allowed
Date: Wed, 20 Feb 2002 15:21:57 -0800
From: Peter Williams <[e-mail]>
Subject: RE: not required to support IDP?
To: "'David A. Cooper'" <[e-mail]>, [e-mail]
Message-id: <[e-mail]>
MIME-version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-type: text/plain
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>

Summary

Side issue for the unwary, for IDPs or CRLs or OCSP
or ORACLE responses, and the distinction between revocation 
information and revocation notice

-------

For those embroiled in IP and legal matters concerning validity, 
one can note that a CA that DOES NOT issue a CRL/DP DOES NOT
issue/perform X.509 "revocation *notice*", by definition.

Similarly, only when an OCSP responder provides a 
reading-service for a CRL on which a particular revocation 
notice is first posted can an OCSP responder (under policy) be 
said to be *publishing* that revocation notice. In no
sense does the mere act by a CA of delegating authority to
an OCSP responder mean that an OCSP responder 
response performs the act of publishing an 
X.509 revocation notice. The same limitation
is true for an ORACLE database Repository 
controlled by a CA.

Relying on an OCSP or ORACLE responder to help verify a 
claimed-legal signature without very carefully reading and vetting
the validation policy of the Repository is not a 
reasonable thing to do. Sadly, the Internet's
PKI repositories mostly all make false claims about
their status as an "X.509 compliant" means for 
publishing revocation notice.


-----Original Message-----
From: David A. Cooper [mailto:[e-mail]]
Sent: Wednesday, February 20, 2002 2:12 PM
To: [e-mail]
Subject: RE: not required to support IDP?



Simon,

I agree that PKIX did not mean to suggest that one could CRL containing a
critical IDP extension even if you can not process the extension. PKIX is
simply saying that you are not required to have the ability to process the
extension, even though this will mean that you may have to reject some CRLs.

However, X.509 does not require that a CA issue full CRLs. If this
requirement did appear in X.509 (1997), it has been removed in X.509 (2000).
In fact, X.509 makes clear that CAs may choose not to issue CRLs at all.
Either because they to not revoke certificates or because they only publish
revocation information using some other mechanism (e.g., OCSP).

So, an X.509 compliant CA could issue only partitioned CRLs, in which case a
relying party that could not process the IDP extension would be unable to
obtain revocation information.

Dave

At 04:53 PM 2/20/02 +0100, Simon Tardell wrote:

>Hi Hiro,
>
>Of course, whatever extension is critical that you don't understand,
>must cause you to reject the CRL. However, according to X.509(97) 12.6.1
>f) a complete CRL shall always be issued, even if partitioned CRLs are
>also issued. That means that you don't have to support partitioned CRLs,
>since there is always (if the CA is X.509 compliant) a complete CRL to
>get. For many applications, partitioning CRLs may not even be the best
>answer to the problem you try to solve (depending on the problem of
>course).
>
>Simon
>
>Simon Tardell, Software Architect, SmartTrust
>voice [phone], fax [phone]
>cell [phone], [e-mail]
>
>
> > -----Original Message-----
> > From: Hiro [mailto:[e-mail]] 
> > Sent: den 20 februari 2002 14:57
> > To: [e-mail]
> > Subject: not required to support IDP?
> > 
> > 
> > 
> > 
> > Hi,
> > I have one question about Issuing Distribution Point 
> > Extension. In RFC2459 and draft-ietf-pkix-new-part1-12.txt, 
> > about this extension
> > 
> >     "Although the extension is critical, conforming implementations
> >      are not required to support this extension."
> > 
> > I cannot understand.
> > I think it is not only conflicting with critical flag 
> > concept, but also, if a CA is issuing CRL/ARL(not complete 
> > CRL) and it happen the CRL 
> > substitution attack
> > on the directory, EE should be find this attack.
> > So I think this extension must be supported.
> > 
> > Does anyone answer for this question?
> > 
> > Regard,
> > 
> > 
> > 
> > --
> > Hiro
> > [e-mail]



Received: by above.proper.com (8.11.6/8.11.3) id g1KMCTi18989 for ietf-pkix-bks; Wed, 20 Feb 2002 14:12:29 -0800 (PST)
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 g1KMCS318983 for <[e-mail]>; Wed, 20 Feb 2002 14:12:28 -0800 (PST)
Received: from krdp2 (krdp2.ncsl.nist.gov [129.6.54.107]) by email.nist.gov (8.12.2/8.12.2) with ESMTP id g1KMCTCr029532 for <[e-mail]>; Wed, 20 Feb 2002 17:12:29 -0500 (EST)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 
Date: Wed, 20 Feb 2002 17:11:53 -0500
To: [e-mail]
From: "David A. Cooper" <[e-mail]>
Subject: RE: not required to support IDP?
In-Reply-To: <[e-mail] m>
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>

Simon,

I agree that PKIX did not mean to suggest that one could CRL containing a critical IDP extension even if you can not process the extension. PKIX is simply saying that you are not required to have the ability to process the extension, even though this will mean that you may have to reject some CRLs.

However, X.509 does not require that a CA issue full CRLs. If this requirement did appear in X.509 (1997), it has been removed in X.509 (2000). In fact, X.509 makes clear that CAs may choose not to issue CRLs at all. Either because they to not revoke certificates or because they only publish revocation information using some other mechanism (e.g., OCSP).

So, an X.509 compliant CA could issue only partitioned CRLs, in which case a relying party that could not process the IDP extension would be unable to obtain revocation information.

Dave

At 04:53 PM 2/20/02 +0100, Simon Tardell wrote:

>Hi Hiro,
>
>Of course, whatever extension is critical that you don't understand,
>must cause you to reject the CRL. However, according to X.509(97) 12.6.1
>f) a complete CRL shall always be issued, even if partitioned CRLs are
>also issued. That means that you don't have to support partitioned CRLs,
>since there is always (if the CA is X.509 compliant) a complete CRL to
>get. For many applications, partitioning CRLs may not even be the best
>answer to the problem you try to solve (depending on the problem of
>course).
>
>Simon
>
>Simon Tardell, Software Architect, SmartTrust
>voice [phone], fax [phone]
>cell [phone], [e-mail]
>
>
> > -----Original Message-----
> > From: Hiro [mailto:[e-mail]] 
> > Sent: den 20 februari 2002 14:57
> > To: [e-mail]
> > Subject: not required to support IDP?
> > 
> > 
> > 
> > 
> > Hi,
> > I have one question about Issuing Distribution Point 
> > Extension. In RFC2459 and draft-ietf-pkix-new-part1-12.txt, 
> > about this extension
> > 
> >     "Although the extension is critical, conforming implementations
> >      are not required to support this extension."
> > 
> > I cannot understand.
> > I think it is not only conflicting with critical flag 
> > concept, but also, if a CA is issuing CRL/ARL(not complete 
> > CRL) and it happen the CRL 
> > substitution attack
> > on the directory, EE should be find this attack.
> > So I think this extension must be supported.
> > 
> > Does anyone answer for this question?
> > 
> > Regard,
> > 
> > 
> > 
> > --
> > Hiro
> > [e-mail]




Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g1KM1nK18595 for ietf-pkix-bks; Wed, 20 Feb 2002 14:01:49 -0800 (PST)
Received: from mailout11.sul.t-online.com (mailout11.sul.t-online.com [194.25.134.85]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1KM1l318591 for <[e-mail]>; Wed, 20 Feb 2002 14:01:47 -0800 (PST)
Received: from fwd01.sul.t-online.de  by mailout11.sul.t-online.com with smtp  id 16deiA-000657-0B; Wed, 20 Feb 2002 22:55:38 +0100
Received: from junker.stroeder.com (520010731148-0001@[217.1.21.231]) by fmrl01.sul.t-online.com with esmtp id 16dei7-15Ta4mC; Wed, 20 Feb 2002 22:55:35 +0100
Received: from stroeder.com (junker [127.0.0.1]) by junker.stroeder.com (Postfix) with ESMTP id 1C512157FF2 for <[e-mail]>; Wed, 20 Feb 2002 22:55:00 +0100 (CET)
Message-ID: <[e-mail]>
Date: Wed, 20 Feb 2002 22:55:00 +0100
From: Michael =?iso-8859-1?Q?Str=F6der?= <[e-mail]>
Reply-To: [e-mail]
Organization: stroeder.com
X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.4.17 i686)
X-Accept-Language: de-DE, de, en
MIME-Version: 1.0
Cc: [e-mail]
Subject: Re: Candidate for moving OCSP to a Draft Standard
References: <[e-mail]> <[e-mail]>
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>

"David P. Kemp" wrote:
> 
> A bank or someone with money at stake on certificate validation can be
> assumed to have a clock in sync with the rest of the world

The bank itself, yes. But not every client. There are always two
ends.

> That is my point, that CRLs *are* consulting the central server
> directly,
> using fewer bytes than with an Oracle replication process, an http or
> OCSP
> query, or any other general-purpose back-end mechanism you might
> suggest.
> If you don't like 15 minute delay, then make it a 15 second delay, or
> one second. The CA can certainly generate one delta CRL every second and
> transmit (or multicast) it to 5000 OCSP responders using less resources
> than it would take to update the same 5000 responders within one second
> using some other mechanism.

You're certainly right that distributing CRLs is kind of a secured
replication mechanism and I would concur that it's less data bloat
than some other DB access protocols.

But since a CRL has to be signed by the CA's private key it depends
very much on the (physical) protection of the private key how fast
you can issue a new CRL after getting knowledge about that a
certificate must be revoked.

Ciao, Michael.


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g1KLtuf18454 for ietf-pkix-bks; Wed, 20 Feb 2002 13:55:56 -0800 (PST)
Received: from mailout05.sul.t-online.com (mailout05.sul.t-online.com [194.25.134.82]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1KLts318450 for <[e-mail]>; Wed, 20 Feb 2002 13:55:54 -0800 (PST)
Received: from fwd00.sul.t-online.de  by mailout05.sul.t-online.com with smtp  id 16deiN-0002Un-02; Wed, 20 Feb 2002 22:55:51 +0100
Received: from junker.stroeder.com (520010731148-0001@[217.1.21.231]) by fmrl00.sul.t-online.com with esmtp id 16dei7-06M35EC; Wed, 20 Feb 2002 22:55:35 +0100
Received: from stroeder.com (junker [127.0.0.1]) by junker.stroeder.com (Postfix) with ESMTP id 29240157FF3 for <[e-mail]>; Wed, 20 Feb 2002 22:55:24 +0100 (CET)
Message-ID: <[e-mail]>
Date: Wed, 20 Feb 2002 22:55:23 +0100
From: Michael =?iso-8859-1?Q?Str=F6der?= <[e-mail]>
Reply-To: [e-mail]
Organization: stroeder.com
X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.4.17 i686)
X-Accept-Language: de-DE, de, en
MIME-Version: 1.0
Cc: [e-mail]
Subject: Re: Candidate for moving OCSP to a Draft Standard
References: <[e-mail]>
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>

Florian Oelmaier wrote:
> 
> Having a setup like 10 Sub-CAs, each certifying 1000 servers for SSL or
> 1.000.000 users for S/MIME, this will easily result in 30.000 OCSP-req/min
> per Sub-CA. This means that in the course of the chain-validation, the
> root-Responder will get 5.000 OCSP-requests per second. Given that I will
> place the root-Responder in a specially secured network-envirmonment these
> figures will make caching/pre-computed responses an issue. Within this
> scenario the possiblity of a client to disallow caching at the responder
> (with sending a nonce that MUST be answered) is a network and production
> problem.

If I understand you correctly one could rephrase the last sentence
to ".. enables the OCSP client to easily launch a DoS attack".

Ciao, Michael.


Received: by above.proper.com (8.11.6/8.11.3) id g1KFrag08489 for ietf-pkix-bks; Wed, 20 Feb 2002 07:53:36 -0800 (PST)
Received: from mail.smarttrust.com ([213.212.5.232]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1KFrZ308485 for <[e-mail]>; Wed, 20 Feb 2002 07:53:35 -0800 (PST)
Received: from sek43.smarttrust.com ([172.16.0.43]) by mail.smarttrust.com with Microsoft SMTPSVC(5.0.2195.2966); Wed, 20 Feb 2002 16:53:20 +0100
X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Subject: RE: not required to support IDP?
Date: Wed, 20 Feb 2002 16:53:09 +0100
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: not required to support IDP?
Thread-Index: AcG6HTSK5MC1a642QIuY63szAZWTRgAABy+A
From: "Simon Tardell" <[e-mail]>
To: "Hiro" <[e-mail]>, <[e-mail]>
X-OriginalArrivalTime: 20 Feb 2002 15:53:20.0835 (UTC) FILETIME=[B866C130:01C1BA26]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id g1KFra308486
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>

Hi Hiro,

Of course, whatever extension is critical that you don't understand,
must cause you to reject the CRL. However, according to X.509(97) 12.6.1
f) a complete CRL shall always be issued, even if partitioned CRLs are
also issued. That means that you don't have to support partitioned CRLs,
since there is always (if the CA is X.509 compliant) a complete CRL to
get. For many applications, partitioning CRLs may not even be the best
answer to the problem you try to solve (depending on the problem of
course).

Simon

Simon Tardell, Software Architect, SmartTrust
voice [phone], fax [phone]
cell [phone], [e-mail]


> -----Original Message-----
> From: Hiro [mailto:[e-mail]] 
> Sent: den 20 februari 2002 14:57
> To: [e-mail]
> Subject: not required to support IDP?
> 
> 
> 
> 
> Hi,
> I have one question about Issuing Distribution Point 
> Extension. In RFC2459 and draft-ietf-pkix-new-part1-12.txt, 
> about this extension
> 
>     "Although the extension is critical, conforming implementations
>      are not required to support this extension."
> 
> I cannot understand.
> I think it is not only conflicting with critical flag 
> concept, but also, if a CA is issuing CRL/ARL(not complete 
> CRL) and it happen the CRL 
> substitution attack
> on the directory, EE should be find this attack.
> So I think this extension must be supported.
> 
> Does anyone answer for this question?
> 
> Regard,
> 
> 
> 
> --
> Hiro
> [e-mail]
> 
> 
> 


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g1KDvLo01879 for ietf-pkix-bks; Wed, 20 Feb 2002 05:57:21 -0800 (PST)
Received: from iscan02.secomtrust.net (iscan02.secomtrust.net [61.114.177.103]) by above.proper.com (8.11.6/8.11.3) with SMTP id g1KDvH301868 for <[e-mail]>; Wed, 20 Feb 2002 05:57:18 -0800 (PST)
Received: (qmail 9822 invoked by alias); 20 Feb 2002 13:57:08 -0000
Delivered-To: [e-mail]@MAP
Received: (qmail 9814 invoked by alias); 20 Feb 2002 13:57:07 -0000
Received: from localhost (HELO mail.secomtrust.net) (127.0.0.1) by localhost with SMTP; 20 Feb 2002 13:57:07 -0000
Received: (qmail 5340 invoked from network); 20 Feb 2002 13:57:06 -0000
Received: from unknown (HELO bon4pc.secomtrust.net) (172.30.5.32) by mail with SMTP; 20 Feb 2002 13:57:06 -0000
Message-Id: <[e-mail]>
X-Sender: [e-mail] (Unverified)
X-Mailer: QUALCOMM Windows Eudora Version 5.0.2-Jr2
Date: Wed, 20 Feb 2002 22:57:05 +0900
To: [e-mail]
From: Hiro <[e-mail]>
Subject: not required to support IDP?
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>

Hi,
I have one question about Issuing Distribution Point Extension.
In RFC2459 and draft-ietf-pkix-new-part1-12.txt, about this extension

    "Although the extension is critical, conforming implementations
     are not required to support this extension."

I cannot understand.
I think it is not only conflicting with critical flag concept, but also,
if a CA is issuing CRL/ARL(not complete CRL) and it happen the CRL 
substitution attack
on the directory, EE should be find this attack.
So I think this extension must be supported.

Does anyone answer for this question?

Regard,



--
Hiro
[e-mail]




Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g1JFBER27374 for ietf-pkix-bks; Tue, 19 Feb 2002 07:11:14 -0800 (PST)
Received: from mtiwmhc22.worldnet.att.net (mtiwmhc22.worldnet.att.net [204.127.131.47]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1JFBC327370 for <[e-mail]>; Tue, 19 Feb 2002 07:11:12 -0800 (PST)
Received: from tsg1 ([12.81.87.169]) by mtiwmhc22.worldnet.att.net (InterMail vM.4.01.03.27 201-229-121-127-20010626) with SMTP id <20020219151107.UTWH11755.mtiwmhc22.worldnet.att.net@tsg1>; Tue, 19 Feb 2002 15:11:07 +0000
Message-ID: <005a01c1b957$a42fe4a0$020aff0c@tsg1>
From: "todd glassey" <[e-mail]>
To: "Denis Pinkas" <[e-mail]>, "LISTS - IETF-PKIX" <[e-mail]>
References: <[e-mail]>
Subject: Re: Policy requirements for Time-Stamping Authorities
Date: Tue, 19 Feb 2002 07:10:59 -0800
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 6.00.2600.0000
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
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>

Denis - this needs to really be signed off on by the auditors not by us
techies. The PKIX-WG  is way out of its league here .

----- Original Message -----
From: "Denis Pinkas" <[e-mail]>
To: "pkix" <[e-mail]>
Sent: Monday, February 18, 2002 6:46 AM
Subject: Policy requirements for Time-Stamping Authorities


>
>
> ETSI has made available the document advertised at the last IETF meeting
> about : "Policy requirements for Time-Stamping Authorities".
>
> It is an exact copy of the document that will be officially published
> as soon as CWA 14167 (which is referenced in this document) becomes
> available.
>
> It can be found at http://portal.etsi.org/sec/ts_102023v010101p.pdf
>
> It is intended have a technical equivalent of this document

No - it should be submitted as a BCP - That's what it is.

> in the form of an Informational RFC.
>
> Denis



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g1IN2hb06170 for ietf-pkix-bks; Mon, 18 Feb 2002 15:02:43 -0800 (PST)
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 g1IN2f306166 for <[e-mail]>; Mon, 18 Feb 2002 15:02:41 -0800 (PST)
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 RAA15856; Mon, 18 Feb 2002 17:59:26 -0500
Received: from d01ml062.pok.ibm.com (d01ml062.pok.ibm.com [9.117.250.163]) by northrelay02.pok.ibm.com (8.11.1m3/NCO/VER6.00) with ESMTP id g1IN2ZC173148; Mon, 18 Feb 2002 18:02:35 -0500
Importance: Normal
Sensitivity: 
Subject: Re: I-D ACTION:draft-ietf-pkix-pi-03.txt
To: Peter Sylvester <[e-mail]>
Cc: [e-mail]
X-Mailer: Lotus Notes Release 5.0.7  March 21, 2001
Message-ID: <[e-mail]>
From: "Tom Gindin" <[e-mail]>
Date: Mon, 18 Feb 2002 18:02:26 -0500
X-MIMETrack: Serialize by Router on D01ML062/01/M/IBM(Release 5.0.9 |November 26, 2001) at 02/18/2002 06:02:37 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>

      Peter:

      If PI is adopted without a constraint format, it will not be the only
name form of GeneralName which does not have a NameConstraint format
specified.  RFC 2459 specifies NameConstraints for URI, DNS, DN, EMail, and
IP but not for X400, EDI, or OID (they mention two of the three at the
bottom of 4.2.1.11, along with OtherName).  The same thing is true of
new-part1.
      I should state, despite the above, that I am working on a constraint
format for PI's, which I hope to post shortly, but I am not certain whether
it is more appropriate as a NameConstraint or as an independent extension.

            Tom Gindin


Peter Sylvester <[e-mail]>@mail.imc.org on 02/18/2002
06:02:43 AM

Sent by:    [e-mail]


To:    [e-mail]
cc:
Subject:    Re: I-D ACTION:draft-ietf-pkix-pi-03.txt



Hi,

The proposal does not specify rules for Name Constraints of
this name form.

The proposal extends the 'equivalence' of certificates
I am not sure whether it is necessary to allow/restrict the
usage of PIs, in particular global ones.

Peter
PS: This comment MUST NOT be regarded as a statement in favour or
against the concept of permanent identifiers.






Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g1IHVxX29159 for ietf-pkix-bks; Mon, 18 Feb 2002 09:31:59 -0800 (PST)
Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1IHVv329154 for <[e-mail]>; Mon, 18 Feb 2002 09:31:57 -0800 (PST)
Received: from lvn-m002.frlv.bull.fr (lvn-m002.frlv.bull.fr [129.184.62.72]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id SAA18798 for <[e-mail]>; Mon, 18 Feb 2002 18:33:42 +0100
Received: from bull.net ([129.184.37.97]) by lvn-m002.frlv.bull.fr (Lotus Domino Release 5.0.8) with ESMTP id 2002021818313374:230 ; Mon, 18 Feb 2002 18:31:33 +0100 
Message-ID: <[e-mail]>
Date: Mon, 18 Feb 2002 18:31:33 +0100
From: Denis Pinkas <[e-mail]>
Organization: Integris. A Bull Company
X-Mailer: Mozilla 4.7 [fr] (Win98; I)
X-Accept-Language: fr
MIME-Version: 1.0
To: pkix <[e-mail]>
Subject: Re: Progression of RFC 3161 (TSP) to Draft Standard
References: <[e-mail]> <[e-mail]>
X-MIMETrack: Itemize by SMTP Server on LVN-M002/FR/BULL(Release 5.0.8 |June 18, 2001) at 18/02/2002 18:31:33, Serialize by Router on LVN-M002/FR/BULL(Release 5.0.8 |June 18, 2001) at 18/02/2002 18:31:59, Serialize complete at 18/02/2002 18:31:59
Content-Transfer-Encoding: 7bit
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>

Sorry, the previous message, with its attachement, was not intended to the
whole PKIX mailing list.

Denis
 
> To the two PKIX co-chairs (Steve and Tim) and to the list of
> TSP implementors.
> 
> Some tests have been performed but, until now, I have not seen a
> "documentation about testing of the interoperation of these implementations"
> as RFC 2026 mentions.
> 
> RFC 2026 also states:
> 
>    The Working Group chair is responsible for documenting the specific
>    implementations which qualify the specification for Draft or Internet
>    Standard status along with documentation about testing of the
>    interoperation of these implementations.
> 
> So while, as the lead editor, I am not responsible, I would like to give an
> help to Tim and Steve.
> 
> :-)
> 
> You will find attached a document in two parts:
> 
> In the first part I have copied ans pasted the relevant parts of RFC 2026.
> 
> In the second part, I have taken my scissors and placed in a first section
> all the SHALL, REQUIRED, MUST and SHOULD that are relevant to a client and
> then in a second section all the SHALL, REQUIRED, MUST and SHOULD that are
> relevant to a server.
> 
> For every SHALL, REQUIRED, MUST and SHOULD, I have placed a number between
> brackets.
> 
> So, unless your documentation is already written, I would suggest to build a
> table using these numbers and say how you passed the each test.
> 
> There are only a few weeks until the next IETF meeting.
> 
> Denis


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g1IGp7v28347 for ietf-pkix-bks; Mon, 18 Feb 2002 08:51:07 -0800 (PST)
Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1IGol328332 for <[e-mail]>; Mon, 18 Feb 2002 08:50:47 -0800 (PST)
Received: from lvn-m002.frlv.bull.fr (lvn-m002.frlv.bull.fr [129.184.62.72]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id RAA20470; Mon, 18 Feb 2002 17:51:05 +0100
Received: from bull.net ([129.184.37.97]) by lvn-m002.frlv.bull.fr (Lotus Domino Release 5.0.8) with ESMTP id 2002021817491628:226 ; Mon, 18 Feb 2002 17:49:16 +0100 
Message-ID: <[e-mail]>
Date: Mon, 18 Feb 2002 17:49:15 +0100
From: Denis Pinkas <[e-mail]>
Organization: Integris. A Bull Company
X-Mailer: Mozilla 4.7 [fr] (Win98; I)
X-Accept-Language: fr
MIME-Version: 1.0
To: [e-mail], [e-mail], [e-mail], [e-mail], [e-mail], [e-mail], [e-mail], [e-mail], pkix <[e-mail]>, Tim Polk <[e-mail]>, Stephen Kent <[e-mail]>
Subject: Re: Progression of RFC 3161 (TSP) to Draft Standard
References: <[e-mail]>
X-MIMETrack: Itemize by SMTP Server on LVN-M002/FR/BULL(Release 5.0.8 |June 18, 2001) at 18/02/2002 17:49:16, Serialize by Router on LVN-M002/FR/BULL(Release 5.0.8 |June 18, 2001) at 18/02/2002 17:49:52
Content-Type: multipart/mixed; boundary="------------DEBC19282E4CC72BCBD4EA5E"
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>

--------------DEBC19282E4CC72BCBD4EA5E
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=us-ascii

To the two PKIX co-chairs (Steve and Tim) and to the list of 
TSP implementors.

Some tests have been performed but, until now, I have not seen a
"documentation about testing of the interoperation of these implementations"
as RFC 2026 mentions.

RFC 2026 also states:

   The Working Group chair is responsible for documenting the specific
   implementations which qualify the specification for Draft or Internet
   Standard status along with documentation about testing of the
   interoperation of these implementations.  

So while, as the lead editor, I am not responsible, I would like to give an
help to Tim and Steve.

:-)

You will find attached a document in two parts:

In the first part I have copied ans pasted the relevant parts of RFC 2026.

In the second part, I have taken my scissors and placed in a first section
all the SHALL, REQUIRED, MUST and SHOULD that are relevant to a client and
then in a second section all the SHALL, REQUIRED, MUST and SHOULD that are
relevant to a server.

For every SHALL, REQUIRED, MUST and SHOULD, I have placed a number between
brackets.

So, unless your documentation is already written, I would suggest to build a
table using these numbers and say how you passed the each test.

There are only a few weeks until the next IETF meeting.

Denis
--------------DEBC19282E4CC72BCBD4EA5E
Content-Type: application/msword;
 name="rfc3161 interop testing.doc"
Content-Disposition: inline;
 filename="rfc3161 interop testing.doc"
Content-Transfer-Encoding: base64

0M8R4KGxGuEAAAAAAAAAAAAAAAAAAAAAPgADAP7/CQAGAAAAAAAAAAAAAAABAAAAXgAAAAAAAAAA
EAAAYAAAAAEAAAD+////AAAAAF0AAAD/////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
///////////////////////////////////////////////////////////////////////////s
pcEAcQAMBAAAABK/AAAAAAAAEAAAAAAABAAA1EwAAA4AYmpianQrdCsAAAAAAAAAAAAAAAAAAAAA
AAAMBBYALoIAABZBAQAWQQEA1EgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD//w8AAAAA
AAAAAAD//w8AAAAAAAAAAAD//w8AAAAAAAAAAAAAAAAAAAAAAF0AAAAAANYAAAAAAAAA1gAAANYA
AAAAAAAA1gAAAAAAAADWAAAAAAAAANYAAAAAAAAA1gAAABQAAAAAAAAAAAAAAOoAAAAAAAAA6gAA
AAAAAADqAAAAAAAAAOoAAAAAAAAA6gAAADQAAAAeAQAAfAAAAOoAAAAAAAAAtREAADIBAADqAQAA
oAMAAIoFAAAAAAAAigUAAAAAAACKBQAAAAAAAIoFAAAAAAAAigUAAAAAAACKBQAAAAAAAIoFAAAA
AAAAehEAAAIAAAB8EQAAAAAAAHwRAAAAAAAAfBEAAAAAAAB8EQAAAAAAAHwRAAAAAAAAfBEAACQA
AADnEgAA9AEAANsUAACCAAAAoBEAABUAAAAAAAAAAAAAAAAAAAAAAAAA1gAAAAAAAACKBQAAAAAA
AAAAAAAAAAAAAAAAAAAAAACKBQAAAAAAAIoFAAAAAAAAigUAAAAAAACKBQAAAAAAAKARAAAAAAAA
uAsAAAAAAADWAAAAAAAAANYAAAAAAAAAigUAAAAAAAAAAAAAAAAAAIoFAAAAAAAAxgEAACQAAAC4
CwAAAAAAALgLAAAAAAAAuAsAAAAAAACKBQAALgYAANYAAAAAAAAAigUAAAAAAADWAAAAAAAAAIoF
AAAAAAAAehEAAAAAAAAAAAAAAAAAAAAAAAAAAAAA6gAAAAAAAADqAAAAAAAAANYAAAAAAAAA1gAA
AAAAAADWAAAAAAAAANYAAAAAAAAAigUAAAAAAAB6EQAAAAAAALgLAADCBQAAuAsAAAAAAAAAAAAA
AAAAAHoRAAAAAAAA1gAAAAAAAADWAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAehEAAAAAAACKBQAAAAAAAJoBAAAsAAAAoEzelZu4
wQHqAAAAAAAAAOoAAAAAAAAAuAsAAAAAAAB6EQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADQ1F
eHRyYWN0IGZyb206DQ1SRkMgMjAyNiBJbnRlcm5ldCBTdGFuZGFyZHMgUHJvY2VzcyAoQmVzdCBD
dXJyZW50IFByYWN0aWNlKSBPY3RvYmVyIDE5OTYNDTQuMS4yICBEcmFmdCBTdGFuZGFyZA0NICAg
QSBzcGVjaWZpY2F0aW9uIGZyb20gd2hpY2ggYXQgbGVhc3QgdHdvIGluZGVwZW5kZW50IGFuZCBp
bnRlcm9wZXJhYmxlDSAgIGltcGxlbWVudGF0aW9ucyBmcm9tIGRpZmZlcmVudCBjb2RlIGJhc2Vz
IGhhdmUgYmVlbiBkZXZlbG9wZWQsIGFuZA0gICBmb3Igd2hpY2ggc3VmZmljaWVudCBzdWNjZXNz
ZnVsIG9wZXJhdGlvbmFsIGV4cGVyaWVuY2UgaGFzIGJlZW4NICAgb2J0YWluZWQsIG1heSBiZSBl
bGV2YXRlZCB0byB0aGUgIkRyYWZ0IFN0YW5kYXJkIiBsZXZlbC4gIEZvciB0aGUNICAgcHVycG9z
ZXMgb2YgdGhpcyBzZWN0aW9uLCAiaW50ZXJvcGVyYWJsZSIgbWVhbnMgdG8gYmUgZnVuY3Rpb25h
bGx5DSAgIGVxdWl2YWxlbnQgb3IgaW50ZXJjaGFuZ2VhYmxlIGNvbXBvbmVudHMgb2YgdGhlIHN5
c3RlbSBvciBwcm9jZXNzIGluDSAgIHdoaWNoIHRoZXkgYXJlIHVzZWQuICBJZiBwYXRlbnRlZCBv
ciBvdGhlcndpc2UgY29udHJvbGxlZCB0ZWNobm9sb2d5DSAgIGlzIHJlcXVpcmVkIGZvciBpbXBs
ZW1lbnRhdGlvbiwgdGhlIHNlcGFyYXRlIGltcGxlbWVudGF0aW9ucyBtdXN0DSAgIGFsc28gaGF2
ZSByZXN1bHRlZCBmcm9tIHNlcGFyYXRlIGV4ZXJjaXNlIG9mIHRoZSBsaWNlbnNpbmcgcHJvY2Vz
cy4NICAgRWxldmF0aW9uIHRvIERyYWZ0IFN0YW5kYXJkIGlzIGEgbWFqb3IgYWR2YW5jZSBpbiBz
dGF0dXMsIGluZGljYXRpbmcNICAgYSBzdHJvbmcgYmVsaWVmIHRoYXQgdGhlIHNwZWNpZmljYXRp
b24gaXMgbWF0dXJlIGFuZCB3aWxsIGJlIHVzZWZ1bC4NDSAgIFRoZSByZXF1aXJlbWVudCBmb3Ig
YXQgbGVhc3QgdHdvIGluZGVwZW5kZW50IGFuZCBpbnRlcm9wZXJhYmxlDSAgIGltcGxlbWVudGF0
aW9ucyBhcHBsaWVzIHRvIGFsbCBvZiB0aGUgb3B0aW9ucyBhbmQgZmVhdHVyZXMgb2YgdGhlDSAg
IHNwZWNpZmljYXRpb24uICBJbiBjYXNlcyBpbiB3aGljaCBvbmUgb3IgbW9yZSBvcHRpb25zIG9y
IGZlYXR1cmVzDSAgIGhhdmUgbm90IGJlZW4gZGVtb25zdHJhdGVkIGluIGF0IGxlYXN0IHR3byBp
bnRlcm9wZXJhYmxlDSAgIGltcGxlbWVudGF0aW9ucywgdGhlIHNwZWNpZmljYXRpb24gbWF5IGFk
dmFuY2UgdG8gdGhlIERyYWZ0IFN0YW5kYXJkDSAgIGxldmVsIG9ubHkgaWYgdGhvc2Ugb3B0aW9u
cyBvciBmZWF0dXJlcyBhcmUgcmVtb3ZlZC4NDSAgIFRoZSBXb3JraW5nIEdyb3VwIGNoYWlyIGlz
IHJlc3BvbnNpYmxlIGZvciBkb2N1bWVudGluZyB0aGUgc3BlY2lmaWMNICAgaW1wbGVtZW50YXRp
b25zIHdoaWNoIHF1YWxpZnkgdGhlIHNwZWNpZmljYXRpb24gZm9yIERyYWZ0IG9yIEludGVybmV0
DSAgIFN0YW5kYXJkIHN0YXR1cyBhbG9uZyB3aXRoIGRvY3VtZW50YXRpb24gYWJvdXQgdGVzdGlu
ZyBvZiB0aGUNICAgaW50ZXJvcGVyYXRpb24gb2YgdGhlc2UgaW1wbGVtZW50YXRpb25zLiAgVGhl
IGRvY3VtZW50YXRpb24gbXVzdA0gICBpbmNsdWRlIGluZm9ybWF0aW9uIGFib3V0IHRoZSBzdXBw
b3J0IG9mIGVhY2ggb2YgdGhlIGluZGl2aWR1YWwNICAgb3B0aW9ucyBhbmQgZmVhdHVyZXMuICBU
aGlzIGRvY3VtZW50YXRpb24gc2hvdWxkIGJlIHN1Ym1pdHRlZCB0byB0aGUNICAgQXJlYSBEaXJl
Y3RvciB3aXRoIHRoZSBwcm90b2NvbCBhY3Rpb24gcmVxdWVzdC4gKHNlZSBTZWN0aW9uIDYpDQ0g
ICBBIERyYWZ0IFN0YW5kYXJkIG11c3QgYmUgd2VsbC11bmRlcnN0b29kIGFuZCBrbm93biB0byBi
ZSBxdWl0ZQ0gICBzdGFibGUsIGJvdGggaW4gaXRzIHNlbWFudGljcyBhbmQgYXMgYSBiYXNpcyBm
b3IgZGV2ZWxvcGluZyBhbg0gICBpbXBsZW1lbnRhdGlvbi4gIEEgRHJhZnQgU3RhbmRhcmQgbWF5
IHN0aWxsIHJlcXVpcmUgYWRkaXRpb25hbCBvcg0gICBtb3JlIHdpZGVzcHJlYWQgZmllbGQgZXhw
ZXJpZW5jZSwgc2luY2UgaXQgaXMgcG9zc2libGUgZm9yDSAgIGltcGxlbWVudGF0aW9ucyBiYXNl
ZCBvbiBEcmFmdCBTdGFuZGFyZCBzcGVjaWZpY2F0aW9ucyB0byBkZW1vbnN0cmF0ZQ0gICB1bmZv
cmVzZWVuIGJlaGF2aW9yIHdoZW4gc3ViamVjdGVkIHRvIGxhcmdlLXNjYWxlIHVzZSBpbiBwcm9k
dWN0aW9uDSAgIGVudmlyb25tZW50cy4NDSAgIEEgRHJhZnQgU3RhbmRhcmQgaXMgbm9ybWFsbHkg
Y29uc2lkZXJlZCB0byBiZSBhIGZpbmFsIHNwZWNpZmljYXRpb24sDSAgIGFuZCBjaGFuZ2VzIGFy
ZSBsaWtlbHkgdG8gYmUgbWFkZSBvbmx5IHRvIHNvbHZlIHNwZWNpZmljIHByb2JsZW1zDSAgIGVu
Y291bnRlcmVkLiAgSW4gbW9zdCBjaXJjdW1zdGFuY2VzLCBpdCBpcyByZWFzb25hYmxlIGZvciB2
ZW5kb3JzIHRvDSAgIGRlcGxveSBpbXBsZW1lbnRhdGlvbnMgb2YgRHJhZnQgU3RhbmRhcmRzIGlu
dG8gYSBkaXNydXB0aW9uIHNlbnNpdGl2ZQ0gICBlbnZpcm9ubWVudC4NDT09PT09PT09PT09PT09
PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09
PQ0NDSAgICAgICAgICAgICAgICBJbnRlcm5ldCBYLjUwOSBQdWJsaWMgS2V5IEluZnJhc3RydWN0
dXJlDSAgICAgICAgICAgICAgICAgICAgICAgVGltZS1TdGFtcCBQcm90b2NvbCAoVFNQKQ0gICAg
ICAgICAgICAgICAgICAgICAgIEludGVyb3BlcmFiaWxpdHkgdGVzdGluZw0NQ0xJRU5UDQ0gICAg
ICBVcG9uIHJlY2VpdmluZyB0aGUgcmVzcG9uc2UgKHdoaWNoIGlzIG9yIGluY2x1ZGVzIGEgVGlt
ZVN0YW1wUmVzcA0gICAgICB0aGF0IG5vcm1hbGx5IGNvbnRhaW5zIGEgVGltZVN0YW1wVG9rZW4g
KFRTVCksIGFzIGRlZmluZWQgYmVsb3cpLCANWxMgTlVNTEdMQVVUTyAVXSAgdGhlIHJlcXVlc3Rp
bmcgZW50aXR5IFNIQUxMIHZlcmlmeSB0aGUgc3RhdHVzIGVycm9yIHJldHVybmVkIGluIHRoZQ1b
EyBOVU1MR0xBVVRPIBVdICByZXNwb25zZSBhbmQgaWYgbm8gZXJyb3IgaXMgcHJlc2VudCBpdCBT
SEFMTCB2ZXJpZnkgdGhlIHZhcmlvdXMNICAgICAgZmllbGRzIGNvbnRhaW5lZCBpbiB0aGUgVGlt
ZVN0YW1wVG9rZW4gYW5kIHRoZSB2YWxpZGl0eSBvZiB0aGUNWxMgTlVNTEdMQVVUTyAVXSAgZGln
aXRhbCBzaWduYXR1cmUgb2YgdGhlIFRpbWVTdGFtcFRva2VuLiANDVsTIE5VTUxHTEFVVE8gFV0g
IEluIHBhcnRpY3VsYXIsIGl0IFNIQUxMIHZlcmlmeSB0aGF0IHdoYXQgd2FzIHRpbWUtc3RhbXBl
ZCANICAgICAgY29ycmVzcG9uZHMgdG8gd2hhdCB3YXMgcmVxdWVzdGVkIHRvIGJlIHRpbWUtc3Rh
bXBlZC4NDVsTIE5VTUxHTEFVVE8gFV0gIFRoZSByZXF1ZXN0ZXIgU0hBTEwgdmVyaWZ5IHRoYXQg
dGhlIFRpbWVTdGFtcFRva2VuIGNvbnRhaW5zIHRoZSANICAgICAgY29ycmVjdCBjZXJ0aWZpY2F0
ZSBpZGVudGlmaWVyIG9mIHRoZSBUU0EsIA1bEyBOVU1MR0xBVVRPIBVdICB0aGUgY29ycmVjdCBk
YXRhIGltcHJpbnQgDVsTIE5VTUxHTEFVVE8gFV0gIGFuZCB0aGUgY29ycmVjdCBoYXNoIGFsZ29y
aXRobSBPSUQuDQ1bEyBOVU1MR0xBVVRPIBVdICBJdCBTSEFMTCB0aGVuIHZlcmlmeSB0aGUgdGlt
ZWxpbmVzcyBvZiB0aGUgcmVzcG9uc2UgYnkgdmVyaWZ5aW5nIGVpdGhlcg0gICAgICB0aGUgdGlt
ZSBpbmNsdWRlZCBpbiB0aGUgcmVzcG9uc2UgYWdhaW5zdCBhIGxvY2FsIHRydXN0ZWQgdGltZQ1b
EyBOVU1MR0xBVVRPIBVdICByZWZlcmVuY2UsIGlmIG9uZSBpcyBhdmFpbGFibGUsIG9yIHRoZSB2
YWx1ZSBvZiB0aGUgbm9uY2UgKGxhcmdlDSAgICAgIHJhbmRvbSBudW1iZXIgd2l0aCBhIGhpZ2gg
cHJvYmFiaWxpdHkgdGhhdCBpdCBpcyBnZW5lcmF0ZWQgYnkgdGhlDSAgICAgIGNsaWVudCBvbmx5
IG9uY2UpIGluY2x1ZGVkIGluIHRoZSByZXNwb25zZSBhZ2FpbnN0IHRoZSB2YWx1ZSBpbmNsdWRl
ZA0gICAgICBpbiB0aGUgcmVxdWVzdC4NDVsTIE5VTUxHTEFVVE8gFV0gSWYgYW55IG9mIHRoZSB2
ZXJpZmljYXRpb25zIGFib3ZlIGZhaWxzLCB0aGUgVGltZVN0YW1wVG9rZW4gU0hBTEwgYmUgDSAg
IHJlamVjdGVkLg0NWxMgTlVNTEdMQVVUTyAVXSBUaGVuLCB0aGUgY2xpZW50IGFwcGxpY2F0aW9u
IFNIT1VMRCBjaGVjayB0aGUgcG9saWN5IGZpZWxkIHRvDSAgICAgIGRldGVybWluZSB3aGV0aGVy
IG9yIG5vdCB0aGUgcG9saWN5IHVuZGVyIHdoaWNoIHRoZSB0b2tlbiB3YXMgaXNzdWVkDSAgICAg
IGlzIGFjY2VwdGFibGUgZm9yIHRoZSBhcHBsaWNhdGlvbi4NDTIuNC4xLiBSZXF1ZXN0IEZvcm1h
dA0NICAgQSB0aW1lLXN0YW1waW5nIHJlcXVlc3QgaXMgYXMgZm9sbG93czoNDVRpbWVTdGFtcFJl
cSA6Oj0gU0VRVUVOQ0UgIHsNICAgdmVyc2lvbiAgICAgICAgICAgICAgICAgICAgICBJTlRFR0VS
ICB7IHYxKDEpIH0sDSAgIG1lc3NhZ2VJbXByaW50ICAgICAgICAgICAgICAgTWVzc2FnZUltcHJp
bnQsDSAgICAgLS1hIGhhc2ggYWxnb3JpdGhtIE9JRCBhbmQgdGhlIGhhc2ggdmFsdWUgb2YgdGhl
IGRhdGEgdG8gYmUNICAgICAtLXRpbWUtc3RhbXBlZA0gICByZXFQb2xpY3kgICAgICAgICAgICAg
VFNBUG9saWN5SWQgICAgICAgICAgICAgIE9QVElPTkFMLA0gICBub25jZSAgICAgICAgICAgICAg
ICAgSU5URUdFUiAgICAgICAgICAgICAgICAgIE9QVElPTkFMLA0gICBjZXJ0UmVxICAgICAgICAg
ICAgICAgQk9PTEVBTiAgICAgICAgICAgICAgICAgIERFRkFVTFQgRkFMU0UsDSAgIGV4dGVuc2lv
bnMgICAgICAgICAgICBbMF0gSU1QTElDSVQgRXh0ZW5zaW9ucyAgT1BUSU9OQUwgIH0NDSAgIFRo
ZSB2ZXJzaW9uIGZpZWxkIChjdXJyZW50bHkgdjEpIGRlc2NyaWJlcyB0aGUgdmVyc2lvbiBvZiB0
aGUgVGltZS0NICAgU3RhbXAgcmVxdWVzdC4NDVsTIE5VTUxHTEFVVE8gFV0gVGhlIG1lc3NhZ2VJ
bXByaW50IGZpZWxkIFNIT1VMRCBjb250YWluIHRoZSBoYXNoIG9mIHRoZSBkYXR1bSB0byBiZQ0g
ICAgICB0aW1lLXN0YW1wZWQuICBUaGUgaGFzaCBpcyByZXByZXNlbnRlZCBhcyBhbiBPQ1RFVCBT
VFJJTkcuICBJdHMNICAgICAgbGVuZ3RoIE1VU1QgbWF0Y2ggdGhlIGxlbmd0aCBvZiB0aGUgaGFz
aCB2YWx1ZSBmb3IgdGhhdCBhbGdvcml0aG0NICAgICAgKGUuZy4sIDIwIGJ5dGVzIGZvciBTSEEt
MSBvciAxNiBieXRlcyBmb3IgTUQ1KS4NDSAgIE1lc3NhZ2VJbXByaW50IDo6PSBTRVFVRU5DRSAg
ew0gICAgICAgIGhhc2hBbGdvcml0aG0gICAgICAgICAgICAgICAgQWxnb3JpdGhtSWRlbnRpZmll
ciwNICAgICAgICBoYXNoZWRNZXNzYWdlICAgICAgICAgICAgICAgIE9DVEVUIFNUUklORyAgfQ0N
WxMgTlVNTEdMQVVUTyAVXSBUaGUgaGFzaCBhbGdvcml0aG0gaW5kaWNhdGVkIGluIHRoZSBoYXNo
QWxnb3JpdGhtIGZpZWxkIFNIT1VMRCBiZSBhDSAgICAgIGtub3duIGhhc2ggYWxnb3JpdGhtIChv
bmUtd2F5IGFuZCBjb2xsaXNpb24gcmVzaXN0YW50KS4NDVsTIE5VTUxHTEFVVE8gFV0gIFRoZSBy
ZXFQb2xpY3kgZmllbGQsIGlmIGluY2x1ZGVkLCBpbmRpY2F0ZXMgdGhlIFRTQSBwb2xpY3kgdW5k
ZXINICAgICAgd2hpY2ggdGhlIFRpbWVTdGFtcFRva2VuIFNIT1VMRCBiZSBwcm92aWRlZC4gIFRT
QVBvbGljeUlkIGlzIGRlZmluZWQNICAgICAgYXMgZm9sbG93czoNDSAgICAgIFRTQVBvbGljeUlk
IDo6PSBPQkpFQ1QgSURFTlRJRklFUg0NICAgICAgVGhlIG5vbmNlLCBpZiBpbmNsdWRlZCwgYWxs
b3dzIHRoZSBjbGllbnQgdG8gdmVyaWZ5IHRoZSB0aW1lbGluZXNzIG9mDSAgICAgIHRoZSByZXNw
b25zZSB3aGVuIG5vIGxvY2FsIGNsb2NrIGlzIGF2YWlsYWJsZS4gIFRoZSBub25jZSBpcyBhIGxh
cmdlDSAgICAgIHJhbmRvbSBudW1iZXIgd2l0aCBhIGhpZ2ggcHJvYmFiaWxpdHkgdGhhdCB0aGUg
Y2xpZW50IGdlbmVyYXRlcyBpdA0gICAgICBvbmx5IG9uY2UgKGUuZy4sIGEgNjQgYml0IGludGVn
ZXIpLiAgSW4gc3VjaCBhIGNhc2UgdGhlIHNhbWUgbm9uY2UNICAgICAgdmFsdWUgTVVTVCBiZSBp
bmNsdWRlZCBpbiB0aGUgcmVzcG9uc2UgYnkgdGhlIHNlcnZlciwgb3RoZXJ3aXNlIHRoZSANWxMg
TlVNTEdMQVVUTyAVXSByZXNwb25zZSBzaGFsbFNIQUxMIGJlIHJlamVjdGVkIGJ5IHRoZSBjbGll
bnQuDQ0gICAgICBUaGUgZXh0ZW5zaW9ucyBmaWVsZCBpcyBhIGdlbmVyaWMgd2F5IHRvIGFkZCBh
ZGRpdGlvbmFsIGluZm9ybWF0aW9uDSAgICAgIHRvIHRoZSByZXF1ZXN0IGluIHRoZSBmdXR1cmUu
ICBFeHRlbnNpb25zIGlzIGRlZmluZWQgaW4gW1JGQyAyNDU5XS4NICAgICAgSWYgYW4gZXh0ZW5z
aW9uLCB3aGV0aGVyIGl0IGlzIG1hcmtlZCBjcml0aWNhbCBvciBub3QgY3JpdGljYWwsIGlzDSAg
ICAgIHVzZWQgYnkgYSByZXF1ZXN0ZXIgYnV0IGlzIG5vdCByZWNvZ25pemVkIGJ5IGEgdGltZS1z
dGFtcGluZyBzZXJ2ZXIsDVsTIE5VTUxHTEFVVE8gFV0gdGhlIHNlcnZlciBTSEFMTCBub3QgaXNz
dWUgYSB0b2tlbiBhbmQgDVsTIE5VTUxHTEFVVE8gFV0gU0hBTEwgcmV0dXJuIGEgZmFpbHVyZSAo
dW5hY2NlcHRlZEV4dGVuc2lvbikuDQ1bEyBOVU1MR0xBVVRPIBVdIENvbmZvcm1pbmcgdGltZS1z
dGFtcGluZyByZXF1ZXN0ZXJzIE1VU1QgYmUgYWJsZSB0byByZWNvZ25pemUgDVsTIE5VTUxHTEFV
VE8gFV0gdmVyc2lvbiAxIHRpbWUtc3RhbXAgdG9rZW5zIHdpdGggYWxsIHRoZSBvcHRpb25hbCBm
aWVsZHMgcHJlc2VudCwgDSAgICAgIGJ1dCBhcmUgbm90IG1hbmRhdGVkIHRvIHVuZGVyc3RhbmQg
dGhlIHNlbWFudGljcyBvZiBhbnkgZXh0ZW5zaW9uLCANICAgICAgaWYgcHJlc2VudC4NDVsTIE5V
TUxHTEFVVE8gFV0gQ29tcGxpYW50IGNsaWVudHMgTVVTVCBnZW5lcmF0ZSBhbiBlcnJvciBpZiBb
UEtJU3RhdHVzXSB2YWx1ZXMgaXQgDSAgICAgIGRvZXMgbm90IHVuZGVyc3RhbmQgYXJlIHByZXNl
bnQuDQ1bEyBOVU1MR0xBVVRPIBVdIENvbXBsaWFudCBjbGllbnRzIE1VU1QgZ2VuZXJhdGUgYW4g
ZXJyb3IgaWYgW1BLSUZhaWx1cmVJbmZvXSB2YWx1ZXMgDSAgICAgIGl0IGRvZXMgbm90IHVuZGVy
c3RhbmQgYXJlIHByZXNlbnQuDQ0NU0VSVkVSDQ0yLjEuIFJlcXVpcmVtZW50cyBvZiB0aGUgVFNB
DQ0gICBUaGUgVFNBIGlzIFJFUVVJUkVEOg0NWxMgTlVNTEdMQVVUTyAVXSAxLiB0byB1c2UgYSB0
cnVzdHdvcnRoeSBzb3VyY2Ugb2YgdGltZS4NDVsTIE5VTUxHTEFVVE8gFV0gMi4gdG8gaW5jbHVk
ZSBhIHRydXN0d29ydGh5IHRpbWUgdmFsdWUgZm9yIGVhY2ggdGltZS1zdGFtcCB0b2tlbi4NDVsT
IE5VTUxHTEFVVE8gFV0gMy4gdG8gaW5jbHVkZSBhIHVuaXF1ZSBpbnRlZ2VyIGZvciBlYWNoIG5l
d2x5IGdlbmVyYXRlZCB0aW1lLXN0YW1wDSAgICAgICAgIHRva2VuLg0NWxMgTlVNTEdMQVVUTyAV
XSA0LiB0byBwcm9kdWNlIGEgdGltZS1zdGFtcCB0b2tlbiB1cG9uIHJlY2VpdmluZyBhIHZhbGlk
IHJlcXVlc3QNICAgICAgICAgZnJvbSB0aGUgcmVxdWVzdGVyLCB3aGVuIGl0IGlzIHBvc3NpYmxl
Lg0NWxMgTlVNTEdMQVVUTyAVXSA1LiB0byBpbmNsdWRlIHdpdGhpbiBlYWNoIHRpbWUtc3RhbXAg
dG9rZW4gYW4gaWRlbnRpZmllciB0bw0gICAgICAgICB1bmlxdWVseSBpbmRpY2F0ZSB0aGUgc2Vj
dXJpdHkgcG9saWN5IHVuZGVyIHdoaWNoIHRoZSB0b2tlbiB3YXMNICAgICAgICAgY3JlYXRlZC4N
DVsTIE5VTUxHTEFVVE8gFV0gNi4gdG8gb25seSB0aW1lLXN0YW1wIGEgaGFzaCByZXByZXNlbnRh
dGlvbiBvZiB0aGUgZGF0dW0sIGkuZS4sIGENICAgICAgICAgZGF0YSBpbXByaW50IGFzc29jaWF0
ZWQgd2l0aCBhIG9uZS13YXkgY29sbGlzaW9uIHJlc2lzdGFudA0gICAgICAgICBoYXNoLWZ1bmN0
aW9uIHVuaXF1ZWx5IGlkZW50aWZpZWQgYnkgYW4gT0lELg0NWxMgTlVNTEdMQVVUTyAVXSA3LiB0
byBleGFtaW5lIHRoZSBPSUQgb2YgdGhlIG9uZS13YXkgY29sbGlzaW9uIHJlc2lzdGFudCBoYXNo
LQ0gICAgICAgICBmdW5jdGlvbiBhbmQgdG8gdmVyaWZ5IHRoYXQgdGhlIGhhc2ggdmFsdWUgbGVu
Z3RoIGlzIGNvbnNpc3RlbnQNICAgICAgICAgd2l0aCB0aGUgaGFzaCBhbGdvcml0aG0uDQ1bEyBO
VU1MR0xBVVRPIBVdIDguIG5vdCB0byBleGFtaW5lIHRoZSBpbXByaW50IGJlaW5nIHRpbWUtc3Rh
bXBlZCBpbiBhbnkgd2F5IChvdGhlcg0gICAgICAgICB0aGFuIHRvIGNoZWNrIGl0cyBsZW5ndGgs
IGFzIHNwZWNpZmllZCBpbiB0aGUgcHJldmlvdXMgYnVsbGV0KS4NDVsTIE5VTUxHTEFVVE8gFV0g
OS4gbm90IHRvIGluY2x1ZGUgYW55IGlkZW50aWZpY2F0aW9uIG9mIHRoZSByZXF1ZXN0aW5nIGVu
dGl0eSBpbg0gICAgICAgICB0aGUgdGltZS1zdGFtcCB0b2tlbnMuDQ1bEyBOVU1MR0xBVVRPIBVd
IDEwLiB0byBzaWduIGVhY2ggdGltZS1zdGFtcCB0b2tlbiB1c2luZyBhIGtleSBnZW5lcmF0ZWQg
ZXhjbHVzaXZlbHkNICAgICAgICAgZm9yIHRoaXMgcHVycG9zZSBhbmQgaGF2ZSB0aGlzIHByb3Bl
cnR5IG9mIHRoZSBrZXkgaW5kaWNhdGVkIG9uDSAgICAgICAgIHRoZSBjb3JyZXNwb25kaW5nIGNl
cnRpZmljYXRlLg0NWxMgTlVNTEdMQVVUTyAVXSAxMS4gdG8gaW5jbHVkZSBhZGRpdGlvbmFsIGlu
Zm9ybWF0aW9uIGluIHRoZSB0aW1lLXN0YW1wIHRva2VuLCBpZg0gICAgICAgICBhc2tlZCBieSB0
aGUgcmVxdWVzdGVyIHVzaW5nIHRoZSBleHRlbnNpb25zIGZpZWxkLCBvbmx5IGZvciB0aGUNICAg
ICAgICAgZXh0ZW5zaW9ucyB0aGF0IGFyZSBzdXBwb3J0ZWQgYnkgdGhlIFRTQS4gIElmIHRoaXMg
aXMgbm90DSAgICAgICAgIHBvc3NpYmxlLCB0aGUgVFNBIFNIQUxMIHJlc3BvbmQgd2l0aCBhbiBl
cnJvciBtZXNzYWdlLg0NMi4zLiBJZGVudGlmaWNhdGlvbiBvZiB0aGUgVFNBDQ1bEyBOVU1MR0xB
VVRPIBVdIFRoZSBUU0EgTVVTVCBzaWduIGVhY2ggdGltZS1zdGFtcCBtZXNzYWdlIHdpdGggYSBr
ZXkgcmVzZXJ2ZWQNICAgICAgc3BlY2lmaWNhbGx5IGZvciB0aGF0IHB1cnBvc2UuIA0NWxMgTlVN
TEdMQVVUTyAVXSBUaGUgY29ycmVzcG9uZGluZyBjZXJ0aWZpY2F0ZSBNVVNUIGNvbnRhaW4gb25s
eSBvbmUgaW5zdGFuY2Ugb2YgdGhlDSAgICAgIGV4dGVuZGVkIGtleSB1c2FnZSBmaWVsZCBleHRl
bnNpb24gYXMgZGVmaW5lZCBpbiBbUkZDMjQ1OV0gU2VjdGlvbg0gICAgICA0LjIuMS4xMyB3aXRo
IEtleVB1cnBvc2VJRCBoYXZpbmcgdmFsdWU6DQ1bEyBOVU1MR0xBVVRPIBVdIGlkLWtwLXRpbWVT
dGFtcGluZy4gIFRoaXMgZXh0ZW5zaW9uIE1VU1QgYmUgY3JpdGljYWwuDQ0yLjQuMi4gUmVzcG9u
c2UgRm9ybWF0DQ0gICBBIHRpbWUtc3RhbXBpbmcgcmVzcG9uc2UgaXMgYXMgZm9sbG93czoNDSAg
IFRpbWVTdGFtcFJlc3AgOjo9IFNFUVVFTkNFICB7DSAgICAgIHN0YXR1cyAgICAgICAgICAgICAg
ICAgIFBLSVN0YXR1c0luZm8sDSAgICAgIHRpbWVTdGFtcFRva2VuICAgICAgICAgIFRpbWVTdGFt
cFRva2VuICAgICBPUFRJT05BTCAgfQ0NICAgVGhlIHN0YXR1cyBpcyBiYXNlZCBvbiB0aGUgZGVm
aW5pdGlvbiBvZiBzdGF0dXMgaW4gc2VjdGlvbiAzLjIuMw0gICBvZiBbUkZDMjUxMF0gYXMgZm9s
bG93czoNDSAgIFBLSVN0YXR1c0luZm8gOjo9IFNFUVVFTkNFIHsNICAgICAgc3RhdHVzICAgICAg
ICBQS0lTdGF0dXMsDSAgICAgIHN0YXR1c1N0cmluZyAgUEtJRnJlZVRleHQgICAgIE9QVElPTkFM
LA0gICAgICBmYWlsSW5mbyAgICAgIFBLSUZhaWx1cmVJbmZvICBPUFRJT05BTCAgfQ0NWxMgTlVN
TEdMQVVUTyAVXSBXaGVuIHRoZSBzdGF0dXMgY29udGFpbnMgdGhlIHZhbHVlIHplcm8gb3Igb25l
LCBhIFRpbWVTdGFtcFRva2VuIE1VU1QNICAgICAgYmUgcHJlc2VudC4gIFdoZW4gc3RhdHVzIGNv
bnRhaW5zIGEgdmFsdWUgb3RoZXIgdGhhbiB6ZXJvIG9yIG9uZSwgYQ1bEyBOVU1MR0xBVVRPIBVd
IFRpbWVTdGFtcFRva2VuIE1VU1QgTk9UIGJlIHByZXNlbnQuICBPbmUgb2YgdGhlIGZvbGxvd2lu
ZyB2YWx1ZXMgDVsTIE5VTUxHTEFVVE8gFV0gTVVTVCBiZSBjb250YWluZWQgaW4gc3RhdHVzOg0N
ICAgUEtJU3RhdHVzIDo6PSBJTlRFR0VSIHsNICAgICAgZ3JhbnRlZCAgICAgICAgICAgICAgICAo
MCksDSAgICAgIC0tIHdoZW4gdGhlIFBLSVN0YXR1cyBjb250YWlucyB0aGUgdmFsdWUgemVybyBh
IFRpbWVTdGFtcFRva2VuLCBhcw0gICAgICAgICByZXF1ZXN0ZWQsIGlzIHByZXNlbnQuDSAgICAg
IGdyYW50ZWRXaXRoTW9kcyAgICAgICAgKDEpLA0gICAgICAgLS0gd2hlbiB0aGUgUEtJU3RhdHVz
IGNvbnRhaW5zIHRoZSB2YWx1ZSBvbmUgYSBUaW1lU3RhbXBUb2tlbiwNICAgICAgICAgd2l0aCBt
b2RpZmljYXRpb25zLCBpcyBwcmVzZW50Lg0gICAgICByZWplY3Rpb24gICAgICAgICAgICAgICgy
KSwNICAgICAgd2FpdGluZyAgICAgICAgICAgICAgICAoMyksDSAgICAgIHJldm9jYXRpb25XYXJu
aW5nICAgICAgKDQpLA0gICAgICAgLS0gdGhpcyBtZXNzYWdlIGNvbnRhaW5zIGEgd2FybmluZyB0
aGF0IGEgcmV2b2NhdGlvbiBpcw0gICAgICAgLS0gaW1taW5lbnQNICAgICAgcmV2b2NhdGlvbk5v
dGlmaWNhdGlvbiAoNSkNICAgICAgIC0tIG5vdGlmaWNhdGlvbiB0aGF0IGEgcmV2b2NhdGlvbiBo
YXMgb2NjdXJyZWQgIH0NDVsTIE5VTUxHTEFVVE8gFV0gQ29tcGxpYW50IHNlcnZlcnMgU0hPVUxE
IE5PVCBwcm9kdWNlIGFueSBvdGhlciB2YWx1ZXMuIA0NICAgICAgV2hlbiB0aGUgVGltZVN0YW1w
VG9rZW4gaXMgbm90IHByZXNlbnQsIHRoZSBmYWlsSW5mbyBpbmRpY2F0ZXMgdGhlDVsTIE5VTUxH
TEFVVE8gFV0gcmVhc29uIHdoeSB0aGUgdGltZS1zdGFtcCByZXF1ZXN0IHdhcyByZWplY3RlZCBh
bmQgTVVTVCBtYXkgYmUgb25lIG9mIHRoZQ0gICAgICBmb2xsb3dpbmcgdmFsdWVzLg0NUEtJRmFp
bHVyZUluZm8gOjo9IEJJVCBTVFJJTkcgew0gICBiYWRBbGcgICAgICAgICAgICAgICAoMCksDSAg
ICAgLS0gdW5yZWNvZ25pemVkIG9yIHVuc3VwcG9ydGVkIEFsZ29yaXRobSBJZGVudGlmaWVyDSAg
IGJhZFJlcXVlc3QgICAgICAgICAgICgyKSwNICAgICAtLSB0cmFuc2FjdGlvbiBub3QgcGVybWl0
dGVkIG9yIHN1cHBvcnRlZA0gICBiYWREYXRhRm9ybWF0ICAgICAgICAoNSksDSAgICAgLS0gdGhl
IGRhdGEgc3VibWl0dGVkIGhhcyB0aGUgd3JvbmcgZm9ybWF0DSAgIHRpbWVOb3RBdmFpbGFibGUg
ICAgKDE0KSwNICAgICAtLSB0aGUgVFNBJ3MgdGltZSBzb3VyY2UgaXMgbm90IGF2YWlsYWJsZQ0g
ICB1bmFjY2VwdGVkUG9saWN5ICAgICgxNSksDSAgICAgLS0gdGhlIHJlcXVlc3RlZCBUU0EgcG9s
aWN5IGlzIG5vdCBzdXBwb3J0ZWQgYnkgdGhlIFRTQQ0gICB1bmFjY2VwdGVkRXh0ZW5zaW9uICgx
NiksDSAgICAgLS0gdGhlIHJlcXVlc3RlZCBleHRlbnNpb24gaXMgbm90IHN1cHBvcnRlZCBieSB0
aGUgVFNBDSAgICBhZGRJbmZvTm90QXZhaWxhYmxlICgxNykNICAgICAgLS0gdGhlIGFkZGl0aW9u
YWwgaW5mb3JtYXRpb24gcmVxdWVzdGVkIGNvdWxkIG5vdCBiZSB1bmRlcnN0b29kDSAgICAgIC0t
IG9yIGlzIG5vdCBhdmFpbGFibGUNICAgIHN5c3RlbUZhaWx1cmUgICAgICAgKDI1KQ0gICAgICAt
LSB0aGUgcmVxdWVzdCBjYW5ub3QgYmUgaGFuZGxlZCBkdWUgdG8gc3lzdGVtIGZhaWx1cmUgIH0N
DSAgIFRoZXNlIGFyZSB0aGUgb25seSB2YWx1ZXMgb2YgUEtJRmFpbHVyZUluZm8gdGhhdCBTSEFM
TCBiZSBzdXBwb3J0ZWQuDQ1bEyBOVU1MR0xBVVRPIBVdIENvbXBsaWFudCBzZXJ2ZXJzIFNIT1VM
RCBOT1QgcHJvZHVjZSBhbnkgb3RoZXIgdmFsdWVzLiANDVsTIE5VTUxHTEFVVE8gFV0gVGhlIHN0
YXR1c1N0cmluZyBmaWVsZCBvZiBQS0lTdGF0dXNJbmZvIE1BWSBiZSB1c2VkIHRvIGluY2x1ZGUg
cmVhc29uDSAgICAgIHRleHQgc3VjaCBhcyAibWVzc2FnZUltcHJpbnQgZmllbGQgaXMgbm90IGNv
cnJlY3RseSBmb3JtYXR0ZWQiLg0NICAgICAgQSBUaW1lU3RhbXBUb2tlbiBpcyBhcyBmb2xsb3dz
LiAgSXQgaXMgZGVmaW5lZCBhcyBhIENvbnRlbnRJbmZvDVsTIE5VTUxHTEFVVE8gFV0gKFtDTVNd
KSBhbmQgU0hBTEwgZW5jYXBzdWxhdGUgYSBzaWduZWQgZGF0YSBjb250ZW50IHR5cGUuDQ0gICBU
aW1lU3RhbXBUb2tlbiA6Oj0gQ29udGVudEluZm8NICAgICAtLSBjb250ZW50VHlwZSBpcyBpZC1z
aWduZWREYXRhIChbQ01TXSkNICAgICAtLSBjb250ZW50IGlzIFNpZ25lZERhdGEgKFtDTVNdKQ0N
ICAgVGhlIGZpZWxkcyBvZiB0eXBlIEVuY2Fwc3VsYXRlZENvbnRlbnRJbmZvIG9mIHRoZSBTaWdu
ZWREYXRhDSAgIGNvbnN0cnVjdCBoYXZlIHRoZSBmb2xsb3dpbmcgbWVhbmluZ3M6DQ0gICBlQ29u
dGVudFR5cGUgaXMgYW4gb2JqZWN0IGlkZW50aWZpZXIgdGhhdCB1bmlxdWVseSBzcGVjaWZpZXMg
dGhlDSAgIGNvbnRlbnQgdHlwZS4gIEZvciBhIHRpbWUtc3RhbXAgdG9rZW4gaXQgaXMgZGVmaW5l
ZCBhczoNDSAgIGlkLWN0LVRTVEluZm8gIE9CSkVDVCBJREVOVElGSUVSIDo6PSB7IGlzbygxKSBt
ZW1iZXItYm9keSgyKQ0gICB1cyg4NDApIHJzYWRzaSgxMTM1NDkpIHBrY3MoMSkgcGtjcy05KDkp
IHNtaW1lKDE2KSBjdCgxKSA0fQ0NICAgICAgZUNvbnRlbnQgaXMgdGhlIGNvbnRlbnQgaXRzZWxm
LCBjYXJyaWVkIGFzIGFuIG9jdGV0IHN0cmluZy4NWxMgTlVNTEdMQVVUTyAVXSBUaGUgZUNvbnRl
bnQgU0hBTEwgYmUgdGhlIERFUi1lbmNvZGVkIHZhbHVlIG9mIFRTVEluZm8uDQ1bEyBOVU1MR0xB
VVRPIBVdIFRoZSB0aW1lLXN0YW1wIHRva2VuIE1VU1QgTk9UIGNvbnRhaW4gYW55IHNpZ25hdHVy
ZXMgb3RoZXIgdGhhbiB0aGUNICAgICAgc2lnbmF0dXJlIG9mIHRoZSBUU0EuICBUaGUgY2VydGlm
aWNhdGUgaWRlbnRpZmllciAoRVNTQ2VydElEKSBvZiB0aGUNWxMgTlVNTEdMQVVUTyAVXSBUU0Eg
Y2VydGlmaWNhdGUgTVVTVCBiZSBpbmNsdWRlZCBhcyBhIHNpZ25lckluZm8gYXR0cmlidXRlIGlu
c2lkZSBhDSAgICAgIFNpZ25pbmdDZXJ0aWZpY2F0ZSBhdHRyaWJ1dGUuDQ1UU1RJbmZvIDo6PSBT
RVFVRU5DRSAgew0gICB2ZXJzaW9uICAgICAgICAgICAgICAgICAgICAgIElOVEVHRVIgIHsgdjEo
MSkgfSwNICAgcG9saWN5ICAgICAgICAgICAgICAgICAgICAgICBUU0FQb2xpY3lJZCwNICAgbWVz
c2FnZUltcHJpbnQgICAgICAgICAgICAgICBNZXNzYWdlSW1wcmludCwNICAgICAtLSBNVVNUIGhh
dmUgdGhlIHNhbWUgdmFsdWUgYXMgdGhlIHNpbWlsYXIgZmllbGQgaW4NICAgICAtLSBUaW1lU3Rh
bXBSZXENICAgc2VyaWFsTnVtYmVyICAgICAgICAgICAgICAgICBJTlRFR0VSLA0gICAgLS0gVGlt
ZS1TdGFtcGluZyB1c2VycyBNVVNUIGJlIHJlYWR5IHRvIGFjY29tbW9kYXRlIGludGVnZXJzDSAg
ICAtLSB1cCB0byAxNjAgYml0cy4NICAgZ2VuVGltZSAgICAgICAgICAgICAgICAgICAgICBHZW5l
cmFsaXplZFRpbWUsDSAgIGFjY3VyYWN5ICAgICAgICAgICAgICAgICAgICAgQWNjdXJhY3kgICAg
ICAgICAgICAgICAgIE9QVElPTkFMLA0gICBvcmRlcmluZyAgICAgICAgICAgICAgICAgICAgIEJP
T0xFQU4gICAgICAgICAgICAgREVGQVVMVCBGQUxTRSwNICAgbm9uY2UgICAgICAgICAgICAgICAg
ICAgICAgICBJTlRFR0VSICAgICAgICAgICAgICAgICAgT1BUSU9OQUwsDSAgICAgLS0gTVVTVCBi
ZSBwcmVzZW50IGlmIHRoZSBzaW1pbGFyIGZpZWxkIHdhcyBwcmVzZW50DSAgICAgLS0gaW4gVGlt
ZVN0YW1wUmVxLiAgSW4gdGhhdCBjYXNlIGl0IE1VU1QgaGF2ZSB0aGUgc2FtZSB2YWx1ZS4NICAg
dHNhICAgICAgICAgICAgICAgICAgICAgICAgICBbMF0gR2VuZXJhbE5hbWUgICAgICAgICAgT1BU
SU9OQUwsDSAgIGV4dGVuc2lvbnMgICAgICAgICAgICAgICAgICAgWzFdIElNUExJQ0lUIEV4dGVu
c2lvbnMgICBPUFRJT05BTCAgfQ0NICAgVGhlIHZlcnNpb24gZmllbGQgKGN1cnJlbnRseSB2MSkg
ZGVzY3JpYmVzIHRoZSB2ZXJzaW9uIG9mIHRoZSB0aW1lLQ0gICBzdGFtcCB0b2tlbi4NDVsTIE5V
TUxHTEFVVE8gFV0gQ29uZm9ybWluZyB0aW1lLXN0YW1waW5nIHNlcnZlcnMgTVVTVCBiZSBhYmxl
IHRvIHByb3ZpZGUgdmVyc2lvbiAxDSAgICAgIHRpbWUtc3RhbXAgdG9rZW5zLg0NWxMgTlVNTEdM
QVVUTyAVXSBBbW9uZyB0aGUgb3B0aW9uYWwgZmllbGRzLCBvbmx5IHRoZSBub25jZSBmaWVsZCBN
VVNUIGJlIHN1cHBvcnRlZC4NDVsTIE5VTUxHTEFVVE8gFV0gVGhlIHBvbGljeSBmaWVsZCBNVVNU
IGluZGljYXRlIHRoZSBUU0EncyBwb2xpY3kgdW5kZXIgd2hpY2ggdGhlDSAgICAgIHJlc3BvbnNl
IHdhcyBwcm9kdWNlZC4gIElmIGEgc2ltaWxhciBmaWVsZCB3YXMgcHJlc2VudCBpbiB0aGUNWxMg
TlVNTEdMQVVUTyAVXSBUaW1lU3RhbXBSZXEsIHRoZW4gaXQgTVVTVCBoYXZlIHRoZSBzYW1lIHZh
bHVlLCBvdGhlcndpc2UgYW4gZXJyb3INWxMgTlVNTEdMQVVUTyAVXSAodW5hY2NlcHRlZFBvbGlj
eSkgTVVTVCBiZSByZXR1cm5lZC4gDQ1bEyBOVU1MR0xBVVRPIBVdIFRoZSBtZXNzYWdlSW1wcmlu
dCBNVVNUIGhhdmUgdGhlIHNhbWUgdmFsdWUgYXMgdGhlIHNpbWlsYXIgZmllbGQgaW4NICAgICAg
VGltZVN0YW1wUmVxLCBwcm92aWRlZCB0aGF0IHRoZSBzaXplIG9mIHRoZSBoYXNoIHZhbHVlIG1h
dGNoZXMgdGhlDSAgICAgIGV4cGVjdGVkIHNpemUgb2YgdGhlIGhhc2ggYWxnb3JpdGhtIGlkZW50
aWZpZWQgaW4gaGFzaEFsZ29yaXRobS4NDVsTIE5VTUxHTEFVVE8gFV0gVGhlIFRpbWUgU3RhbXAg
QXV0aG9yaXR5IFNIT1VMRCBjaGVjayB3aGV0aGVyIG9yIG5vdCB0aGUgZ2l2ZW4gDSAgICAgIGhh
c2ggYWxnb3JpdGhtIGlzIGtub3duIHRvIGJlICJzdWZmaWNpZW50IiAoYmFzZWQgb24gdGhlIGN1
cnJlbnQgDSAgICAgIHN0YXRlIG9mIGtub3dsZWRnZSBpbiBjcnlwdGFuYWx5c2lzIGFuZCB0aGUg
Y3VycmVudCBzdGF0ZSBvZiB0aGUgDSAgICAgIGFydCBpbiBjb21wdXRhdGlvbmFsIHJlc291cmNl
cywgZm9yIGV4YW1wbGUpLiAgSWYgdGhlIFRTQSBkb2VzIG5vdCANICAgICAgcmVjb2duaXplIHRo
ZSBoYXNoIGFsZ29yaXRobSBvciBrbm93cyB0aGF0IHRoZSBoYXNoIGFsZ29yaXRobSBpcyANICAg
ICAgd2VhayAoYSBkZWNpc2lvbiBsZWZ0IHRvIHRoZSBkaXNjcmV0aW9uIG9mIGVhY2ggaW5kaXZp
ZHVhbCBUU0EpLCANWxMgTlVNTEdMQVVUTyAVXSB0aGVuIHRoZSBUU0EgU0hPVUxEIHJlZnVzZSB0
byBwcm92aWRlIHRoZSB0aW1lLXN0YW1wIHRva2VuIGJ5IA0gICAgICByZXR1cm5pbmcgYSBwa2lT
dGF0dXNJbmZvIG9mICdiYWRfYWxnJy4NDSAgICAgIFRoZSBzZXJpYWxOdW1iZXIgZmllbGQgaXMg
YW4gaW50ZWdlciBhc3NpZ25lZCBieSB0aGUgVFNBIHRvIGVhY2gNWxMgTlVNTEdMQVVUTyAVXSBU
aW1lU3RhbXBUb2tlbi4gIEl0IE1VU1QgYmUgdW5pcXVlIGZvciBlYWNoIFRpbWVTdGFtcFRva2Vu
IGlzc3VlZCBieQ0gICAgICBhIGdpdmVuIFRTQSAoaS5lLiwgdGhlIFRTQSBuYW1lIGFuZCBzZXJp
YWwgbnVtYmVyIGlkZW50aWZ5IGEgdW5pcXVlDVsTIE5VTUxHTEFVVE8gFV0gVGltZVN0YW1wVG9r
ZW4pLiAgSXQgc2hvdWxkIGJlIG5vdGljZWQgdGhhdCB0aGUgcHJvcGVydHkgTVVTVCBiZQ0gICAg
ICBwcmVzZXJ2ZWQgZXZlbiBhZnRlciBhIHBvc3NpYmxlIGludGVycnVwdGlvbiAoZS5nLiwgY3Jh
c2gpIG9mIHRoZQ0gICAgICBzZXJ2aWNlLg0NWxMgTlVNTEdMQVVUTyAVXSBHZW5lcmFsaXplZFRp
bWUgdmFsdWVzIE1VU1QgaW5jbHVkZSBzZWNvbmRzLiAgSG93ZXZlciwgd2hlbiB0aGVyZSBpcw0g
ICAgICBubyBuZWVkIHRvIGhhdmUgYSBwcmVjaXNpb24gYmV0dGVyIHRoYW4gdGhlIHNlY29uZCwg
dGhlbg1bEyBOVU1MR0xBVVRPIBVdIEdlbmVyYWxpemVkVGltZSB3aXRoIGEgcHJlY2lzaW9uIGxp
bWl0ZWQgdG8gb25lIHNlY29uZCBTSE9VTEQgYmUgdXNlZA0gICAgIChhcyBpbiBbUkZDIDI0NTld
KS4NDVsTIE5VTUxHTEFVVE8gFV0gVGhlIGVuY29kaW5nIE1VU1QgdGVybWluYXRlIHdpdGggYSAi
WiIgKHdoaWNoIG1lYW5zICJadWx1IiB0aW1lKS4gVGhlDVsTIE5VTUxHTEFVVE8gFV0gZGVjaW1h
bCBwb2ludCBlbGVtZW50LCBpZiBwcmVzZW50LCBNVVNUIGJlIHRoZSBwb2ludCBvcHRpb24gIi4i
LiBUaGUNWxMgTlVNTEdMQVVUTyAVXSBmcmFjdGlvbmFsLXNlY29uZHMgZWxlbWVudHMsIGlmIHBy
ZXNlbnQsIE1VU1Qgb21pdCBhbGwgdHJhaWxpbmcgMCdzOw1bEyBOVU1MR0xBVVRPIBVdIGlmIHRo
ZSBlbGVtZW50cyBjb3JyZXNwb25kIHRvIDAsIHRoZXkgTVVTVCBiZSB3aG9sbHkgb21pdHRlZCwg
YW5kIHRoZQ1bEyBOVU1MR0xBVVRPIBVdIGRlY2ltYWwgcG9pbnQgZWxlbWVudCBhbHNvIE1VU1Qg
YmUgb21pdHRlZC4NDSAgIGFjY3VyYWN5IHJlcHJlc2VudHMgdGhlIHRpbWUgZGV2aWF0aW9uIGFy
b3VuZCB0aGUgVVRDIHRpbWUgY29udGFpbmVkDSAgIGluIEdlbmVyYWxpemVkVGltZS4NDSAgIEFj
Y3VyYWN5IDo6PSBTRVFVRU5DRSB7DSAgICAgICAgIHNlY29uZHMgICAgICAgIElOVEVHRVIgICAg
ICAgICAgICAgIE9QVElPTkFMLA0gICAgICAgICBtaWxsaXMgICAgIFswXSBJTlRFR0VSICAoMS4u
OTk5KSAgICBPUFRJT05BTCwNICAgICAgICAgbWljcm9zICAgICBbMV0gSU5URUdFUiAgKDEuLjk5
OSkgICAgT1BUSU9OQUwgIH0NDSAgICAgIElmIGVpdGhlciBzZWNvbmRzLCBtaWxsaXMgb3IgbWlj
cm9zIGlzIG1pc3NpbmcsIHRoZW4gYSB2YWx1ZSBvZiB6ZXJvDVsTIE5VTUxHTEFVVE8gFV0gTVVT
VCBiZSB0YWtlbiBmb3IgdGhlIG1pc3NpbmcgZmllbGQuDQ1bEyBOVU1MR0xBVVRPIBVdIFdoZW4g
dGhlIGFjY3VyYWN5IG9wdGlvbmFsIGZpZWxkIGlzIG5vdCBwcmVzZW50LCB0aGVuIHRoZSBhY2N1
cmFjeQ0gICAgICBtYXkgYmUgYXZhaWxhYmxlIHRocm91Z2ggb3RoZXIgbWVhbnMsIGUuZy4sIHRo
ZSBUU0FQb2xpY3lJZC4NDVsTIE5VTUxHTEFVVE8gFV0gSWYgdGhlIG9yZGVyaW5nIGZpZWxkIGlz
IG1pc3NpbmcsIG9yIA1bEyBOVU1MR0xBVVRPIBVdIGlmIHRoZSBvcmRlcmluZyBmaWVsZCBpcyBw
cmVzZW50IGFuZCBzZXQgdG8gZmFsc2UsIHRoZW4gdGhlIGdlblRpbWUgDSAgICAgIGZpZWxkIG9u
bHkgaW5kaWNhdGVzIHRoZSB0aW1lIGF0IHdoaWNoIHRoZSB0aW1lLXN0YW1wIHRva2VuIGhhcyBi
ZWVuIA0gICAgICBjcmVhdGVkIGJ5IHRoZSBUU0EuDQ1bEyBOVU1MR0xBVVRPIBVdIElmIHRoZSBv
cmRlcmluZyBmaWVsZCBpcyBwcmVzZW50IGFuZCBzZXQgdG8gdHJ1ZSwgZXZlcnkgdGltZS1zdGFt
cA0gICAgICB0b2tlbiBmcm9tIHRoZSBzYW1lIFRTQSBjYW4gYWx3YXlzIGJlIG9yZGVyZWQgYmFz
ZWQgb24gdGhlIGdlblRpbWUNICAgICAgZmllbGQsIHJlZ2FyZGxlc3Mgb2YgdGhlIGdlblRpbWUg
YWNjdXJhY3kuDQ1bEyBOVU1MR0xBVVRPIBVdIFRoZSBub25jZSBmaWVsZCBNVVNUIGJlIHByZXNl
bnQgaWYgaXQgd2FzIHByZXNlbnQgaW4gdGhlDVsTIE5VTUxHTEFVVE8gFV0gVGltZVN0YW1wUmVx
LiBJbiBzdWNoIGEgY2FzZSBpdCBNVVNUIGVxdWFsIHRoZSB2YWx1ZSBwcm92aWRlZCBpbiB0aGUN
ICAgICAgVGltZVN0YW1wUmVxIHN0cnVjdHVyZS4NDSAgICAgIFRoZSBwdXJwb3NlIG9mIHRoZSB0
c2EgZmllbGQgaXMgdG8gZ2l2ZSBhIGhpbnQgaW4gaWRlbnRpZnlpbmcgdGhlDVsTIE5VTUxHTEFV
VE8gFV0gbmFtZSBvZiB0aGUgVFNBLiAgSWYgcHJlc2VudCwgaXQgTVVTVCBjb3JyZXNwb25kIHRv
IG9uZSBvZiB0aGUNICAgICAgc3ViamVjdCBuYW1lcyBpbmNsdWRlZCBpbiB0aGUgY2VydGlmaWNh
dGUgdGhhdCBpcyB0byBiZSB1c2VkIHRvDSAgICAgIHZlcmlmeSB0aGUgdG9rZW4uIA0NICAgICAg
SWYgdGhlIGNlcnRSZXEgZmllbGQgaXMgcHJlc2VudCBhbmQgc2V0IHRvIHRydWUsIHRoZSBUU0En
cyBwdWJsaWMga2V5DSAgICAgIGNlcnRpZmljYXRlIHRoYXQgaXMgcmVmZXJlbmNlZCBieSB0aGUg
RVNTQ2VydElEIGlkZW50aWZpZXIgaW5zaWRlIGENWxMgTlVNTEdMQVVUTyAVXSBTaWduaW5nQ2Vy
dGlmaWNhdGUgYXR0cmlidXRlIGluIHRoZSByZXNwb25zZSBNVVNUIGJlIHByb3ZpZGVkIGJ5IHRo
ZQ0gICAgICBUU0EgaW4gdGhlIGNlcnRpZmljYXRlcyBmaWVsZCBmcm9tIHRoZSBTaWduZWREYXRh
IHN0cnVjdHVyZSBpbiB0aGF0DSAgICAgICByZXNwb25zZS4gDQ1bEyBOVU1MR0xBVVRPIBVdIElm
IHRoZSBjZXJ0UmVxIGZpZWxkIGlzIG1pc3Npbmcgb3IgaWYgdGhlIGNlcnRSZXEgZmllbGQgaXMg
cHJlc2VudA0gICAgICBhbmQgc2V0IHRvIGZhbHNlIHRoZW4gdGhlIGNlcnRpZmljYXRlcyBmaWVs
ZCBmcm9tIHRoZSBTaWduZWREYXRhDSAgICAgIHN0cnVjdHVyZSBNVVNUIG5vdCBiZSBwcmVzZW50
IGluIHRoZSByZXNwb25zZS4NDQ0zLiBUcmFuc3BvcnRzDQ0gICBUaGVyZSBpcyBubyBtYW5kYXRv
cnkgdHJhbnNwb3J0IG1lY2hhbmlzbSBmb3IgVFNBIG1lc3NhZ2VzIGluIHRoaXMNICAgZG9jdW1l
bnQuICBUaGUgbWVjaGFuaXNtcyBkZXNjcmliZWQgYmVsb3cgYXJlIG9wdGlvbmFsOyANDVsTIE5V
TUxHTEFVVE8gFV0gMy4xLiBUaW1lLVN0YW1wIFByb3RvY29sIFVzaW5nIEUtbWFpbA1bEyBOVU1M
R0xBVVRPIBVdIDMuMi4gRmlsZSBCYXNlZCBQcm90b2NvbA1bEyBOVU1MR0xBVVRPIBVdIDMuMy4g
U29ja2V0IEJhc2VkIFByb3RvY29sDVsTIE5VTUxHTEFVVE8gFV0gMy40LiBUaW1lLVN0YW1wIFBy
b3RvY29sIHZpYSBIVFRQDQ1bTm90ZSBhdCBsZWFzdCBvbmUgbXVjaCBiZSBzdXBwb3J0ZWQgIV0N
DQ0AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAABAAAWwQAAFwEAAB8BwAAFAgAAAUJAAAuCQAAqAkAAHQKAAC/DQAA
wA0AAEEPAABCDwAATg8AAE8PAABoDwAAbQ8AAJcPAACYDwAApA8AAKUPAADPDwAA1A8AAC4QAAAv
EAAAOxAAADwQAABrEAAAbBAAAHgQAAB5EAAAjhAAAJMQAAD1EAAA9hAAAAIRAAADEQAAFBEAABkR
AAB6EQAAexEAAIcRAACIEQAAphEAAKcRAACzEQAAtBEAAN0RAADeEQAA6hEAAOsRAADxEQAA9hEA
AEASAABEEgAAfBIAAH0SAACJEgAAihIAAMESAADGEgAAehMAAHsTAACHEwAAiBMAAMYTAADLEwAA
3xMAAOATAADsEwAA7RMAAAwUAAASFAAADRcAAA4XAAAaFwAAGxcAADYXAAA8FwAAtBcAALgXAAC5
GAAAuhgAAMYYAADHGAAAARkAAAcZAABNGQAAThkAAP0A/fn9+f35/QD06/Tr9OX06/Tr9OX06/Tr
9Ov06/Tl9Ov06/Tl9Ov06/Tr9Ov06/Tr9OX03/Tr9Ov03/Tr9Ov05fTr9Ov05fTr9Ov05fTl9Ov0
6/Tl9OsAAAs2CIFQSgMAbUgJBAs1CIFQSgMAbUgJBBEDagAAAABQSgMAVQgBbUgJBAhQSgMAbUgJ
BAAHNQiBbUgJCARtSAkIWAAEAAABBAAAAgQAABAEAAARBAAAWgQAAFsEAABxBAAAcgQAALsEAAAB
BQAARAUAAIkFAADPBQAAFwYAAF8GAACkBgAA6wYAADMHAAB7BwAAfAcAAL4HAAADCAAASAgAAIQI
AADMCAAABAkAAAUJAABMCQAAlQkAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAA
AAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9
AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAA
AAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAA
AAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAA
AAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAA
AAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAEPAAAdAAQAAAEEAAACBAAAEAQAABEEAABaBAAAWwQAAHEEAAByBAAAuwQAAAEF
AABEBQAAiQUAAM8FAAAXBgAAXwYAAKQGAADrBgAAMwcAAHsHAAB8BwAAvgcAAAMIAABICAAAhAgA
AMwIAAAECQAABQkAAEwJAACVCQAA1gkAABoKAABdCgAApQoAAOgKAADpCgAAKwsAAG0LAACyCwAA
8AsAADkMAACADAAAkQwAAJIMAADaDAAAHw0AAGcNAACwDQAAwA0AAMENAAAKDgAACw4AAAwOAABF
DgAAdg4AAKYOAACnDgAArg4AAK8OAAD3DgAAQA8AAJYPAADoDwAALRAAAGkQAABqEAAAtxAAAPMQ
AAD0EAAARxEAAHkRAAClEQAA2xEAANwRAAA2EgAAexIAAM4SAAAWEwAAYhMAAHgTAAB5EwAA0BMA
AN0TAADeEwAALRQAAHgUAAChFAAAohQAALgUAAC5FAAA4xQAAOQUAAABFQAANRUAAGUVAACmFQAA
uhUAAPYVAAAyFgAAcxYAALEWAAD+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+
/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+
/v7+/v7+AAAAAAIBAWSVCQAA1gkAABoKAABdCgAApQoAAOgKAADpCgAAKwsAAG0LAACyCwAA8AsA
ADkMAACADAAAkQwAAJIMAADaDAAAHw0AAGcNAACwDQAAwA0AAMENAAAKDgAACw4AAAwOAABFDgAA
dg4AAKYOAACnDgAArg4AAK8OAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAA
AAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAA
AAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAA
AAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA
/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAA
AAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAA
AAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAAAA
AAAAAAAAAAABDwAAHa8OAAD3DgAAQA8AAJYPAADoDwAALRAAAGkQAABqEAAAtxAAAPMQAAD0EAAA
RxEAAHkRAAClEQAA2xEAANwRAAA2EgAAexIAAM4SAAAWEwAAYhMAAHgTAAB5EwAA0BMAAN0TAADe
EwAALRQAAHgUAAChFAAAohQAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAA
AP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAA
AAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAA
AAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9
AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAA
AAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAA
AAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAEPAAAdohQAALgUAAC5FAAA4xQAAOQUAAABFQAANRUAAGUVAACmFQAAuhUAAPYVAAAy
FgAAcxYAALEWAACyFgAA+RYAAAsXAAAMFwAAYRcAAKcXAADvFwAAJRgAACYYAABIGAAAghgAALcY
AAC4GAAADRkAAEsZAABMGQAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA
/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAA
AAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAA
AAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0A
AAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAA
AAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAA
AP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAQ8AAB2xFgAAshYAAPkWAAALFwAADBcAAGEXAACnFwAA7xcAACUYAAAmGAAASBgAAIIY
AAC3GAAAuBgAAA0ZAABLGQAATBkAAJ8ZAADqGQAA/BkAAP0ZAAAlGgAAJhoAAHIaAAC9GgAABhsA
AE8bAACaGwAA2hsAANsbAAAlHAAAbxwAALgcAAADHQAAPB0AAHsdAAB8HQAAzB0AACAeAABqHgAA
fB4AAH0eAADRHgAA+B4AAPkeAABPHwAAeR8AAHofAAB7HwAAgh8AAIMfAACgHwAAoR8AALkfAAC6
HwAA8x8AAPQfAABHIAAASCAAAJwgAACsIAAArSAAAP4gAAAwIQAAMSEAAH4hAADHIQAA2SEAANoh
AAAtIgAAcSIAAKciAACoIgAA+CIAAEEjAABjIwAAZCMAALgjAAABJAAAAiQAAFQkAAB0JAAAdSQA
AMokAAATJQAAOyUAADwlAACPJQAA2CUAABsmAABbJgAAXCYAAHsmAAB8JgAAyyYAAPEmAADyJgAA
RycAAJAnAAC/JwAAwCcAAP7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+
/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+
/v4AAAAAAgEBZE4ZAABaGQAAWxkAAF4ZAAC+GQAAxBkAAPsZAAB7GwAAiRsAAJsbAACcGwAAqBsA
AKkbAAC0GwAAuRsAAL4bAADKGwAA0hsAANgbAAAEHQAABR0AABEdAAASHQAAHx0AACQdAAA9HQAA
Ph0AAEodAABLHQAATR0AAFIdAAB9HQAAfh0AAIodAACLHQAAsR0AALUdAADNHQAAzh0AANodAADb
HQAA+R0AAB0eAAB+HgAAfx4AAIseAACMHgAAoB4AAKQeAAD6HgAA+x4AAAcfAAAIHwAArx8AALcf
AAC7HwAAvB8AAMgfAADJHwAA9R8AAPYfAAACIAAAAyAAAEkgAAD78vvs5Oz71/vy+/L7yLT7p9f7
8vvy+6H78vvy+6H78vvy+6H78vvy++z78vvy+6H78vvy+6H78vvy+/L78vsAAAALNQiBUEoDAG1I
CQQZAQiBBEgBAAVodY1iBgdIAABQSgMAbUgJBCYBCIEESAEABWh1jWIGB0gAADUIgVBKAwBXygcB
AQB2jWIGbUgJBAAcAAiBDCoHUEoDAGNIAQBkaHeNYgZnSAAAbUgJBAAZAQiBBEgBAAVodo1iBgdI
AABQSgMAbUgJBA4MKgc1CIFQSgMAbUgJBAALDCoHUEoDAG1ICQQRA2oAAAAAUEoDAFUIAW1ICQQI
UEoDAG1ICQQ/TBkAAJ8ZAADqGQAA/BkAAP0ZAAAlGgAAJhoAAHIaAAC9GgAABhsAAE8bAACaGwAA
2hsAANsbAAAlHAAAbxwAALgcAAADHQAAPB0AAHsdAAB8HQAAzB0AACAeAABqHgAAfB4AAH0eAADR
HgAA+B4AAPkeAABPHwAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAA
AAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAA
AAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA
/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAA
AAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAA
AAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0A
AAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAQ8AAB1PHwAAeR8AAHofAAB7HwAAgh8AAIMfAACgHwAAoR8AALkfAAC6HwAA8x8AAPQfAABH
IAAASCAAAJwgAACsIAAArSAAAP4gAAAwIQAAMSEAAH4hAADHIQAA2SEAANohAAAtIgAAcSIAAKci
AACoIgAA+CIAAEEjAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAA
AAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAA
AAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9
AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAA
AAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAA
AAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAA
AAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAAAAAAAAAAAA
AAABDwAAHUkgAABKIAAAViAAAFcgAACuIAAAryAAALsgAAC8IAAAMiEAADMhAAA/IQAAQCEAANsh
AADcIQAA6CEAAOkhAACpIgAAqiIAALYiAAC3IgAAZSMAAGYjAAByIwAAcyMAAAMkAAAEJAAAECQA
ABEkAAB2JAAAdyQAAIMkAACEJAAAPSUAAD4lAABKJQAASyUAADYmAAA7JgAAfSYAAH4mAACKJgAA
iyYAAJUmAACZJgAA8yYAAPQmAAAAJwAAAScAACEnAAAlJwAAwScAAMInAADOJwAAzycAAPUnAAD5
JwAA2CkAANkpAADlKQAA5ikAACkqAAAtKgAAeSoAAHoqAACGKgAAhyoAAJgqAACgKgAAzCoAAM0q
AADZKgAA2ioAANwqAADhKgAARS0AAEYtAABSLQAAUy0AAGctAABxLQAA2C0AANktAADlLQAA5i0A
ABsuAAAfLgAA9vH28fbx9vH28fbx9vH28fbx9vH28fbx9vH28fbx9vH28fbx6/H28fbx6/H28fbx
6/H28fbx6/H28fbx6/H28fbx6/H28fbx6/H28fbx6/H28fbx1wAmAQiBBEgBAAVoeI1iBgdIAAA1
CIFQSgMAV8oHAQEAeI1iBm1ICQQACzUIgVBKAwBtSAkECFBKAwBtSAkEABEDagAAAABQSgMAVQgB
bUgJBABVQSMAAGMjAABkIwAAuCMAAAEkAAACJAAAVCQAAHQkAAB1JAAAyiQAABMlAAA7JQAAPCUA
AI8lAADYJQAAGyYAAFsmAABcJgAAeyYAAHwmAADLJgAA8SYAAPImAABHJwAAkCcAAL8nAADAJwAA
BygAAAgoAAAfKAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAA
AAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAA
AAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAA
AAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAA
AAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA
/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAA
AAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AQ8AAB3AJwAABygAAAgoAAAfKAAAICgAAEsoAABMKAAAbSgAAJooAADXKAAA2CgAABwpAAA4KQAA
OSkAAFkpAAB4KQAApikAANYpAADXKQAALioAAHgqAADLKgAA+SoAAPoqAAAVKwAANysAAIArAACg
KwAAwisAAAgsAAAxLAAAUywAAHUsAACXLAAA1iwAAOksAAAKLQAAQy0AAEQtAACNLQAAji0AANct
AAAyLgAASi4AAEsuAABrLgAAiC4AAMEuAADeLgAADS8AACovAABaLwAAdy8AAKYvAADDLwAAADAA
AB0wAABZMAAAdjAAALwwAADZMAAA9jAAADYxAAA3MQAAfzEAAIAxAADJMQAAyjEAACEyAABnMgAA
aDIAAK4yAAD5MgAA+jIAABwzAABJMwAAbzMAAHAzAACwMwAA2jMAANszAAAfNAAAWjQAAFs0AACb
NAAA2jQAANs0AAAdNQAAZjUAAGc1AAC8NQAABzYAAFw2AACANgAAgTYAAJk2AADNNgAA+jYAACo3
AABjNwAAeDcAAP7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+
/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v4AAAAA
AgEBZB8oAAAgKAAASygAAEwoAABtKAAAmigAANcoAADYKAAAHCkAADgpAAA5KQAAWSkAAHgpAACm
KQAA1ikAANcpAAAuKgAAeCoAAMsqAAD5KgAA+ioAABUrAAA3KwAAgCsAAKArAADCKwAACCwAADEs
AABTLAAAdSwAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAA
AAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA
/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAA
AAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAA
AAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0A
AAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAA
AAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEP
AAAddSwAAJcsAADWLAAA6SwAAAotAABDLQAARC0AAI0tAACOLQAA1y0AADIuAABKLgAASy4AAGsu
AACILgAAwS4AAN4uAAANLwAAKi8AAFovAAB3LwAApi8AAMMvAAAAMAAAHTAAAFkwAAB2MAAAvDAA
ANkwAAD2MAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAA
AAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9
AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAA
AAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAA
AAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAA
AAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAA
AAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQ8A
AB0fLgAAIC4AACMuAAAkLgAAazEAAHAxAACBMQAAgjEAAI4xAACPMQAAozEAAK0xAADLMQAAzDEA
ANgxAADZMQAAAzIAAAYyAACvMgAAsDIAALwyAAC9MgAAyzIAANAyAAAeNQAAHzUAACs1AAAsNQAA
OzUAAEA1AABoNQAAaTUAAHU1AAB2NQAAjTUAAJU1AAAINgAACTYAABU2AAAWNgAAKDYAACw2AABT
OgAAVDoAAGA6AABhOgAAhDoAAIg6AADBOgAAwjoAAM46AADPOgAAATsAAAU7AAAWOwAAFzsAACM7
AAAkOwAANzsAADs7AACrOwAArDsAALg7AAC5OwAA0TsAANU7AAD/OwAAADwAAAw8AAANPAAAIjwA
ACY8AAA3PAAAODwAAEQ8AABFPAAAWjwAAPLj1tHL0cLRwtHL0cLRwtHL0cLRwtHL0cLRwtHL0cLR
wtHL0cLRwtHL0cLRwtHL0cLRwtHL0cLRwtHL0cLRwtHL0cLRwtHL0cLRwtEAAAAAEQNqAAAAAFBK
AwBVCAFtSAkECzUIgVBKAwBtSAkECFBKAwBtSAkEABkACIFQSgMAY0gBAGRoeI1iBmdIAABtSAkE
HAAIgQwqB1BKAwBjSAEAZGh4jWIGZ0gAAG1ICQQAGQEIgQRIAQAFaHiNYgYHSAAAUEoDAG1ICQQA
TPYwAAA2MQAANzEAAH8xAACAMQAAyTEAAMoxAAAhMgAAZzIAAGgyAACuMgAA+TIAAPoyAAAcMwAA
STMAAG8zAABwMwAAsDMAANozAADbMwAAHzQAAFo0AABbNAAAmzQAANo0AADbNAAAHTUAAGY1AABn
NQAAvDUAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAA
AAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAA
AAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAA
AAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA
/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAA
AAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAA
AAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEPAAAd
vDUAAAc2AABcNgAAgDYAAIE2AACZNgAAzTYAAPo2AAAqNwAAYzcAAHg3AAChNwAA4jcAAPk3AAAq
OAAAbTgAALA4AADzOAAALDkAAHA5AACzOQAA+TkAAPo5AABBOgAAUToAAFI6AACmOgAAvzoAAMA6
AAAUOwAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAA
AP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAA
AAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAA
AAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9
AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAA
AAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAA
AAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQ8AAB14
NwAAoTcAAOI3AAD5NwAAKjgAAG04AACwOAAA8zgAACw5AABwOQAAszkAAPk5AAD6OQAAQToAAFE6
AABSOgAApjoAAL86AADAOgAAFDsAABU7AABmOwAAqjsAAP47AAA1PAAANjwAAIs8AADUPAAAGz0A
ABw9AABtPQAAtT0AAP09AABHPgAAjz4AANc+AAAnPwAAVT8AAFY/AACdPwAA8z8AAD1AAACPQAAA
10AAAOZAAADnQAAAPUEAAHxBAADTQQAA7EEAAO1BAABEQgAAmkIAAPBCAABHQwAAhEMAAIVDAADN
QwAA5EMAAOVDAAAARAAAN0QAAG5EAACnRAAAqEQAAPNEAAApRQAAKkUAAH5FAADBRQAAwkUAAPlF
AABPRgAAm0YAALVGAAC2RgAACkcAAFNHAACERwAAhUcAAM9HAAAlSAAAQ0gAAERIAACMSAAA3EgA
ACJJAAA7SQAAPEkAAIhJAADSSQAAKEoAAHJKAACESgAAhUoAANlKAAAgSwAAVUsAAFZLAABXSwAA
ZUsAAP7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+
/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v4AAAAAAgEBZBQ7
AAAVOwAAZjsAAKo7AAD+OwAANTwAADY8AACLPAAA1DwAABs9AAAcPQAAbT0AALU9AAD9PQAARz4A
AI8+AADXPgAAJz8AAFU/AABWPwAAnT8AAPM/AAA9QAAAj0AAANdAAADmQAAA50AAAD1BAAB8QQAA
00EAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9
AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAA
AAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAA
AAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAA
AAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAA
AAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA
/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEPAAAdWjwA
AF48AAAdPQAAHj0AACo9AAArPQAARj0AAEw9AADYPgAA2T4AAOU+AADmPgAA9T4AAPs+AACePwAA
nz8AAKs/AACsPwAAwj8AAMY/AAA+QAAAP0AAAEtAAABMQAAAh0AAAItAAADoQAAA6UAAAPVAAAD2
QAAAD0EAABNBAAB9QQAAfkEAAIpBAACLQQAAxEEAAMpBAADuQQAA70EAAPtBAAD8QQAAC0IAAA9C
AABFQgAARkIAAFJCAABTQgAAeEIAAHxCAACbQgAAnEIAAKhCAACpQgAA1EIAANhCAADxQgAA8kIA
AP5CAAD/QgAAJ0MAACtDAABIQwAASUMAAFVDAABWQwAAc0MAAHdDAAD0RAAA9UQAAAFFAAACRQAA
BEUAAAhFAAArRQAALEUAADhFAAA5RQAAX0UAAGpFAADDRQAAxEUAANBFAADRRQAA2kUAAOhFAAD6
RQAA+0UAAAdGAAAIRgAAt0YAAPn06/Tr9Pn06/Tr9Pn06/Tr9Pn06/Tr9Pn06/Tr9Pn06/Tr9Pn0
6/Tr9Pn06/Tr9Pn06/Tr9Pn06/Tr9Pn06/Tr9Pn06/Tr9Pn06/Tr9OX06/Tr9Pn06/Tr9AAAAAAL
NgiBUEoDAG1ICQQRA2oAAAAAUEoDAFUIAW1ICQQIUEoDAG1ICQQACzUIgVBKAwBtSAkEAFrTQQAA
7EEAAO1BAABEQgAAmkIAAPBCAABHQwAAhEMAAIVDAADNQwAA5EMAAOVDAAAARAAAN0QAAG5EAACn
RAAAqEQAAPNEAAApRQAAKkUAAH5FAADBRQAAwkUAAPlFAABPRgAAm0YAALVGAAC2RgAACkcAAFNH
AAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAA
AAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAA
AAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA
/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAA
AAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAA
AAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0A
AAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAAAAAAAAAAAAAAABDwAAHbdGAAC4
RgAAxEYAAMVGAACGRwAAh0cAAJNHAACURwAApkcAAKpHAADQRwAA0UcAAN1HAADeRwAAAEgAAARI
AACNSAAAjkgAAJpIAACbSAAAvkgAAMJIAADTSQAA1EkAAOBJAADhSQAAEEoAABRKAACGSgAAh0oA
AJNKAACUSgAAMEsAADRLAADqSwAA60sAAPdLAAD4SwAAIUwAACJMAAAuTAAAL0wAAEtMAABMTAAA
WEwAAFlMAAB3TAAAeEwAAIRMAACFTAAA1EwAAPbx9vH28fbx6/H28fbx6/H28fbx6/H28fbx6/H2
8fbx6/H28fbx9vH28fbx9vH28fbxAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAACzUIgVBKAwBtSAkECFBKAwBtSAkEABEDagAAAABQSgMAVQgBbUgJBAAyU0cAAIRH
AACFRwAAz0cAACVIAABDSAAAREgAAIxIAADcSAAAIkkAADtJAAA8SQAAiEkAANJJAAAoSgAAckoA
AIRKAACFSgAA2UoAACBLAABVSwAAVksAAFdLAABlSwAAZksAAKxLAADoSwAA6UsAACBMAABKTAAA
/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAA
AAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAA
AAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0A
AAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAA
AAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAA
AP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAA
AAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQ8AAB1lSwAAZksA
AKxLAADoSwAA6UsAACBMAABKTAAAdkwAAKlMAACqTAAA0kwAANNMAADUTAAA/v7+/v7+/v7+/v7+
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAgEBDEpMAAB2TAAA
qUwAAKpMAADSTAAA00wAANRMAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAA
AAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEPAAAGLAAxkGgBH7CC
LiCwxkEhsIAEIrCABCOQiQUkkIkFJbAAABewxAIYsMQCDJDEAgAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAASABAACgABAFsA
DwACAAAAAAAAADgAAEDx/wIAOAAMAAYATgBvAHIAbQBhAGwAAAACAAAAGABDShgAX0gBBGFKGABt
SAwEc0gMBHRIDAQAAAAAAAAAAAAAAAAAAAAAAAAyAEFA8v+hADIADAARAFAAbwBsAGkAYwBlACAA
cABhAHIAIABkAOkAZgBhAHUAdAAAAAAAAAAAAAAAAAA4AFpAAQDyADgADAAKAFQAZQB4AHQAZQAg
AGIAcgB1AHQAAAACAA8AEABDShQAT0oEAFFKBABhShQAAAAAANRIAAAFAACCAAAEAP////8ABAAA
ThkAAEkgAAAfLgAAWjwAALdGAADUTAAAJwAAAC4AAAAxAAAANgAAADsAAAA9AAAAAAQAAJUJAACv
DgAAohQAAEwZAABPHwAAQSMAAB8oAAB1LAAA9jAAALw1AAAUOwAA00EAAFNHAABKTAAA1EwAACgA
AAAqAAAAKwAAACwAAAAvAAAAMAAAADIAAAA0AAAANQAAADcAAAA4AAAAOgAAADwAAAA+AAAAQAAA
AAAEAACxFgAAwCcAAHg3AABlSwAA1EwAACkAAAAtAAAAMwAAADkAAAA/AAAA//8CAAAABwBVAG4A
awBuAG8AdwBuAAYAUABJAE4ASwBBAFMAQQsAAE4LAACXCwAApAsAAC4MAAA7DAAAawwAAHgMAAD1
DAAAAg0AAHoNAACHDQAApg0AALMNAADdDQAA6g0AAHwOAACJDgAAeg8AAIcPAADfDwAA7A8AAA0T
AAAaEwAAuRQAAMYUAABNFQAAWhUAAJsXAACoFwAABBkAABEZAAA9GQAAShkAAH0ZAACKGQAAzRkA
ANoZAAB+GgAAixoAAPoaAAAHGwAAuxsAAMgbAAD1GwAAAhwAAEkcAABWHAAArhwAALscAAAyHQAA
Px0AANsdAADoHQAAqR4AALYeAABlHwAAch8AAAMgAAAQIAAAdiAAAIMgAAA9IQAASiEAAH0iAACK
IgAA8yIAAAAjAADBIwAAziMAANglAADlJQAAeSYAAIYmAADMJgAA2SYAAEUpAABSKQAA2CkAAOUp
AACBLQAAji0AAMstAADYLQAAry4AALwuAAAeMQAAKzEAAGgxAAB1MQAACDIAABUyAABTNgAAYDYA
AME2AADONgAAFjcAACM3AACrNwAAuDcAAP83AAAMOAAANzgAAEQ4AAAdOQAAKjkAANg6AADlOgAA
njsAAKs7AAA+PAAASzwAAOg8AAD1PAAAfT0AAIo9AADuPQAA+z0AAEU+AABSPgAAmz4AAKg+AADx
PgAA/j4AAEg/AABVPwAA9EAAAAFBAAArQQAAOEEAAMNBAADQQQAA+kEAAAdCAAC3QgAAxEIAAIZD
AACTQwAA0EMAAN1DAACNRAAAmkQAANNFAADgRQAAhkYAAJNGAADqRwAA90cAACFIAAAuSAAAS0gA
AFhIAAB3SAAAhEgAANRIAAATNZUAEzWVABM1lQATNZUAEzWVABM1lQATNZUAEzWVABM1lQATNZUA
EzWVABM1lQATNZUAEzWVABM1lQATNZUAEzWVABM1lQATNZUAEzWVABM1lQATNZUAEzWVABM1lQAT
NZUAEzWVABM1lQATNZUAEzWVABM1lQATNZUAEzWVABM1lQATNZUAEzWVABM1lQATNZUAEzWVABM1
lQATNZUAEzWVABM1lQATNZUAEzWVABM1lQATNZUAEzWVABM1lQATNZUAEzWVABM1lQATNZUAEzWV
ABM1lQATNZUAEzWVABM1lQATNZUAEzWVABM1lQATNZUAEzWVABM1lQATNZUAEzWVABM1lQATNZUA
EzWVABM1lQATNZUAEzWVABM1lQATNZUAEzWVABM1lQATNZUAEzWVAAAAAABHCAAATwgAAOkKAAD2
CgAAFgsAACQLAAAGDAAAFAwAAFgMAABmDAAAKg0AADgNAAC3DwAAxQ8AAOQQAADwEAAAOBEAAEYR
AABVEQAAYxEAAL0RAADGEQAA0xEAAN4RAAA1EgAAPBIAACETAAAvEwAAKRQAADcUAABQFAAAXRQA
AG0UAACAFAAAihQAAJcUAADtFAAA+hQAAGIVAABrFQAArxUAAL0VAADTFQAA3hUAAAMWAAAOFgAA
ZRkAAHgZAAC7GgAAxBoAADcbAABFGwAApCMAALAjAADRIwAA4yMAAE8kAABcJAAAiyQAAJgkAACg
JAAAriQAALgkAADGJAAAPCUAAEklAABtJQAAdiUAAH4lAACKJQAAjCUAAJclAACsJQAAtCUAALol
AADIJQAAGiYAACgmAACJJgAAlyYAAP0mAAAGJwAASScAAFInAABtJwAAeycAAKYnAAC1JwAA1ScA
AN4nAAD4JwAABigAAHsoAACMKAAA7ygAAAUpAACdKQAAqykAAMApAADIKQAASyoAAFkqAABuKgAA
dCoAAMQqAADOKgAAECsAAB0rAABdKwAAbSsAAIMrAACIKwAAqSsAALkrAAADLAAAFiwAAF0sAABw
LAAA3SwAAOosAABXLQAAZS0AAN8tAADrLQAA9S0AAAIuAAA1LgAAQy4AAHAuAAB+LgAAoi4AAK0u
AAD9LgAACy8AABAvAAAbLwAAJC8AAC8vAAA2LwAAQC8AAFwvAABmLwAAhi8AAJ0vAAClLwAAry8A
AN4vAADqLwAAXjAAAGswAACFMAAAiDAAAKYwAACsMAAAtTAAALkwAADHMAAAzDAAANEwAADTMAAA
4TAAAOkwAAAyMQAAOjEAAF0xAABkMQAA9TEAAP4xAAA+MgAASDIAAGIyAAB0MgAAgTIAAIgyAADt
MgAA+DIAAP0yAAALMwAAGjMAACgzAABrMwAAdzMAAHszAACHMwAA/DMAAAM0AAAZNAAAKDQAAEo0
AABSNAAANzUAAEM1AABzNQAAdjUAAJQ1AACfNQAASTcAAE43AAC7NwAAxzcAABA4AAAgOAAASzgA
AFk4AACROAAAnTgAAAw5AAAZOQAA0TkAAN45AAA5OwAARjsAAEs7AABSOwAAYDsAAGw7AACuOwAA
vDsAANo7AADoOwAATjwAAFw8AAD4PAAABz0AAI09AACcPQAA0z8AAOI/AABAQAAARkAAAMFAAADH
QAAAtEEAAL9BAABGQgAATUIAAEtDAABSQwAAckMAAHlDAADgQwAA7EMAACtEAAA3RAAAXUQAAGBE
AABJRQAAUEUAAHdFAAB8RQAAtEUAAL1FAADjRQAA9UUAAFVGAABfRgAAnUYAAKRGAADARgAAx0YA
ABVHAAAfRwAA1kgAAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwA
BwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAH
ABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcA
HAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAc
AAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwA
BwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAH
ABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABsABwAcAAcA
HAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAc
AAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwA
BwAcAAcAHAAHABwABwAcAAcAHAAHABwABwD//xQAAAAGAFAASQBOAEsAQQBTADAARgA6AFwARABB
AFQAQQBcAEQARQBOAEkAUwBcAEIAbwB1AGwAbwB0AFwAcgBmAGMAMwAxADYAMQAgAGkAbgB0AGUA
cgBvAHAAKwByAGUAdgArAG4AdQBtAC4AZABvAGMABgBQAEkATgBLAEEAUwAwAEYAOgBcAEQAQQBU
AEEAXABEAEUATgBJAFMAXABCAG8AdQBsAG8AdABcAHIAZgBjADMAMQA2ADEAIABpAG4AdABlAHIA
bwBwACsAcgBlAHYAKwBuAHUAbQAuAGQAbwBjAAYAUABJAE4ASwBBAFMAYQBDADoAXABXAEkATgA5
ADgAXABBAHAAcABsAGkAYwBhAHQAaQBvAG4AIABEAGEAdABhAFwATQBpAGMAcgBvAHMAbwBmAHQA
XABXAG8AcgBkAFwARQBuAHIAZQBnAGkAcwB0AHIAZQBtAGUAbgB0ACAAYQB1AHQAbwBtAGEAdABp
AHEAdQBlACAAZABlAHIAZgBjADMAMQA2ADEAIABpAG4AdABlAHIAbwBwACsAcgBlAHYAKwBuAHUA
bQAuAGEAcwBkAAYAUABJAE4ASwBBAFMAMABGADoAXABEAEEAVABBAFwARABFAE4ASQBTAFwAQgBv
AHUAbABvAHQAXAByAGYAYwAzADEANgAxACAAaQBuAHQAZQByAG8AcAArAHIAZQB2ACsAbgB1AG0A
LgBkAG8AYwAGAFAASQBOAEsAQQBTADAARgA6AFwARABBAFQAQQBcAEQARQBOAEkAUwBcAEIAbwB1
AGwAbwB0AFwAcgBmAGMAMwAxADYAMQAgAGkAbgB0AGUAcgBvAHAAKwByAGUAdgArAG4AdQBtAC4A
ZABvAGMABgBQAEkATgBLAEEAUwBhAEMAOgBcAFcASQBOADkAOABcAEEAcABwAGwAaQBjAGEAdABp
AG8AbgAgAEQAYQB0AGEAXABNAGkAYwByAG8AcwBvAGYAdABcAFcAbwByAGQAXABFAG4AcgBlAGcA
aQBzAHQAcgBlAG0AZQBuAHQAIABhAHUAdABvAG0AYQB0AGkAcQB1AGUAIABkAGUAcgBmAGMAMwAx
ADYAMQAgAGkAbgB0AGUAcgBvAHAAKwByAGUAdgArAG4AdQBtAC4AYQBzAGQADABEAGUAbgBpAHMA
IABQAGkAbgBrAGEAcwAyAEMAOgBcAEYAaQBsAGUAcwBcAEQAYQB0AGEAXABpAGUAdABmAFwAdABz
AHMAXAByAGYAYwAzADEANgAxACAAaQBuAHQAZQByAG8AcAArAHIAZQB2ACsAbgB1AG0ALgBkAG8A
YwAMAEQAZQBuAGkAcwAgAFAAaQBuAGsAYQBzAEgAQwA6AFwAdwBpAG4AZABvAHcAcwBcAFQARQBN
AFAAXABFAG4AcgBlAGcAaQBzAHQAcgBlAG0AZQBuAHQAIABhAHUAdABvAG0AYQB0AGkAcQB1AGUA
IABkAGUAcgBmAGMAMwAxADYAMQAgAGkAbgB0AGUAcgBvAHAAKwByAGUAdgArAG4AdQBtAC4AYQBz
AGQADABEAGUAbgBpAHMAIABQAGkAbgBrAGEAcwBIAEMAOgBcAHcAaQBuAGQAbwB3AHMAXABUAEUA
TQBQAFwARQBuAHIAZQBnAGkAcwB0AHIAZQBtAGUAbgB0ACAAYQB1AHQAbwBtAGEAdABpAHEAdQBl
ACAAZABlAHIAZgBjADMAMQA2ADEAIABpAG4AdABlAHIAbwBwACsAcgBlAHYAKwBuAHUAbQAuAGEA
cwBkAAwARABlAG4AaQBzACAAUABpAG4AawBhAHMAMgBDADoAXABGAGkAbABlAHMAXABEAGEAdABh
AFwAaQBlAHQAZgBcAHQAcwBzAFwAcgBmAGMAMwAxADYAMQAgAGkAbgB0AGUAcgBvAHAAIAB0AGUA
cwB0AGkAbgBnAC4AZABvAGMA/0ABgAEAWgAAAFoAAAAYc2QAAQAAAFoAAAAAAAAAWgAAAAAAAAAC
EAAAAAAAAADUSAAAUAAACABAAAAFAAAARxaQAQAAAgIGAwUEBQIDBIc6AAAAAAAAAAAAAAAAAAD/
AAAAAAAAAFQAaQBtAGUAcwAgAE4AZQB3ACAAUgBvAG0AYQBuAAAANRaQAQIABQUBAgEHBgIFBwAA
AAAAAAAQAAAAAAAAAAAAAACAAAAAAFMAeQBtAGIAbwBsAAAAMyaQAQAAAgsGBAICAgICBIc6AAAA
AAAAAAAAAAAAAAD/AAAAAAAAAEEAcgBpAGEAbAAAADs1kAGAAAICBgkEAgUIAwSHAgAAAAAHCBAA
AAAAAAAAnwACAAAAAABNAFMAIABNAGkAbgBjAGgAbwAAAD81kAEAAAIHAwkCAgUCBASHOgAAAAAA
AAAAAAAAAAAA/wAAAAAAAABDAG8AdQByAGkAZQByACAATgBlAHcAAAAiAAQAcIiIAADwxAIAAKkB
AAAAAGyUYiZslGImAAAAAAIAAAAAAIkKAAANPAAAAQAeAAAABAADEIAAAAAAAAAAAAAAAAEAAQAA
AAEAAAAAAAAAJAMA8BAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAApQbAB7QAtACBgRIwAAAQ
ABkAZAAAABkAAAC/SQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAIAAAAAAP//EgAAAAAAAAAaACAAIAAgACAAIAAgACAAIAAg
ACAAIAAgACAAIAAgACAASQBuAHQAZQByAG4AZQB0ACAAWAAAAAAAAAAGAFAASQBOAEsAQQBTAAwA
RABlAG4AaQBzACAAUABpAG4AawBhAHMAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA/v8AAAQKAgAAAAAAAAAAAAAAAAAA
AAAAAQAAAOCFn/L5T2gQq5EIACsns9kwAAAAiAEAABEAAAABAAAAkAAAAAIAAACYAAAAAwAAALwA
AAAEAAAAyAAAAAUAAADYAAAABgAAAOQAAAAHAAAA8AAAAAgAAAAEAQAACQAAABwBAAASAAAAKAEA
AAoAAABEAQAADAAAAFABAAANAAAAXAEAAA4AAABoAQAADwAAAHABAAAQAAAAeAEAABMAAACAAQAA
AgAAAOQEAAAeAAAAGwAAACAgICAgICAgICAgICAgICBJbnRlcm5ldCBYAAAeAAAAAQAAAAAgICAe
AAAABwAAAFBJTktBUwAgHgAAAAEAAAAASU5LHgAAAAEAAAAASU5LHgAAAAsAAABOb3JtYWwuZG90
ACAeAAAADQAAAERlbmlzIFBpbmthcwAgICAeAAAAAgAAADIAbmkeAAAAEwAAAE1pY3Jvc29mdCBX
b3JkIDguMABlQAAAAAAAAAAAAAAAQAAAAAAID3ebuMEBQAAAAAAID3ebuMEBAwAAAAEAAAADAAAA
iQoAAAMAAAANPAAAAwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAP7/AAAECgIAAAAAAAAAAAAAAAAAAAAAAAIAAAAC
1c3VnC4bEJOXCAArLPmuRAAAAAXVzdWcLhsQk5cIACss+a5MAQAACAEAAAwAAAABAAAAaAAAAA8A
AABwAAAABQAAAIAAAAAGAAAAiAAAABEAAACQAAAAFwAAAJgAAAALAAAAoAAAABAAAACoAAAAEwAA
ALAAAAAWAAAAuAAAAA0AAADAAAAADAAAAOcAAAACAAAA5AQAAB4AAAAHAAAAKioqKioqAAADAAAA
gAAAAAMAAAAeAAAAAwAAAL9JAAADAAAAMRUIAAsAAAAAAAAACwAAAAAAAAALAAAAAAAAAAsAAAAA
AAAAHhAAAAEAAAAbAAAAICAgICAgICAgICAgICAgIEludGVybmV0IFgADBAAAAIAAAAeAAAABgAA
AFRpdHJlAAMAAAABAAAAAAAAmAAAAAMAAAAAAAAAIAAAAAEAAAA2AAAAAgAAAD4AAAABAAAAAgAA
AAoAAABfUElEX0dVSUQAAgAAAOQEAABBAAAATgAAAHsARABFADgAMwAzADUAMgA5AC0AMgA0ADUA
MQAtADEAMQBEADYALQBCAEEANgA3AC0AMAAwADAAMQAwADIARQAxADYARQBDADkAfQAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAABAAAAAgAAAAMAAAAEAAAABQAAAAYAAAAHAAAACAAAAAkAAAAK
AAAACwAAAAwAAAANAAAADgAAAA8AAAAQAAAAEQAAABIAAAATAAAAFAAAABUAAAAWAAAAFwAAABgA
AAAZAAAAGgAAABsAAAAcAAAAHQAAAB4AAAAfAAAAIAAAACEAAAAiAAAAIwAAACQAAAAlAAAAJgAA
ACcAAAAoAAAAKQAAACoAAAArAAAALAAAAC0AAAAuAAAALwAAADAAAAAxAAAAMgAAADMAAAA0AAAA
NQAAADYAAAA3AAAAOAAAADkAAAA6AAAAOwAAADwAAAA9AAAAPgAAAD8AAABAAAAAQQAAAP7///9D
AAAARAAAAEUAAABGAAAARwAAAEgAAABJAAAASgAAAEsAAABMAAAA/v///04AAABPAAAAUAAAAFEA
AABSAAAAUwAAAFQAAAD+////VgAAAFcAAABYAAAAWQAAAFoAAABbAAAAXAAAAP7////9////XwAA
AP7////+/////v//////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
/////////////////////////1IAbwBvAHQAIABFAG4AdAByAHkAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAWAAUB//////////8DAAAABgkCAAAAAADAAAAAAAAA
RgAAAABgCs+Vm7jBAWB055WbuMEBYQAAAIAAAAAAAAAAMQBUAGEAYgBsAGUAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA4AAgD///////////////8A
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABCAAAAXRUAAAAAAABXAG8AcgBkAEQA
bwBjAHUAbQBlAG4AdAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAGgAC
AQUAAAD//////////wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAuggAA
AAAAAAUAUwB1AG0AbQBhAHIAeQBJAG4AZgBvAHIAbQBhAHQAaQBvAG4AAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAoAAIBAgAAAAQAAAD/////AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAATQAAAAAQAAAAAAAABQBEAG8AYwB1AG0AZQBuAHQAUwB1AG0AbQBhAHIAeQBJAG4AZgBv
AHIAbQBhAHQAaQBvAG4AAAAAAAAAAAAAADgAAgH///////////////8AAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAABVAAAAABAAAAAAAAABAEMAbwBtAHAATwBiAGoAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEgACAQEAAAAGAAAA/////wAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABqAAAAAAAAAE8AYgBqAGUAYwB0
AFAAbwBvAGwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAWAAEA
////////////////AAAAAAAAAAAAAAAAAAAAAAAAAABgdOeVm7jBAWB055WbuMEBAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAD///////////////8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAABAAAA/v//////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
/////////////////////wEA/v8DCgAA/////wYJAgAAAAAAwAAAAAAAAEYYAAAARG9jdW1lbnQg
TWljcm9zb2Z0IFdvcmQACgAAAE1TV29yZERvYwAQAAAAV29yZC5Eb2N1bWVudC44APQ5snEAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAA

--------------DEBC19282E4CC72BCBD4EA5E--



Received: by above.proper.com (8.11.6/8.11.3) id g1IG7DM25534 for ietf-pkix-bks; Mon, 18 Feb 2002 08:07:13 -0800 (PST)
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 g1IG7B325527 for <[e-mail]>; Mon, 18 Feb 2002 08:07:11 -0800 (PST)
Received: from [128.89.88.34] (comsec.bbn.com [128.89.88.34]) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id LAA07448 for <[e-mail]>; Mon, 18 Feb 2002 11:07:07 -0500 (EST)
Mime-Version: 1.0
X-Sender: [e-mail]
Message-Id: <p0510030bb896d6068fab@[128.89.88.34]>
Date: Mon, 18 Feb 2002 11:07:40 -0500
To: pkix <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: agenda topics, WG last call for DPV requirements
Content-Type: multipart/alternative; boundary="============_-1198074017==_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>

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

Folks,

We are preparing the PKIX WG meeting agenda for March and thus 
soliciting requests for slots. Please send requests to both Tim and 
to me.

The current version of the DPV requirements ID has been posted:
  (draft-ietf-pkix-dpv-dpd-req-02.txt)

This version reflects changes based on comments since the last IETF 
meeting, where we announced that the document would go to WG last 
call.  So, let's begin the last call process today, and complete it 
by Monday, March 4.

Thanks,

Steve
--============_-1198074017==_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 { padding-top: 0 ; padding-bottom: 0 }
 --></style><title>agenda topics, WG last call for DPV
requirements</title></head><body>
<div>Folks,</div>
<div><br></div>
<div>We are preparing the PKIX WG meeting agenda for March and thus
soliciting requests for slots. Please send requests to both Tim and to
me.</div>
<div><br></div>
<div>The current version of the DPV requirements ID has been
posted:</div>
<div>&nbsp;(<font face="Courier New" size="+3"
color="#000000">draft-ietf-pkix-dpv-dpd-req-02.txt</font>)</div>
<div><br></div>
<div>This version reflects changes based on comments since the last
IETF meeting, where we announced that the document would go to WG last
call.&nbsp; So, let's begin the last call process today, and complete
it by Monday, March 4.</div>
<div><br></div>
<div>Thanks,</div>
<div><br></div>
<div>Steve</div>
</body>
</html>
--============_-1198074017==_ma============--


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g1IEkQb20121 for ietf-pkix-bks; Mon, 18 Feb 2002 06:46:26 -0800 (PST)
Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1IEkO320117 for <[e-mail]>; Mon, 18 Feb 2002 06:46:24 -0800 (PST)
Received: from lvn-m002.frlv.bull.fr (lvn-m002.frlv.bull.fr [129.184.62.72]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id PAA27096 for <[e-mail]>; Mon, 18 Feb 2002 15:48:07 +0100
Received: from bull.net ([129.184.37.97]) by lvn-m002.frlv.bull.fr (Lotus Domino Release 5.0.8) with ESMTP id 2002021815460595:197 ; Mon, 18 Feb 2002 15:46:05 +0100 
Message-ID: <[e-mail]>
Date: Mon, 18 Feb 2002 15:46:04 +0100
From: Denis Pinkas <[e-mail]>
Organization: Integris. A Bull Company
X-Mailer: Mozilla 4.7 [fr] (Win98; I)
X-Accept-Language: fr
MIME-Version: 1.0
To: pkix <[e-mail]>
Subject: Policy requirements for Time-Stamping Authorities
X-MIMETrack: Itemize by SMTP Server on LVN-M002/FR/BULL(Release 5.0.8 |June 18, 2001) at 18/02/2002 15:46:06, Serialize by Router on LVN-M002/FR/BULL(Release 5.0.8 |June 18, 2001) at 18/02/2002 15:46:24, Serialize complete at 18/02/2002 15:46:24
Content-Transfer-Encoding: 7bit
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>

ETSI has made available the document advertised at the last IETF meeting
about : "Policy requirements for Time-Stamping Authorities".

It is an exact copy of the document that will be officially published 
as soon as CWA 14167 (which is referenced in this document) becomes 
available.

It can be found at http://portal.etsi.org/sec/ts_102023v010101p.pdf

It is intended have a technical equivalent of this document 
in the form of an Informational RFC.

Denis


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g1IB2nx05897 for ietf-pkix-bks; Mon, 18 Feb 2002 03:02:49 -0800 (PST)
Received: from edelweb.fr (edelweb.fr [212.234.46.16]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1IB2l305892 for <[e-mail]>; Mon, 18 Feb 2002 03:02:47 -0800 (PST)
Received: from champagne.edelweb.fr (localhost.edelweb.fr [127.0.0.1]) by edelweb.fr with ESMTP id MAA09621 for <[e-mail]>; Mon, 18 Feb 2002 12:02:45 +0100 (MET)
Received: from champagne.edelweb.fr (champagne.edelweb.fr [193.51.14.161]) by edelweb.fr (nospam/1.3); Mon, 18 Feb 2002 12:02:45 +0100 (MET)
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 MAA28394 for <[e-mail]>; Mon, 18 Feb 2002 12:02:44 +0100 (MET)
From: Peter Sylvester <[e-mail]>
Received: (sylvest@localhost) by emeriau.edelweb.fr (8.7.6/8.6.6) id MAA16482 for [e-mail]; Mon, 18 Feb 2002 12:02:43 +0100 (MET)
Date: Mon, 18 Feb 2002 12:02:43 +0100 (MET)
Message-Id: <[e-mail]>
To: [e-mail]
Subject: Re: I-D ACTION:draft-ietf-pkix-pi-03.txt
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>

Hi, 

The proposal does not specify rules for Name Constraints of
this name form. 

The proposal extends the 'equivalence' of certificates
I am not sure whether it is necessary to allow/restrict the
usage of PIs, in particular global ones.

Peter
PS: This comment MUST NOT be regarded as a statement in favour or
against the concept of permanent identifiers. 


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g1I97rR22985 for ietf-pkix-bks; Mon, 18 Feb 2002 01:07:53 -0800 (PST)
Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1I97p322974 for <[e-mail]>; Mon, 18 Feb 2002 01:07:52 -0800 (PST)
Received: from lvn-m002.frlv.bull.fr (lvn-m002.frlv.bull.fr [129.184.62.72]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id KAA15494; Mon, 18 Feb 2002 10:09:31 +0100
Received: from bull.net ([129.184.37.97]) by lvn-m002.frlv.bull.fr (Lotus Domino Release 5.0.8) with ESMTP id 2002021810061942:135 ; Mon, 18 Feb 2002 10:06:19 +0100 
Message-ID: <[e-mail]>
Date: Mon, 18 Feb 2002 10:06:25 +0100
From: Denis Pinkas <[e-mail]>
Organization: Integris. A Bull Company
X-Mailer: Mozilla 4.7 [fr] (Win98; I)
X-Accept-Language: fr
MIME-Version: 1.0
To: Anders Rundgren <[e-mail]>
CC: [e-mail]
Subject: Re: I-D ACTION:draft-ietf-pkix-pi-03.txt
References: <[e-mail]> <009401c1b5a3$ea927cd0$0500a8c0@arport> <[e-mail]> <012201c1b633$93cd09c0$0500a8c0@arport>
X-MIMETrack: Itemize by SMTP Server on LVN-M002/FR/BULL(Release 5.0.8 |June 18, 2001) at 18/02/2002 10:06:19, Serialize by Router on LVN-M002/FR/BULL(Release 5.0.8 |June 18, 2001) at 18/02/2002 10:07:48, Serialize complete at 18/02/2002 10:07:48
Content-Transfer-Encoding: 7bit
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>

Anders,

> Denis,
> <snip>
> 
> >> So how do you fulfil 3039's DN uniqness requirement using the PI draft?
> 
> >DN uniqueness has to be fulfiled, whatever the content of any extension
> >(including the PI extension) may be.
> 
> Agreed.
> 
> >> Probably by *duplicating* the RUN, citizen number etc. in the DN, or
> >> creating nonsense disamabiguers.  Although its not a crime to duplicate
> >> data, I feel some resistance to creating a scheme based on that.
> 
> >There is a major difference. The number you place in the DN cannot tell you
> >it is, e.g. a RUN.
> 
> Agreed, but there _could_ be a variant of the PI-option that points to other
> elements holding the actual value.  This become particularly interesting
> if the descriptor is not restricted to EE-level but is also usable on CA-level,
> because then the existing population of pre-PI-certs could be PI-enabled
> by regenerating the CA-cert with old keys and expiration data.  I know that
> you don't support that, but I think that it is too much to ask CAs to recall
> all certificates out there, when there are workarounds available.  I also
> find it less attractive to be *forced* to put the "information that really counts"
> for access control etc. in new places, not directly supported by current
> crypto SW and associated GUI.
> 
> >It is a number that is not guaranteed to be unique by itself.
> 
> Agreed.
> 
> >Only the combination country+name+number is unique.
> 
> This is an *entirely* different discussion that is not PI-related but here is my
> disagreeing view on that:
> Another CA could *rightfully* issue a certificate with exactly these
> datas and elements but for anoher purpose (including another subject).

Correct. I should have said: 
"Only the combination country+name+number is unique for a given CA."

> At least 3039 does not do any assumptions that country indicates citizenship,
> it could be "blue oyster club" membership in some way associated with
> country in some way.  This is the X509 "Namespace" problem in a nutshell,
> as described in a recent posting.
> 
> >It happens that, in your example, the "number" being used is unique, but nobody can take
> >advantage of it. The PI information on the contrary is by itself unique.
> 
> Well, everybody using the aforementioned certificates *are* already
> taking these advantages including for access control based on "knowledge".

In a "private PKI", you can certainly have additional conventions. You may,
for example, state that all CNs are unique, even if additional attributes
are
present. But in an "open PKI" no one can take advantage of this additional
property and, in this WG, we are considering specifications for "open PKIs".

> >> If the PI draft is no longer limited to individuls, should there not be any
> >> kind of identifier telling what it denotes?
> 
> >Applicable to any entity, as the text says.
> 
> That's good, but what about the last paragraph in my question?

I could not clearly understand the last paragraph and the question. 
Would you rephrase it ?

Denis
 
> Anders


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g1FNKRE17187 for ietf-pkix-bks; Fri, 15 Feb 2002 15:20:27 -0800 (PST)
Received: from marte.ifxnw.cl (marte.ifxnw.cl [216.241.0.152]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1FNKP317182 for <[e-mail]>; Fri, 15 Feb 2002 15:20:25 -0800 (PST)
Received: from ropazo (unverified [216.241.20.226]) by marte.ifxnw.cl (Rockliffe SMTPRA 3.4.7) with SMTP id <[e-mail]>; Fri, 15 Feb 2002 20:16:14 -0400
From: "Roberto Opazo Gazmuri" <[e-mail]>
To: "Housley, Russ" <[e-mail]>
Cc: <[e-mail]>, <[e-mail]>, <[e-mail]>
Subject: RE: Comment on RFC 2459
Date: Fri, 15 Feb 2002 20:09:53 -0300
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 1 (Highest)
X-MSMail-Priority: High
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Importance: High
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>

Russ,

It is a little detail, but may be you could consider an equivalent treat of
issuer v/s subject and issuerAltName v/s subjectAltName fields.

In the PI discussion I said than the scope of the new syntax should be for
subjectAltName and for issuerAltName. I believe this attributes are plenty
equivalent, not only for their type, but for their purpose.

1.- A certificate has no meaning if you do not know the issuer and the
subject, so they are both equally critical information.

2.- In practice, naming an entity is equivalent than naming the special type
of entity that is the issuer.

At this time, it is difficult to imagine a certificate with an empty issuer
field (as it is with an empty subject field), but I think in the future PI
could be a better way to name entities when you are not interested in
building a directory tree. So it could be used for chaining purpose too.

At this time, the only clear is there is no reason to treat in different
ways issuer and subject fields, to see the future we have some time (I
hope).

Best regards,

Opazo, Roberto ([e-mail])
CEO - www.acepta.com
Certification Authority for Chile

Notes:

Page 19
The issuer field MUST contain a non-empty distinguished name (DN)

Page 24
The subject name MAY be carried in the subject field and/or the
subjectAltName extension.



Received: by above.proper.com (8.11.6/8.11.3) id g1FFjuP04154 for ietf-pkix-bks; Fri, 15 Feb 2002 07:45:56 -0800 (PST)
Received: from tholian.rsasecurity.com (mail.rsasecurity.com [204.167.112.129]) by above.proper.com (8.11.6/8.11.3) with SMTP id g1FFjr304149 for <[e-mail]>; Fri, 15 Feb 2002 07:45:53 -0800 (PST)
Received: from sdtihq24.securitydynamics.com by tholian.rsasecurity.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 15 Feb 2002 15:45:17 UT
Received: from ebola.securitydynamics.com (ebola.securid.com [192.168.7.4]) by sdtihq24.securid.com (Pro-8.9.3/Pro-8.9.3) with ESMTP id KAA10854 for <[e-mail]>; Fri, 15 Feb 2002 10:45:54 -0500 (EST)
Received: from exna00.securitydynamics.com (localhost [127.0.0.1]) by ebola.securitydynamics.com (8.10.2+Sun/8.9.1) with ESMTP id g1FFjrc10648 for <[e-mail]>; Fri, 15 Feb 2002 10:45:53 -0500 (EST)
Received: by exna00.securitydynamics.com with Internet Mail Service (5.5.2653.19) id <19KG7ZZL>; Fri, 15 Feb 2002 10:04:52 -0500
Received: from HOUSLEY-LAP.rsasecurity.com (HOUSLEY-LAP [10.3.1.105]) by exna00.securitydynamics.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 19KG7ZZ2; Fri, 15 Feb 2002 10:04:46 -0500
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.1
Date: Fri, 15 Feb 2002 10:23:27 -0500
Subject: Re: Comment on RFC 2459
In-Reply-To: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"; format=flowed
X-MIME-Autoconverted: from 8bit to quoted-printable by sdtihq24.securid.com id KAA10854
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id g1FFjs304150
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>

Dieter:

Please review 
http://www.ietf.org/internet-drafts/draft-ietf-pkix-new-part1-12.txt.

This document will obsolete RFC 2459 very shortly. It is in the RFC Editor 
queue right now, so publication will likely occur in the next few weeks.

Russ

At 08:54 AM 2/15/2002 +0100, [e-mail] wrote:


>Comment on RFC 2459 Internet X.509 Public Key Infrastructure Certificate
>and CRL Profile.
>
>In Appendix D3 End-Entity Certificate Using RSA the encoding of the
>critical key usage extension at offset 464 is the following:
>
>
>0464 30 19         25: . . . . SEQUENCE
>0466 06 03          3: . . . . . OID 2.5.29.15: keyUsage
>                      : 55 1d 0f
>0471 01 01          1: . . . . . TRUE
>0474 04 04          4: . . . . . OCTET STRING
>                      : 03 02 07 80
>0480 30 19         25: . . . . SEQUENCE
>
>The correct encoding should be:
>
>0464 30 0e         14: . . . . SEQUENCE
>0466 06 03          3: . . . . . OID 2.5.29.15: keyUsage
>                      : 55 1d 0f
>0471 01 01          1: . . . . . TRUE
>                      : ff
>0474 04 04          4: . . . . . OCTET STRING
>                      : 03 02 07 80
>0480 30 19         25: . . . . SEQUENCE
>
>
>Regards
>Dieter Schomaker
>_________________________________________________________________
>GAD eG, Weseler Str. 500, 48163 Münster   [e-mail]
>Tel.: [phone]                     FAX: [phone]
>_________________________________________________________________


Received: by above.proper.com (8.11.6/8.11.3) id g1FFHE102505 for ietf-pkix-bks; Fri, 15 Feb 2002 07:17:14 -0800 (PST)
Received: from mail.utfors.se (mail.utfors.se [195.58.103.125]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1FFHD302499 for <[e-mail]>; Fri, 15 Feb 2002 07:17:13 -0800 (PST)
Received: from arport ([62.119.75.13]) by mail.utfors.se (8.8.8/8.8.8) with SMTP id QAA20556; Fri, 15 Feb 2002 16:16:20 +0100 (MET)
Message-ID: <012201c1b633$93cd09c0$0500a8c0@arport>
From: "Anders Rundgren" <[e-mail]>
To: "Denis Pinkas" <[e-mail]>
Cc: "Roberto Opazo" <[e-mail]>, <[e-mail]>
References: <[e-mail]> <009401c1b5a3$ea927cd0$0500a8c0@arport> <[e-mail]>
Subject: Re: I-D ACTION:draft-ietf-pkix-pi-03.txt
Date: Fri, 15 Feb 2002 16:15:13 +0100
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.50.4133.2400
X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
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>

Denis,
<snip>
 
>> So how do you fulfil 3039's DN uniqness requirement using the PI draft?

>DN uniqueness has to be fulfiled, whatever the content of any extension 
>(including the PI extension) may be.

Agreed.

>> Probably by *duplicating* the RUN, citizen number etc. in the DN, or
>> creating nonsense disamabiguers.  Although its not a crime to duplicate
>> data, I feel some resistance to creating a scheme based on that.

>There is a major difference. The number you place in the DN cannot tell you
>it is, e.g. a RUN. 

Agreed, but there _could_ be a variant of the PI-option that points to other
elements holding the actual value.  This become particularly interesting
if the descriptor is not restricted to EE-level but is also usable on CA-level,
because then the existing population of pre-PI-certs could be PI-enabled
by regenerating the CA-cert with old keys and expiration data.  I know that
you don't support that, but I think that it is too much to ask CAs to recall
all certificates out there, when there are workarounds available.  I also
find it less attractive to be *forced* to put the "information that really counts"
for access control etc. in new places, not directly supported by current
crypto SW and associated GUI.

>It is a number that is not guaranteed to be unique by itself.

Agreed.

>Only the combination country+name+number is unique.

This is an *entirely* different discussion that is not PI-related but here is my
disagreeing view on that:
Another CA could *rightfully* issue a certificate with exactly these
datas and elements but for anoher purpose (including another subject).
At least 3039 does not do any assumptions that country indicates citizenship,
it could be "blue oyster club" membership in some way associated with
country in some way.  This is the X509 "Namespace" problem in a nutshell,
as described in a recent posting.

>It happens that, in your example, the "number" being used is unique, but nobody can take
>advantage of it. The PI information on the contrary is by itself unique.

Well, everybody using the aforementioned certificates *are* already
taking these advantages including for access control based on "knowledge".

>> If the PI draft is no longer limited to individuls, should there not be any
>> kind of identifier telling what it denotes?

>Applicable to any entity, as the text says.

That's good, but what about the last paragraph in my question?

Anders




Received: by above.proper.com (8.11.6/8.11.3) id g1FEtAZ01807 for ietf-pkix-bks; Fri, 15 Feb 2002 06:55:10 -0800 (PST)
Received: from tholian.rsasecurity.com (mail.rsasecurity.com [204.167.112.129]) by above.proper.com (8.11.6/8.11.3) with SMTP id g1FEt6301803 for <[e-mail]>; Fri, 15 Feb 2002 06:55:07 -0800 (PST)
Received: from sdtihq24.securid.com by tholian.rsasecurity.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 15 Feb 2002 14:54:30 UT
Received: from ebola.securitydynamics.com (ebola.securid.com [192.168.7.4]) by sdtihq24.securid.com (Pro-8.9.3/Pro-8.9.3) with ESMTP id JAA00173 for <[e-mail]>; Fri, 15 Feb 2002 09:55:07 -0500 (EST)
Received: from exeu00.securid.com (localhost [127.0.0.1]) by ebola.securitydynamics.com (8.10.2+Sun/8.9.1) with ESMTP id g1FEt6904038 for <[e-mail]>; Fri, 15 Feb 2002 09:55:06 -0500 (EST)
Received: by exeu00.securid.com with Internet Mail Service (5.5.2653.19) id <1B31RMCA>; Fri, 15 Feb 2002 14:55:17 -0000
Received: from HOUSLEY-LAP.rsasecurity.com (HOUSLEY-LAP [10.3.1.105]) by exna00.securitydynamics.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 19KG7YX0; Fri, 15 Feb 2002 09:14:02 -0500
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Fri, 15 Feb 2002 09:54:48 -0500
To: [e-mail]
From: "Housley, Russ" <[e-mail]>
Subject: draft-ietf-ipsra-pic-05.txt
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>

Dear PKIX WG:

Given our collective interest in furthering use of certificates, I suggest 
that you review the
PIC specification <draft-ietf-ipsra-pic-05.txt>.

PIC, a product of the IPSRA WG, is in IETF Last Call. PIC is intended to 
provide legacy authentication support for VPNs while also supporting a 
transition to PKI.  Since PKIX WG members are experts on certificates, 
their usage, and PKI enrollment, it seems appropriate for PKIX WG members 
to take a look before it is published as an RFC.

As with other IETF last call, comments should be sent to [e-mail].

Russ





Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g1FBItR18194 for ietf-pkix-bks; Fri, 15 Feb 2002 03:18:55 -0800 (PST)
Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1FBIs318190 for <[e-mail]>; Fri, 15 Feb 2002 03:18:54 -0800 (PST)
Received: from lvt-mail.frlv.bull.fr (lvt-mail.frlv.bull.fr [129.184.62.223]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id MAA28888; Fri, 15 Feb 2002 12:20:34 +0100
Received: from bull.net (frlva3786.frlv.bull.fr [129.184.37.97]) by lvt-mail.frlv.bull.fr (8.9.2/8.9.1) with ESMTP id MAA15772; Fri, 15 Feb 2002 12:18:18 +0100
Message-ID: <[e-mail]>
Date: Fri, 15 Feb 2002 12:18:21 +0100
From: Denis Pinkas <[e-mail]>
Organization: Integris. A Bull Company
X-Mailer: Mozilla 4.7 [fr] (Win98; I)
X-Accept-Language: fr
MIME-Version: 1.0
To: Anders Rundgren <[e-mail]>
CC: Roberto Opazo <[e-mail]>, [e-mail]
Subject: Re: I-D ACTION:draft-ietf-pkix-pi-03.txt
References: <[e-mail]> <009401c1b5a3$ea927cd0$0500a8c0@arport>
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 g1FBIt318191
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>

Anders,

> Roberto,

> I support issuer PIs as well.

As Roberto mentionned it, the syntax proposed in the draft allows to support
issuer PIs, but the text does not. It is an extension for GeneralNames, so
it could easily be supported.

Since PKIX-part 1 states: "The issuer field MUST contain a non-empty
distinguished name (DN)", the issuerAltName is usually not used.

I presently see two persons supporting issuer PIs. 
Anybody else for it or against it  ?

> I have an objection to this xxxxAltName thing for PIs that you may comment on.
> The majority of pre-PI schemes use serialNumber for keeping this infomation.
> The really huge programs going on in Norway and Sweden where the banks
> build national PKIs is a prime example.
> 
> These certficates contain a minimal DN (country, name, number).  The latest version
> of the Post Offices' profile even excluded country!  Nice and clean IMO.
> 
> So how do you fulfil 3039's DN uniqness requirement using the PI draft?

DN uniqueness has to be fulfiled, whatever the content of any extension 
(including the PI extension) may be.

> Probably by *duplicating* the RUN, citizen number etc. in the DN, or
> creating nonsense disamabiguers.  Although its not a crime to duplicate
> data, I feel some resistance to creating a scheme based on that.

There is a major difference. The number you place in the DN cannot tell you
it is, e.g. a RUN. It is a number that is not guaranteed to be unique by
itself. Only the combination country+name+number is unique. It happens that,
in your example, the "number" being used is unique, but nobody can take
advantage of it. The PI information on the contrary is by itself unique.

> If the PI draft is no longer limited to individuls, should there not be any
> kind of identifier telling what it denotes?

Applicable to any entity, as the text says.

Denis


> Anders
> 
> ----- Original Message -----
> From: "Roberto Opazo" <[e-mail]>
> To: <[e-mail]>
> Sent: Thursday, February 14, 2002 22:01
> Subject: RE: I-D ACTION:draft-ietf-pkix-pi-03.txt
> 
> Congratulations, I think it is very good and necessary.
> 
> I agree with the syntax proposed, but I think the text is not completely
> coherent with the syntax.
> 
> I do not understand why the text has a scope so restricted. The term
>  "Person" in the e-mail abstract is obviously a typing error since it is
> right in the draft using the term "entity". But there is another scope
> restriction, ".may be included in the subjectAltName extension.". Why only
> subjectAltName? The new syntax applies to OtherName type, so in fact it
> applies to every extension witch use a General Name (GN) type, like
> issuerAltName for example. The text is saying "may be", so it is not
> restricting the possibility of using it in another extension, but I think
> there is a space for interpretation, that implies confusion.
> 
> Based on previous conversation with Denis Pinkas, I think this is not a
> typing error, so I would like to post my point.
> 
> Usually we do not have collision problems with CA names, so PIs are less
> necessary for issuers than for subjects, but there are other reasons to use
> a PI, at least consistency and comfort.
> 
> I think consistency is very important, if PI are going to be used, then
> there will be many routines to extract that identifier from one certificate
> and there will be DBs witch use this identifier as record key. So, it will
> be very comfortable and consistent to use the same method to treat entities
> and CAs in DB. Actually, there are many Systems that are not PKI based and
> this systems are using some identifier that will be good candidates to be
> PI. Many of these systems are going to be migrated to use PKI. The
> developers involved has no idea about what DNs are. I think PI will
> facilitate the construction of tools for that people and they will want to
> have a routine to manipulate identifiers, not necessary DN.
> 
> One example: Last year, when we wore discussing the Service of Internal
> Taxes (SII) regulation in Chile to use public key certificates, they said
> they want the certificates to have the Run (Rol único nacional) of the
> subject and the Rut (Rol único tributario) of the issuer. My opinion was not
> in favor of putting de Rut of the CA in certificates because that
> information can be obtained very easily from CPS, CA Web site and Service of
> Internal Taxes resolutions, between others. Other reason to not want to put
> the Rut there was to increase the certificate size, that is not very good
> when you are putting it in a smart card. But people prefer to administrate
> the Run and the Rut in the same way.
> 
> Lets think in an access control database, there you have entities authorized
> identifies by PI, and there you have a list of CAs in which the System
> trust, do you want to identify this CAs by DN or you prefer to use the same
> method used for entities?
> 
> In many cases this CAs are going to be regulated, so there is no risk of not
> finding the CA PI in the certificate if the organization using the DB want
> to use a CA PI.
> 
> Does it sound reasonable to you?
> 
> If not, the syntax proposed in the draft allows it, but the text do not.
> 
> Best regards,
> 
> Roberto Opazo - [e-mail]
> CEO - www.acepta.com
> Certification Authority for Chile
> 
> > -----Mensaje original-----
> > De: [e-mail] [mailto:[e-mail]]En
> > nombre de [e-mail]
> > Enviado el: Jueves 14 de Febrero de 2002 08:05 AM
> > Para: IETF-Announce:
> > CC: [e-mail]
> > Asunto: I-D ACTION:draft-ietf-pkix-pi-03.txt
> >
> >
> > 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
> > Permanent
> >                           Identifier
> > Author(s) : D. Pinkas, T. Gindin
> > Filename : draft-ietf-pkix-pi-03.txt
> > Pages : 9
> > Date : 13-Feb-02
> >
> > This document define a new form of name, called permanent
> > identifier, that may be included in the subjectAltName extension
> > of a public key certificate issued to a physical person.
> >
> > A URL for this Internet-Draft is:
> > http://www.ietf.org/internet-drafts/draft-ietf-pkix-pi-03.txt
> >
> > To remove yourself from the IETF Announcement list, send a message to
> > ietf-announce-request with the word unsubscribe in the body of
> > the message.
> >
> > 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-pi-03.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-pi-03.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.
> >


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g1FB2f315825 for ietf-pkix-bks; Fri, 15 Feb 2002 03:02:41 -0800 (PST)
Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1FB2d315821 for <[e-mail]>; Fri, 15 Feb 2002 03:02:39 -0800 (PST)
Received: from lvt-mail.frlv.bull.fr (lvt-mail.frlv.bull.fr [129.184.62.223]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id MAA28320; Fri, 15 Feb 2002 12:04:19 +0100
Received: from bull.net (frlva3786.frlv.bull.fr [129.184.37.97]) by lvt-mail.frlv.bull.fr (8.9.2/8.9.1) with ESMTP id MAA14226; Fri, 15 Feb 2002 12:02:03 +0100
Message-ID: <[e-mail]>
Date: Fri, 15 Feb 2002 12:02:06 +0100
From: Denis Pinkas <[e-mail]>
Organization: Integris. A Bull Company
X-Mailer: Mozilla 4.7 [fr] (Win98; I)
X-Accept-Language: fr
MIME-Version: 1.0
To: Anders Rundgren <[e-mail]>
CC: [e-mail]
Subject: Re: I-D ACTION:draft-ietf-pkix-pi-03.txt
References: <[e-mail]> <010601c1b561$3a328890$0500a8c0@arport>
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>

Anders,

> >This document define a new form of name, called permanent
> >identifier, that may be included in the subjectAltName extension
> >of a public key certificate issued to a physical person.
 
> I cannot from the draft deduct that this is only about physical persons.
> Actually it talkes about "entities" which IMO is anything worthy of an ID.

You noticed a difference between the advertisement made by the web editor
and the actual abstract.

The editor has kept the old abstract to advertise the new draft instead 
of using the new abstract.

The new abstract has been changed and now considers any kind of entity 
and is thus no more limited to physical persons.

Denis

> To do a separete PI effort for organizations as been suggested seems like
> complicating things and deviates from DN attributes which are universal.
> 
> Anders


Received: by above.proper.com (8.11.6/8.11.3) id g1F7sR222953 for ietf-pkix-bks; Thu, 14 Feb 2002 23:54:27 -0800 (PST)
Received: from wnpdms.gadeg.de (wxmail.gad.de [194.149.246.12]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1F7sQ322949 for <[e-mail]>; Thu, 14 Feb 2002 23:54:26 -0800 (PST)
Received: from O7O7.GADeG.de (unverified) by wnprms.gadeg.de (Content Technologies SMTPRS 4.2.5) with ESMTP id <[e-mail]> for <[e-mail]>; Fri, 15 Feb 2002 08:57:23 +0100
Subject: Comment on RFC 2459
X-Priority: 3 (Normal)
To: [e-mail]
X-Mailer: Lotus Notes Release 5.0.6a  January 17, 2001
Message-ID: <[e-mail]>
From: [e-mail]
Date: Fri, 15 Feb 2002 08:54:18 +0100
X-MIMETrack: Serialize by Router on ltgad011/GAD(Release 5.0.8 |June 20, 2001) at 02/15/2002 08:54:19 AM
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 g1F7sR322950
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>

Comment on RFC 2459 Internet X.509 Public Key Infrastructure Certificate
and CRL Profile.

In Appendix D3 End-Entity Certificate Using RSA the encoding of the
critical key usage extension at offset 464 is the following:


0464 30 19         25: . . . . SEQUENCE
0466 06 03          3: . . . . . OID 2.5.29.15: keyUsage
                     : 55 1d 0f
0471 01 01          1: . . . . . TRUE
0474 04 04          4: . . . . . OCTET STRING
                     : 03 02 07 80
0480 30 19         25: . . . . SEQUENCE

The correct encoding should be:

0464 30 0e         14: . . . . SEQUENCE
0466 06 03          3: . . . . . OID 2.5.29.15: keyUsage
                     : 55 1d 0f
0471 01 01          1: . . . . . TRUE
                     : ff
0474 04 04          4: . . . . . OCTET STRING
                     : 03 02 07 80
0480 30 19         25: . . . . SEQUENCE


Regards
Dieter Schomaker
_________________________________________________________________
GAD eG, Weseler Str. 500, 48163 Münster   [e-mail]
Tel.: [phone]                     FAX: [phone]
_________________________________________________________________




Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g1EM8Ed27710 for ietf-pkix-bks; Thu, 14 Feb 2002 14:08:14 -0800 (PST)
Received: from mailb.telia.com (mailb.telia.com [194.22.194.6]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1EM8D327706 for <[e-mail]>; Thu, 14 Feb 2002 14:08:13 -0800 (PST)
Received: from arport (t1o69p69.telia.com [62.20.144.69]) by mailb.telia.com (8.11.6/8.11.6) with SMTP id g1EM7xi09953; Thu, 14 Feb 2002 23:07:59 +0100 (CET)
Message-ID: <009401c1b5a3$ea927cd0$0500a8c0@arport>
From: "Anders Rundgren" <[e-mail]>
To: "Roberto Opazo" <[e-mail]>, <[e-mail]>
References: <[e-mail]>
Subject: Re: I-D ACTION:draft-ietf-pkix-pi-03.txt
Date: Thu, 14 Feb 2002 23:06:54 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
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>

Roberto,
I support issuer PIs as well.

I have an objection to this xxxxAltName thing for PIs that you may comment on.
The majority of pre-PI schemes use serialNumber for keeping this infomation.
The really huge programs going on in Norway and Sweden where the banks
build national PKIs is a prime example.

These certficates contain a minimal DN (country, name, number).  The latest version
of the Post Offices' profile even excluded country!  Nice and clean IMO.

So how do you fulfil 3039's DN uniqness requirement using the PI draft?
Probably by *duplicating* the RUN, citizen number etc. in the DN, or
creating nonsense disamabiguers.  Although its not a crime to duplicate
data, I feel some resistance to creating a scheme based on that.

If the PI draft is no longer limited to individuls, should there not be any
kind of identifier telling what it denotes?

Anders

----- Original Message -----
From: "Roberto Opazo" <[e-mail]>
To: <[e-mail]>
Sent: Thursday, February 14, 2002 22:01
Subject: RE: I-D ACTION:draft-ietf-pkix-pi-03.txt



Congratulations, I think it is very good and necessary.

I agree with the syntax proposed, but I think the text is not completely
coherent with the syntax.

I do not understand why the text has a scope so restricted. The term
 "Person" in the e-mail abstract is obviously a typing error since it is
right in the draft using the term "entity". But there is another scope
restriction, ".may be included in the subjectAltName extension.". Why only
subjectAltName? The new syntax applies to OtherName type, so in fact it
applies to every extension witch use a General Name (GN) type, like
issuerAltName for example. The text is saying "may be", so it is not
restricting the possibility of using it in another extension, but I think
there is a space for interpretation, that implies confusion.

Based on previous conversation with Denis Pinkas, I think this is not a
typing error, so I would like to post my point.

Usually we do not have collision problems with CA names, so PIs are less
necessary for issuers than for subjects, but there are other reasons to use
a PI, at least consistency and comfort.

I think consistency is very important, if PI are going to be used, then
there will be many routines to extract that identifier from one certificate
and there will be DBs witch use this identifier as record key. So, it will
be very comfortable and consistent to use the same method to treat entities
and CAs in DB. Actually, there are many Systems that are not PKI based and
this systems are using some identifier that will be good candidates to be
PI. Many of these systems are going to be migrated to use PKI. The
developers involved has no idea about what DNs are. I think PI will
facilitate the construction of tools for that people and they will want to
have a routine to manipulate identifiers, not necessary DN.

One example: Last year, when we wore discussing the Service of Internal
Taxes (SII) regulation in Chile to use public key certificates, they said
they want the certificates to have the Run (Rol único nacional) of the
subject and the Rut (Rol único tributario) of the issuer. My opinion was not
in favor of putting de Rut of the CA in certificates because that
information can be obtained very easily from CPS, CA Web site and Service of
Internal Taxes resolutions, between others. Other reason to not want to put
the Rut there was to increase the certificate size, that is not very good
when you are putting it in a smart card. But people prefer to administrate
the Run and the Rut in the same way.

Lets think in an access control database, there you have entities authorized
identifies by PI, and there you have a list of CAs in which the System
trust, do you want to identify this CAs by DN or you prefer to use the same
method used for entities?

In many cases this CAs are going to be regulated, so there is no risk of not
finding the CA PI in the certificate if the organization using the DB want
to use a CA PI.

Does it sound reasonable to you?

If not, the syntax proposed in the draft allows it, but the text do not.

Best regards,

Roberto Opazo - [e-mail]
CEO - www.acepta.com
Certification Authority for Chile

> -----Mensaje original-----
> De: [e-mail] [mailto:[e-mail]]En
> nombre de [e-mail]
> Enviado el: Jueves 14 de Febrero de 2002 08:05 AM
> Para: IETF-Announce:
> CC: [e-mail]
> Asunto: I-D ACTION:draft-ietf-pkix-pi-03.txt
>
>
> 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
> Permanent
>                           Identifier
> Author(s) : D. Pinkas, T. Gindin
> Filename : draft-ietf-pkix-pi-03.txt
> Pages : 9
> Date : 13-Feb-02
>
> This document define a new form of name, called permanent
> identifier, that may be included in the subjectAltName extension
> of a public key certificate issued to a physical person.
>
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-ietf-pkix-pi-03.txt
>
> To remove yourself from the IETF Announcement list, send a message to
> ietf-announce-request with the word unsubscribe in the body of
> the message.
>
> 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-pi-03.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-pi-03.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.
>




Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g1EK7do19811 for ietf-pkix-bks; Thu, 14 Feb 2002 12:07:39 -0800 (PST)
Received: from nxs_cus_dns01.acepta.com ([216.241.20.227]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1EK7Y319803 for <[e-mail]>; Thu, 14 Feb 2002 12:07:35 -0800 (PST)
Received: from portatil3 ([200.72.27.26]) by nxs_cus_dns01.acepta.com (8.12.2/8.12.2) with SMTP id g1EKL5D8030335 for <[e-mail]>; Thu, 14 Feb 2002 17:21:07 -0300
From: "Roberto Opazo" <[e-mail]>
To: <[e-mail]>
Subject: RE: I-D ACTION:draft-ietf-pkix-pi-03.txt
Date: Thu, 14 Feb 2002 17:01:50 -0400
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 V6.00.2600.0000
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>

Congratulations, I think it is very good and necessary.

I agree with the syntax proposed, but I think the text is not completely
coherent with the syntax…

I do not understand why the text has a scope so restricted. The term
 “Person” in the e-mail abstract is obviously a typing error since it is
right in the draft using the term “entity”. But there is another scope
restriction, “…may be included in the subjectAltName extension…”. Why only
subjectAltName? The new syntax applies to OtherName type, so in fact it
applies to every extension witch use a General Name (GN) type, like
issuerAltName for example. The text is saying “may be”, so it is not
restricting the possibility of using it in another extension, but I think
there is a space for interpretation, that implies confusion.

Based on previous conversation with Denis Pinkas, I think this is not a
typing error, so I would like to post my point…

Usually we do not have collision problems with CA names, so PIs are less
necessary for issuers than for subjects, but there are other reasons to use
a PI, at least consistency and comfort.

I think consistency is very important, if PI are going to be used, then
there will be many routines to extract that identifier from one certificate
and there will be DBs witch use this identifier as record key. So, it will
be very comfortable and consistent to use the same method to treat entities
and CAs in DB. Actually, there are many Systems that are not PKI based and
this systems are using some identifier that will be good candidates to be
PI. Many of these systems are going to be migrated to use PKI. The
developers involved has no idea about what DNs are. I think PI will
facilitate the construction of tools for that people and they will want to
have a routine to manipulate identifiers, not necessary DN.

One example: Last year, when we wore discussing the Service of Internal
Taxes (SII) regulation in Chile to use public key certificates, they said
they want the certificates to have the Run (Rol único nacional) of the
subject and the Rut (Rol único tributario) of the issuer. My opinion was not
in favor of putting de Rut of the CA in certificates because that
information can be obtained very easily from CPS, CA Web site and Service of
Internal Taxes resolutions, between others. Other reason to not want to put
the Rut there was to increase the certificate size, that is not very good
when you are putting it in a smart card. But people prefer to administrate
the Run and the Rut in the same way.

Lets think in an access control database, there you have entities authorized
identifies by PI, and there you have a list of CAs in which the System
trust, do you want to identify this CAs by DN or you prefer to use the same
method used for entities?

In many cases this CAs are going to be regulated, so there is no risk of not
finding the CA PI in the certificate if the organization using the DB want
to use a CA PI.

Does it sound reasonable to you?

If not, the syntax proposed in the draft allows it, but the text do not.

Best regards,

Roberto Opazo – [e-mail]
CEO – www.acepta.com
Certification Authority for Chile

> -----Mensaje original-----
> De: [e-mail] [mailto:[e-mail]]En
> nombre de [e-mail]
> Enviado el: Jueves 14 de Febrero de 2002 08:05 AM
> Para: IETF-Announce:
> CC: [e-mail]
> Asunto: I-D ACTION:draft-ietf-pkix-pi-03.txt
>
>
> 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
> Permanent
>                           Identifier
> 	Author(s)	: D. Pinkas, T. Gindin
> 	Filename	: draft-ietf-pkix-pi-03.txt
> 	Pages		: 9
> 	Date		: 13-Feb-02
>
> This document define a new form of name, called permanent
> identifier, that may be included in the subjectAltName extension
> of a public key certificate issued to a physical person.
>
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-ietf-pkix-pi-03.txt
>
> To remove yourself from the IETF Announcement list, send a message to
> ietf-announce-request with the word unsubscribe in the body of
> the message.
>
> 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-pi-03.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-pi-03.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.
>



Received: by above.proper.com (8.11.6/8.11.3) id g1EEAi003142 for ietf-pkix-bks; Thu, 14 Feb 2002 06:10:44 -0800 (PST)
Received: from mail.utfors.se (mail.utfors.se [195.58.103.125]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1EEAf303136 for <[e-mail]>; Thu, 14 Feb 2002 06:10:41 -0800 (PST)
Received: from arport ([62.119.75.13]) by mail.utfors.se (8.8.8/8.8.8) with SMTP id PAA28095 for <[e-mail]>; Thu, 14 Feb 2002 15:10:35 +0100 (MET)
Message-ID: <010601c1b561$3a328890$0500a8c0@arport>
From: "Anders Rundgren" <[e-mail]>
To: <[e-mail]>
References: <[e-mail]>
Subject: Re: I-D ACTION:draft-ietf-pkix-pi-03.txt
Date: Thu, 14 Feb 2002 15:09:32 +0100
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.50.4133.2400
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
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>

>This document define a new form of name, called permanent 
>identifier, that may be included in the subjectAltName extension 
>of a public key certificate issued to a physical person.

I cannot from the draft deduct that this is only about physical persons.
Actually it talkes about "entities" which IMO is anything worthy of an ID.

To do a separete PI effort for organizations as been suggested seems like
complicating things and deviates from DN attributes which are universal.

Anders



Received: by above.proper.com (8.11.6/8.11.3) id g1EC5L126932 for ietf-pkix-bks; Thu, 14 Feb 2002 04:05:21 -0800 (PST)
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1EC5K326928 for <[e-mail]>; Thu, 14 Feb 2002 04:05:20 -0800 (PST)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA15920; Thu, 14 Feb 2002 07:05:19 -0500 (EST)
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-pi-03.txt
Date: Thu, 14 Feb 2002 07:05:18 -0500
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>

--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 Permanent 
                          Identifier
	Author(s)	: D. Pinkas, T. Gindin
	Filename	: draft-ietf-pkix-pi-03.txt
	Pages		: 9
	Date		: 13-Feb-02
	
This document define a new form of name, called permanent 
identifier, that may be included in the subjectAltName extension 
of a public key certificate issued to a physical person.

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

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

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-pi-03.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-pi-03.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-pi-03.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-pkix-pi-03.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.6/8.11.3) id g1EBEWH22729 for ietf-pkix-bks; Thu, 14 Feb 2002 03:14:32 -0800 (PST)
Received: from ocasey.baltimore.com (ocasey.baltimore.com [193.41.17.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1EBEQ322724 for <[e-mail]>; Thu, 14 Feb 2002 03:14:30 -0800 (PST)
Received: from Baltimore-FW1 ([172.19.1.1]) by ocasey.baltimore.com (8.11.6/8.9.3) with SMTP id g1EBEQU17504 for <[e-mail]>; Thu, 14 Feb 2002 11:14:26 GMT
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, 14 Feb 2002 11:09:41 +0000
Received: from baltimore.ie (wks140-4.ie.baltimore.com [10.153.4.140]) by bobcat.baltimore.ie (8.9.3/8.9.3) with ESMTP id LAA25053; Thu, 14 Feb 2002 11:14:22 GMT
Message-ID: <[e-mail]>
Date: Thu, 14 Feb 2002 11:12:14 +0000
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: "Yee, Peter" <[e-mail]>
CC: [e-mail]
Subject: Re: I-D ACTION:draft-ietf-pkix-acrmf-00.txt
References: <D516C97A440DD31197640008C7EBBE4701B27D1E@EXRSA02>
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>

Peter,

> >- The old LAAP protocol effectively allowed (the equivalent of) a regInfo
> >  value to select the "type" of AC to be produced - this draft seems to
> >  preclude that. Did I read it wrong or don't you think that's needed?
> 
> Are you referring to LAAP's LACRequestMessage profile values?  

Yep.

> And yes,
> this draft does not have a shortcut representation for a particular,
> pre-agreed profile.  This could be a useful feature to incorporate,
> although it might then compete more directly with LAAP.  

What I was thinking was that if you did incorporate that nicely then 
there'd be no need for LAAP anymore (and since no-one seems to want 
to produce a new LAAP draft that'd be a happy outcome - if someone
does, let me know and I'll send you the source).

> That and it would
> add to the complexity of essentially two different request types within
> the protocol -- one the "flexible, specify all the attributes type" and the
> other the "pre-defined, specify the profile" type.  I'm not against the
> concept but would like to hear what other think.
> 
> >- Lastly, I never did come across a use case where a client would want
> >  to specify a really complicated AttrCertTemplate - have you? Absent
> >  that I'd have to say that this is maybe more complex than it needs
> >  to be.
> 
> ACRMF was modeled to have nearly the same flexibility as found in CRMF.
> So, that's the historical source of the complexity.  In terms of the need,
> I have spoken with some potential users who wanted more flexibility, to
> which
> I finally acquiesced.  

Fair enough, I guess though in hindsight the amount of flexibility
in CRMF was a mistake - there're probably still fields that no-one
can handle being populated in requests! (And *please*, let's not start
a thread on that!). 

> This protocol is intended to cover cases where LAAP
> doesn't provide the on-the-fly flexibility that might be desired, at the
> obvious cost of complexity.  I think LAAP might be more appropriate for
> cases where the ACs were of a well-defined nature and only needed generation
> on-the-fly.

Stephen.

-- 
____________________________________________________________
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 g1DJrwA29756 for ietf-pkix-bks; Wed, 13 Feb 2002 11:53:58 -0800 (PST)
Received: from mtiwmhc22.worldnet.att.net (mtiwmhc22.worldnet.att.net [204.127.131.47]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1DJru329752 for <[e-mail]>; Wed, 13 Feb 2002 11:53:56 -0800 (PST)
Received: from tsg1 ([12.81.71.42]) by mtiwmhc22.worldnet.att.net (InterMail vM.4.01.03.27 201-229-121-127-20010626) with SMTP id <20020213195346.IRKN29236.mtiwmhc22.worldnet.att.net@tsg1>; Wed, 13 Feb 2002 19:53:46 +0000
Message-ID: <021501c1b4c8$16c877a0$020aff0c@tsg1>
From: "todd glassey" <[e-mail]>
To: "Cotton Franck" <[e-mail]>, "'Denis Pinkas'" <[e-mail]>
Cc: "'Tom Gindin'" <[e-mail]>, <[e-mail]>
References: <7BABBC255DA2D311BFF60000F6AF21FA04FD8809@S90X01>
Subject: Re: Permanent identifier draft
Date: Wed, 13 Feb 2002 11:53:19 -0800
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0212_01C1B485.078D8610"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2600.0000
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
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>

This is a multi-part message in MIME format.

------=_NextPart_000_0212_01C1B485.078D8610
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

RE : Permanent identifier draft
  ----- Original Message -----=20
  From: Cotton Franck=20
  To: 'Denis Pinkas'=20
  Cc: 'Tom Gindin' ; '[e-mail]'=20
  Sent: Wednesday, February 13, 2002 9:48 AM
  Subject: RE : Permanent identifier draft


  Denis,=20

SNIP



  Well I'm not an expert on ISO literature, but I think that Annex A of =
ISO/IEC 6523 and ISO/IEC 8824-1 say that.=20

  >I have browsed on the web pages from www.dnb.com and I was not able =
to find=20
  >any information about the OID. It is important to make sure the =
holder of=20
  >the organization OID is indeed willing that its tree below can be =
used in=20
  >this way. The same applies for INSEE.=20

  What you register under ISO6523 is not an organisation but a code =
system and a registration authority for that=20
  code system. The mapping, as I understand it, is not just limited to =
the ICD, but goes down the whole tree below that.=20
  See =
http://www.isi.salford.ac.uk/staff/dwc/Version.Web/AppendixA/appendixa.ht=
m for an example.=20

So then perhaps each document type gets a TST assigned to it and then =
the TSA needs to understand the different token formats and making them =
interoperable to the extent that the policy-vecotr for the TST's will =
overlay enough that like  constructs can be compared from entity to =
entity (as represented by the TST's).

  >Looking forward for more information.=20

  >Regards,=20

  >Denis=20

  >> There are a many coding systems declared under ISO-6523 (EAN, =
SWIFT,=20
  >> EDIRA, ...), see=20
  >> =
http://xw2k.sdct.itl.nist.gov/l8/document-library/draft-standards/ICD-lis=
t.htm=20
  >>=20
  >> Franck Cotton=20
  >> INSEE - http://www.insee.fr=20


------=_NextPart_000_0212_01C1B485.078D8610
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD><TITLE>RE : Permanent identifier draft</TITLE>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Diso-8859-1">
<META content=3D"MSHTML 6.00.2712.300" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<BLOCKQUOTE dir=3Dltr=20
style=3D"PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; =
BORDER-LEFT: #000000 2px solid; MARGIN-RIGHT: 0px">
  <DIV style=3D"FONT: 10pt arial">----- Original Message ----- </DIV>
  <DIV=20
  style=3D"BACKGROUND: #e4e4e4; FONT: 10pt arial; font-color: =
black"><B>From:</B>=20
  <A title=[e-mail] =
href=3D"mailto:[e-mail]">Cotton=20
  Franck</A> </DIV>
  <DIV style=3D"FONT: 10pt arial"><B>To:</B> <A =
title=[e-mail]=20
  href=3D"mailto:[e-mail]">'Denis Pinkas'</A> </DIV>
  <DIV style=3D"FONT: 10pt arial"><B>Cc:</B> <A =
title=[e-mail]=20
  href=3D"mailto:[e-mail]">'Tom Gindin'</A> ; <A =
title=[e-mail]=20
  href=3D"mailto:'[e-mail]'">'[e-mail]'</A> </DIV>
  <DIV style=3D"FONT: 10pt arial"><B>Sent:</B> Wednesday, February 13, =
2002 9:48=20
  AM</DIV>
  <DIV style=3D"FONT: 10pt arial"><B>Subject:</B> RE : Permanent =
identifier=20
  draft</DIV>
  <DIV><BR></DIV>
  <P><FONT size=3D2>Denis,</FONT> </P></BLOCKQUOTE>
<P dir=3Dltr><FONT size=3D2>SNIP</FONT></P>
<BLOCKQUOTE dir=3Dltr=20
style=3D"PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; =
BORDER-LEFT: #000000 2px solid; MARGIN-RIGHT: 0px">
  <P>&nbsp;</P>
  <P><FONT size=3D2>Well I'm not an expert on ISO literature, but I =
think that=20
  Annex A of ISO/IEC 6523 and ISO/IEC 8824-1 say that.</FONT> </P>
  <P><FONT size=3D2>&gt;I have browsed on the web pages from www.dnb.com =
and I was=20
  not able to find </FONT><BR><FONT size=3D2>&gt;any information about =
the OID. It=20
  is important to make sure the holder of </FONT><BR><FONT =
size=3D2>&gt;the=20
  organization OID is indeed willing that its tree below can be used in=20
  </FONT><BR><FONT size=3D2>&gt;this way. The same applies for =
INSEE.</FONT> </P>
  <P><FONT size=3D2>What you register under ISO6523 is not an =
organisation but a=20
  code system and a registration authority for that</FONT> <BR><FONT =
size=3D2>code=20
  system. The mapping, as I understand it, is not just limited to the =
ICD, but=20
  goes down the whole tree below that.</FONT> <BR><FONT size=3D2>See <A=20
  =
href=3D"http://www.isi.salford.ac.uk/staff/dwc/Version.Web/AppendixA/appe=
ndixa.htm"=20
  =
target=3D_blank>http://www.isi.salford.ac.uk/staff/dwc/Version.Web/Append=
ixA/appendixa.htm</A>=20
  for an example.</FONT> </P></BLOCKQUOTE>
<P dir=3Dltr><FONT face=3DArial size=3D2>So then perhaps each document =
type gets a TST=20
assigned to it and then the TSA needs to understand the different token =
formats=20
and making them interoperable to the extent that the policy-vecotr for =
the TST's=20
will overlay enough that like&nbsp; constructs can be compared from =
entity to=20
entity (as represented by the TST's).</FONT></P>
<BLOCKQUOTE dir=3Dltr=20
style=3D"PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; =
BORDER-LEFT: #000000 2px solid; MARGIN-RIGHT: 0px">
  <P><FONT size=3D2>&gt;Looking forward for more information.</FONT> =
</P>
  <P><FONT size=3D2>&gt;Regards,</FONT> </P>
  <P><FONT size=3D2>&gt;Denis</FONT> </P>
  <P><FONT size=3D2>&gt;&gt; There are a many coding systems declared =
under=20
  ISO-6523 (EAN, SWIFT,</FONT> <BR><FONT size=3D2>&gt;&gt; EDIRA, ...), =
see</FONT>=20
  <BR><FONT size=3D2>&gt;&gt; <A=20
  =
href=3D"http://xw2k.sdct.itl.nist.gov/l8/document-library/draft-standards=
/ICD-list.htm"=20
  =
target=3D_blank>http://xw2k.sdct.itl.nist.gov/l8/document-library/draft-s=
tandards/ICD-list.htm</A></FONT>=20
  <BR><FONT size=3D2>&gt;&gt; </FONT><BR><FONT size=3D2>&gt;&gt; Franck=20
  Cotton</FONT> <BR><FONT size=3D2>&gt;&gt; INSEE - <A =
href=3D"http://www.insee.fr"=20
  target=3D_blank>http://www.insee.fr</A></FONT> =
</P></BLOCKQUOTE></BODY></HTML>

------=_NextPart_000_0212_01C1B485.078D8610--



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g1DJdF129246 for ietf-pkix-bks; Wed, 13 Feb 2002 11:39:15 -0800 (PST)
Received: from tholian.rsasecurity.com (mail.rsasecurity.com [204.167.112.129]) by above.proper.com (8.11.6/8.11.3) with SMTP id g1DJdD329242 for <[e-mail]>; Wed, 13 Feb 2002 11:39:13 -0800 (PST)
Received: from sdtihq24.securitydynamics.com by tholian.rsasecurity.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 13 Feb 2002 19:38:38 UT
Received: from exrsa01.rsa.com (exrsa01.rsa.com [10.81.217.7]) by sdtihq24.securid.com (Pro-8.9.3/Pro-8.9.3) with ESMTP id OAA09778; Wed, 13 Feb 2002 14:39:14 -0500 (EST)
Received: by exrsa01.rsa.com with Internet Mail Service (5.5.2653.19) id <1KL8QJ7Y>; Wed, 13 Feb 2002 11:39:13 -0800
Message-ID: <D516C97A440DD31197640008C7EBBE4701B27D1E@EXRSA02>
From: "Yee, Peter" <[e-mail]>
To: "'[e-mail]'" <[e-mail]>
Cc: [e-mail]
Subject: RE: I-D ACTION:draft-ietf-pkix-acrmf-00.txt
Date: Wed, 13 Feb 2002 11:39:13 -0800
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>

Stephen,

>Glad to see someone's picked up on this topic. Coupla initial 
>comments:-

Sorry about the delay in responding -- sent out the drafts and then
disappeared off to a week's worth of training.  Bad timing!

>- Shouldn't this say that the ACs in question are to be conformant
>  to [ACPROF]? Presumably this'd also mean that some fields in this
>  spec have to obey the same profiling rules too, which sounds like
>  a good idea.

Agreed.  ACMC notes requirements about [ACPROF] compliance in a couple
of places.  I'll make sure that ACRMF points at ACPROF.

>- What's [ACMC] from november 2001? (Maybe its about to pop out?)

Seems it was delayed in posting, but has now come out.

>- The old LAAP protocol effectively allowed (the equivalent of) a regInfo
>  value to select the "type" of AC to be produced - this draft seems to
>  preclude that. Did I read it wrong or don't you think that's needed?

Are you referring to LAAP's LACRequestMessage profile values?  And yes,
this draft does not have a shortcut representation for a particular,
pre-agreed profile.  This could be a useful feature to incorporate,
although it might then compete more directly with LAAP.  That and it would
add to the complexity of essentially two different request types within
the protocol -- one the "flexible, specify all the attributes type" and the
other the "pre-defined, specify the profile" type.  I'm not against the
concept but would like to hear what other think.

>- Lastly, I never did come across a use case where a client would want
>  to specify a really complicated AttrCertTemplate - have you? Absent
>  that I'd have to say that this is maybe more complex than it needs
>  to be.

ACRMF was modeled to have nearly the same flexibility as found in CRMF.
So, that's the historical source of the complexity.  In terms of the need,
I have spoken with some potential users who wanted more flexibility, to
which
I finally acquiesced.  This protocol is intended to cover cases where LAAP
doesn't provide the on-the-fly flexibility that might be desired, at the 
obvious cost of complexity.  I think LAAP might be more appropriate for
cases where the ACs were of a well-defined nature and only needed generation
on-the-fly.

>Stephen.

							-Peter
							[e-mail]



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g1DHmsB26181 for ietf-pkix-bks; Wed, 13 Feb 2002 09:48:54 -0800 (PST)
Received: from hermes2.insee.fr (s2b.insee.fr [194.254.38.69]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1DHmr326177 for <[e-mail]>; Wed, 13 Feb 2002 09:48:53 -0800 (PST)
Received: from proxyext1.insee.fr ([194.254.38.143]) by hermes2.insee.fr (Post.Office MTA V2.1.5 release 144 ID# 511-59534U100L100S0V35) with SMTP id fr; Wed, 13 Feb 2002 18:48:43 +0100
Received: by S54XSMTP with Internet Mail Service (5.5.2653.19) id <16Y0ZBV4>; Wed, 13 Feb 2002 18:48:38 +0100
Message-ID: <7BABBC255DA2D311BFF60000F6AF21FA04FD8809@S90X01>
From: Cotton Franck <[e-mail]>
To: "'Denis Pinkas'" <[e-mail]>
Cc: "'Tom Gindin'" <[e-mail]>, "'[e-mail]'" <[e-mail]>
Subject: RE : Permanent identifier draft
Date: Wed, 13 Feb 2002 18:48:39 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/mixed; boundary="----=_NextPartTM-000-4795dce4-df48-4cfe-b5e1-25c5d1778d2a"
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>

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.

------=_NextPartTM-000-4795dce4-df48-4cfe-b5e1-25c5d1778d2a
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C1B4B6.AB9EC080"

------_=_NextPart_001_01C1B4B6.AB9EC080
Content-Type: text/plain

Denis,

>Franck,

>> Denis, Tom
 
>> I think the PI draft should be re-issued on the standard track, because
>> these questions about naming and identifying are likely to become more
and
>> more important and should be discussed (cf. recent threads after Roberto
>> Opazo Gazmuri's posting).

>I agree.

>> Il you re-issue the draft, maybe you will like to add an Appendix A.3.3
>> covering the fact that most organizations already have an OID (and often
>> several) without knowing it through the mapping between ISO-6523 and OID
>> arc 1.3. For example, D-U-N-S number <N> is mapped to 1.3.60.<N>. If
>> France, every enterprise has an OID derived from its 9-digit SIRENE
number
>> <S>, which is 1.3.2.<S>.

>Before doing this, while I understand that this is "technically possible", 
>could you provide us with information which proves it is "legally feasible"

>to do it this way ?

Well I'm not an expert on ISO literature, but I think that Annex A of
ISO/IEC 6523 and ISO/IEC 8824-1 say that.

>I have browsed on the web pages from www.dnb.com and I was not able to find

>any information about the OID. It is important to make sure the holder of 
>the organization OID is indeed willing that its tree below can be used in 
>this way. The same applies for INSEE.

What you register under ISO6523 is not an organisation but a code system and
a registration authority for that
code system. The mapping, as I understand it, is not just limited to the
ICD, but goes down the whole tree below that.
See
http://www.isi.salford.ac.uk/staff/dwc/Version.Web/AppendixA/appendixa.htm
for an example.

>Looking forward for more information.

>Regards,

>Denis

>> There are a many coding systems declared under ISO-6523 (EAN, SWIFT,
>> EDIRA, ...), see
>>
http://xw2k.sdct.itl.nist.gov/l8/document-library/draft-standards/ICD-list.h
tm
>> 
>> Franck Cotton
>> INSEE - http://www.insee.fr

------_=_NextPart_001_01C1B4B6.AB9EC080
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.2653.12">
<TITLE>RE : Permanent identifier draft</TITLE>
</HEAD>
<BODY>

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

<P><FONT SIZE=3D2>&gt;Franck,</FONT>
</P>

<P><FONT SIZE=3D2>&gt;&gt; Denis, Tom</FONT>
<BR><FONT SIZE=3D2>&nbsp;</FONT>
<BR><FONT SIZE=3D2>&gt;&gt; I think the PI draft should be re-issued on =
the standard track, because</FONT>
<BR><FONT SIZE=3D2>&gt;&gt; these questions about naming and =
identifying are likely to become more and</FONT>
<BR><FONT SIZE=3D2>&gt;&gt; more important and should be discussed (cf. =
recent threads after Roberto</FONT>
<BR><FONT SIZE=3D2>&gt;&gt; Opazo Gazmuri's posting).</FONT>
</P>

<P><FONT SIZE=3D2>&gt;I agree.</FONT>
</P>

<P><FONT SIZE=3D2>&gt;&gt; Il you re-issue the draft, maybe you will =
like to add an Appendix A.3.3</FONT>
<BR><FONT SIZE=3D2>&gt;&gt; covering the fact that most organizations =
already have an OID (and often</FONT>
<BR><FONT SIZE=3D2>&gt;&gt; several) without knowing it through the =
mapping between ISO-6523 and OID</FONT>
<BR><FONT SIZE=3D2>&gt;&gt; arc 1.3. For example, D-U-N-S number =
&lt;N&gt; is mapped to 1.3.60.&lt;N&gt;. If</FONT>
<BR><FONT SIZE=3D2>&gt;&gt; France, every enterprise has an OID derived =
from its 9-digit SIRENE number</FONT>
<BR><FONT SIZE=3D2>&gt;&gt; &lt;S&gt;, which is 1.3.2.&lt;S&gt;.</FONT>
</P>

<P><FONT SIZE=3D2>&gt;Before doing this, while I understand that this =
is &quot;technically possible&quot;, </FONT>
<BR><FONT SIZE=3D2>&gt;could you provide us with information which =
proves it is &quot;legally feasible&quot; </FONT>
<BR><FONT SIZE=3D2>&gt;to do it this way ?</FONT>
</P>

<P><FONT SIZE=3D2>Well I'm not an expert on ISO literature, but I think =
that Annex A of ISO/IEC 6523 and ISO/IEC 8824-1 say that.</FONT>
</P>

<P><FONT SIZE=3D2>&gt;I have browsed on the web pages from www.dnb.com =
and I was not able to find </FONT>
<BR><FONT SIZE=3D2>&gt;any information about the OID. It is important =
to make sure the holder of </FONT>
<BR><FONT SIZE=3D2>&gt;the organization OID is indeed willing that its =
tree below can be used in </FONT>
<BR><FONT SIZE=3D2>&gt;this way. The same applies for INSEE.</FONT>
</P>

<P><FONT SIZE=3D2>What you register under ISO6523 is not an =
organisation but a code system and a registration authority for =
that</FONT>
<BR><FONT SIZE=3D2>code system. The mapping, as I understand it, is not =
just limited to the ICD, but goes down the whole tree below =
that.</FONT>
<BR><FONT SIZE=3D2>See <A =
HREF=3D"http://www.isi.salford.ac.uk/staff/dwc/Version.Web/AppendixA/app=
endixa.htm" =
TARGET=3D"_blank">http://www.isi.salford.ac.uk/staff/dwc/Version.Web/App=
endixA/appendixa.htm</A> for an example.</FONT>
</P>

<P><FONT SIZE=3D2>&gt;Looking forward for more information.</FONT>
</P>

<P><FONT SIZE=3D2>&gt;Regards,</FONT>
</P>

<P><FONT SIZE=3D2>&gt;Denis</FONT>
</P>

<P><FONT SIZE=3D2>&gt;&gt; There are a many coding systems declared =
under ISO-6523 (EAN, SWIFT,</FONT>
<BR><FONT SIZE=3D2>&gt;&gt; EDIRA, ...), see</FONT>
<BR><FONT SIZE=3D2>&gt;&gt; <A =
HREF=3D"http://xw2k.sdct.itl.nist.gov/l8/document-library/draft-standard=
s/ICD-list.htm" =
TARGET=3D"_blank">http://xw2k.sdct.itl.nist.gov/l8/document-library/draf=
t-standards/ICD-list.htm</A></FONT>
<BR><FONT SIZE=3D2>&gt;&gt; </FONT>
<BR><FONT SIZE=3D2>&gt;&gt; Franck Cotton</FONT>
<BR><FONT SIZE=3D2>&gt;&gt; INSEE - <A HREF=3D"http://www.insee.fr" =
TARGET=3D"_blank">http://www.insee.fr</A></FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C1B4B6.AB9EC080--

------=_NextPartTM-000-4795dce4-df48-4cfe-b5e1-25c5d1778d2a--



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g1DFUHC20274 for ietf-pkix-bks; Wed, 13 Feb 2002 07:30:17 -0800 (PST)
Received: from mailout05.sul.t-online.com (mailout05.sul.t-online.com [194.25.134.82]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1DFUG320267 for <[e-mail]>; Wed, 13 Feb 2002 07:30:16 -0800 (PST)
Received: from fwd06.sul.t-online.de  by mailout05.sul.t-online.com with smtp  id 16b1MJ-00017F-02; Wed, 13 Feb 2002 16:30:11 +0100
Received: from junker.stroeder.com (520010731148-0001@[217.1.20.25]) by fmrl06.sul.t-online.com with esmtp id 16b1M1-2LARmqC; Wed, 13 Feb 2002 16:29:53 +0100
Received: from stroeder.com (junker [127.0.0.1]) by junker.stroeder.com (Postfix) with ESMTP id 8E1F2157FF2 for <[e-mail]>; Wed, 13 Feb 2002 16:29:42 +0100 (CET)
Message-ID: <[e-mail]>
Date: Wed, 13 Feb 2002 16:29:41 +0100
From: Michael =?iso-8859-1?Q?Str=F6der?= <[e-mail]>
Reply-To: [e-mail]
Organization: stroeder.com
X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.4.17 i686)
X-Accept-Language: de-DE, de, en
MIME-Version: 1.0
To: [e-mail]
Subject: Re: I-D ACTION:draft-ietf-pkix-certstore-http-02.txt
References: <[e-mail]>
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>

[e-mail] wrote:
> 
>         Title           : Internet X.509 Public Key Infrastructure Operational
>                           Protocols: Certificate Store Access via HTTP

I still see no reason why hash values (marked as binary) have to be
hashed again to generate the search value. IMHO base64-encoding them
would be sufficient. Well, personally I'm far less concerned about
limited length of URL query strings than Peter is anyway.

Ciao, Michael.


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g1DFLMH19909 for ietf-pkix-bks; Wed, 13 Feb 2002 07:21:22 -0800 (PST)
Received: from mailout01.sul.t-online.com (mailout01.sul.t-online.com [194.25.134.80]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1DFLK319905 for <[e-mail]>; Wed, 13 Feb 2002 07:21:20 -0800 (PST)
Received: from fwd05.sul.t-online.de  by mailout01.sul.t-online.com with smtp  id 16b1DO-00031k-0T; Wed, 13 Feb 2002 16:20:58 +0100
Received: from junker.stroeder.com (520010731148-0001@[217.1.20.68]) by fmrl05.sul.t-online.com with esmtp id 16b1DF-0IB9TEC; Wed, 13 Feb 2002 16:20:49 +0100
Received: from stroeder.com (junker [127.0.0.1]) by junker.stroeder.com (Postfix) with ESMTP id 07E13157FF2; Wed, 13 Feb 2002 16:19:58 +0100 (CET)
Message-ID: <[e-mail]>
Date: Wed, 13 Feb 2002 16:19:58 +0100
From: Michael =?iso-8859-1?Q?Str=F6der?= <[e-mail]>
Reply-To: [e-mail]
Organization: stroeder.com
X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.4.17 i686)
X-Accept-Language: de-DE, de, en
MIME-Version: 1.0
To: "Deacon, Alex" <[e-mail]>
Cc: [e-mail]
Subject: Re: I-D ACTION:draft-ietf-pkix-certstore-http-02.txt
References: <[e-mail]>
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>

"Deacon, Alex" wrote:
> 
> However, why should
> we force the client/user to choose one way or the other?  Can't we add an
> optional "response attribute" to enable the client to tell the server what
> format it wants to deal with?

Hmm, although I voted for MIME multipart I would happily prefer
having to implement SEQUENCE OF Certificate just to have one way xor
the other.

IMHO we should avoid blowing up this simple draft to another famous
PKIX collection of keywords like MAY, OPTIONAL and doing the same
thing in three different ways.

Ciao, Michael.


Received: by above.proper.com (8.11.6/8.11.3) id g1DCA7K09230 for ietf-pkix-bks; Wed, 13 Feb 2002 04:10:07 -0800 (PST)
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1DCA5309224 for <[e-mail]>; Wed, 13 Feb 2002 04:10:05 -0800 (PST)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA28831; Wed, 13 Feb 2002 07:10:04 -0500 (EST)
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-rfc2560bis-01.txt
Date: Wed, 13 Feb 2002 07:10:04 -0500
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>

--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		: X.509 Internet Public Key Infrastructure Online 
                          Certificate Status Protocol - OCSP
	Author(s)	: M. Myers et al.
	Filename	: draft-ietf-pkix-rfc2560bis-01.txt
	Pages		: 
	Date		: 12-Feb-02
	
This document specifies a protocol useful in determining the current
status of a digital certificate without requiring CRLs. Additional
mechanisms addressing PKIX operational requirements are specified in
separate documents.

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

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

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-rfc2560bis-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-rfc2560bis-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-rfc2560bis-01.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-pkix-rfc2560bis-01.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.6/8.11.3) id g1DBC1a04809 for ietf-pkix-bks; Wed, 13 Feb 2002 03:12:01 -0800 (PST)
Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1DBBw304801 for <[e-mail]>; Wed, 13 Feb 2002 03:11:59 -0800 (PST)
Received: from lvt-mail.frlv.bull.fr (lvt-mail.frlv.bull.fr [129.184.62.223]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id MAA54014; Wed, 13 Feb 2002 12:13:33 +0100
Received: from bull.net (frlva3786.frlv.bull.fr [129.184.37.97]) by lvt-mail.frlv.bull.fr (8.9.2/8.9.1) with ESMTP id MAA16476; Wed, 13 Feb 2002 12:11:21 +0100
Message-ID: <[e-mail]>
Date: Wed, 13 Feb 2002 12:11:40 +0100
From: Denis Pinkas <[e-mail]>
Organization: Integris. A Bull Company
X-Mailer: Mozilla 4.7 [fr] (Win98; I)
X-Accept-Language: fr
MIME-Version: 1.0
To: Cotton Franck <[e-mail]>
CC: "'Tom Gindin'" <[e-mail]>, "'[e-mail]'" <[e-mail]>
Subject: Re: Permanent identifier draft
References: <7BABBC255DA2D311BFF60000F6AF21FA04FD87C9@S90X01>
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>

Franck,

> Denis, Tom
 
> I think the PI draft should be re-issued on the standard track, because
> these questions about naming and identifying are likely to become more and
> more important and should be discussed (cf. recent threads after Roberto
> Opazo Gazmuri's posting).

I agree.

> Il you re-issue the draft, maybe you will like to add an Appendix A.3.3
> covering the fact that most organizations already have an OID (and often
> several) without knowing it through the mapping between ISO-6523 and OID
> arc 1.3. For example, D-U-N-S number <N> is mapped to 1.3.60.<N>. If
> France, every enterprise has an OID derived from its 9-digit SIRENE number
> <S>, which is 1.3.2.<S>.

Before doing this, while I understand that this is "technically possible", 
could you provide us with information which proves it is "legally feasible" 
to do it this way ?

I have browsed on the web pages from www.dnb.com and I was not able to find 
any information about the OID. It is important to make sure the holder of 
the organization OID is indeed willing that its tree below can be used in 
this way. The same applies for INSEE.

Looking forward for more information.

Regards,

Denis

> There are a many coding systems declared under ISO-6523 (EAN, SWIFT,
> EDIRA, ...), see
> http://xw2k.sdct.itl.nist.gov/l8/document-library/draft-standards/ICD-list.htm
> 
> Franck Cotton
> INSEE - http://www.insee.fr


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g1D6Am826744 for ietf-pkix-bks; Tue, 12 Feb 2002 22:10:48 -0800 (PST)
Received: from mtiwmhc21.worldnet.att.net (mtiwmhc21.worldnet.att.net [204.127.131.46]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1D6Aj326738 for <[e-mail]>; Tue, 12 Feb 2002 22:10:45 -0800 (PST)
Received: from tsg1 ([12.81.78.176]) by mtiwmhc21.worldnet.att.net (InterMail vM.4.01.03.27 201-229-121-127-20010626) with SMTP id <20020213061042.TINS10911.mtiwmhc21.worldnet.att.net@tsg1>; Wed, 13 Feb 2002 06:10:42 +0000
Message-ID: <064401c1b455$1e408810$020aff0c@tsg1>
From: "todd glassey" <[e-mail]>
To: "LISTS - IETF-PKIX" <[e-mail]>, "LISTS - IETF-IESG" <[e-mail]>, <[e-mail]>
Subject: What is the PKIX TSP anyway?
Date: Tue, 12 Feb 2002 22:09:43 -0800
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 6.00.2600.0000
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
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>

I wrote this about two weeks ago and wound up striking half of it as being
too obnoxious to post. But the other part I think is important to the bigger
picture of timestamps and timestamping as an evidentiary practice especially
when compared to XML based receipts.


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

Folks - I want to point out that I am not in favor of trashing(1) all the
effort that has gone into the PKIX TSP effort but I want to steer it towards
a more usable service model and one that will adapt to new Token-Types and
Verification or Assurance Models.

Rethinking the TSP and TST models
-------------------------------------
To do this some major rethinking of the uses of the tokens is going to need
to be done and to that end I would propose that this WG collectively tell
its management that the current TSP provides no more realizable assurance
for any processes that might use it than a clear text distributed processing
model does and that makes there no reason to use this system since it is
totally predicated on the security and operational model of the Audit on the
platform below the TSA in order to reinforce its own veracity.

The reasons for this failing are the stated uses for the TST's themselves.
And that the TSP does not take into account the facility issues a "proofing
model" would require to demonstrate its own integrity. I

TSP vs. NTP
--------------
Another issue is that the service levels provided by the TSP and the TSA,
i.e. the functions they perform and what they actually provide to the
applications or users depending on them, have now degraded such that they
are no more potent than a marque that could be made with NTP. The problem
here again is that NTP predates the TSP by years and has tens of thousands
of implementations at minimum in the world today. What this really meant is
that the use of NTP for timestamping requires a practice statement, and not
a protocol and that is what choked PKIX on the process of using one of the
IETF's other protocols for its TS Protocol.

The bottom line on the TSP is that PKIX refuses to acknowledge that now more
than ever - the TSP they wound up with is a neutered knock-off of NTP and
that NTP has a better TS Token generation capability since it addresses the
credibility of the Time Data in the TST.  What this means is that most all
the functions that the TSP can perform now and many that it cant are already
in place inside the NTP protocol and what is missing from both protocol is
the simple token verifier application.

TSA's and TSP's are needed
------------------------------
As to a TSP - let me restate for the third time here - that they are
critical, but for Evidentiary Purposes, not as a part of simple
decision-support processes. No one in their right mind is going to need a
TSToken to stick into a database on a secured system to indicate some
digital event. The would just create a set of even-type markers and throw
one of them into the DB with the time the event happened. VIOLA - Time
stamp!
The Securing of the system provides credibility of the document's induction
time into the DB, likewise the reports generated by the IDS tools and System
Integrity tools also fold in to reinforce the methodology of doing
timestamps exactly how they are done today.

Yesterday's vs. Today's TST's
-------------------------------
Timestamps today are fields in DB based applications and whether there is a
hash of the document included or not, the model where a TTP is already in
place where needed, and is accomplished through simple DB Replication from
site to back-up site.  That means that the total need to date for TS's is
that of those reproduced in the form of reports from DB based applications.
So what in the commercial world would require the addition of this PKIX TS
Token Structure as its evidentiary marque? Why not just use a Server that
has a document reception application written on it and a report generator
that used Syslog and NTP to timestamp the receipt of each document. I can
use the SHAsign and MD5hash tools to build the signature and boom there we
go.

If PKIX is going to create a better token and TS Process, that at minimum
what PKIX needs to do is to hone the calling and verification API's to this
TSP to generate standard calling and response sequences that are more in
tune with the "validity of the Token and its Payload(s)", and likewise
generate a standard set of token structures to represent a slew of
commercial type events, maybe even use portions of what the
ONLINE-TRADING-PROTOCOL WG built up as the transaction types.

The problem is that there is no commercial way to use this technology, and
while Italy may indeed have legal requirements for the use of Time Stamps,
they will soon find out that what they were really looking for is a process
for automating Notorial Ceremonies.


Todd




Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g1CMBLi16950 for ietf-pkix-bks; Tue, 12 Feb 2002 14:11:21 -0800 (PST)
Received: from gateway.secude.com (linux.secude.com [141.12.207.27] (may be forged)) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1CMBJ316946 for <[e-mail]>; Tue, 12 Feb 2002 14:11:19 -0800 (PST)
Received: from remus.secude.com (remus.intranet.secude.com [192.168.2.2]) by gateway.secude.com (Postfix) with ESMTP id C0B3BB50D; Tue, 12 Feb 2002 23:11:16 +0100 (CET)
Received: from secude.com (obelix.intranet.secude.com [192.168.1.3]) by remus.secude.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id 1X3SMRYF; Tue, 12 Feb 2002 23:11:15 +0100
Message-ID: <[e-mail]>
Date: Tue, 12 Feb 2002 23:13:27 +0100
From: Petra Barzin <[e-mail]>
X-Mailer: Mozilla 4.73 [de]C-CCK-MCD DT  (Win95; U)
X-Accept-Language: de
MIME-Version: 1.0
To: "Khaja E. Ahmed" <[e-mail]>
Cc: Michael McIntosh <[e-mail]>, Simon Tardell <[e-mail]>, [e-mail]
Subject: Re: Candidate for moving OCSP to a Draft Standard
References: <[e-mail]>
Content-Type: text/html; 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>

<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
Maybe this will help:
<p>This is an excerpt of the so called ISIS-MTT specification (Industrial
<br>Signature Interoperability Specification &amp; Mailtrust). The specification
<br>may be obtained from: <A HREF="http://www.t7-isis.de/">http://www.t7-isis.de/</A>
<br>Part 4, section 3.1.2 describes the scenario Khaja is talking about.
<br>It defines a private extension to be used in an OCSP response:
<blockquote TYPE=CITE>
<pre>3.1.2 ISIS-MTT Private OCSP Extensions

CertHash (Positive Statement)

id-isismtt-at-certHash OBJECT IDENTIFIER ::= {1 3 36 8 3 13}

CertHash ::= SEQUENCE {
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; hashAlgorithm AlgorithmIdentifier,&nbsp;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; certificateHash OCTET STRING }&nbsp;

hashAlgorithm: The identifier of the algorithm that has been used
certificateHash: A hash over the DER-encoding of the entire PKC or AC.


ISIS-MTT: The responder may include this extension in a response to send&nbsp;
the hash of the requested certificate to the responder. This hash is&nbsp;
cryptographically bound to the certificate and serves as evidence that&nbsp;
the certificate is known to the responder (i.e. it has been issued and&nbsp;
is present in the directory). Hence, this extension is a means to provide&nbsp;
a ‘positive statement about issuance’ as described in Table 8.[8]. As&nbsp;
explained in Table 13.[1], clients may rely on this information to be able&nbsp;
to validate signatures after the expiry of the corresponding certificate.&nbsp;
Hence, clients MUST support this extension. If the intention is to deliver&nbsp;
a ‘positive statement about issuance’, this extension MUST be inserted.&nbsp;
A further note on security: Including the hash of the queried certificate&nbsp;
in the response prevents impersonation attacks of the following scenario:&nbsp;
Mallory manages to get the private key of a CA. The corresponding CA&nbsp;
certificate is immediately revoked. Using the stolen CA key, Mallory creates&nbsp;
a faked certificate with the same serial number as an existing one (the&nbsp;
original) and containing a new public key. Using the corresponding private&nbsp;
key, Mallory signs a message and sends it, along with the faked certificate,&nbsp;
to Alice. Alice succeeds to mathematically verify the signature and wants to&nbsp;
check the state of the received certificate by sending its serial number to&nbsp;
the OCSP server. The server returns the answer ‘good’, if the original&nbsp;
certificate has not been revoked. Having received the response ‘good’, Alice&nbsp;
thinks that the (actually faked) certificate is O.K. and accepts the signature.&nbsp;
She is unable to detect that the response corresponds to another certificate&nbsp;
than what she was asking about. This threat is apparently not handled by&nbsp;
PKIX documents. The security gap can be closed by including either the&nbsp;
certificate or a fingerprint of it in the response, respectively in the&nbsp;
‘positive statement’ as proposed here. It is crucial that the signature&nbsp;
of the responder can be reliably verified. Hence, departing from the&nbsp;
practice proposed by RFC2560, the certificate of the responder SHOULD be&nbsp;
issued by some independent the CA, i.e. not by the CA the certificates&nbsp;
of which the responder provides information about. This configuration&nbsp;
is described in Table 8.[1], item d).</pre>
</blockquote>

<p><br>Table 8 states:
<blockquote TYPE=CITE>
<pre>Accredited CAs obtain certificates from the German Federal Agency for</pre>
</blockquote>

<blockquote TYPE=CITE>
<pre>Communication and Post (RegTP), which contains an ‘OCSP signing’ key.</pre>
</blockquote>

<p><br>Regards, Petra
<br>&nbsp;
<p>"Khaja E. Ahmed" schrieb:
<blockquote TYPE=CITE>Mike,
<p>I would like to wash my hands of all responsibility associated with
this
<br>scenario :-).&nbsp; It is not mine but was presented to me by some
Bank PKI folks
<br>in EU and is (I believe) of ISIS origins.&nbsp;&nbsp; I share your
opinion that it is
<br>unlikely but then there are too many things that are equally (ore more)
<br>unlikely yet have elaborate counter measures in the technologies /
standards
<br>we develop.&nbsp; Looks like people do worry about unlikely by possible
<br>scenarios.
<p>To answer your question however,&nbsp; this scenario is certainly in
the realm of
<br>the possible and the solution you describe would not work because the
trust
<br>model envisioned, required clients to always go to an OCSP responder
it
<br>trusted regardless of what the AIA pointed it to.&nbsp; In fact the
OCSP
<br>responder was not even delegated the authority to respond by the CA
in
<br>question but by a different CA.&nbsp; As an example, the solution was
being
<br>promoted by some Identrus banks and would work fine in the Identrus
PKI
<br>model also.&nbsp; So, if the unlikely were to happen, the solution
would actually
<br>work as expected in the cases that we were able to work out, as long
as the
<br>OCSP responder did the necessary/proper checking.&nbsp;&nbsp; The hash
of cert
<br>technique described by Peter G would do just fine as a checking mechanism
<br>for example.
<p>Khaja
<p>> -----Original Message-----
<br>> From: [e-mail]
<br>> [<a href="mailto:[e-mail]">mailto:[e-mail]</a>]On
Behalf Of Michael McIntosh
<br>> Sent: Tuesday, February 12, 2002 4:53 AM
<br>> To: 'Khaja E. Ahmed'; Simon Tardell; [e-mail]
<br>> Subject: RE: Candidate for moving OCSP to a Draft Standard
<br>>
<br>>
<br>>
<br>> Khaja,
<br>>
<br>> Wouldn't someone that went to the trouble to issue rogue
<br>> certificates using
<br>> a stolen CA private key would also probably inject the OCSP
<br>> Service Locator
<br>> for a rogue OCSP Responder? Is the scenario you describe really likely?
<br>>
<br>> Thanks,
<br>> Mike
<br>>
<br>> -----Original Message-----
<br>> From: Khaja E. Ahmed [<a href="mailto:[e-mail]">mailto:[e-mail]</a>]
<br>> Sent: Tuesday, February 12, 2002 2:00 AM
<br>> To: Simon Tardell; [e-mail]
<br>> Subject: RE: Candidate for moving OCSP to a Draft Standard
<br>>
<br>>
<br>>
<br>> Simon,
<br>>
<br>> I am afraid I did not describe the scenario and it's assumptions
in full
<br>> detail but the solution you are pointing out would not apply.&nbsp;
In
<br>> this (ISIS
<br>> envisioned scenario...I think) the OCSP responder and the CA do not
know
<br>> that the CA's private key has been stolen/copied and is being used
to mint
<br>> certificates.&nbsp; Thus the OCSP responder would respond that the
certificate
<br>> was good because it was not known to be revoked.&nbsp; In fact even
if the
<br>> CertificateOK extension is used this problem may not be caught if
<br>> duplicate
<br>> serial numbers were being used.&nbsp; Indeed even a delegated path
validation
<br>> capable server may not catch this particular problem depending on
<br>> the nature
<br>> of the checking done prior to generating a response.&nbsp; The solution
<br>> envisioned, as explained to me by some German and other EU bank PKI
folks,
<br>> was that the OCSP responder would have access to some sort of a database
<br>> that contains all the certificates issued by the legit CA and will
check
<br>> against this database.&nbsp; The validation server would have to
be given the
<br>> entire certificate or at least the public key or identifier and
<br>> confirm that
<br>> that precise key, was certified in a certificate with that exact
serial
<br>> number, etc.
<br>>
<br>> Anyway, where I had left it was that it would be fine to do anything
over
<br>> and above basic OCSP (via extensions) so long as it did not
<br>> change/overload
<br>> the semantics of the OCSP status itself from that specified in
<br>> RFC2560.&nbsp; My
<br>> own inclination was, and remains, to settle for people doing ANY
<br>> checking of
<br>> status at all to get started.
<br>>
<br>> Anything beyond that is probably best handled by some standardized
<br>> (hopefully easy to use) protocol the list comes up with.
<br>>
<br>>
<br>> Khaja
<br>>
<br>> > -----Original Message-----
<br>> > From: Simon Tardell [<a href="mailto:[e-mail]">mailto:[e-mail]</a>]
<br>> > Sent: Monday, February 11, 2002 7:33 AM
<br>> > To: Khaja E. Ahmed; [e-mail]
<br>> > Subject: RE: Candidate for moving OCSP to a Draft Standard
<br>> >
<br>> >
<br>> > > I agree that there is no great need for an OCSP server to
<br>> > > tell a PKI enabled client that a certificate exists or was
<br>> > > issued if the PKI enabled client has first performed the
<br>> > > required verification of the CAs signature on the cert and
<br>> > > done proper path validation and is now only checking the
<br>> > > revocation status.&nbsp; My initial reaction was that it might
not
<br>> > > do any harm to have an optional extension to satisfy some
<br>> > > corner cases.&nbsp; One such case, that was put forth was of
a
<br>> > > situation where the CA's private key was stolen and being
<br>> > > used to mint certificates by an attacker.&nbsp; Such certificates
<br>> > > would not be in the CA's database. An optional extension like
<br>> > > the one proposed by Peter could afford some limited
<br>> > > protection against this.
<br>> >
<br>> > Khaja,
<br>> >
<br>> > This case is already catered for in RFC2560:
<br>> >
<br>> > "2.7&nbsp; CA Key Compromise
<br>> >
<br>> >&nbsp;&nbsp;&nbsp; If an OCSP responder knows that a particular
CA's private key has
<br>> >&nbsp;&nbsp;&nbsp; been compromised, it MAY return the revoked state
for all
<br>> >&nbsp;&nbsp;&nbsp; certificates issued by that CA."
<br>> >
<br>> > Simon.
<br>> >
<br>> > Simon Tardell, Software Architect, SmartTrust
<br>> > voice [phone], fax [phone]
<br>> > cell [phone], [e-mail]
<br>></blockquote>
</html>



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g1CJ58G13045 for ietf-pkix-bks; Tue, 12 Feb 2002 11:05:08 -0800 (PST)
Received: from rwcrmhc51.attbi.com (rwcrmhc51.attbi.com [204.127.198.38]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1CJ57313040 for <[e-mail]>; Tue, 12 Feb 2002 11:05:07 -0800 (PST)
Received: from C707777B ([12.232.94.141]) by rwcrmhc51.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with SMTP id <20020212190504.WZRD1672.rwcrmhc51.attbi.com@C707777B>; Tue, 12 Feb 2002 19:05:04 +0000
From: "Khaja E. Ahmed" <[e-mail]>
To: "Al Arsenault" <[e-mail]>, "Simon Tardell" <[e-mail]>, <[e-mail]>
Subject: Compromised OCSP server Key: Was: RE: Candidate for moving OCSP to a Draft Standard
Date: Tue, 12 Feb 2002 11:04:28 -0800
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)
X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
In-Reply-To: <012c01c1b3e6$66807870$6501a8c0@SJOSEPH>
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>

Al,

Different problem, different thread.  Answers inline...

> -----Original Message-----
> From: Al Arsenault [mailto:[e-mail]]
> Sent: Tuesday, February 12, 2002 8:58 AM
> To: Khaja E. Ahmed; Simon Tardell; [e-mail]
> Subject: Re: Candidate for moving OCSP to a Draft Standard
>
>
> Gee, what happens in this scenario if it's the OCSP responder's
> private key
> that has been compromised? :-)

Nothing.  Even if this has not been discovered, I can't think of any harm
this (by itself) would do.  Recall that the trust model here had the relying
party go to a specific URL for OCSP queries.  This URL was configured into
clients or communicated to them through some trusted mechanism.  As long as
the legit OCSP responder at the appointed URL was doing it's thing, the fact
that someone has it's private key probably does no harm.  Of course, if is
_known_ that the OCSP responder key has been compromised, it can and will be
revoked.

>
> Further, what happens if, as Michael McIntosh suggested, the CA
> private key
> that issued the OCSP responder certificate is compromised, and
> the attacker
> creates a new OCSP responder (and points all new/bogus
> certificates to it).
> Now we have two communities, with two OCSP responders, each of
> which claims
> the OTHER is invalid.  How is this resolved?

Answered in previous response to Michael.

>
>         Al Arsenault
>          Chief Security Architect
>         Diversinet Corp.
>
>
> ----- Original Message -----
> From: "Khaja E. Ahmed" <[e-mail]>
> To: "Simon Tardell" <[e-mail]>; <[e-mail]>
> Sent: Tuesday, February 12, 2002 1:59 AM
> Subject: RE: Candidate for moving OCSP to a Draft Standard
>
>
> >
> > Simon,
> >
> > I am afraid I did not describe the scenario and it's assumptions in full
> > detail but the solution you are pointing out would not apply.  In this
> (ISIS
> > envisioned scenario...I think) the OCSP responder and the CA do not know
> > that the CA's private key has been stolen/copied and is being
> used to mint
> > certificates.  Thus the OCSP responder would respond that the
> certificate
> > was good because it was not known to be revoked.  In fact even if the
> > CertificateOK extension is used this problem may not be caught if
> duplicate
> > serial numbers were being used.  Indeed even a delegated path validation
> > capable server may not catch this particular problem depending on the
> nature
> > of the checking done prior to generating a response.  The solution
> > envisioned, as explained to me by some German and other EU bank
> PKI folks,
> > was that the OCSP responder would have access to some sort of a database
> > that contains all the certificates issued by the legit CA and will check
> > against this database.  The validation server would have to be given the
> > entire certificate or at least the public key or identifier and confirm
> that
> > that precise key, was certified in a certificate with that exact serial
> > number, etc.
> >
> > Anyway, where I had left it was that it would be fine to do
> anything over
> > and above basic OCSP (via extensions) so long as it did not
> change/overload
> > the semantics of the OCSP status itself from that specified in RFC2560.
> My
> > own inclination was, and remains, to settle for people doing
> ANY checking
> of
> > status at all to get started.
> >
> > Anything beyond that is probably best handled by some standardized
> > (hopefully easy to use) protocol the list comes up with.
> >
> >
> > Khaja
> >
> > > -----Original Message-----
> > > From: Simon Tardell [mailto:[e-mail]]
> > > Sent: Monday, February 11, 2002 7:33 AM
> > > To: Khaja E. Ahmed; [e-mail]
> > > Subject: RE: Candidate for moving OCSP to a Draft Standard
> > >
> > >
> > > > I agree that there is no great need for an OCSP server to
> > > > tell a PKI enabled client that a certificate exists or was
> > > > issued if the PKI enabled client has first performed the
> > > > required verification of the CAs signature on the cert and
> > > > done proper path validation and is now only checking the
> > > > revocation status.  My initial reaction was that it might not
> > > > do any harm to have an optional extension to satisfy some
> > > > corner cases.  One such case, that was put forth was of a
> > > > situation where the CA's private key was stolen and being
> > > > used to mint certificates by an attacker.  Such certificates
> > > > would not be in the CA's database. An optional extension like
> > > > the one proposed by Peter could afford some limited
> > > > protection against this.
> > >
> > > Khaja,
> > >
> > > This case is already catered for in RFC2560:
> > >
> > > "2.7  CA Key Compromise
> > >
> > >    If an OCSP responder knows that a particular CA's private key has
> > >    been compromised, it MAY return the revoked state for all
> > >    certificates issued by that CA."
> > >
> > > Simon.
> > >
> > > Simon Tardell, Software Architect, SmartTrust
> > > voice [phone], fax [phone]
> > > cell [phone], [e-mail]
> >
>



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g1CIpQQ12780 for ietf-pkix-bks; Tue, 12 Feb 2002 10:51:26 -0800 (PST)
Received: from rwcrmhc52.attbi.com (rwcrmhc52.attbi.com [216.148.227.88]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1CIpP312776 for <[e-mail]>; Tue, 12 Feb 2002 10:51:25 -0800 (PST)
Received: from C707777B ([12.232.94.141]) by rwcrmhc52.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with SMTP id <20020212185122.WXJG1147.rwcrmhc52.attbi.com@C707777B>; Tue, 12 Feb 2002 18:51:22 +0000
From: "Khaja E. Ahmed" <[e-mail]>
To: "Michael McIntosh" <[e-mail]>, "Simon Tardell" <[e-mail]>, <[e-mail]>
Subject: RE: Candidate for moving OCSP to a Draft Standard
Date: Tue, 12 Feb 2002 10:50:45 -0800
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)
X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
In-Reply-To: <[e-mail]>
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>

Mike,

I would like to wash my hands of all responsibility associated with this
scenario :-).  It is not mine but was presented to me by some Bank PKI folks
in EU and is (I believe) of ISIS origins.   I share your opinion that it is
unlikely but then there are too many things that are equally (ore more)
unlikely yet have elaborate counter measures in the technologies / standards
we develop.  Looks like people do worry about unlikely by possible
scenarios.

To answer your question however,  this scenario is certainly in the realm of
the possible and the solution you describe would not work because the trust
model envisioned, required clients to always go to an OCSP responder it
trusted regardless of what the AIA pointed it to.  In fact the OCSP
responder was not even delegated the authority to respond by the CA in
question but by a different CA.  As an example, the solution was being
promoted by some Identrus banks and would work fine in the Identrus PKI
model also.  So, if the unlikely were to happen, the solution would actually
work as expected in the cases that we were able to work out, as long as the
OCSP responder did the necessary/proper checking.   The hash of cert
technique described by Peter G would do just fine as a checking mechanism
for example.

Khaja

> -----Original Message-----
> From: [e-mail]
> [mailto:[e-mail]]On Behalf Of Michael McIntosh
> Sent: Tuesday, February 12, 2002 4:53 AM
> To: 'Khaja E. Ahmed'; Simon Tardell; [e-mail]
> Subject: RE: Candidate for moving OCSP to a Draft Standard
>
>
>
> Khaja,
>
> Wouldn't someone that went to the trouble to issue rogue
> certificates using
> a stolen CA private key would also probably inject the OCSP
> Service Locator
> for a rogue OCSP Responder? Is the scenario you describe really likely?
>
> Thanks,
> Mike
>
> -----Original Message-----
> From: Khaja E. Ahmed [mailto:[e-mail]]
> Sent: Tuesday, February 12, 2002 2:00 AM
> To: Simon Tardell; [e-mail]
> Subject: RE: Candidate for moving OCSP to a Draft Standard
>
>
>
> Simon,
>
> I am afraid I did not describe the scenario and it's assumptions in full
> detail but the solution you are pointing out would not apply.  In
> this (ISIS
> envisioned scenario...I think) the OCSP responder and the CA do not know
> that the CA's private key has been stolen/copied and is being used to mint
> certificates.  Thus the OCSP responder would respond that the certificate
> was good because it was not known to be revoked.  In fact even if the
> CertificateOK extension is used this problem may not be caught if
> duplicate
> serial numbers were being used.  Indeed even a delegated path validation
> capable server may not catch this particular problem depending on
> the nature
> of the checking done prior to generating a response.  The solution
> envisioned, as explained to me by some German and other EU bank PKI folks,
> was that the OCSP responder would have access to some sort of a database
> that contains all the certificates issued by the legit CA and will check
> against this database.  The validation server would have to be given the
> entire certificate or at least the public key or identifier and
> confirm that
> that precise key, was certified in a certificate with that exact serial
> number, etc.
>
> Anyway, where I had left it was that it would be fine to do anything over
> and above basic OCSP (via extensions) so long as it did not
> change/overload
> the semantics of the OCSP status itself from that specified in
> RFC2560.  My
> own inclination was, and remains, to settle for people doing ANY
> checking of
> status at all to get started.
>
> Anything beyond that is probably best handled by some standardized
> (hopefully easy to use) protocol the list comes up with.
>
>
> Khaja
>
> > -----Original Message-----
> > From: Simon Tardell [mailto:[e-mail]]
> > Sent: Monday, February 11, 2002 7:33 AM
> > To: Khaja E. Ahmed; [e-mail]
> > Subject: RE: Candidate for moving OCSP to a Draft Standard
> >
> >
> > > I agree that there is no great need for an OCSP server to
> > > tell a PKI enabled client that a certificate exists or was
> > > issued if the PKI enabled client has first performed the
> > > required verification of the CAs signature on the cert and
> > > done proper path validation and is now only checking the
> > > revocation status.  My initial reaction was that it might not
> > > do any harm to have an optional extension to satisfy some
> > > corner cases.  One such case, that was put forth was of a
> > > situation where the CA's private key was stolen and being
> > > used to mint certificates by an attacker.  Such certificates
> > > would not be in the CA's database. An optional extension like
> > > the one proposed by Peter could afford some limited
> > > protection against this.
> >
> > Khaja,
> >
> > This case is already catered for in RFC2560:
> >
> > "2.7  CA Key Compromise
> >
> >    If an OCSP responder knows that a particular CA's private key has
> >    been compromised, it MAY return the revoked state for all
> >    certificates issued by that CA."
> >
> > Simon.
> >
> > Simon Tardell, Software Architect, SmartTrust
> > voice [phone], fax [phone]
> > cell [phone], [e-mail]
>



Received: by above.proper.com (8.11.6/8.11.3) id g1CHngv11305 for ietf-pkix-bks; Tue, 12 Feb 2002 09:49:42 -0800 (PST)
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 g1CHne311301 for <[e-mail]>; Tue, 12 Feb 2002 09:49:40 -0800 (PST)
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 GAA07001; Wed, 13 Feb 2002 06:49:23 +1300 (NZDT) (sender [e-mail])
Received: (from pgut001@localhost) by ruru.cs.auckland.ac.nz (8.9.3/8.8.6/cs-slave) id GAA245474; Wed, 13 Feb 2002 06:49:23 +1300 (NZDT) (sender [e-mail])
Date: Wed, 13 Feb 2002 06:49:23 +1300 (NZDT)
Message-ID: <[e-mail]>
From: [e-mail] (Peter Gutmann)
To: [e-mail], [e-mail], [e-mail], [e-mail]
Subject: Re: Candidate for moving OCSP to a Draft Standard
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>

Al Arsenault <[e-mail]> writes:

>Further, what happens if, as Michael McIntosh suggested, the CA private key
>that issued the OCSP responder certificate is compromised, and the attacker
>creates a new OCSP responder (and points all new/bogus certificates to it).
>Now we have two communities, with two OCSP responders, each of which claims
>the OTHER is invalid.  How is this resolved?

In the same way that two monotheistic religions consign their believers to the
other side's hell for reason of heresy :-).

Peter.


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g1CH1bJ10379 for ietf-pkix-bks; Tue, 12 Feb 2002 09:01:37 -0800 (PST)
Received: from smtp.comcast.net (smtp.comcast.net [24.153.64.2]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1CH1a310375 for <[e-mail]>; Tue, 12 Feb 2002 09:01:37 -0800 (PST)
Received: from SJOSEPH ([68.55.160.145]) by mtaout04.icomcast.net (iPlanet Messaging Server 5.1 (built May  7 2001)) with SMTP id <[e-mail]> for [e-mail]; Tue, 12 Feb 2002 12:01:33 -0500 (EST)
Date: Tue, 12 Feb 2002 11:57:48 -0500
From: Al Arsenault <[e-mail]>
Subject: Re: Candidate for moving OCSP to a Draft Standard
To: "Khaja E. Ahmed" <[e-mail]>, Simon Tardell <[e-mail]>, [e-mail]
Message-id: <012c01c1b3e6$66807870$6501a8c0@SJOSEPH>
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>

Gee, what happens in this scenario if it's the OCSP responder's private key
that has been compromised? :-)

Further, what happens if, as Michael McIntosh suggested, the CA private key
that issued the OCSP responder certificate is compromised, and the attacker
creates a new OCSP responder (and points all new/bogus certificates to it).
Now we have two communities, with two OCSP responders, each of which claims
the OTHER is invalid.  How is this resolved?

        Al Arsenault
         Chief Security Architect
        Diversinet Corp.


----- Original Message -----
From: "Khaja E. Ahmed" <[e-mail]>
To: "Simon Tardell" <[e-mail]>; <[e-mail]>
Sent: Tuesday, February 12, 2002 1:59 AM
Subject: RE: Candidate for moving OCSP to a Draft Standard


>
> Simon,
>
> I am afraid I did not describe the scenario and it's assumptions in full
> detail but the solution you are pointing out would not apply.  In this
(ISIS
> envisioned scenario...I think) the OCSP responder and the CA do not know
> that the CA's private key has been stolen/copied and is being used to mint
> certificates.  Thus the OCSP responder would respond that the certificate
> was good because it was not known to be revoked.  In fact even if the
> CertificateOK extension is used this problem may not be caught if
duplicate
> serial numbers were being used.  Indeed even a delegated path validation
> capable server may not catch this particular problem depending on the
nature
> of the checking done prior to generating a response.  The solution
> envisioned, as explained to me by some German and other EU bank PKI folks,
> was that the OCSP responder would have access to some sort of a database
> that contains all the certificates issued by the legit CA and will check
> against this database.  The validation server would have to be given the
> entire certificate or at least the public key or identifier and confirm
that
> that precise key, was certified in a certificate with that exact serial
> number, etc.
>
> Anyway, where I had left it was that it would be fine to do anything over
> and above basic OCSP (via extensions) so long as it did not
change/overload
> the semantics of the OCSP status itself from that specified in RFC2560.
My
> own inclination was, and remains, to settle for people doing ANY checking
of
> status at all to get started.
>
> Anything beyond that is probably best handled by some standardized
> (hopefully easy to use) protocol the list comes up with.
>
>
> Khaja
>
> > -----Original Message-----
> > From: Simon Tardell [mailto:[e-mail]]
> > Sent: Monday, February 11, 2002 7:33 AM
> > To: Khaja E. Ahmed; [e-mail]
> > Subject: RE: Candidate for moving OCSP to a Draft Standard
> >
> >
> > > I agree that there is no great need for an OCSP server to
> > > tell a PKI enabled client that a certificate exists or was
> > > issued if the PKI enabled client has first performed the
> > > required verification of the CAs signature on the cert and
> > > done proper path validation and is now only checking the
> > > revocation status.  My initial reaction was that it might not
> > > do any harm to have an optional extension to satisfy some
> > > corner cases.  One such case, that was put forth was of a
> > > situation where the CA's private key was stolen and being
> > > used to mint certificates by an attacker.  Such certificates
> > > would not be in the CA's database. An optional extension like
> > > the one proposed by Peter could afford some limited
> > > protection against this.
> >
> > Khaja,
> >
> > This case is already catered for in RFC2560:
> >
> > "2.7  CA Key Compromise
> >
> >    If an OCSP responder knows that a particular CA's private key has
> >    been compromised, it MAY return the revoked state for all
> >    certificates issued by that CA."
> >
> > Simon.
> >
> > Simon Tardell, Software Architect, SmartTrust
> > voice [phone], fax [phone]
> > cell [phone], [e-mail]
>



Received: by above.proper.com (8.11.6/8.11.3) id g1CG0bu08697 for ietf-pkix-bks; Tue, 12 Feb 2002 08:00:37 -0800 (PST)
Received: from pigeon.verisign.com (pigeon.verisign.com [65.205.251.71]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1CG0a308693 for <[e-mail]>; Tue, 12 Feb 2002 08:00:36 -0800 (PST)
Received: from vhqpostal-gw2.verisign.com (verisign.com [65.205.251.56]) by pigeon.verisign.com (8.9.3/BCH1.7.1) with ESMTP id HAA09500; Tue, 12 Feb 2002 07:50:31 -0800 (PST)
Received: by vhqpostal-gw2.verisign.com with Internet Mail Service (5.5.2653.19) id <DYDFWR6P>; Tue, 12 Feb 2002 08:01:17 -0800
Message-ID: <[e-mail]>
From: "Deacon, Alex" <[e-mail]>
To: "'[e-mail]'" <[e-mail]>, "Deacon, Alex" <[e-mail]>, [e-mail], [e-mail]
Cc: [e-mail]
Subject: RE: I-D ACTION:draft-ietf-pkix-certstore-http-02.txt
Date: Tue, 12 Feb 2002 07:59:01 -0800
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>

I don't see these as problems at all.  Moving processing complexity to the
server and away from the client is a good thing in my opinion.  

Alex
 

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]]
> Sent: Tuesday, February 12, 2002 5:20 AM
> To: [e-mail]; [e-mail];
> [e-mail]; [e-mail]
> Cc: [e-mail]
> Subject: RE: I-D ACTION:draft-ietf-pkix-certstore-http-02.txt
> 
> 
> "Deacon, Alex" <[e-mail]> writes:
> 
> >I would prefer we use the existing PKCS7/CMS formats.  
> However, why should we
> >force the client/user to choose one way or the other?  Can't 
> we add an
> >optional "response attribute" to enable the client to tell 
> the server what
> >format it wants to deal with?
> 
> There are two problems with this:
> 
> - It adds unnecessary complexity to the query processing 
> (it's not just a
>   simple <attribute>=<value> any more).
> 
> - It makes it even worse than before, because now instead of 
> having to support
>   one of the two (right or wrong, depending on personal 
> opinion) you have to
>   support both.
> 
> Peter.
> 


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g1CFQSh06614 for ietf-pkix-bks; Tue, 12 Feb 2002 07:26:28 -0800 (PST)
Received: from hall.mail.mindspring.net (hall.mail.mindspring.net [207.69.200.60]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1CFQQ306609 for <[e-mail]>; Tue, 12 Feb 2002 07:26:27 -0800 (PST)
Received: from user-2ivf2c8.dialup.mindspring.com ([165.247.137.136] helo=ASN-1.com) by hall.mail.mindspring.net with esmtp (Exim 3.33 #1) id 16aep3-0003Nj-00; Tue, 12 Feb 2002 10:26:21 -0500
Message-ID: <[e-mail]>
Date: Tue, 12 Feb 2002 10:21:58 -0500
From: Phil Griffin <[e-mail]>
Organization: Griffin Consulting - http://ASN-1.com
X-Mailer: Mozilla 4.73 [en]C-{C-UDP; EBM-SONY1}  (Win95; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Peter Gutmann <[e-mail]>
CC: [e-mail], [e-mail], [e-mail]
Subject: Re: I-D ACTION:draft-ietf-pkix-certstore-http-02.txt
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>

Peter Gutmann wrote:
> 
> "Deacon, Alex" <[e-mail]> writes:
> 
> >I would prefer we use the existing PKCS7/CMS formats.  However, why should we
> >force the client/user to choose one way or the other?  Can't we add an
> >optional "response attribute" to enable the client to tell the server what
> >format it wants to deal with?
> 
> There are two problems with this:
> 
> - It adds unnecessary complexity to the query processing (it's not just a
>   simple <attribute>=<value> any more).
> 
> - It makes it even worse than before, because now instead of having to support
>   one of the two (right or wrong, depending on personal opinion) you have to
>   support both.
> 
> Peter.

Peter,

>From a purely philosophical bent, I agree. But as 
a practical matter, supporting both (or either one
or the other - it IS a choice really) is the least
of the complexity concerns in this setting. 

We're talking about X.509 Certificates and PKCS #7
for crying out loud. Both are small craft warnings.
Neither should be recommended to the faint hearted.

Phil :-)


Received: by above.proper.com (8.11.6/8.11.3) id g1CDcTZ02134 for ietf-pkix-bks; Tue, 12 Feb 2002 05:38:29 -0800 (PST)
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 g1CDcR302125 for <[e-mail]>; Tue, 12 Feb 2002 05:38:27 -0800 (PST)
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 CAA01404; Wed, 13 Feb 2002 02:38:19 +1300 (NZDT) (sender [e-mail])
Received: (from pgut001@localhost) by ruru.cs.auckland.ac.nz (8.9.3/8.8.6/cs-slave) id CAA238081; Wed, 13 Feb 2002 02:38:18 +1300 (NZDT) (sender [e-mail])
Date: Wed, 13 Feb 2002 02:38:18 +1300 (NZDT)
Message-ID: <[e-mail]>
From: [e-mail] (Peter Gutmann)
To: [e-mail], [e-mail], [e-mail]
Subject: RE: Candidate for moving OCSP to a Draft Standard
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>

"Khaja E. Ahmed" <[e-mail]> writes:

>I am afraid I did not describe the scenario and it's assumptions in full
>detail but the solution you are pointing out would not apply.  In this (ISIS
>envisioned scenario...I think) the OCSP responder and the CA do not know that
>the CA's private key has been stolen/copied and is being used to mint
>certificates.  Thus the OCSP responder would respond that the certificate was
>good because it was not known to be revoked.  In fact even if the
>CertificateOK extension is used this problem may not be caught if duplicate
>serial numbers were being used.  
>
>[...]
>
>The validation server would have to be given the entire certificate or at
>least the public key or identifier and confirm that that precise key, was
>certified in a certificate with that exact serial number, etc.

A simple fix for this would be to submit a hash of the cert as the ID.  The
client gets a cert, hashes it, submits it as the OCSP ID, and responder sends
back a copy of the hash as the ID and a CertificateOK = TRUE/FALSE.  Simple,
straightforward, and stirring up such a hornet's nest that it's unlikely to
ever get mentioned in any CertificateOK draft :-).

Peter.


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g1CDMKu29777 for ietf-pkix-bks; Tue, 12 Feb 2002 05:22:20 -0800 (PST)
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 g1CDMI329771 for <[e-mail]>; Tue, 12 Feb 2002 05:22:18 -0800 (PST)
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 CAA02823; Wed, 13 Feb 2002 02:20:09 +1300 (NZDT) (sender [e-mail])
Received: (from pgut001@localhost) by ruru.cs.auckland.ac.nz (8.9.3/8.8.6/cs-slave) id CAA237693; Wed, 13 Feb 2002 02:20:08 +1300 (NZDT) (sender [e-mail])
Date: Wed, 13 Feb 2002 02:20:08 +1300 (NZDT)
Message-ID: <[e-mail]>
From: [e-mail] (Peter Gutmann)
To: [e-mail], [e-mail], [e-mail], [e-mail]
Subject: RE: I-D ACTION:draft-ietf-pkix-certstore-http-02.txt
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>

"Deacon, Alex" <[e-mail]> writes:

>I would prefer we use the existing PKCS7/CMS formats.  However, why should we
>force the client/user to choose one way or the other?  Can't we add an
>optional "response attribute" to enable the client to tell the server what
>format it wants to deal with?

There are two problems with this:

- It adds unnecessary complexity to the query processing (it's not just a
  simple <attribute>=<value> any more).

- It makes it even worse than before, because now instead of having to support
  one of the two (right or wrong, depending on personal opinion) you have to
  support both.

Peter.



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g1CCrZX27698 for ietf-pkix-bks; Tue, 12 Feb 2002 04:53:35 -0800 (PST)
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 g1CCrY327694 for <[e-mail]>; Tue, 12 Feb 2002 04:53:34 -0800 (PST)
Received: from CONVERSION-DAEMON by ext-mail.valicert.com (PMDF V5.2-33 #46613) id <[e-mail]> for [e-mail]; Tue, 12 Feb 2002 04:53:33 -0800 (PST)
Received: from polaris.valicert.com ([192.168.2.34]) by ext-mail.valicert.com (PMDF V5.2-33 #46613) with ESMTP id <[e-mail]>; Tue, 12 Feb 2002 04:53:33 -0800 (PST)
Received: by exchange.valicert.com with Internet Mail Service (5.5.2653.19) id <D6WG9Z7S>; Tue, 12 Feb 2002 04:53:32 -0800
Content-return: allowed
Date: Tue, 12 Feb 2002 04:53:22 -0800
From: Michael McIntosh <[e-mail]>
Subject: RE: Candidate for moving OCSP to a Draft Standard
To: "'Khaja E. Ahmed'" <[e-mail]>, Simon Tardell <[e-mail]>, [e-mail]
Message-id: <[e-mail]>
MIME-version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-type: text/plain
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>

Khaja,

Wouldn't someone that went to the trouble to issue rogue certificates using
a stolen CA private key would also probably inject the OCSP Service Locator
for a rogue OCSP Responder? Is the scenario you describe really likely?

Thanks,
Mike

-----Original Message-----
From: Khaja E. Ahmed [mailto:[e-mail]]
Sent: Tuesday, February 12, 2002 2:00 AM
To: Simon Tardell; [e-mail]
Subject: RE: Candidate for moving OCSP to a Draft Standard



Simon,

I am afraid I did not describe the scenario and it's assumptions in full
detail but the solution you are pointing out would not apply.  In this (ISIS
envisioned scenario...I think) the OCSP responder and the CA do not know
that the CA's private key has been stolen/copied and is being used to mint
certificates.  Thus the OCSP responder would respond that the certificate
was good because it was not known to be revoked.  In fact even if the
CertificateOK extension is used this problem may not be caught if duplicate
serial numbers were being used.  Indeed even a delegated path validation
capable server may not catch this particular problem depending on the nature
of the checking done prior to generating a response.  The solution
envisioned, as explained to me by some German and other EU bank PKI folks,
was that the OCSP responder would have access to some sort of a database
that contains all the certificates issued by the legit CA and will check
against this database.  The validation server would have to be given the
entire certificate or at least the public key or identifier and confirm that
that precise key, was certified in a certificate with that exact serial
number, etc.

Anyway, where I had left it was that it would be fine to do anything over
and above basic OCSP (via extensions) so long as it did not change/overload
the semantics of the OCSP status itself from that specified in RFC2560.  My
own inclination was, and remains, to settle for people doing ANY checking of
status at all to get started.

Anything beyond that is probably best handled by some standardized
(hopefully easy to use) protocol the list comes up with.


Khaja

> -----Original Message-----
> From: Simon Tardell [mailto:[e-mail]]
> Sent: Monday, February 11, 2002 7:33 AM
> To: Khaja E. Ahmed; [e-mail]
> Subject: RE: Candidate for moving OCSP to a Draft Standard
>
>
> > I agree that there is no great need for an OCSP server to
> > tell a PKI enabled client that a certificate exists or was
> > issued if the PKI enabled client has first performed the
> > required verification of the CAs signature on the cert and
> > done proper path validation and is now only checking the
> > revocation status.  My initial reaction was that it might not
> > do any harm to have an optional extension to satisfy some
> > corner cases.  One such case, that was put forth was of a
> > situation where the CA's private key was stolen and being
> > used to mint certificates by an attacker.  Such certificates
> > would not be in the CA's database. An optional extension like
> > the one proposed by Peter could afford some limited
> > protection against this.
>
> Khaja,
>
> This case is already catered for in RFC2560:
>
> "2.7  CA Key Compromise
>
>    If an OCSP responder knows that a particular CA's private key has
>    been compromised, it MAY return the revoked state for all
>    certificates issued by that CA."
>
> Simon.
>
> Simon Tardell, Software Architect, SmartTrust
> voice [phone], fax [phone]
> cell [phone], [e-mail]


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g1CC96W26186 for ietf-pkix-bks; Tue, 12 Feb 2002 04:09:06 -0800 (PST)
Received: from edelweb.fr (edelweb.fr [212.234.46.16]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1CC94326180 for <[e-mail]>; Tue, 12 Feb 2002 04:09:04 -0800 (PST)
Received: from champagne.edelweb.fr (localhost.edelweb.fr [127.0.0.1]) by edelweb.fr with ESMTP id NAA14254; Tue, 12 Feb 2002 13:08:57 +0100 (MET)
Received: from champagne.edelweb.fr (champagne.edelweb.fr [193.51.14.161]) by edelweb.fr (nospam/1.3); Tue, 12 Feb 2002 13:08:57 +0100 (MET)
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 NAA07652; Tue, 12 Feb 2002 13:08:51 +0100 (MET)
From: Peter Sylvester <[e-mail]>
Received: (sylvest@localhost) by emeriau.edelweb.fr (8.7.6/8.6.6) id NAA14309; Tue, 12 Feb 2002 13:08:50 +0100 (MET)
Date: Tue, 12 Feb 2002 13:08:50 +0100 (MET)
Message-Id: <[e-mail]>
To: [e-mail]
Subject: RE: I-D ACTION:draft-ietf-pkix-certstore-http-02.txt
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>

> 
> I would prefer we use the existing PKCS7/CMS formats.  However, why should
> we force the client/user to choose one way or the other?  Can't we add an
> optional "response attribute" to enable the client to tell the server what
> format it wants to deal with?  
> 
> <query URI> '?' <attribute> '=' <value> ['&' 'response' '=' <value>]
> 
> I don't see this complicating the server side implementation very much.  
> 
> Alex
> 

The HTTP request could simply have an Accept: application/pkcs7 or
Accept: multipart/* header. 


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g1C9qOJ15748 for ietf-pkix-bks; Tue, 12 Feb 2002 01:52:24 -0800 (PST)
Received: from mail.smarttrust.com ([213.212.5.232]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1C9qN315744 for <[e-mail]>; Tue, 12 Feb 2002 01:52:23 -0800 (PST)
Received: from sek43.smarttrust.com ([172.16.0.43]) by mail.smarttrust.com with Microsoft SMTPSVC(5.0.2195.2966); Tue, 12 Feb 2002 10:52:17 +0100
X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Subject: RE: Candidate for moving OCSP to a Draft Standard
Date: Tue, 12 Feb 2002 10:52:21 +0100
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Candidate for moving OCSP to a Draft Standard
Thread-Index: AcGzkvoPAUULUxzVQVSeSuaWJzYEpAAEcFsg
From: "Simon Tardell" <[e-mail]>
To: "Khaja E. Ahmed" <[e-mail]>, <[e-mail]>
X-OriginalArrivalTime: 12 Feb 2002 09:52:17.0853 (UTC) FILETIME=[F4F406D0:01C1B3AA]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id g1C9qO315745
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>

> Simon,
> 
> I am afraid I did not describe the scenario and it's 
> assumptions in full detail but the solution you are pointing 
> out would not apply.  In this (ISIS envisioned scenario...I 
> think) the OCSP responder and the CA do not know that the 
> CA's private key has been stolen/copied and is being used to 
> mint certificates.  Thus the OCSP responder would respond 
> that the certificate was good because it was not known to be 
> revoked.  In fact even if the CertificateOK extension is used 
> this problem may not be caught if duplicate serial numbers 
> were being used.  Indeed even a delegated path validation 
> capable server may not catch this particular problem 
> depending on the nature of the checking done prior to 
> generating a response.  The solution envisioned, as explained 
> to me by some German and other EU bank PKI folks, was that 
> the OCSP responder would have access to some sort of a 
> database that contains all the certificates issued by the 
> legit CA and will check against this database.  The 
> validation server would have to be given the entire 
> certificate or at least the public key or identifier and 
> confirm that that precise key, was certified in a certificate 
> with that exact serial number, etc.
> 
> Anyway, where I had left it was that it would be fine to do 
> anything over and above basic OCSP (via extensions) so long 
> as it did not change/overload the semantics of the OCSP 
> status itself from that specified in RFC2560.  My own 
> inclination was, and remains, to settle for people doing ANY 
> checking of status at all to get started.
> 
> Anything beyond that is probably best handled by some 
> standardized (hopefully easy to use) protocol the list comes up with.
> 
> 
> Khaja

Khaja,

As I have understood it the driver for the ISIS scenario can be
described in these terms: Imagine a CA that issued a large number of
certificate to smart cards (lets say millions). If the CA key is
compromised replacing millions of certificates would take a significant
amount of time (the end-entity keys are still ok). During that time the
German economy can not be let grind to a halt. 

Hence they introduce an extension whereby the OCSP responder asserts
that a certain certificate (identified by its hash) was known to the
responder before a certain time. In effect they turn the responder into
a certificate time stamping service.

Unfortunately, they do it by modifying the OCSP semantics so as to make
ISIS OCSP somewhat incompatible with RFC2560 OCSP (using the vague
language of "unknown" -- in ISIS "unknown" is an affirmative assertion
"I know that this certificate does not exist").

IMHO a better way to achieve redundancy, would have been to mandate that
more than (independent) CA should certify the same keys. 

I tend to believe that ISIS is a lost case, the "profile" will likely
remain incompatible with ordinary OCSP. I am not sure that there will be
enough "certificate time stamping" needs outside of the ISIS sphere to
warrant a PKIX extension to this effect, but I might be wrong. However I
do not rule out additional "goodness" assertion extensions in general
(issuance, within validity, ...).

Simon

Simon Tardell, Software Architect, SmartTrust
voice [phone], fax [phone]
cell [phone], [e-mail]


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g1C85kF00458 for ietf-pkix-bks; Tue, 12 Feb 2002 00:05:46 -0800 (PST)
Received: from anatolia.msis.metu.edu.tr (anatolia.msis.metu.edu.tr [144.122.201.5]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1C85g300446 for <[e-mail]>; Tue, 12 Feb 2002 00:05:43 -0800 (PST)
Received: from tkilicli by anatolia.msis.metu.edu.tr with local (Exim 3.34 #1 (Debian)) id 16aXur-0005Mn-00 for <[e-mail]>; Tue, 12 Feb 2002 10:03:53 +0200
Date: Tue, 12 Feb 2002 10:03:53 +0200
To: [e-mail]
Subject: ;login: special issue
Message-ID: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.3.27i
From: Tolga KILICLI <[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>

Hi,        
            
I am prepearing a special issue on PKI for ;login:, newsletter of USENIX.
I would like to ask for your comments and contributions.  

In the issue, I want articles on all about PKI, from implementations to problems 
faced. And I want to have the comments and thoughts on why we don't see broad range
applications of PKI. Is it because it is not cheap enough or is it because of        
the key point in PKI, trust? Does people not trust others on the net who they    
do not see?
        
The issue, I think, must have articles on experiences, implementations,
applications and also the future of PKI. Some say that PKI is dead and has
risks. May be this is true or not but these should be discussed in the issue.
                    
I would like to receive your comments and the topics you can write about. But
not to waste the group's time I would like to have your inputs mailed to me.
You can send any of your inputs (thoughts, articles, etc ...)

Thanks and I am waiting for your comments
Tolga KILICLI



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g1C70ab17544 for ietf-pkix-bks; Mon, 11 Feb 2002 23:00:36 -0800 (PST)
Received: from rwcrmhc51.attbi.com (rwcrmhc51.attbi.com [204.127.198.38]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1C70Z317536 for <[e-mail]>; Mon, 11 Feb 2002 23:00:35 -0800 (PST)
Received: from C707777B ([12.232.94.141]) by rwcrmhc51.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with SMTP id <20020212070030.MKBA1672.rwcrmhc51.attbi.com@C707777B>; Tue, 12 Feb 2002 07:00:30 +0000
From: "Khaja E. Ahmed" <[e-mail]>
To: "Simon Tardell" <[e-mail]>, <[e-mail]>
Subject: RE: Candidate for moving OCSP to a Draft Standard
Date: Mon, 11 Feb 2002 22:59:54 -0800
Message-ID: <[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 IMO, Build 9.0.2416 (9.0.2910.0)
X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
In-Reply-To: <[e-mail]>
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>

Simon,

I am afraid I did not describe the scenario and it's assumptions in full
detail but the solution you are pointing out would not apply.  In this (ISIS
envisioned scenario...I think) the OCSP responder and the CA do not know
that the CA's private key has been stolen/copied and is being used to mint
certificates.  Thus the OCSP responder would respond that the certificate
was good because it was not known to be revoked.  In fact even if the
CertificateOK extension is used this problem may not be caught if duplicate
serial numbers were being used.  Indeed even a delegated path validation
capable server may not catch this particular problem depending on the nature
of the checking done prior to generating a response.  The solution
envisioned, as explained to me by some German and other EU bank PKI folks,
was that the OCSP responder would have access to some sort of a database
that contains all the certificates issued by the legit CA and will check
against this database.  The validation server would have to be given the
entire certificate or at least the public key or identifier and confirm that
that precise key, was certified in a certificate with that exact serial
number, etc.

Anyway, where I had left it was that it would be fine to do anything over
and above basic OCSP (via extensions) so long as it did not change/overload
the semantics of the OCSP status itself from that specified in RFC2560.  My
own inclination was, and remains, to settle for people doing ANY checking of
status at all to get started.

Anything beyond that is probably best handled by some standardized
(hopefully easy to use) protocol the list comes up with.


Khaja

> -----Original Message-----
> From: Simon Tardell [mailto:[e-mail]]
> Sent: Monday, February 11, 2002 7:33 AM
> To: Khaja E. Ahmed; [e-mail]
> Subject: RE: Candidate for moving OCSP to a Draft Standard
>
>
> > I agree that there is no great need for an OCSP server to
> > tell a PKI enabled client that a certificate exists or was
> > issued if the PKI enabled client has first performed the
> > required verification of the CAs signature on the cert and
> > done proper path validation and is now only checking the
> > revocation status.  My initial reaction was that it might not
> > do any harm to have an optional extension to satisfy some
> > corner cases.  One such case, that was put forth was of a
> > situation where the CA's private key was stolen and being
> > used to mint certificates by an attacker.  Such certificates
> > would not be in the CA's database. An optional extension like
> > the one proposed by Peter could afford some limited
> > protection against this.
>
> Khaja,
>
> This case is already catered for in RFC2560:
>
> "2.7  CA Key Compromise
>
>    If an OCSP responder knows that a particular CA's private key has
>    been compromised, it MAY return the revoked state for all
>    certificates issued by that CA."
>
> Simon.
>
> Simon Tardell, Software Architect, SmartTrust
> voice [phone], fax [phone]
> cell [phone], [e-mail]



Received: by above.proper.com (8.11.6/8.11.3) id g1BN0MO09141 for ietf-pkix-bks; Mon, 11 Feb 2002 15:00:22 -0800 (PST)
Received: from peacock.verisign.com (peacock.verisign.com [65.205.251.73]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1BN0K309134 for <[e-mail]>; Mon, 11 Feb 2002 15:00:21 -0800 (PST)
Received: from vhqpostal-gw1.verisign.com (verisign.com [65.205.251.55]) by peacock.verisign.com (8.11.3/BCH1.7.5) with ESMTP id g1BMs1R05722; Mon, 11 Feb 2002 14:54:05 -0800 (PST)
Received: by vhqpostal-gw1.verisign.com with Internet Mail Service (5.5.2653.19) id <DY1RYW0X>; Mon, 11 Feb 2002 14:58:30 -0800
Message-ID: <[e-mail]>
From: "Deacon, Alex" <[e-mail]>
To: "'[e-mail]'" <[e-mail]>, [e-mail], [e-mail]
Cc: [e-mail]
Subject: RE: I-D ACTION:draft-ietf-pkix-certstore-http-02.txt
Date: Mon, 11 Feb 2002 14:56:15 -0800
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>

I would prefer we use the existing PKCS7/CMS formats.  However, why should
we force the client/user to choose one way or the other?  Can't we add an
optional "response attribute" to enable the client to tell the server what
format it wants to deal with?  

<query URI> '?' <attribute> '=' <value> ['&' 'response' '=' <value>]

I don't see this complicating the server side implementation very much.  

Alex


> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]]
> Sent: Sunday, February 10, 2002 11:16 PM
> To: [e-mail]; [e-mail]
> Cc: [e-mail]
> Subject: Re: I-D ACTION:draft-ietf-pkix-certstore-http-02.txt
> 
> 
> 
> So far there seems to be a pretty even split on this.  
> Initially when I
> suggested SEQUENCE OF there was a clamour for MIME multipart, 
> with MIME
> multipart people are saying they want SEQUENCE OF.  Russ 
> Housley commented
> that:
> 
> >On the client side of the HTTP Cert Store, I agree.  
> However, it is not clear
> >that the server side of the HTTP Cert Store needs to do 
> anything with the
> >certificate at all.  It is just a blob that needs to be 
> returned to the client.
> >
> >The MIME wrapper is already needed.  We are discussing 
> whether a new MIME type
> >should be defined to carry the SEQUENCE OF Certificate or we 
> should use the
> >existing MIME type define in RFC 2585 with a multipart.  All of the
> >specifications and implementation tools are already in place 
> to do the latter.
> 
> To try and sort this out I asked one or two of the people who 
> have implemented
> this (that is, not strictly what's in the draft since it 
> didn't exist when they
> did it, but something pretty similar).  All they did was (on 
> the server side)
> allow web queries of SQL Server via the SQL ISAPI extension, 
> and (on the client
> side) use WinInet (which is either an API name or an ActiveX 
> control) to grab
> the results, the interface is something like connect, 
> send-request, get-result
> (I don't use this stuff myself so I'm just repeating what I 
> was told).  These
> are standard tools which (presumably) a majority of users 
> will end up using.
> Since this seems to be the way which implementations will go, 
> and without any
> strong argument to push the balance one way or the other, 
> I'll leave it at MIME
> multipart for now.  Following the PKIX tradition this will 
> probably remain a
> draft for ages :-), so there'll be plenty of time to change it if an
> overwhelming reason for SEQUENCE OF appears later.
> 
> Peter.
> 


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g1BGRuq01113 for ietf-pkix-bks; Mon, 11 Feb 2002 08:27:56 -0800 (PST)
Received: from mtiwmhc22.worldnet.att.net (mtiwmhc22.worldnet.att.net [204.127.131.47]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1BGRs301109 for <[e-mail]>; Mon, 11 Feb 2002 08:27:54 -0800 (PST)
Received: from tsg1 ([12.81.70.124]) by mtiwmhc22.worldnet.att.net (InterMail vM.4.01.03.27 201-229-121-127-20010626) with SMTP id <20020211162748.YYAN21579.mtiwmhc22.worldnet.att.net@tsg1>; Mon, 11 Feb 2002 16:27:48 +0000
Message-ID: <001b01c1b319$0633fff0$020aff0c@tsg1>
From: "todd glassey" <[e-mail]>
To: "Cotton Franck" <[e-mail]>, "'Denis Pinkas'" <[e-mail]>, "'Tom Gindin'" <[e-mail]>
Cc: <[e-mail]>
References: <7BABBC255DA2D311BFF60000F6AF21FA04FD87C9@S90X01>
Subject: Re: Permanent identifier draft
Date: Mon, 11 Feb 2002 08:27:38 -0800
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0018_01C1B2D5.F6C6B3C0"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2600.0000
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
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>

This is a multi-part message in MIME format.

------=_NextPart_000_0018_01C1B2D5.F6C6B3C0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Permanent identifier draftFrank you are 100% dead on but the same is =
true of many PKI protocols.=20

Denis and TS Authors - The timestamp protocol has exactly the same =
problem and desperately needs a way to specify a variant Token Protocol =
and its management - Especially for tokens to represent financial =
transactions like in SWIFT, QUICK and FLASH. The TST is where the TSP =
meets the road as I have always said and the power to do and negotiate =
various types of TST's is the power behind the true TSA.

However if you think about it, the same is true of most PKI protocols. =
They may be able to manage signature-verification (which is all that =
pure PKI is good for), but the question is how Signatures are applied to =
individual data blobs for use. Its the Rules and processes that make up =
the Protocol per se.

Ultimately I think that ALL of the successful PKI protocols will need =
this same type of capability, that is to leverage services from another =
PKI Service, since at the application level all they are good for is =
decision support systems. Without significant additions in data and =
content assurance processes all they can be used for is by an =
application for verifying a signature in time as part of a larger =
decision support process.=20


Todd Glassey.
  ----- Original Message -----=20
  From: Cotton Franck=20
  To: 'Denis Pinkas' ; 'Tom Gindin'=20
  Cc: '[e-mail]'=20
  Sent: Sunday, February 10, 2002 11:17 PM
  Subject: Permanent identifier draft




  Denis, Tom=20

  I think the PI draft should be re-issued on the standard track, =
because these questions about naming and identifying are likely to =
become more and more important and should be discussed (cf. recent =
threads after Roberto Opazo Gazmuri's posting).

  Il you re-issue the draft, maybe you will like to add an Appendix =
A.3.3 covering the fact that most organizations already have an OID (and =
often several) without knowing it through the mapping between ISO-6523 =
and OID arc 1.3. For example, D-U-N-S number <N> is mapped to =
1.3.60.<N>. If France, every enterprise has an OID derived from its =
9-digit SIRENE number <S>, which is 1.3.2.<S>.

  There are a many coding systems declared under ISO-6523 (EAN, SWIFT, =
EDIRA, ...), see =
http://xw2k.sdct.itl.nist.gov/l8/document-library/draft-standards/ICD-lis=
t.htm

  Franck Cotton=20
  INSEE - http://www.insee.fr=20


------=_NextPart_000_0018_01C1B2D5.F6C6B3C0
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD><TITLE>Permanent identifier draft</TITLE>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Diso-8859-1">
<META content=3D"MSHTML 6.00.2712.300" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2>Frank you are 100% dead on but&nbsp;the =
same is=20
true of&nbsp;many PKI protocols. </FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>Denis and TS Authors - The timestamp =
protocol has=20
exactly the same problem and desperately needs a way to specify a =
variant Token=20
Protocol and its management - Especially for tokens to represent =
financial=20
transactions like in SWIFT, QUICK and FLASH. The TST is where the TSP =
meets the=20
road as I have always said and the power to do and negotiate various =
types of=20
TST's is the power behind the true TSA.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>However if you think about it, the same =
is true of=20
most PKI protocols. They may be able to manage signature-verification =
(which is=20
all that pure PKI is good for), but the question is how Signatures are =
applied=20
to individual data blobs for use. Its the Rules and processes that make =
up the=20
Protocol per se.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>Ultimately I think that ALL of the =
successful PKI=20
protocols will need this same type of capability, that is to leverage =
services=20
from another PKI Service, since at the application level all they are =
good for=20
is decision support systems. Without significant additions in data and =
content=20
assurance processes all they can be used for is by an application for =
verifying=20
a signature in time as part of a larger&nbsp;decision support=20
process.&nbsp;</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>Todd Glassey.</FONT></DIV>
<BLOCKQUOTE dir=3Dltr=20
style=3D"PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; =
BORDER-LEFT: #000000 2px solid; MARGIN-RIGHT: 0px">
  <DIV style=3D"FONT: 10pt arial">----- Original Message ----- </DIV>
  <DIV=20
  style=3D"BACKGROUND: #e4e4e4; FONT: 10pt arial; font-color: =
black"><B>From:</B>=20
  <A title=[e-mail] =
href=3D"mailto:[e-mail]">Cotton=20
  Franck</A> </DIV>
  <DIV style=3D"FONT: 10pt arial"><B>To:</B> <A =
title=[e-mail]=20
  href=3D"mailto:[e-mail]">'Denis Pinkas'</A> ; <A=20
  title=[e-mail] href=3D"mailto:[e-mail]">'Tom =
Gindin'</A>=20
  </DIV>
  <DIV style=3D"FONT: 10pt arial"><B>Cc:</B> <A =
title=[e-mail]=20
  href=3D"mailto:'[e-mail]'">'[e-mail]'</A> </DIV>
  <DIV style=3D"FONT: 10pt arial"><B>Sent:</B> Sunday, February 10, 2002 =
11:17=20
  PM</DIV>
  <DIV style=3D"FONT: 10pt arial"><B>Subject:</B> Permanent identifier =
draft</DIV>
  <DIV><BR></DIV><BR>
  <P><FONT face=3DArial size=3D2>Denis, Tom</FONT> </P>
  <P><FONT face=3DArial size=3D2>I think the PI draft should be =
re-issued on the=20
  standard track, because these questions about naming and identifying =
are=20
  likely to become more and more important and should be discussed (cf. =
recent=20
  threads after Roberto Opazo Gazmuri's posting).</FONT></P>
  <P><FONT face=3DArial size=3D2>Il you re-issue the draft, maybe you =
will like to=20
  add an Appendix A.3.3 covering the fact that most organizations =
already have=20
  an OID (and often several) without knowing it through the mapping =
between=20
  ISO-6523 and OID arc 1.3. For example, D-U-N-S number &lt;N&gt; is =
mapped to=20
  1.3.60.&lt;N&gt;. If France, every enterprise has an OID derived from =
its=20
  9-digit SIRENE number &lt;S&gt;, which is 1.3.2.&lt;S&gt;.</FONT></P>
  <P><FONT face=3DArial size=3D2>There are a many coding systems =
declared under=20
  ISO-6523 (EAN, SWIFT, EDIRA, ...), see </FONT><A=20
  =
href=3D"http://xw2k.sdct.itl.nist.gov/l8/document-library/draft-standards=
/ICD-list.htm"><U><FONT=20
  face=3DArial color=3D#0000ff=20
  =
size=3D2>http://xw2k.sdct.itl.nist.gov/l8/document-library/draft-standard=
s/ICD-list.htm</FONT></U></A></P>
  <P><FONT face=3DArial size=3D2>Franck Cotton</FONT> <BR><FONT =
face=3DArial=20
  size=3D2>INSEE - </FONT><A href=3D"http://www.insee.fr"><U><FONT =
face=3DArial=20
  color=3D#0000ff size=3D2>http://www.insee.fr</FONT></U></A>=20
</P></BLOCKQUOTE></BODY></HTML>

------=_NextPart_000_0018_01C1B2D5.F6C6B3C0--



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g1BGDP300809 for ietf-pkix-bks; Mon, 11 Feb 2002 08:13:25 -0800 (PST)
Received: from mail.smarttrust.com ([213.212.5.232]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1BGDN300805 for <[e-mail]>; Mon, 11 Feb 2002 08:13:23 -0800 (PST)
Received: from sek43.smarttrust.com ([172.16.0.43]) by mail.smarttrust.com with Microsoft SMTPSVC(5.0.2195.2966); Mon, 11 Feb 2002 17:13:19 +0100
X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Subject: RE: Candidate for moving OCSP to a Draft Standard
Date: Mon, 11 Feb 2002 17:13:23 +0100
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Candidate for moving OCSP to a Draft Standard
Thread-Index: AcGw/jJi1aS1a4hoRiOH9y+Bj0xUFACGLhuw
From: "Simon Tardell" <[e-mail]>
To: <[e-mail]>
X-OriginalArrivalTime: 11 Feb 2002 16:13:19.0830 (UTC) FILETIME=[05571F60:01C1B317]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id g1BGDO300806
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>

> I agree that there is no great need for an OCSP server to
> tell a PKI enabled client that a certificate exists or was 
> issued if the PKI enabled client has first performed the 
> required verification of the CAs signature on the cert and 
> done proper path validation and is now only checking the 
> revocation status.  My initial reaction was that it might not 
> do any harm to have an optional extension to satisfy some 
> corner cases.  One such case, that was put forth was of a 
> situation where the CA's private key was stolen and being 
> used to mint certificates by an attacker.  Such certificates 
> would not be in the CA's database. An optional extension like 
> the one proposed by Peter could afford some limited 
> protection against this.

Khaja,

This case is already catered for in RFC2560:

"2.7  CA Key Compromise

   If an OCSP responder knows that a particular CA's private key has
   been compromised, it MAY return the revoked state for all
   certificates issued by that CA."

Simon.

Simon Tardell, Software Architect, SmartTrust
voice [phone], fax [phone]
cell [phone], [e-mail]


Received: by above.proper.com (8.11.6/8.11.3) id g1BDplZ22335 for ietf-pkix-bks; Mon, 11 Feb 2002 05:51:47 -0800 (PST)
Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1BDpk322331 for <[e-mail]>; Mon, 11 Feb 2002 05:51:46 -0800 (PST)
Received: from ireserver.Ireland.Sun.COM ([129.156.220.7]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA28284; Mon, 11 Feb 2002 06:51:41 -0700 (MST)
Received: from sun.com (dhcp-edub03-21 [129.156.220.138]) by ireserver.Ireland.Sun.COM (8.8.8+Sun/8.8.8/ENSMAIL,v2.2) with ESMTP id NAA28136; Mon, 11 Feb 2002 13:51:40 GMT
Message-ID: <[e-mail]>
Date: Mon, 11 Feb 2002 13:51:39 +0000
From: Andreas Sterbenz <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.8) Gecko/20020204
X-Accept-Language: en-us
MIME-Version: 1.0
To: "Housley, Russ" <[e-mail]>
CC: [e-mail]
Subject: Re: I-D ACTION:draft-ietf-pkix-certstore-http-02.txt
References: <[e-mail]> <[e-mail]> <[e-mail]>
Content-Type: text/plain; charset=us-ascii; format=flowed
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>

Housley, Russ wrote:
> 
> The MIME wrapper is already needed.  We are discussing whether a new 
> MIME type should be defined to carry the SEQUENCE OF Certificate or we 
> should use the existing MIME type define in RFC 2585 with a multipart.  
> All of the specifications and implementation tools are already in place 
> to do the latter.

I was not arguing for a new MIME type, I was arguing for using the 
existing PKCS7/CMS format and MIME type. I would claim that this is much 
better supported by certificate handling applications than multipart.

Andreas.



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g1BD4bI18600 for ietf-pkix-bks; Mon, 11 Feb 2002 05:04:37 -0800 (PST)
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 g1BD4Z318596 for <[e-mail]>; Mon, 11 Feb 2002 05:04:35 -0800 (PST)
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 CAA03574; Tue, 12 Feb 2002 02:04:24 +1300 (NZDT) (sender [e-mail])
Received: (from pgut001@localhost) by ruru.cs.auckland.ac.nz (8.9.3/8.8.6/cs-slave) id CAA211243; Tue, 12 Feb 2002 02:04:24 +1300 (NZDT) (sender [e-mail])
Date: Tue, 12 Feb 2002 02:04:24 +1300 (NZDT)
Message-ID: <[e-mail]>
From: [e-mail] (Peter Gutmann)
To: [e-mail], [e-mail]
Subject: Re: Candidate for moving OCSP to a Draft Standard
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>

"David P. Kemp" <[e-mail]> writes:

>You don't like CAs who update their CRLs every 24 hours, then suggest that
>they update them every 15 seconds (to a select group of redistributors, not
>every end user) instead.

In practice (or at least with many of the CAs I know of) you don't really have
much choice, if they decide they're going to give you a CRL once a month you
can either sit there and grin ("You got the right to shut up and do wot yor
told") or (at best) set up and run your own CA.

>If I were a CA bidding on a Service Level Agreement to provide 15-second
>revocation freshness and 1 second response time for 1 million users, I would
>bid less to do it using delta CRLs than using Oracle or Sabre or whatever
>acceptance system Lynn has in mind.

The model I have in mind is Berkeley DB (fully in-memory) and a pile of SSL
accelerators to do the signing [0].  I bet I can make it faster, cheaper, and
more scalable than anything that uses CRLs.

Peter.

[0] And by "SSL accelerators" I'm thinking of the ones made by AMD and Intel as
    well as the usual nCipher and Broadcom.


Received: by above.proper.com (8.11.6/8.11.3) id g1BBuwv14374 for ietf-pkix-bks; Mon, 11 Feb 2002 03:56:58 -0800 (PST)
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1BBuu314369 for <[e-mail]>; Mon, 11 Feb 2002 03:56:56 -0800 (PST)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA28762; Mon, 11 Feb 2002 06:56:56 -0500 (EST)
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-dpv-dpd-req-02.txt
Date: Mon, 11 Feb 2002 06:56:55 -0500
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>

--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		: Delegated Path Validation and Delegated Path Discovery
                          Protocol Requirements (DPV&DPD-REQ)
	Author(s)	: D. Pinkas, R. Housley
	Filename	: draft-ietf-pkix-dpv-dpd-req-02.txt
	Pages		: 14
	Date		: 08-Feb-02
	
This document specifies the requirements for Delegated Path Validation (DPV) and Delegated Path Discovery (DPD). It also specifies the  requirements for DPV and DPD policy management.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-pkix-dpv-dpd-req-02.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

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-dpv-dpd-req-02.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-dpv-dpd-req-02.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-dpv-dpd-req-02.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-pkix-dpv-dpd-req-02.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.6/8.11.3) id g1BBuZ014362 for ietf-pkix-bks; Mon, 11 Feb 2002 03:56:35 -0800 (PST)
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1BBuY314358 for <[e-mail]>; Mon, 11 Feb 2002 03:56:34 -0800 (PST)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA28686; Mon, 11 Feb 2002 06:56:33 -0500 (EST)
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-01.txt
Date: Mon, 11 Feb 2002 06:56:33 -0500
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>

--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, R. Housley
	Filename	: draft-ietf-pkix-logotypes-01.txt
	Pages		: 14
	Date		: 08-Feb-02
	
This document contains an initial outline of a standard for attaching
logotypes to certificates. The draft includes background discussions
around different aspects of problems and solutions, forming a
starting point for the creation of a complete standard.
Please send comments on this document to the [e-mail]
mailing list.

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

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

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-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-logotypes-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-logotypes-01.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-pkix-logotypes-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.6/8.11.3) id g1B7Hc113381 for ietf-pkix-bks; Sun, 10 Feb 2002 23:17:38 -0800 (PST)
Received: from hermes2.insee.fr (s2b.insee.fr [194.254.38.69]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1B7Ha313371 for <[e-mail]>; Sun, 10 Feb 2002 23:17:37 -0800 (PST)
Received: from proxyext1.insee.fr ([194.254.38.143]) by hermes2.insee.fr (Post.Office MTA V2.1.5 release 144 ID# 511-59534U100L100S0V35) with SMTP id fr; Mon, 11 Feb 2002 08:17:35 +0100
Received: by S54XSMTP with Internet Mail Service (5.5.2653.19) id <D51Z6D4S>; Mon, 11 Feb 2002 08:17:29 +0100
Message-ID: <7BABBC255DA2D311BFF60000F6AF21FA04FD87C9@S90X01>
From: Cotton Franck <[e-mail]>
To: "'Denis Pinkas'" <[e-mail]>, "'Tom Gindin'" <[e-mail]>
Cc: "'[e-mail]'" <[e-mail]>
Subject: Permanent identifier draft
Date: Mon, 11 Feb 2002 08:17:27 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/mixed; boundary="----=_NextPartTM-000-9eed5919-79eb-46c4-ac50-e3f534aba459"
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>

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.

------=_NextPartTM-000-9eed5919-79eb-46c4-ac50-e3f534aba459
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C1B2CC.294DED90"

------_=_NextPart_001_01C1B2CC.294DED90
Content-Type: text/plain


> Denis, Tom
> 
> I think the PI draft should be re-issued on the standard track, because
> these questions about naming and identifying are likely to become more and
> more important and should be discussed (cf. recent threads after Roberto
> Opazo Gazmuri's posting).
> 
> Il you re-issue the draft, maybe you will like to add an Appendix A.3.3
> covering the fact that most organizations already have an OID (and often
> several) without knowing it through the mapping between ISO-6523 and OID
> arc 1.3. For example, D-U-N-S number <N> is mapped to 1.3.60.<N>. If
> France, every enterprise has an OID derived from its 9-digit SIRENE number
> <S>, which is 1.3.2.<S>.
> 
> There are a many coding systems declared under ISO-6523 (EAN, SWIFT,
> EDIRA, ...), see
> http://xw2k.sdct.itl.nist.gov/l8/document-library/draft-standards/ICD-list
> .htm
> <http://xw2k.sdct.itl.nist.gov/l8/document-library/draft-standards/ICD-lis
> t.htm> 
> 
> Franck Cotton
> INSEE - http://www.insee.fr <http://www.insee.fr> 

------_=_NextPart_001_01C1B2CC.294DED90
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.2653.12">
<TITLE>Permanent identifier draft</TITLE>
</HEAD>
<BODY>
<BR>

<P><FONT SIZE=3D2 FACE=3D"Arial">Denis, Tom</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">I think the PI draft should be =
re-issued on the standard track, because these questions about naming =
and identifying are likely to become more and more important and should =
be discussed (cf. recent threads after Roberto Opazo Gazmuri's =
posting).</FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Il you re-issue the draft, maybe you =
will like to add an Appendix A.3.3 covering the fact that most =
organizations already have an OID (and often several) without knowing =
it through the mapping between ISO-6523 and OID arc 1.3. For example, =
D-U-N-S number &lt;N&gt; is mapped to 1.3.60.&lt;N&gt;. If France, =
every enterprise has an OID derived from its 9-digit SIRENE number =
&lt;S&gt;, which is 1.3.2.&lt;S&gt;.</FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Arial">There are a many coding systems =
declared under ISO-6523 (EAN, SWIFT, EDIRA, ...), see </FONT><A =
HREF=3D"http://xw2k.sdct.itl.nist.gov/l8/document-library/draft-standard=
s/ICD-list.htm"><U><FONT COLOR=3D"#0000FF" SIZE=3D2 =
FACE=3D"Arial">http://xw2k.sdct.itl.nist.gov/l8/document-library/draft-s=
tandards/ICD-list.htm</FONT></U></A></P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Franck Cotton</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">INSEE - </FONT><A =
HREF=3D"http://www.insee.fr"><U><FONT COLOR=3D"#0000FF" SIZE=3D2 =
FACE=3D"Arial">http://www.insee.fr</FONT></U></A>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C1B2CC.294DED90--

------=_NextPartTM-000-9eed5919-79eb-46c4-ac50-e3f534aba459--



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g1B7H8T13321 for ietf-pkix-bks; Sun, 10 Feb 2002 23:17:08 -0800 (PST)
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 g1B7H6313317 for <[e-mail]>; Sun, 10 Feb 2002 23:17:06 -0800 (PST)
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 UAA30879; Mon, 11 Feb 2002 20:15:59 +1300 (NZDT) (sender [e-mail])
Received: (from pgut001@localhost) by ruru.cs.auckland.ac.nz (8.9.3/8.8.6/cs-slave) id UAA205742; Mon, 11 Feb 2002 20:15:58 +1300 (NZDT) (sender [e-mail])
Date: Mon, 11 Feb 2002 20:15:58 +1300 (NZDT)
Message-ID: <[e-mail]>
From: [e-mail] (Peter Gutmann)
To: [e-mail], [e-mail]
Subject: Re: I-D ACTION:draft-ietf-pkix-certstore-http-02.txt
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>

So far there seems to be a pretty even split on this.  Initially when I
suggested SEQUENCE OF there was a clamour for MIME multipart, with MIME
multipart people are saying they want SEQUENCE OF.  Russ Housley commented
that:

>On the client side of the HTTP Cert Store, I agree.  However, it is not clear
>that the server side of the HTTP Cert Store needs to do anything with the
>certificate at all.  It is just a blob that needs to be returned to the client.
>
>The MIME wrapper is already needed.  We are discussing whether a new MIME type
>should be defined to carry the SEQUENCE OF Certificate or we should use the
>existing MIME type define in RFC 2585 with a multipart.  All of the
>specifications and implementation tools are already in place to do the latter.

To try and sort this out I asked one or two of the people who have implemented
this (that is, not strictly what's in the draft since it didn't exist when they
did it, but something pretty similar).  All they did was (on the server side)
allow web queries of SQL Server via the SQL ISAPI extension, and (on the client
side) use WinInet (which is either an API name or an ActiveX control) to grab
the results, the interface is something like connect, send-request, get-result
(I don't use this stuff myself so I'm just repeating what I was told).  These
are standard tools which (presumably) a majority of users will end up using.
Since this seems to be the way which implementations will go, and without any
strong argument to push the balance one way or the other, I'll leave it at MIME
multipart for now.  Following the PKIX tradition this will probably remain a
draft for ages :-), so there'll be plenty of time to change it if an
overwhelming reason for SEQUENCE OF appears later.

Peter.


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g1B6uAD09022 for ietf-pkix-bks; Sun, 10 Feb 2002 22:56:10 -0800 (PST)
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 g1B6u8309017 for <[e-mail]>; Sun, 10 Feb 2002 22:56:08 -0800 (PST)
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 TAA30301; Mon, 11 Feb 2002 19:56:03 +1300 (NZDT) (sender [e-mail])
Received: (from pgut001@localhost) by ruru.cs.auckland.ac.nz (8.9.3/8.8.6/cs-slave) id TAA205271; Mon, 11 Feb 2002 19:56:01 +1300 (NZDT) (sender [e-mail])
Date: Mon, 11 Feb 2002 19:56:01 +1300 (NZDT)
Message-ID: <[e-mail]>
From: [e-mail] (Peter Gutmann)
To: [e-mail], [e-mail], [e-mail], [e-mail]
Subject: RE: Candidate for moving OCSP to a Draft Standard
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>

Ambarish Malpani <[e-mail]> writes:

>In a lot of cases, people have set up our VA (Validation Authority/ OCSP
>Responder), to run next to a CA, operated by the CA operator.
>
>They have set up the system, so that as soon as there is a new revocation
>event, a new CRL is produced, with is immediately shipped to the VA. The VA
>now provides revocation information based on this new CRL.

Which just seems bizarre to me.  The CA maintains a centralised record of
what's valid and what isn't, why do you need to jump through all these hoops
just to do what you could do directly without all the overhead?

Peter.



Received: by above.proper.com (8.11.6/8.11.3) id g190nun25487 for ietf-pkix-bks; Fri, 8 Feb 2002 16:49:56 -0800 (PST)
Received: from tisch.mail.mindspring.net (tisch.mail.mindspring.net [207.69.200.157]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g190nt325483 for <[e-mail]>; Fri, 8 Feb 2002 16:49:55 -0800 (PST)
Received: from user-2ivf50h.dialup.mindspring.com ([165.247.148.17] helo=ASN-1.com) by tisch.mail.mindspring.net with esmtp (Exim 3.33 #1) id 16ZLiF-0002UF-00; Fri, 08 Feb 2002 19:49:55 -0500
Message-ID: <[e-mail]>
Date: Fri, 08 Feb 2002 19:45:05 -0500
From: Phil Griffin <[e-mail]>
Organization: Griffin Consulting - http://ASN-1.com
X-Mailer: Mozilla 4.73 [en]C-{C-UDP; EBM-SONY1}  (Win95; U)
X-Accept-Language: en
MIME-Version: 1.0
To: "Housley, Russ" <[e-mail]>
CC: [e-mail]
Subject: Re: I-D ACTION:draft-ietf-pkix-certstore-http-02.txt
References: <[e-mail]> <[e-mail]> <[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>

Completely understand. Opinion unchanged.

Phil


"Housley, Russ" wrote:
> 
> Hi Phil.
> 
> >It seems to me that if you are capable of
> >handling a certificate, then handling a sequence
> >of certificates is not too much to ask.
> 
> On the client side of the HTTP Cert Store, I agree.  However, it is not
> clear that the server side of the HTTP Cert Store needs to do anything with
> the certificate at all.  It is just a blob that needs to be returned to the
> client.
> 
> The MIME wrapper is already needed.  We are discussing whether a new MIME
> type should be defined to carry the SEQUENCE OF Certificate or we should
> use the existing MIME type define in RFC 2585 with a multipart.  All of the
> specifications and implementation tools are already in place to do the latter.
> 
> Russ


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g18NVVo23624 for ietf-pkix-bks; Fri, 8 Feb 2002 15:31:31 -0800 (PST)
Received: from rwcrmhc51.attbi.com (rwcrmhc51.attbi.com [204.127.198.38]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g18NVT323620 for <[e-mail]>; Fri, 8 Feb 2002 15:31:30 -0800 (PST)
Received: from C707777B ([12.232.94.141]) by rwcrmhc51.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with SMTP id <20020208233127.NWTQ1672.rwcrmhc51.attbi.com@C707777B>; Fri, 8 Feb 2002 23:31:27 +0000
From: "Khaja E. Ahmed" <[e-mail]>
To: "David P. Kemp" <[e-mail]>, <[e-mail]>
Subject: RE: Candidate for moving OCSP to a Draft Standard
Date: Fri, 8 Feb 2002 15:30:42 -0800
Message-ID: <[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 IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
In-Reply-To: <[e-mail]>
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
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>

I agree that there is no great need for an OCSP server to tell a PKI enabled
client that a certificate exists or was issued if the PKI enabled client has
first performed the required verification of the CAs signature on the cert
and done proper path validation and is now only checking the revocation
status.  My initial reaction was that it might not do any harm to have an
optional extension to satisfy some corner cases.  One such case, that was
put forth was of a situation where the CA's private key was stolen and being
used to mint certificates by an attacker.  Such certificates would not be in
the CA's database. An optional extension like the one proposed by Peter
could afford some limited protection against this.

That said, the CertificateOK optional extension seems to introduce
certificate validation services in a non standardized and potentially
incomplete fashion.  A TTP should probably either limit itself to doing
revocation status response only or provide a proper and complete
certificate/path validity checking service.  Which means that if people are
interested in certificate validation services that might be more in SCVP and
XKMS like services rather than in OCSP extensions. Peters extension in the
meantime, may be temporary/partial solution.

Khaja

> -----Original Message-----
> From: [e-mail]
> [mailto:[e-mail]]On Behalf Of David P. Kemp
> Sent: Friday, February 08, 2002 9:23 AM
> To: [e-mail]
> Subject: Re: Candidate for moving OCSP to a Draft Standard
>
>
>
> Peter Gutmann wrote:
> >
> > "Khaja E. Ahmed" <[e-mail]> writes:
> >
> > >This sounds like a perfectly reasonable solution. Surprised it
> was rejected.
> > >After-all this would be an optional extension, why not add it?
> >
> > The reasoning as I recall was that OCSP shouldn't include
> facilities which
> > aren't bug-compatible with CRLs.  Since CRLs can only provide a negative
> > response, and even that only for some cases of invalid certs,
> OCSP doesn't
> > include a straighforward yes/no indication.
>
> Say what?  CRLs provide positive and negative responses, and the
> positive
> response is optimized down to 0 bytes.  If you want to know whether a
> certificate was issued, the signature on the cert tells you that, and if
> it doesn't you've got bigger problems than just revocation status.
>
> The reason OCSP can't say that a cert is valid has nothing to do with
> CRLs.
> It's crippled by the fact that the request does not include a cert, so
> the
> responder can't validate the signature unless it fetches the cert
> itself.
> Presumably the OCSP authors made a conscious decision not to require the
> responder to validate certification paths before providing a response.
>
>
> > (IMHO any poor guy who's stuck with feeding their online status
> service from
> >  offline CRLs has bigger things to worry about than this...).
>
> Speaking as one such poor guy :-), what's the problem?   I have a user
> community of 4.5 million people, and having each of them bang against
> a central OCSP server every time they do something PKI-related on their
> LAN is going to incur their wrath.  Server delays and Internet
> congestion shouldn't be designed into local applications, causing
> things that should have happened instantaneously to take 5 seconds,
> or more when their pipe to the Internet is loaded.
>
> I've learned to ignore Lynn Wheeler when he refers to CRLs as
> '60's-era blacklists (and I can remember when supermarket clerks thumbed
> through those little books).  But I expect you'd have a little more
> appreciation for simplicity.  What could be more elegant than having
> your
> LAN-based OCSP server replicate the PKI revocation database by fetching
> delta CRLs from the central server every 15 minutes?
>



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g18Msxu22898 for ietf-pkix-bks; Fri, 8 Feb 2002 14:54:59 -0800 (PST)
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 g18Msv322894 for <[e-mail]>; Fri, 8 Feb 2002 14:54:57 -0800 (PST)
Received: from [198.202.64.124] (SSH.BBN.COM [192.1.50.70]) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id RAA00990; Fri, 8 Feb 2002 17:54:47 -0500 (EST)
Mime-Version: 1.0
X-Sender: kent@127.0.0.1
Message-Id: <p0510030cb889fcb1a5cb@[198.202.64.124]>
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Date: Fri, 8 Feb 2002 17:10:33 -0500
To: "Bill Price" <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: Re: Certificate's Pointer to its Issuer's Certificate - AIA or IAN
Cc: <[e-mail]>
Content-Type: multipart/alternative; boundary="============_-1198913471==_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>

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

At 4:21 PM -0500 2/8/02, Bill Price wrote:
>PKIX defined the AIA extension which includes a caIssuers type to 
>point to Issuing CA information. The content of the extension is a 
>general name. The Issuer Alternative Name (IAN) standard extension 
>which also uses general names could point to issuer information. 
>Prior to the creation of the AIA extension, at least one PKI used 
>the URI form of IAN to point to an LDAP directory entry that 
>contained the issuer's information. The rationale was to 
>allow retrieval of the issuer's certificate.
>
>I was wondering what was the rationale for not using the IAN when 
>the AIA caIssuers extension was created. I was also wondering if the 
>PKIX path discovery work would focus on use of the AIA caIssuers 
>type and disregard use of the IAN. At least one of the major vendors 
>appears to have ignored use of the IAN for path creation.
>
>RFC 2459 does not seem to give any guidance on whether or how the 
>IAN and AIA relate other than what one might conclude from the 
>extension names-IAN provides an alternate name and AIA provides for 
>information access. It seems that they would or could have the same 
>content since they both depend on general names.
>
>Thanks.
>
>Bill Price

Bill,

The semantics for IAN would not generally imply that the CA's cert 
and CRL would be located at a site pointed to by a URI contained in 
that field. The AIA extension has semantics that explicitly 
communicate this information, and allow for more info, e.g., access 
method, in cases when it is not encoded via a URI.

Steve
--============_-1198913471==_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 { padding-top: 0 ; padding-bottom: 0 }
 --></style><title>Re: Certificate's Pointer to its Issuer's
Certificate</title></head><body>
<div>At 4:21 PM -0500 2/8/02, Bill Price wrote:</div>
<blockquote type="cite" cite>PKIX defined the AIA extension which
includes a<font face="Times New Roman"> caIssuers type to point to
Issuing CA information. The content of the extension is a general
name. The Issuer Alternative Name (IAN) standard extension which also
uses general names could point to issuer information. Prior to the
creation of the AIA extension, at least one PKI used the URI form of
IAN to point to an LDAP directory entry that contained the issuer's
information. The rationale was to allow&nbsp;retrieval of the issuer's
certificate.</font></blockquote>
<blockquote type="cite" cite>&nbsp;</blockquote>
<blockquote type="cite" cite><font face="Times New Roman">I was
wondering what was&nbsp;the&nbsp;rationale for not using the IAN when
the AIA caIssuers extension was created. I was also wondering if the
PKIX path discovery work would focus on use of the AIA caIssuers type
and disregard use of the IAN. At least one of the major vendors
appears to have ignored use of the IAN for path
creation.</font></blockquote>
<blockquote type="cite" cite>&nbsp;</blockquote>
<blockquote type="cite" cite><font face="Arial">RFC 2459 does not seem
to give any guidance on whether or how the IAN and AIA relate other
than what one might conclude from the extension names-IAN provides an
alternate name and AIA provides for information access. It seems that
they would or could have the same content since they both depend on
general names.</font></blockquote>
<blockquote type="cite" cite>&nbsp;</blockquote>
<blockquote type="cite" cite><font
face="Arial">Thanks.</font></blockquote>
<blockquote type="cite" cite>&nbsp;</blockquote>
<blockquote type="cite" cite><font face="Arial">Bill
Price</font></blockquote>
<div><br></div>
<div>Bill,</div>
<div><br></div>
<div>The semantics for IAN would not generally imply that the CA's
cert and CRL would be located at a site pointed to by a URI contained
in that field. The AIA extension has semantics that explicitly
communicate this information, and allow for more info, e.g., access
method, in cases when it is not encoded via a URI.</div>
<div><br></div>
<div>Steve</div>
</body>
</html>
--============_-1198913471==_ma============--


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g18MLPN22228 for ietf-pkix-bks; Fri, 8 Feb 2002 14:21:25 -0800 (PST)
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 g18MLP322224 for <[e-mail]>; Fri, 8 Feb 2002 14:21:25 -0800 (PST)
Received: from CONVERSION-DAEMON by ext-mail.valicert.com (PMDF V5.2-33 #46613) id <[e-mail]> for [e-mail]; Fri, 8 Feb 2002 14:21:27 -0800 (PST)
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, 08 Feb 2002 14:21:27 -0800 (PST)
Received: by exchange.valicert.com with Internet Mail Service (5.5.2653.19) id <D6WG9NR9>; Fri, 08 Feb 2002 14:21:26 -0800
Content-return: allowed
Date: Fri, 08 Feb 2002 14:21:16 -0800
From: Ambarish Malpani <[e-mail]>
Subject: RE: Candidate for moving OCSP to a Draft Standard
To: "'[e-mail]'" <[e-mail]>, [e-mail]
Cc: [e-mail]
Message-id: <[e-mail]>
MIME-version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-type: text/plain
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>

Hi Peter,
    Here is an earlier response to your issue with OCSP responses
about certificate/account exists etc.

Regards,
Ambarish

In a mail sent to the PKIX list in April 1998, here is what I had
asked:

------------------Begin Included Mail------------------------

Here is a list of the different kinds of status information that an OCSP
responder may want to return:

1. Revocation status of a certificate
    - revoked
    - on hold
    - not revoked
    - don't know about this CA
    - know about this CA, but not about this cert (??? I am not sure I
        think this state should ever be returned, but this corresponds
        to the state where the responder is looking up the CA's database
        and can't find this entry in the database. Mike, I believe you
        think this is an important state - is that correct?)

2. Expiration status of a certificate
    - not yet valid (will be valid in the future)
    - valid (in its validity period)
    - expired
    - don't know about the expiration status

3. Issued status of the certificate
    - never issued (no cert with this serial number was ever issued by
this CA)
    - issued
    - don't know if it was ever issued

My take on this issue: I believe OCSP is just a revocation status
protocol,
so we should restrict the return status to just revoked, onHold,
notRevoked
and dontKnowAboutThisCA. This would leave the syntax of the protocol
simple and the semantics very clear - OCSP basically returns the same
information that you would get if you had a CRL from the CA at the
instant of the response (NOTE: I am NOT implying that a CRL is ever
issued).

However, if the consensus of the group is that it is important that all
three types of states be returned, I would prefer there to be 3
separate state fields, one for each of the different statii. This would
allow us to add more states in the future (e.g. whether this certificate
can be used for a specific kind of operation, or maybe some information
about the CA of this cert) without affecting these basic status fields.

What do the rest of you on the list feel about this issue:
    - Should OCSP support one or more of these statuses?
    - If we support multiple of these states, should we define separate
        fields, or should we merge all states into one field?

Ambarish


-----------------------End Included Mail-----------

The concensus at that time was that the only status needed was whether
the certificate was revoked or not.


---------------------------------------------------------------------
Ambarish Malpani
Architect                                                650.567.5457
ValiCert, Inc.                                  [e-mail]
339 N. Bernardo Ave.                          http://www.valicert.com
Mountain View, CA 94043


> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]]
> Sent: Thursday, February 07, 2002 11:23 PM
> To: [e-mail]; [e-mail]; 
> [e-mail];
> [e-mail]
> Cc: [e-mail]
> Subject: RE: Candidate for moving OCSP to a Draft Standard
> 
> 
> "Khaja E. Ahmed" <[e-mail]> writes:
> 
> >This sounds like a perfectly reasonable solution. Surprised 
> it was rejected.
> >After-all this would be an optional extension, why not add it?  
> 
> The reasoning as I recall was that OCSP shouldn't include 
> facilities which
> aren't bug-compatible with CRLs.  Since CRLs can only provide 
> a negative
> response, and even that only for some cases of invalid certs, 
> OCSP doesn't
> include a straighforward yes/no indication.
> 
> (IMHO any poor guy who's stuck with feeding their online 
> status service from
>  offline CRLs has bigger things to worry about than this...).
> 
> Peter.
> 


Received: by above.proper.com (8.11.6/8.11.3) id g18LqOu21519 for ietf-pkix-bks; Fri, 8 Feb 2002 13:52:24 -0800 (PST)
Received: from tholian.rsasecurity.com (mail.rsasecurity.com [204.167.112.129]) by above.proper.com (8.11.6/8.11.3) with SMTP id g18LqN321515 for <[e-mail]>; Fri, 8 Feb 2002 13:52:23 -0800 (PST)
Received: from sdtihq24.securid.com by tholian.rsasecurity.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 8 Feb 2002 21:51:49 UT
Received: from ebola.securitydynamics.com (ebola.securid.com [192.168.7.4]) by sdtihq24.securid.com (Pro-8.9.3/Pro-8.9.3) with ESMTP id QAA17134 for <[e-mail]>; Fri, 8 Feb 2002 16:52:24 -0500 (EST)
Received: from exna00.securitydynamics.com (localhost [127.0.0.1]) by ebola.securitydynamics.com (8.10.2+Sun/8.9.1) with ESMTP id g18LqGe24351 for <[e-mail]>; Fri, 8 Feb 2002 16:52:17 -0500 (EST)
Received: by exna00.securitydynamics.com with Internet Mail Service (5.5.2653.19) id <DTB6718R>; Fri, 8 Feb 2002 16:52:15 -0500
Received: from HOUSLEY-LAP.rsasecurity.com (HOUSLEY-LAP [10.3.1.3]) by exna00.securitydynamics.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id DTB6718M; Fri, 8 Feb 2002 16:52:13 -0500
From: "Housley, Russ" <[e-mail]>
To: Phil Griffin <[e-mail]>
Cc: [e-mail]
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Fri, 08 Feb 2002 16:50:22 -0500
Subject: Re: I-D ACTION:draft-ietf-pkix-certstore-http-02.txt
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[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>

Hi Phil.

>It seems to me that if you are capable of
>handling a certificate, then handling a sequence
>of certificates is not too much to ask.

On the client side of the HTTP Cert Store, I agree.  However, it is not 
clear that the server side of the HTTP Cert Store needs to do anything with 
the certificate at all.  It is just a blob that needs to be returned to the 
client.

The MIME wrapper is already needed.  We are discussing whether a new MIME 
type should be defined to carry the SEQUENCE OF Certificate or we should 
use the existing MIME type define in RFC 2585 with a multipart.  All of the 
specifications and implementation tools are already in place to do the latter.

Russ


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g18LeGV20981 for ietf-pkix-bks; Fri, 8 Feb 2002 13:40:16 -0800 (PST)
Received: from stingray.missi.ncsc.mil (stingray.missi.ncsc.mil [144.51.50.20]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g18LeF320977 for <[e-mail]>; Fri, 8 Feb 2002 13:40:15 -0800 (PST)
Received: from stingray.missi.ncsc.mil (root@localhost) by stingray.missi.ncsc.mil with ESMTP id g18LcrI15765 for <[e-mail]>; Fri, 8 Feb 2002 16:38:53 -0500 (EST)
Message-ID: <[e-mail]>
Date: Fri, 08 Feb 2002 16:37:21 -0500
From: "David P. Kemp" <[e-mail]>
X-Mailer: Mozilla 4.77 [en] (X11; U; SunOS 5.7 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: [e-mail]
Subject: Re: Candidate for moving OCSP to a Draft Standard
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-H-S-Loop-Check-Ejzfr: 
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>

Peter Gutmann wrote:

> They don't provide a positive response, only a negative one.  If a cert is ever
> rendered invalid for *any* reason other than CA revocation, a CRL can't
> indicate this.  Examples of this include the fact that it hasn't become valid
> yet or has expired and the client doesn't realise because its time is out
> (standard practice in the Windows world, the worst I've seen was a system with
> its clock out by several decades), it wasn't regarded as being issued by the CA
> and therefore can't be revoked (which can occur in CMP, see the postings about
> a neverValid CRL status from a while back), or a number of other situations.

A bank or someone with money at stake on certificate validation can be
assumed to have a clock in sync with the rest of the world - Darwin
ensures
that.  So you don't need OCSP or CRLs at all to tell that a certificate
is outside it's validity period, if the answer matters.

If a remote issuance process requires an acceptance receipt before
considering the certificate valid, then the certificate can certainly be
revoked by the CA if the subscriber doesn't acknowledge receipt.
How can you say "can't be revoked" in the same sentence with the
neverValid revocation reason?


> What could be more sensible than having your OCSP responder process
> queries by consulting the central server directly?  If I'm using
> certs for financial transaction authorisation then it may be elegant
> to introduce a 15-minute delay in order to give the crooks a sporting
> chance, but it's not financially satisfying in the long run :-).

That is my point, that CRLs *are* consulting the central server
directly,
using fewer bytes than with an Oracle replication process, an http or
OCSP
query, or any other general-purpose back-end mechanism you might
suggest.
If you don't like 15 minute delay, then make it a 15 second delay, or
one
second. The CA can certainly generate one delta CRL every second and
transmit (or multicast) it to 5000 OCSP responders using less resources
than it would take to update the same 5000 responders within one second
using some other mechanism.


> Why do CRLs even need to feature in the process, except to highlight their
> deficiencies?  Someone (probably the aforementioned Lynn Wheeler) once said
> that the only reason you'd use an offline mechanism to feed online queries is
> to point out how broken it is.

The fallacy with that reasoning is that CRLs aren't inherently "offline"
any more than a web page is "offline".  Information can be delivered to
a recipient, and cached by that recipient.  If the recipient chooses to
cache web pages or CRLs or OCSP responses, then the recipient is
choosing to be offline. If the recipient never caches, then the
recipient is online.

Source information such as a web cam image, a stock market quote, or a
revocation status is also neither "offline" nor "online", it is only
updated with a certain frequency.  You don't like CAs who update
their CRLs every 24 hours, then suggest that they update them every
15 seconds (to a select group of redistributors, not every end user)
instead.  If I were a CA bidding on a Service Level Agreement to provide
15-second revocation freshness and 1 second response time for 1 million
users, I would bid less to do it using delta CRLs than using Oracle
or Sabre or whatever acceptance system Lynn has in mind.


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g18LLdW20049 for ietf-pkix-bks; Fri, 8 Feb 2002 13:21:39 -0800 (PST)
Received: from smtpproxy2.mitre.org (smtpproxy2.mitre.org [198.76.173.29]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g18LLb320045 for <[e-mail]>; Fri, 8 Feb 2002 13:21:37 -0800 (PST)
Received: from avsrv2.mitre.org (avsrv2.mitre.org [128.29.154.4]) by smtpproxy2.mitre.org (8.11.3/8.11.3) with ESMTP id g18LLd510444 for <[e-mail]>; Fri, 8 Feb 2002 16:21:39 -0500 (EST)
Received: from MAILHUB1 (mailhub1.mitre.org [129.83.20.31]) by smtpsrv2.mitre.org (8.11.3/8.11.3) with ESMTP id g18LLcp21694 for <[e-mail]>; Fri, 8 Feb 2002 16:21:38 -0500 (EST)
Received: from dhcp-162-186.mitre.org (128.29.162.186) by mailhub1.mitre.org with SMTP id 9133506; Fri, 08 Feb 2002 16:21:35 -0500
From: "Bill Price" <[e-mail]>
To: <[e-mail]>
Subject: Certificate's Pointer to its Issuer's Certificate - AIA or IAN
Date: Fri, 8 Feb 2002 16:21:37 -0500
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_006C_01C1B0BC.AEB80400"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
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>

This is a multi-part message in MIME format.

------=_NextPart_000_006C_01C1B0BC.AEB80400
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

PKIX defined the AIA extension which includes a caIssuers type to point to
Issuing CA information. The content of the extension is a general name. The
Issuer Alternative Name (IAN) standard extension which also uses general
names could point to issuer information. Prior to the creation of the AIA
extension, at least one PKI used the URI form of IAN to point to an LDAP
directory entry that contained the issuer's information. The rationale was
to allow retrieval of the issuer's certificate.

I was wondering what was the rationale for not using the IAN when the AIA
caIssuers extension was created. I was also wondering if the PKIX path
discovery work would focus on use of the AIA caIssuers type and disregard
use of the IAN. At least one of the major vendors appears to have ignored
use of the IAN for path creation.

RFC 2459 does not seem to give any guidance on whether or how the IAN and
AIA relate other than what one might conclude from the extension names-IAN
provides an alternate name and AIA provides for information access. It seems
that they would or could have the same content since they both depend on
general names.

Thanks.

Bill Price






------=_NextPart_000_006C_01C1B0BC.AEB80400
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Diso-8859-1">
<META content=3D"MSHTML 6.00.2712.300" name=3DGENERATOR></HEAD>
<BODY>
<DIV><SPAN class=3D667483720-08022002>PKIX defined the AIA extension =
which=20
includes a <SPAN=20
style=3D"FONT-SIZE: 10pt; FONT-FAMILY: 'Courier New'; =
mso-fareast-font-family: 'MS Mincho'; mso-bidi-font-family: 'Times New =
Roman'; mso-ansi-language: EN-US; mso-fareast-language: EN-US; =
mso-bidi-language: AR-SA"><FONT=20
face=3D"Times New Roman" size=3D3>caIssuers type to point to Issuing CA =
information.=20
The content of the extension is a general name. The Issuer Alternative =
Name=20
(IAN) standard extension which also uses general names could point to =
issuer=20
information. Prior to the creation of the AIA extension, at least one =
PKI used=20
the URI form of IAN to point to an LDAP directory entry that contained =
the=20
issuer's information. The rationale was to allow&nbsp;retrieval of the =
issuer's=20
certificate. </FONT></SPAN></SPAN></DIV>
<DIV><SPAN class=3D667483720-08022002><SPAN=20
style=3D"FONT-SIZE: 10pt; FONT-FAMILY: 'Courier New'; =
mso-fareast-font-family: 'MS Mincho'; mso-bidi-font-family: 'Times New =
Roman'; mso-ansi-language: EN-US; mso-fareast-language: EN-US; =
mso-bidi-language: AR-SA"><FONT=20
face=3D"Times New Roman" size=3D3></FONT></SPAN></SPAN><SPAN=20
class=3D667483720-08022002><SPAN=20
style=3D"FONT-SIZE: 10pt; FONT-FAMILY: 'Courier New'; =
mso-fareast-font-family: 'MS Mincho'; mso-bidi-font-family: 'Times New =
Roman'; mso-ansi-language: EN-US; mso-fareast-language: EN-US; =
mso-bidi-language: AR-SA"></SPAN></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D667483720-08022002><SPAN=20
style=3D"FONT-SIZE: 10pt; FONT-FAMILY: 'Courier New'; =
mso-fareast-font-family: 'MS Mincho'; mso-bidi-font-family: 'Times New =
Roman'; mso-ansi-language: EN-US; mso-fareast-language: EN-US; =
mso-bidi-language: AR-SA"><FONT=20
face=3D"Times New Roman" size=3D3>I was wondering what =
was&nbsp;the&nbsp;rationale=20
for not using the IAN when the AIA caIssuers extension was created. I =
was also=20
wondering if the PKIX path discovery work would focus on use of the AIA=20
caIssuers type and disregard use of the IAN. At least one of the major =
vendors=20
appears to have ignored use of the IAN for path=20
creation.</FONT></SPAN></SPAN></DIV>
<DIV><SPAN class=3D667483720-08022002><SPAN=20
style=3D"FONT-SIZE: 10pt; FONT-FAMILY: 'Courier New'; =
mso-fareast-font-family: 'MS Mincho'; mso-bidi-font-family: 'Times New =
Roman'; mso-ansi-language: EN-US; mso-fareast-language: EN-US; =
mso-bidi-language: AR-SA"><FONT=20
face=3D"Times New Roman" size=3D3></FONT></SPAN></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D667483720-08022002><SPAN=20
style=3D"FONT-SIZE: 10pt; FONT-FAMILY: 'Courier New'; =
mso-fareast-font-family: 'MS Mincho'; mso-bidi-font-family: 'Times New =
Roman'; mso-ansi-language: EN-US; mso-fareast-language: EN-US; =
mso-bidi-language: AR-SA"><FONT=20
face=3DArial>RFC 2459 does not seem to give any guidance on whether or =
how the IAN=20
and AIA relate other than what one might conclude from the extension =
names-IAN=20
provides an alternate name and AIA provides for information access. It =
seems=20
that they would or could have the same content since they both depend on =
general=20
names.</FONT></SPAN></SPAN></DIV>
<DIV><SPAN class=3D667483720-08022002><SPAN=20
style=3D"FONT-SIZE: 10pt; FONT-FAMILY: 'Courier New'; =
mso-fareast-font-family: 'MS Mincho'; mso-bidi-font-family: 'Times New =
Roman'; mso-ansi-language: EN-US; mso-fareast-language: EN-US; =
mso-bidi-language: AR-SA"><FONT=20
face=3DArial></FONT></SPAN></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D667483720-08022002><SPAN=20
style=3D"FONT-SIZE: 10pt; FONT-FAMILY: 'Courier New'; =
mso-fareast-font-family: 'MS Mincho'; mso-bidi-font-family: 'Times New =
Roman'; mso-ansi-language: EN-US; mso-fareast-language: EN-US; =
mso-bidi-language: AR-SA"><FONT=20
face=3DArial>Thanks.</FONT></SPAN></SPAN></DIV>
<DIV><SPAN class=3D667483720-08022002><SPAN=20
style=3D"FONT-SIZE: 10pt; FONT-FAMILY: 'Courier New'; =
mso-fareast-font-family: 'MS Mincho'; mso-bidi-font-family: 'Times New =
Roman'; mso-ansi-language: EN-US; mso-fareast-language: EN-US; =
mso-bidi-language: AR-SA"><FONT=20
face=3D"Times New Roman" size=3D3></FONT></SPAN></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D667483720-08022002><SPAN=20
style=3D"FONT-SIZE: 10pt; FONT-FAMILY: 'Courier New'; =
mso-fareast-font-family: 'MS Mincho'; mso-bidi-font-family: 'Times New =
Roman'; mso-ansi-language: EN-US; mso-fareast-language: EN-US; =
mso-bidi-language: AR-SA"><FONT=20
face=3DArial>Bill Price</FONT></SPAN></SPAN></DIV>
<DIV><SPAN class=3D667483720-08022002><SPAN=20
style=3D"FONT-SIZE: 10pt; FONT-FAMILY: 'Courier New'; =
mso-fareast-font-family: 'MS Mincho'; mso-bidi-font-family: 'Times New =
Roman'; mso-ansi-language: EN-US; mso-fareast-language: EN-US; =
mso-bidi-language: AR-SA"></SPAN></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D667483720-08022002><FONT face=3DArial size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt; FONT-FAMILY: 'Courier New'; =
mso-fareast-font-family: 'MS Mincho'; mso-bidi-font-family: 'Times New =
Roman'; mso-ansi-language: EN-US; mso-fareast-language: EN-US; =
mso-bidi-language: AR-SA"></SPAN></FONT></SPAN>&nbsp;</DIV>
<P><FONT face=3DArial size=3D2></FONT> </P>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV></BODY></HTML>

------=_NextPart_000_006C_01C1B0BC.AEB80400--




Received: by above.proper.com (8.11.6/8.11.3) id g18KrJw19122 for ietf-pkix-bks; Fri, 8 Feb 2002 12:53:19 -0800 (PST)
Received: from mailf.telia.com (mailf.telia.com [194.22.194.25]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g18KrH319117 for <[e-mail]>; Fri, 8 Feb 2002 12:53:18 -0800 (PST)
Received: from arport (t1o69p102.telia.com [62.20.144.102]) by mailf.telia.com (8.11.6/8.11.6) with SMTP id g18KrJT04957 for <[e-mail]>; Fri, 8 Feb 2002 21:53:19 +0100 (CET)
Message-ID: <00a501c1b0e2$82a08560$0500a8c0@arport>
From: "Anders Rundgren" <[e-mail]>
To: <[e-mail]>
Subject: X509.v3 Namespace Extension
Date: Fri, 8 Feb 2002 21:52:23 +0100
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.50.4133.2400
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
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,
A problem in the X509 world is to create a reasonably robust naming scheme
that allows RP software to *safely* distinguish certificates from different CAs,
using subject attributes based on DN, SubjectAltName, private extensions etc.
Essentially the DN has become useless for separating subjects certified by
different CAs as there is no convention for naming subjects that has any major
acceptance.

There is also a problem with separating different subject types using the same
CA cert+key.

Therefore I propose two non-critical extensions to cope with this.

Both are based on using a URI [RFC2396] as a name-space indicator.
As this has been found to be enough to globally separate the truly giant
amount of different XML Schemas currently in preparation, it should
definitely be satisfactory for X509.v3 certificates.

In addition to separating name-spaces, the extension also allows
CAs to use an http URL (a URI) to point to a document/directory
describing the name-space and the associated subject.

The proposed extensions essentially make an X509.v3 certificate
having three dimensions:
- An issuer/trust dimension
- A subject/entity dimension
- A name-space/entity-type dimension

The last dimension is actually already heavily exploited, based on
conventions (usually hard-coding knowledge about the CA and its
issuance), but would with the proposed extensions, become explicit.

If name-spaces are shared between CAs, the CAs SHOULD follow
the same procedures, and subject formats, so that EE-certificates
can be compared at subject level with no false matches.

One version of the extension is CA-cert-based and vouches
for the *next* level of certificates belonging to a set of defined
name-spaces. 

Another version of the extension would vouch for the certificate
itself, telling what name-space the certificate belongs to.  If the
certificates' CA, has a CA-based name-space extension, one of
the CA-declared name-spaces MUST match that of the certificate.
This extension MUST be specified, if the CA-cert has a CA-level
name-space extension, with more than one declared name-space.

Any thoughts on this?

Anders Rundgren




Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g18K8vr17874 for ietf-pkix-bks; Fri, 8 Feb 2002 12:08:57 -0800 (PST)
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 g18K8u317869 for <[e-mail]>; Fri, 8 Feb 2002 12:08:56 -0800 (PST)
Received: from CONVERSION-DAEMON by ext-mail.valicert.com (PMDF V5.2-33 #46613) id <[e-mail]> for [e-mail]; Fri, 8 Feb 2002 12:08:57 -0800 (PST)
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, 08 Feb 2002 12:08:57 -0800 (PST)
Received: by exchange.valicert.com with Internet Mail Service (5.5.2653.19) id <D6WG9MT9>; Fri, 08 Feb 2002 12:08:56 -0800
Content-return: allowed
Date: Fri, 08 Feb 2002 12:08:46 -0800
From: Ambarish Malpani <[e-mail]>
Subject: RE: Candidate for moving OCSP to a Draft Standard
To: "'[e-mail]'" <[e-mail]>, [e-mail], [e-mail]
Message-id: <[e-mail]>
MIME-version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-type: text/plain
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>

Hi Peter,
     I was hoping to stay out of this discussion, but I suppose I
need to get back in.

About responders working off CRLs:

In a lot of cases, people have set up our VA (Validation Authority/
OCSP Responder), to run next to a CA, operated by the CA operator.

They have set up the system, so that as soon as there is a new
revocation event, a new CRL is produced, with is immediately
shipped to the VA. The VA now provides revocation information
based on this new CRL.

As I have stated many time before - the problem with CRLs is not
that it takes long to produce them - the problem is with
getting client applications new CRLs as soon as they are
produced. Because of their size, most client applications cache
old CRLs and CAs like this behavior because otherwise their
directory will get overloaded.

With the combination I talked about above, a CA can produce new
CRLs as soon as there is new information, pass that on to the VA
and get the new information to all OCSP clients as they need it.

Hope this helps,
Regards,
Ambarish




---------------------------------------------------------------------
Ambarish Malpani
Architect                                                650.567.5457
ValiCert, Inc.                                  [e-mail]
339 N. Bernardo Ave.                          http://www.valicert.com
Mountain View, CA 94043


> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]]
> Sent: Friday, February 08, 2002 10:42 AM
> To: [e-mail]; [e-mail]
> Subject: Re: Candidate for moving OCSP to a Draft Standard
> 
> 
> 
> "David P. Kemp" <[e-mail]> writes:
> 
> >>The reasoning as I recall was that OCSP shouldn't include 
> facilities which
> >>aren't bug-compatible with CRLs.  Since CRLs can only 
> provide a negative
> >>response, and even that only for some cases of invalid 
> certs, OCSP doesn't
> >>include a straighforward yes/no indication.
> >
> >Say what?  CRLs provide positive and negative responses, and 
> the positive
> >response is optimized down to 0 bytes.
> 
> They don't provide a positive response, only a negative one.  
> If a cert is ever
> rendered invalid for *any* reason other than CA revocation, a 
> CRL can't
> indicate this.  Examples of this include the fact that it 
> hasn't become valid
> yet or has expired and the client doesn't realise because its 
> time is out
> (standard practice in the Windows world, the worst I've seen 
> was a system with
> its clock out by several decades), it wasn't regarded as 
> being issued by the CA
> and therefore can't be revoked (which can occur in CMP, see 
> the postings about
> a neverValid CRL status from a while back), or a number of 
> other situations.
> 
> The problem with CRLs is that they ask entirely the wrong 
> question - "Has this
> been revoked?" - when what's really of interest is an answer 
> to the question
> "Is this currently valid?".  This can't really be fixed, 
> because that's the
> only question a blacklist is capable of answering.
> 
> >The reason OCSP can't say that a cert is valid has nothing 
> to do with CRLs.
> >It's crippled by the fact that the request does not include 
> a cert, so the
> >responder can't validate the signature unless it fetches the 
> cert itself.
> >Presumably the OCSP authors made a conscious decision not to 
> require the
> >responder to validate certification paths before providing a 
> response.
> 
> It doesn't need to validate anything.  That's why my text 
> summary went to such
> pains to point out that it was strictly an "account in good 
> standing" query.
> The CA acknowledges that it issued the cert, and that it's 
> currently in good
> standing.  That's all.  There's no validation, path checking, 
> or anything else.
> 
> >>(IMHO any poor guy who's stuck with feeding their online 
> status service from
> >  offline CRLs has bigger things to worry about than this...).
> >
> >Speaking as one such poor guy :-), what's the problem?
> 
> The fact that you're feeding a real-time status process from 
> a source updated
> hourly or daily or whatever (I've seen CAs which issue CRLs 
> in half-day or
> full-day intervals, or which guarantee a CRL age of not more 
> than 24 hours, 8
> hours average-case).
> 
> >What could be more elegant than having your LAN-based OCSP 
> server replicate
> >the PKI revocation database by fetching delta CRLs from the 
> central server
> >every 15 minutes?
> 
> What could be more sensible than having your OCSP responder 
> process queries by
> consulting the central server directly?  If I'm using certs 
> for financial
> transaction authorisation then it may be elegant to introduce 
> a 15-minute delay
> in order to give the crooks a sporting chance, but it's not 
> financially
> satisfying in the long run :-).
> 
> Why do CRLs even need to feature in the process, except to 
> highlight their
> deficiencies?  Someone (probably the aforementioned Lynn 
> Wheeler) once said
> that the only reason you'd use an offline mechanism to feed 
> online queries is
> to point out how broken it is.
> 
> Peter.
> 


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g18J6PC16426 for ietf-pkix-bks; Fri, 8 Feb 2002 11:06:25 -0800 (PST)
Received: from finch-post-11.mail.demon.net (finch-post-11.mail.demon.net [194.217.242.39]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g18J6O316421 for <[e-mail]>; Fri, 8 Feb 2002 11:06:24 -0800 (PST)
Received: from drh-consultancy.demon.co.uk ([193.237.150.98] helo=gemplus.com) by finch-post-11.mail.demon.net with esmtp (Exim 3.34 #1) id 16ZGLh-00073p-0B for [e-mail]; Fri, 08 Feb 2002 19:06:17 +0000
Message-ID: <[e-mail]>
Date: Fri, 08 Feb 2002 19:08:15 +0000
From: Dr S N Henson <[e-mail]>
X-Mailer: Mozilla 4.79 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: [e-mail]
Subject: Re: I-D ACTION:draft-ietf-pkix-certstore-http-02.txt
References: <[e-mail]> <[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>

Andreas Sterbenz wrote:
> 
> 
> And as pointed out by Dr. Henson, a CMS certlist can be generated
> without an ASN.1 encoder if indefinite length encoding is used.
> 

Needless to say SEQUENCE OF can be handled similarly. Its encoding is:

30 80 <SEQUENCE tag, indefinite length>
	<concatenation of all certificates>
00 00 <EOC>

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


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g18Ig2915768 for ietf-pkix-bks; Fri, 8 Feb 2002 10:42:02 -0800 (PST)
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 g18Ifx315761 for <[e-mail]>; Fri, 8 Feb 2002 10:42:00 -0800 (PST)
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 HAA09859; Sat, 9 Feb 2002 07:41:56 +1300 (NZDT) (sender [e-mail])
Received: (from pgut001@localhost) by ruru.cs.auckland.ac.nz (8.9.3/8.8.6/cs-slave) id HAA141803; Sat, 9 Feb 2002 07:41:55 +1300 (NZDT) (sender [e-mail])
Date: Sat, 9 Feb 2002 07:41:55 +1300 (NZDT)
Message-ID: <[e-mail]>
From: [e-mail] (Peter Gutmann)
To: [e-mail], [e-mail]
Subject: Re: Candidate for moving OCSP to a Draft Standard
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>

"David P. Kemp" <[e-mail]> writes:

>>The reasoning as I recall was that OCSP shouldn't include facilities which
>>aren't bug-compatible with CRLs.  Since CRLs can only provide a negative
>>response, and even that only for some cases of invalid certs, OCSP doesn't
>>include a straighforward yes/no indication.
>
>Say what?  CRLs provide positive and negative responses, and the positive
>response is optimized down to 0 bytes.

They don't provide a positive response, only a negative one.  If a cert is ever
rendered invalid for *any* reason other than CA revocation, a CRL can't
indicate this.  Examples of this include the fact that it hasn't become valid
yet or has expired and the client doesn't realise because its time is out
(standard practice in the Windows world, the worst I've seen was a system with
its clock out by several decades), it wasn't regarded as being issued by the CA
and therefore can't be revoked (which can occur in CMP, see the postings about
a neverValid CRL status from a while back), or a number of other situations.

The problem with CRLs is that they ask entirely the wrong question - "Has this
been revoked?" - when what's really of interest is an answer to the question
"Is this currently valid?".  This can't really be fixed, because that's the
only question a blacklist is capable of answering.

>The reason OCSP can't say that a cert is valid has nothing to do with CRLs.
>It's crippled by the fact that the request does not include a cert, so the
>responder can't validate the signature unless it fetches the cert itself.
>Presumably the OCSP authors made a conscious decision not to require the
>responder to validate certification paths before providing a response.

It doesn't need to validate anything.  That's why my text summary went to such
pains to point out that it was strictly an "account in good standing" query.
The CA acknowledges that it issued the cert, and that it's currently in good
standing.  That's all.  There's no validation, path checking, or anything else.

>>(IMHO any poor guy who's stuck with feeding their online status service from
>  offline CRLs has bigger things to worry about than this...).
>
>Speaking as one such poor guy :-), what's the problem?

The fact that you're feeding a real-time status process from a source updated
hourly or daily or whatever (I've seen CAs which issue CRLs in half-day or
full-day intervals, or which guarantee a CRL age of not more than 24 hours, 8
hours average-case).

>What could be more elegant than having your LAN-based OCSP server replicate
>the PKI revocation database by fetching delta CRLs from the central server
>every 15 minutes?

What could be more sensible than having your OCSP responder process queries by
consulting the central server directly?  If I'm using certs for financial
transaction authorisation then it may be elegant to introduce a 15-minute delay
in order to give the crooks a sporting chance, but it's not financially
satisfying in the long run :-).

Why do CRLs even need to feature in the process, except to highlight their
deficiencies?  Someone (probably the aforementioned Lynn Wheeler) once said
that the only reason you'd use an offline mechanism to feed online queries is
to point out how broken it is.

Peter.


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g18I6rP14701 for ietf-pkix-bks; Fri, 8 Feb 2002 10:06:53 -0800 (PST)
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 g18I6p314697 for <[e-mail]>; Fri, 8 Feb 2002 10:06:51 -0800 (PST)
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 HAA09857; Sat, 9 Feb 2002 07:06:33 +1300 (NZDT) (sender [e-mail])
Received: (from pgut001@localhost) by ruru.cs.auckland.ac.nz (8.9.3/8.8.6/cs-slave) id HAA141040; Sat, 9 Feb 2002 07:06:33 +1300 (NZDT) (sender [e-mail])
Date: Sat, 9 Feb 2002 07:06:33 +1300 (NZDT)
Message-ID: <[e-mail]>
From: [e-mail] (Peter Gutmann)
To: [e-mail], [e-mail]
Subject: RE: Candidate for moving OCSP to a Draft Standard
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>

"Housley, Russ" <[e-mail]> writes:

>If the extension is specified in an IETF document, then I will gladly issue an
>OID from the PKIX arc.  Otherwise, it is a private extension, and it should
>not be issued an OID from the PKIX arc.

It's not specified anywhere, I'm just nervous about using private OIDs because
(historically) they've proven awkward for implementors to deal with because no-
one knows where they're defined.  This particular one's a bit of a grey area,
it's not specified in an RFC, but since others are going to use it it's not
really private either.  I'm not really fussed about it, it just seemed a bit
cleaner to have a well-known OID.

Peter.


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g18HkVP14249 for ietf-pkix-bks; Fri, 8 Feb 2002 09:46:31 -0800 (PST)
Received: from stingray.missi.ncsc.mil (stingray.missi.ncsc.mil [144.51.50.20]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g18HkU314245 for <[e-mail]>; Fri, 8 Feb 2002 09:46:31 -0800 (PST)
Received: from stingray.missi.ncsc.mil (root@localhost) by stingray.missi.ncsc.mil with ESMTP id g18Hj8d04655; Fri, 8 Feb 2002 12:45:08 -0500 (EST)
Message-ID: <[e-mail]>
Date: Fri, 08 Feb 2002 12:43:45 -0500
From: "David P. Kemp" <[e-mail]>
X-Mailer: Mozilla 4.77 [en] (X11; U; SunOS 5.7 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: Peter Sylvester <[e-mail]>
CC: [e-mail], [e-mail], [e-mail]
Subject: Re: I-D ACTION:draft-ietf-pkix-certstore-http-02.txt
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-H-S-Loop-Check-Ejzfr: 
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>

Peter Sylvester wrote:
> 
> > Andreas Sterbenz <[e-mail]> writes:
> >
> > Most respondents were in favour of multipart, because they didn't want to build
> > an ASN.1 encoder into their database.
> 
> It seems to me that implementing an encoder for a sequence like
> 
> 30 80 cert1 cert2 ... 00 00
> 
> isn't really a big task,
> and even surrounding this with some fixed magic octets
> representing a p7c message, thus allowing to reuse an
> already existing content-type.
> 
> Or, I seem to share Andreas' disagreement.


If we are taking a straw poll, I agree with Peter, Andreas,
and Phil Griffin.  Multipart is excessive overhead and complexity;
four fixed octets is trivial.


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g18HPZl13709 for ietf-pkix-bks; Fri, 8 Feb 2002 09:25:35 -0800 (PST)
Received: from stingray.missi.ncsc.mil (stingray.missi.ncsc.mil [144.51.50.20]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g18HPY313704 for <[e-mail]>; Fri, 8 Feb 2002 09:25:34 -0800 (PST)
Received: from stingray.missi.ncsc.mil (root@localhost) by stingray.missi.ncsc.mil with ESMTP id g18HOCU03734 for <[e-mail]>; Fri, 8 Feb 2002 12:24:12 -0500 (EST)
Message-ID: <[e-mail]>
Date: Fri, 08 Feb 2002 12:22:48 -0500
From: "David P. Kemp" <[e-mail]>
X-Mailer: Mozilla 4.77 [en] (X11; U; SunOS 5.7 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: [e-mail]
Subject: Re: Candidate for moving OCSP to a Draft Standard
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-H-S-Loop-Check-Ejzfr: 
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>

Peter Gutmann wrote:
> 
> "Khaja E. Ahmed" <[e-mail]> writes:
> 
> >This sounds like a perfectly reasonable solution. Surprised it was rejected.
> >After-all this would be an optional extension, why not add it?
> 
> The reasoning as I recall was that OCSP shouldn't include facilities which
> aren't bug-compatible with CRLs.  Since CRLs can only provide a negative
> response, and even that only for some cases of invalid certs, OCSP doesn't
> include a straighforward yes/no indication.

Say what?  CRLs provide positive and negative responses, and the
positive
response is optimized down to 0 bytes.  If you want to know whether a
certificate was issued, the signature on the cert tells you that, and if
it doesn't you've got bigger problems than just revocation status.

The reason OCSP can't say that a cert is valid has nothing to do with
CRLs.
It's crippled by the fact that the request does not include a cert, so
the
responder can't validate the signature unless it fetches the cert
itself.
Presumably the OCSP authors made a conscious decision not to require the
responder to validate certification paths before providing a response.


> (IMHO any poor guy who's stuck with feeding their online status service from
>  offline CRLs has bigger things to worry about than this...).

Speaking as one such poor guy :-), what's the problem?   I have a user
community of 4.5 million people, and having each of them bang against
a central OCSP server every time they do something PKI-related on their
LAN is going to incur their wrath.  Server delays and Internet
congestion shouldn't be designed into local applications, causing
things that should have happened instantaneously to take 5 seconds,
or more when their pipe to the Internet is loaded.

I've learned to ignore Lynn Wheeler when he refers to CRLs as 
'60's-era blacklists (and I can remember when supermarket clerks thumbed
through those little books).  But I expect you'd have a little more
appreciation for simplicity.  What could be more elegant than having
your
LAN-based OCSP server replicate the PKI revocation database by fetching
delta CRLs from the central server every 15 minutes?


Received: by above.proper.com (8.11.6/8.11.3) id g18HK9Z13588 for ietf-pkix-bks; Fri, 8 Feb 2002 09:20:09 -0800 (PST)
Received: from tholian.rsasecurity.com (mail.rsasecurity.com [204.167.112.129]) by above.proper.com (8.11.6/8.11.3) with SMTP id g18HK7313583 for <[e-mail]>; Fri, 8 Feb 2002 09:20:07 -0800 (PST)
Received: from sdtihq24.securitydynamics.com by tholian.rsasecurity.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 8 Feb 2002 17:19:33 UT
Received: from ebola.securitydynamics.com (ebola.securid.com [192.168.7.4]) by sdtihq24.securid.com (Pro-8.9.3/Pro-8.9.3) with ESMTP id MAA01257; Fri, 8 Feb 2002 12:20:08 -0500 (EST)
Received: from exna00.securitydynamics.com (localhost [127.0.0.1]) by ebola.securitydynamics.com (8.10.2+Sun/8.9.1) with ESMTP id g18HK6306825; Fri, 8 Feb 2002 12:20:06 -0500 (EST)
Received: by exna00.securitydynamics.com with Internet Mail Service (5.5.2653.19) id <DTB67CGY>; Fri, 8 Feb 2002 12:20:05 -0500
Received: from HOUSLEY-LAP.rsasecurity.com (HOUSLEY-LAP [10.3.1.116]) by exna00.securitydynamics.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id DTB67CGS; Fri, 8 Feb 2002 12:19:54 -0500
From: "Housley, Russ" <[e-mail]>
To: [e-mail]
Cc: [e-mail], [e-mail]
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Fri, 08 Feb 2002 12:09:07 -0500
Subject: RE: Candidate for moving OCSP to a Draft Standard
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>

Peter:

If the extension is specified in an IETF document, then I will gladly issue 
an OID from the PKIX arc.  Otherwise, it is a private extension, and it 
should not be issued an OID from the PKIX arc.

Russ

  At 08:17 PM 2/8/2002 +1300, Peter Gutmann wrote:

>"Florian Oelmaier" <[e-mail]> writes:
>
> >Advantage of OCSP: extensible.
> >
> >Idea: Use advantages heavily.
> >
> >Conclusion: Interested in Peter Gutmanns extension.
> >
> >:) So Peter, plz post the extension and the derscription. Best to the list -
> >then it is somewhat half-official and a lot of other people in the community
> >can use it, too.
>
>Here it is, slightly more formalised than the original source code comment:
>
>-- Snip --
>
>CertificateOK
>
>The CertOK extension sidesteps the limitations of the CRL-based semantics of
>the standard OCSP response and provides a straightforward indication of 
>whether
>a certificate is OK or not.  "OK" in this sense is the equivalent of the
>banking assertion that an account is in good standing, namely that the
>identified certificate was issued and is currently valid.  Further information
>on why a certificate may not be OK can be found in the standard OCSP response.
>
>   id-certOK OBJECT IDENTIFIER ::= { 1 3 6 1 4 1 3029 3 1 2 }
>
>   CertOK ::= BOOLEAN
>
>   [I'll take a PKIX OID in place of the current private one if it's 
> considered
>    worth issuing it]
>
>Rationale
>
>The CertOK response is purely an indication that the account is in good
>standing.  In other words, it provides the information that the OCSP responder
>is likely to possess, but is prevented by the standard OCSP status values from
>providing to the user.  It does not provide, and is not intended to provide, a
>DVCS/DPV/DPD/etc-style checking mechanism (for example, again using banking
>terms, an indication that the account contains enough to cover a given
>transaction, or that the account owner can be trusted to do business with).
>These extended forms of checking are covered in separate standards.
>
>-- Snip --
>
>Peter.


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g18GqVE12919 for ietf-pkix-bks; Fri, 8 Feb 2002 08:52:31 -0800 (PST)
Received: from edelweb.fr (edelweb.fr [212.234.46.16]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g18GqS312915 for <[e-mail]>; Fri, 8 Feb 2002 08:52:29 -0800 (PST)
Received: from champagne.edelweb.fr (localhost.edelweb.fr [127.0.0.1]) by edelweb.fr with ESMTP id RAA27434; Fri, 8 Feb 2002 17:52:20 +0100 (MET)
Received: from champagne.edelweb.fr (champagne.edelweb.fr [193.51.14.161]) by edelweb.fr (nospam/1.3); Fri, 8 Feb 2002 17:52:21 +0100 (MET)
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 RAA25378; Fri, 8 Feb 2002 17:52:19 +0100 (MET)
From: Peter Sylvester <[e-mail]>
Received: (sylvest@localhost) by emeriau.edelweb.fr (8.7.6/8.6.6) id RAA12980; Fri, 8 Feb 2002 17:52:19 +0100 (MET)
Date: Fri, 8 Feb 2002 17:52:19 +0100 (MET)
Message-Id: <[e-mail]>
To: [e-mail], [e-mail]
Subject: Re: I-D ACTION:draft-ietf-pkix-certstore-http-02.txt
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>

> Andreas Sterbenz <[e-mail]> writes:
> 
> Most respondents were in favour of multipart, because they didn't want to build
> an ASN.1 encoder into their database.

It seems to me that implementing an encoder for a sequence like

30 80 cert1 cert2 ... 00 00

isn't really a big task, 
and even surrounding this with some fixed magic octets
representing a p7c message, thus allowing to reuse an 
already existing content-type.

Or, I seem to share Andreas' disagreement.




Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g18GiNl12755 for ietf-pkix-bks; Fri, 8 Feb 2002 08:44:23 -0800 (PST)
Received: from barry.mail.mindspring.net (barry.mail.mindspring.net [207.69.200.25]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g18GiM312750 for <[e-mail]>; Fri, 8 Feb 2002 08:44:22 -0800 (PST)
Received: from user-2ivf0sl.dialup.mindspring.com ([165.247.131.149] helo=ASN-1.com) by barry.mail.mindspring.net with esmtp (Exim 3.33 #1) id 16ZE8K-0003vt-00 for [e-mail]; Fri, 08 Feb 2002 11:44:20 -0500
Message-ID: <[e-mail]>
Date: Fri, 08 Feb 2002 11:40:11 -0500
From: Phil Griffin <[e-mail]>
Organization: Griffin Consulting - http://ASN-1.com
X-Mailer: Mozilla 4.73 [en]C-{C-UDP; EBM-SONY1}  (Win95; U)
X-Accept-Language: en
MIME-Version: 1.0
To: [e-mail]
Subject: Re: I-D ACTION:draft-ietf-pkix-certstore-http-02.txt
References: <[e-mail]> <[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>

Andreas Sterbenz wrote:
> 
>  > 2. HTTP Certificate Store Interface
> 
>  > If more than one certificate matches a query, it MUST be returned as a
>  > multipart/mixed response.
> 
>  > 2.4 Rationale
> 
>  > Multiple response are returned as multipart/mixed rather than an ASN.1
>  > SEQUENCE OF Certificate or PKCS #7/CMS certificate chain because this
>  > is more straightforward to implement with standard web-enabled tools.
>  > An additional advantage is that it doesn't restrict this access
>  > mechanism to DER-based data, allowing it to be extended to other
>  > certificate types such as XML, PGP, and SPKI.
> 
> I continue to disagree with the decision to use multipart MIME for the
> reasons previously stated by me and others.
> 
> The XML/PGP argument does not seem to carry much weight either, because
> the spec is only targeted at X.509. It also seems questionable that MIME
> would be a suitable choice for XML/PGP any more than it is for X.509.
> 
> [I speak for myself, not for Sun]
> 
> Andreas.

Agree. It seems to me that if you are capable of
handling a certificate, then handling a sequence
of certificates is not too much to ask. Common
industry practice. Reasonably expected capability.

And a bag of certificates is no more difficult for
an application not ASN.1-aware to hand off than a 
single certificate. It's a blob after all.

As to XML markup, that's just another ASN.1
encoding format too now. From the Study Group
17 Secretariat to the public asn1 list at ITU-T:

   "X.680, X.681, X.682, X.683, X.690, X.691 are being
   revised by Question 12 of ITU-T Study Group 17. As
   part of the ITU-T ASN.1 Project, an FTP server was
   set up with the aim of increasing interaction with
   all parties interested in the development of ASN.1
   related standards.

   I am pleased to inform you that the draft revision
   of the set of above mentioned Recommendations has
   been made available on an FTP server for a limited
   period of time (pdf format), and you are invited to
   review these texts to provide any comments that 
   could help to improve the most valuable base texts
   for your future reference.

   In addition, the draft of a new ASN.1-series 
   Recommendation, X.692, on Encoding Control Notation
   (ECN) is also made available on the FTP server. 
 
   Please note that the next scheduled meeting to discuss
   this issue is 27 February - 8 March 2002 (Geneva). If
   you wish to comment, could you please do so prior to
   15 February 2002 by using this e-mail mailing list 
   ([e-mail]) or by direct contact with the Rapporteur
   concerned ([e-mail]). 

   Many thanks in advance for your interest,

   NOTE: 
   asn1 FTP HOST NAME: ties.itu.int, 
   ID asn1, 
   PWD notation1"
   

Phil Griffin


Received: by above.proper.com (8.11.6/8.11.3) id g18FtbZ11429 for ietf-pkix-bks; Fri, 8 Feb 2002 07:55:37 -0800 (PST)
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 g18Fta311425 for <[e-mail]>; Fri, 8 Feb 2002 07:55:36 -0800 (PST)
Received: from ireserver.Ireland.Sun.COM ([129.156.220.7]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id HAA23171; Fri, 8 Feb 2002 07:55:36 -0800 (PST)
Received: from sun.com (dhcp-edub03-21 [129.156.220.138]) by ireserver.Ireland.Sun.COM (8.8.8+Sun/8.8.8/ENSMAIL,v2.2) with ESMTP id PAA10300; Fri, 8 Feb 2002 15:55:36 GMT
Message-ID: <[e-mail]>
Date: Fri, 08 Feb 2002 15:55:35 +0000
From: Andreas Sterbenz <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.8) Gecko/20020204
X-Accept-Language: en-us
MIME-Version: 1.0
To: Peter Gutmann <[e-mail]>
CC: [e-mail]
Subject: Re: I-D ACTION:draft-ietf-pkix-certstore-http-02.txt
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii; format=flowed
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>

Peter Gutmann wrote:
> 
>>I continue to disagree with the decision to use multipart MIME for the reasons
>>previously stated by me and others.
> 
> Most respondents were in favour of multipart, because they didn't want to build
> an ASN.1 encoder into their database.

I may be wrong, but here's my count:

multipart: 3 (Peter Gutmann, Russ Housley, Michael Stroeder)
PKCS#7 or SEQUENCE: 3 (Andreas Sterbenz, Peter Sylvester, Eric Murray)

And as pointed out by Dr. Henson, a CMS certlist can be generated 
without an ASN.1 encoder if indefinite length encoding is used.

I don't want to discuss this more than necessary, but I believe another 
look is warranted.

Andreas.



Received: by above.proper.com (8.11.6/8.11.3) id g18FVe910931 for ietf-pkix-bks; Fri, 8 Feb 2002 07:31:40 -0800 (PST)
Received: from edelweb.fr (edelweb.fr [212.234.46.16]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g18FVc310927 for <[e-mail]>; Fri, 8 Feb 2002 07:31:38 -0800 (PST)
Received: from champagne.edelweb.fr (localhost.edelweb.fr [127.0.0.1]) by edelweb.fr with ESMTP id QAA26944 for <[e-mail]>; Fri, 8 Feb 2002 16:31:34 +0100 (MET)
Received: from champagne.edelweb.fr (champagne.edelweb.fr [193.51.14.161]) by edelweb.fr (nospam/1.3); Fri, 8 Feb 2002 16:31:34 +0100 (MET)
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 QAA24886 for <[e-mail]>; Fri, 8 Feb 2002 16:31:33 +0100 (MET)
From: Peter Sylvester <[e-mail]>
Received: (sylvest@localhost) by emeriau.edelweb.fr (8.7.6/8.6.6) id QAA12962 for [e-mail]; Fri, 8 Feb 2002 16:31:32 +0100 (MET)
Date: Fri, 8 Feb 2002 16:31:32 +0100 (MET)
Message-Id: <[e-mail]>
To: [e-mail]
Subject: Re: RFC 3161 (TSP): update for the criticality flag
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>

> 
> It will be replaced by:
> 
You probably mean: 

  "I propose to replace it by:"


Received: by above.proper.com (8.11.6/8.11.3) id g18FJd010340 for ietf-pkix-bks; Fri, 8 Feb 2002 07:19:39 -0800 (PST)
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 g18FJY310321 for <[e-mail]>; Fri, 8 Feb 2002 07:19:35 -0800 (PST)
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 EAA06777; Sat, 9 Feb 2002 04:19:30 +1300 (NZDT) (sender [e-mail])
Received: (from pgut001@localhost) by ruru.cs.auckland.ac.nz (8.9.3/8.8.6/cs-slave) id EAA138430; Sat, 9 Feb 2002 04:19:30 +1300 (NZDT) (sender [e-mail])
Date: Sat, 9 Feb 2002 04:19:30 +1300 (NZDT)
Message-ID: <[e-mail]>
From: [e-mail] (Peter Gutmann)
To: [e-mail], [e-mail]
Subject: Re: I-D ACTION:draft-ietf-pkix-certstore-http-02.txt
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>

Andreas Sterbenz <[e-mail]> writes:

>I continue to disagree with the decision to use multipart MIME for the reasons
>previously stated by me and others.

Most respondents were in favour of multipart, because they didn't want to build
an ASN.1 encoder into their database.

Peter.


Received: by above.proper.com (8.11.6/8.11.3) id g18ExBW08399 for ietf-pkix-bks; Fri, 8 Feb 2002 06:59:11 -0800 (PST)
Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g18ExA308395 for <[e-mail]>; Fri, 8 Feb 2002 06:59:10 -0800 (PST)
Received: from ireserver.Ireland.Sun.COM ([129.156.220.7]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA22373; Fri, 8 Feb 2002 07:59:07 -0700 (MST)
Received: from sun.com (dhcp-edub03-21 [129.156.220.138]) by ireserver.Ireland.Sun.COM (8.8.8+Sun/8.8.8/ENSMAIL,v2.2) with ESMTP id OAA27512; Fri, 8 Feb 2002 14:59:06 GMT
Message-ID: <[e-mail]>
Date: Fri, 08 Feb 2002 14:59:05 +0000
From: Andreas Sterbenz <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.8) Gecko/20020204
X-Accept-Language: en-us
MIME-Version: 1.0
To: Peter Gutmann <[e-mail]>
CC: [e-mail]
Subject: Re: I-D ACTION:draft-ietf-pkix-certstore-http-02.txt
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii; format=flowed
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>

 > 2. HTTP Certificate Store Interface

 > If more than one certificate matches a query, it MUST be returned as a
 > multipart/mixed response.

 > 2.4 Rationale

 > Multiple response are returned as multipart/mixed rather than an ASN.1
 > SEQUENCE OF Certificate or PKCS #7/CMS certificate chain because this
 > is more straightforward to implement with standard web-enabled tools.
 > An additional advantage is that it doesn't restrict this access
 > mechanism to DER-based data, allowing it to be extended to other
 > certificate types such as XML, PGP, and SPKI.

I continue to disagree with the decision to use multipart MIME for the 
reasons previously stated by me and others.

The XML/PGP argument does not seem to carry much weight either, because 
the spec is only targeted at X.509. It also seems questionable that MIME 
would be a suitable choice for XML/PGP any more than it is for X.509.

[I speak for myself, not for Sun]

Andreas.



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g18EX7k06711 for ietf-pkix-bks; Fri, 8 Feb 2002 06:33:07 -0800 (PST)
Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g18EX6306707 for <[e-mail]>; Fri, 8 Feb 2002 06:33:06 -0800 (PST)
Received: from lvt-mail.frlv.bull.fr (lvt-mail.frlv.bull.fr [129.184.62.223]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id PAA15996; Fri, 8 Feb 2002 15:34:39 +0100
Received: from bull.net (frlva3786.frlv.bull.fr [129.184.37.97]) by lvt-mail.frlv.bull.fr (8.9.2/8.9.1) with ESMTP id PAA11684; Fri, 8 Feb 2002 15:32:30 +0100
Message-ID: <[e-mail]>
Date: Fri, 08 Feb 2002 15:32:38 +0100
From: Denis Pinkas <[e-mail]>
Organization: Integris. A Bull Company
X-Mailer: Mozilla 4.7 [fr] (Win98; I)
X-Accept-Language: fr
MIME-Version: 1.0
To: Peter Gutmann <[e-mail]>
CC: [e-mail]
Subject: Re: RFC 3161 (TSP): update for the criticality flag
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>

Peter,

> Denis Pinkas <[e-mail]> writes:
> 
> >   A server that does not recognize a non-critical extension SHALL
> >   ignore the extension and SHALL not return an error for this.
> >
> >   A server that recognizes an extension SHALL process the extension
> >   regardless of the value of the criticality flag. A server MUST
> >   reject the request if it encounters a critical extension it does
> >   not recognize and in that case SHALL return a failure
> >   (unacceptedExtension).
> 
> This is still in conflict with RFC 2459.  
>
> Why not just use the RFC 2459 semantics?
  
The explanation has already been given by Peter Sylvester in an e-mail 
sent to the PKIX mailing list on Wednesday, 30 Jan 2002.
 
Please read that e-mail on the subsequent thread.

Denis
 
> Peter.


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g18EF5q06374 for ietf-pkix-bks; Fri, 8 Feb 2002 06:15:05 -0800 (PST)
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 g18EF3306368 for <[e-mail]>; Fri, 8 Feb 2002 06:15:03 -0800 (PST)
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 DAA05526; Sat, 9 Feb 2002 03:14:58 +1300 (NZDT) (sender [e-mail])
Received: (from pgut001@localhost) by ruru.cs.auckland.ac.nz (8.9.3/8.8.6/cs-slave) id DAA137011; Sat, 9 Feb 2002 03:14:58 +1300 (NZDT) (sender [e-mail])
Date: Sat, 9 Feb 2002 03:14:58 +1300 (NZDT)
Message-ID: <[e-mail]>
From: [e-mail] (Peter Gutmann)
To: [e-mail], [e-mail]
Subject: Re:  RFC 3161 (TSP): update for the criticality flag
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>

Denis Pinkas <[e-mail]> writes:

>   A server that does not recognize a non-critical extension SHALL
>   ignore the extension and SHALL not return an error for this.
>
>   A server that recognizes an extension SHALL process the extension
>   regardless of the value of the criticality flag. A server MUST
>   reject the request if it encounters a critical extension it does
>   not recognize and in that case SHALL return a failure
>   (unacceptedExtension).

This is still in conflict with RFC 2459.  Why not just use the RFC 2459
semantics?

Peter.


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g18DSIH02876 for ietf-pkix-bks; Fri, 8 Feb 2002 05:28:18 -0800 (PST)
Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g18DSH302868 for <[e-mail]>; Fri, 8 Feb 2002 05:28:17 -0800 (PST)
Received: from lvt-mail.frlv.bull.fr (lvt-mail.frlv.bull.fr [129.184.62.223]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id OAA18974 for <[e-mail]>; Fri, 8 Feb 2002 14:29:49 +0100
Received: from bull.net (frlva3786.frlv.bull.fr [129.184.37.97]) by lvt-mail.frlv.bull.fr (8.9.2/8.9.1) with ESMTP id OAA17314 for <[e-mail]>; Fri, 8 Feb 2002 14:27:40 +0100
Message-ID: <[e-mail]>
Date: Fri, 08 Feb 2002 14:27:49 +0100
From: Denis Pinkas <[e-mail]>
Organization: Integris. A Bull Company
X-Mailer: Mozilla 4.7 [fr] (Win98; I)
X-Accept-Language: fr
MIME-Version: 1.0
To: pkix <[e-mail]>
Subject: RFC 3161 (TSP): update for the criticality flag
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>

I am in the process to capture the changes to be done to RFC 3161. 
In response to the comments raised about the criticality flag 
for the extensions.

The current text reads:  

   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).

It will be replaced by:

   A server that does not recognize a non-critical extension SHALL 
   ignore the extension and SHALL not return an error for this.

   A server that recognizes an extension SHALL process the extension 
   regardless of the value of the criticality flag. A server MUST 
   reject the request if it encounters a critical extension it does 
   not recognize and in that case SHALL return a failure 
   (unacceptedExtension). 

Denis


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g18DFqw02445 for ietf-pkix-bks; Fri, 8 Feb 2002 05:15:52 -0800 (PST)
Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g18DFp302441 for <[e-mail]>; Fri, 8 Feb 2002 05:15:51 -0800 (PST)
Received: from lvt-mail.frlv.bull.fr (lvt-mail.frlv.bull.fr [129.184.62.223]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id OAA09080; Fri, 8 Feb 2002 14:17:24 +0100
Received: from bull.net (frlva3786.frlv.bull.fr [129.184.37.97]) by lvt-mail.frlv.bull.fr (8.9.2/8.9.1) with ESMTP id OAA18078; Fri, 8 Feb 2002 14:15:15 +0100
Message-ID: <[e-mail]>
Date: Fri, 08 Feb 2002 14:15:24 +0100
From: Denis Pinkas <[e-mail]>
Organization: Integris. A Bull Company
X-Mailer: Mozilla 4.7 [fr] (Win98; I)
X-Accept-Language: fr
MIME-Version: 1.0
To: Miguel Reis <[e-mail]>
CC: [e-mail]
Subject: Re: TSP via HTTP - MIME objects
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>

Miguel,

> Hi all,
> 
> RFC3161 says:
> 
> "Content-Type: application/timestamp-reply
> 
>       <<the ASN.1 DER-encoded Time-Stamp Response message>>"
> ...
> 
> "Upon receiving a valid request, the server MUST respond with either a
> valid response with content type application/timestamp-response or
> with an HTTP error."
> 
> My question is:
> 
> The TSA should respond with "application/timestamp-reply" or with
> "application/timestamp-response"?

"application/timestamp-reply". Good catch. Thank you.

Denis

> thanks,
> 
> miguel


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g18B3Fq23718 for ietf-pkix-bks; Fri, 8 Feb 2002 03:03:15 -0800 (PST)
Received: from smtp.isp.novis.pt (onyx.ip.pt [195.23.92.252]) by above.proper.com (8.11.6/8.11.3) with SMTP id g18B3E323714 for <[e-mail]>; Fri, 8 Feb 2002 03:03:14 -0800 (PST)
Received: (qmail 9230 invoked from network); 8 Feb 2002 11:03:08 -0000
Received: from unknown (HELO hook.ip.pt) ([195.23.98.141]) (envelope-sender <[e-mail]>) by onyx.ip.pt (qmail-ldap-1.03) with SMTP for <[e-mail]>; 8 Feb 2002 11:03:08 -0000
Subject: TSP via HTTP - MIME objects
From: Miguel Reis <[e-mail]>
To: [e-mail]
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
X-Mailer: Evolution/1.0 (Preview Release)
Date: 08 Feb 2002 11:12:22 +0000
Message-Id: <[e-mail]>
Mime-Version: 1.0
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>

Hi all,


RFC3161 says:

"Content-Type: application/timestamp-reply

      <<the ASN.1 DER-encoded Time-Stamp Response message>>"

...

"Upon receiving a valid request, the server MUST respond with either a
valid response with content type application/timestamp-response or
with an HTTP error."


My question is:

The TSA should respond with "application/timestamp-reply" or with
"application/timestamp-response"?


thanks,

miguel





Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g187Naj25798 for ietf-pkix-bks; Thu, 7 Feb 2002 23:23:36 -0800 (PST)
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 g187NY325787 for <[e-mail]>; Thu, 7 Feb 2002 23:23:34 -0800 (PST)
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 UAA32557; Fri, 8 Feb 2002 20:23:23 +1300 (NZDT) (sender [e-mail])
Received: (from pgut001@localhost) by ruru.cs.auckland.ac.nz (8.9.3/8.8.6/cs-slave) id UAA129849; Fri, 8 Feb 2002 20:23:18 +1300 (NZDT) (sender [e-mail])
Date: Fri, 8 Feb 2002 20:23:18 +1300 (NZDT)
Message-ID: <[e-mail]>
From: [e-mail] (Peter Gutmann)
To: [e-mail], [e-mail], [e-mail], [e-mail]
Subject: RE: Candidate for moving OCSP to a Draft Standard
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>

"Khaja E. Ahmed" <[e-mail]> writes:

>This sounds like a perfectly reasonable solution. Surprised it was rejected.
>After-all this would be an optional extension, why not add it?  

The reasoning as I recall was that OCSP shouldn't include facilities which
aren't bug-compatible with CRLs.  Since CRLs can only provide a negative
response, and even that only for some cases of invalid certs, OCSP doesn't
include a straighforward yes/no indication.

(IMHO any poor guy who's stuck with feeding their online status service from
 offline CRLs has bigger things to worry about than this...).

Peter.



Received: by above.proper.com (8.11.6/8.11.3) id g187I4624231 for ietf-pkix-bks; Thu, 7 Feb 2002 23:18:04 -0800 (PST)
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 g187I1324227 for <[e-mail]>; Thu, 7 Feb 2002 23:18:02 -0800 (PST)
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 UAA32488; Fri, 8 Feb 2002 20:17:46 +1300 (NZDT) (sender [e-mail])
Received: (from pgut001@localhost) by ruru.cs.auckland.ac.nz (8.9.3/8.8.6/cs-slave) id UAA129798; Fri, 8 Feb 2002 20:17:45 +1300 (NZDT) (sender [e-mail])
Date: Fri, 8 Feb 2002 20:17:45 +1300 (NZDT)
Message-ID: <[e-mail]>
From: [e-mail] (Peter Gutmann)
To: [e-mail], [e-mail]
Subject: RE: Candidate for moving OCSP to a Draft Standard
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>

"Florian Oelmaier" <[e-mail]> writes:

>Advantage of OCSP: extensible.
>
>Idea: Use advantages heavily.
>
>Conclusion: Interested in Peter Gutmanns extension.
>
>:) So Peter, plz post the extension and the derscription. Best to the list -
>then it is somewhat half-official and a lot of other people in the community
>can use it, too.

Here it is, slightly more formalised than the original source code comment:

-- Snip --

CertificateOK

The CertOK extension sidesteps the limitations of the CRL-based semantics of
the standard OCSP response and provides a straightforward indication of whether
a certificate is OK or not.  "OK" in this sense is the equivalent of the
banking assertion that an account is in good standing, namely that the
identified certificate was issued and is currently valid.  Further information
on why a certificate may not be OK can be found in the standard OCSP response.

  id-certOK OBJECT IDENTIFIER ::= { 1 3 6 1 4 1 3029 3 1 2 }

  CertOK ::= BOOLEAN

  [I'll take a PKIX OID in place of the current private one if it's considered
   worth issuing it]

Rationale

The CertOK response is purely an indication that the account is in good
standing.  In other words, it provides the information that the OCSP responder
is likely to possess, but is prevented by the standard OCSP status values from
providing to the user.  It does not provide, and is not intended to provide, a
DVCS/DPV/DPD/etc-style checking mechanism (for example, again using banking
terms, an indication that the account contains enough to cover a given
transaction, or that the account owner can be trusted to do business with).
These extended forms of checking are covered in separate standards.

-- Snip --

Peter.


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g1804gN08365 for ietf-pkix-bks; Thu, 7 Feb 2002 16:04:42 -0800 (PST)
Received: from www.seguridata.com (seguridata02.terra.net.mx [200.4.103.226]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1804e308361 for <[e-mail]>; Thu, 7 Feb 2002 16:04:40 -0800 (PST)
Received: from mars ([10.0.0.1]) by www.seguridata.com (Post.Office MTA v3.5.3 release 223 ID# 517-61027U100L2S100V35) with SMTP id com for <[e-mail]>; Thu, 7 Feb 2002 18:11:35 -0600
Reply-To: <[e-mail]>
From: [e-mail] (Miguel Angel Rodriguez)
To: <[e-mail]>
Subject: Response Signer Identity in OCSP
Date: Thu, 7 Feb 2002 17:54:15 -0600
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
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600
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>

Regarding section 3.2  Signed Response Acceptance Requirements in
OCSP-draft-03, in point number 3:

3. The identity of the signer matches the intended recipient of the
   request.

What does the client know about the identity of the responder? It knows    a
URL from the AuthorityInfoAccess in a given certifcate, and once it gets the
response it has the responder's certificate, a responderId, which may be a
name or the hash of its public key. But how can a client check that the
responder's identity matches the one of the intended recipient of the
request. Does it imply that the client has to validate the responder's
certificate? What is the purpose of the ResponderID field in the response?

Thanks,

Miguel A. Rodriguez
SeguriDATA
Mexico



Received: by above.proper.com (8.11.6/8.11.3) id g173MV013426 for ietf-pkix-bks; Wed, 6 Feb 2002 19:22:31 -0800 (PST)
Received: from rwcrmhc53.attbi.com (rwcrmhc53.attbi.com [204.127.198.39]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g173MQ313417 for <[e-mail]>; Wed, 6 Feb 2002 19:22:30 -0800 (PST)
Received: from C707777B ([12.232.94.141]) by rwcrmhc53.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with SMTP id <20020207032225.HBJJ10199.rwcrmhc53.attbi.com@C707777B>; Thu, 7 Feb 2002 03:22:25 +0000
From: "Khaja E. Ahmed" <[e-mail]>
To: "Peter Gutmann" <[e-mail]>, <[e-mail]>, <[e-mail]>
Cc: <[e-mail]>
Subject: RE: Candidate for moving OCSP to a Draft Standard
Date: Wed, 6 Feb 2002 19:21:52 -0800
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.50.4133.2400
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>

This sounds like a perfectly reasonable solution. Surprised it was rejected.
After-all this would be an optional extension, why not add it?  ...if for no
other reason than that it would put an end to the 'good' is not good enough
debate.

Khaja

> -----Original Message-----
> From: [e-mail]
> [mailto:[e-mail]]On Behalf Of Peter Gutmann
> Sent: Wednesday, February 06, 2002 7:25 AM
> To: [e-mail]; [e-mail]
> Cc: [e-mail]
> Subject: Re: Candidate for moving OCSP to a Draft Standard
>
>
>
> Denis Pinkas <[e-mail]> writes:
>
> >2) The "good" status has always been misleading. The text says:
> >
> >   The "good" state indicates that the certificate has not been revoked.
> >
> >According to this definition, which is correct, an unambiguous
> status would
> >better be called: "not revoked" rather than "good".
>
> Uh-oh, the OCSP-status-debate perpetual motion machine has
> started again :-).
> In case anyone's interested, I've been using a private extension
> which tries to
> fix the OCSP status problems, for about a year or so.  It's very
> simple, just a
> boolean when says that the certificate in question exists and is currently
> valid (ie was issued and hasn't expired, been revoked, or
> whatever).  This was
> rejected for addition to OCSP, but if anyone else is interested in adding
> support for this I'll post the details.
>
> Peter.



Received: by above.proper.com (8.11.6/8.11.3) id g16IodJ17673 for ietf-pkix-bks; Wed, 6 Feb 2002 10:50:39 -0800 (PST)
Received: from mail-out.secaron.de (druss.secaron.de [195.145.99.123]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g16Iob317667 for <[e-mail]>; Wed, 6 Feb 2002 10:50:38 -0800 (PST)
Received: by mail-out.secaron.de (Postfix, from userid 0) id 3F61E51F26; Wed,  6 Feb 2002 19:50:34 +0100 (MET)
Received: from druss.secaron.de (localhost [127.0.0.1]) by mail-out.secaron.de (Postfix) with ESMTP id CC66232577; Wed,  6 Feb 2002 19:50:33 +0100 (MET)
Received: from marvin.munich.secaron.de (marvin.munich.secaron.de [192.168.1.20]) by druss.secaron.de (Postfix) with ESMTP id 8DCB54ACC0; Wed,  6 Feb 2002 19:50:28 +0100 (MET)
Received: from MUCDEV101 ([192.168.2.101]) by marvin.munich.secaron.de (Lotus Domino Release 5.0.9a) with SMTP id 2002020619502744:5682 ; Wed, 6 Feb 2002 19:50:27 +0100 
From: "Florian Oelmaier" <[e-mail]>
To: "Peter Gutmann" <[e-mail]>
Cc: <[e-mail]>
Subject: RE: Candidate for moving OCSP to a Draft Standard
Date: Wed, 6 Feb 2002 19:46:21 +0100
Message-ID: <[e-mail]>
MIME-Version: 1.0
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
In-Reply-To: <[e-mail]>
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600
X-MIMETrack: Itemize by SMTP Server on Marvin/Secaron(Release 5.0.9a |January 7, 2002) at 02/06/2002 07:50:27 PM, Serialize by Router on Marvin/Secaron(Release 5.0.9a |January 7, 2002) at 02/06/2002 07:50:28 PM, Serialize complete at 02/06/2002 07:50:28 PM
Content-Transfer-Encoding: 7bit
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>

Advantage of OCSP: extensible.

Idea: Use advantages heavily.

Conclusion: Interested in Peter Gutmanns extension.

:) So Peter, plz post the extension and the derscription. Best to the list -
then it is somewhat half-official and a lot of other people in the community
can use it, too.

--
Dipl.Inf. Florian Oelmaier
Head of Development
syTrust S.A.


> -----Original Message-----
> From: [e-mail]
> [mailto:[e-mail]]On Behalf Of Peter Gutmann
> Sent: Wednesday, February 06, 2002 4:25 PM
> To: [e-mail]; [e-mail]
> Cc: [e-mail]
> Subject: Re: Candidate for moving OCSP to a Draft Standard
>
>
>
> Denis Pinkas <[e-mail]> writes:
>
> >2) The "good" status has always been misleading. The text says:
> >
> >   The "good" state indicates that the certificate has not been revoked.
> >
> >According to this definition, which is correct, an unambiguous
> status would
> >better be called: "not revoked" rather than "good".
>
> Uh-oh, the OCSP-status-debate perpetual motion machine has
> started again :-).
> In case anyone's interested, I've been using a private extension
> which tries to
> fix the OCSP status problems, for about a year or so.  It's very
> simple, just a
> boolean when says that the certificate in question exists and is currently
> valid (ie was issued and hasn't expired, been revoked, or
> whatever).  This was
> rejected for addition to OCSP, but if anyone else is interested in adding
> support for this I'll post the details.
>
> Peter.



Received: by above.proper.com (8.11.6/8.11.3) id g16Fcv410406 for ietf-pkix-bks; Wed, 6 Feb 2002 07:38:57 -0800 (PST)
Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g16Fct310402 for <[e-mail]>; Wed, 6 Feb 2002 07:38:55 -0800 (PST)
Received: from lvt-mail.frlv.bull.fr (lvt-mail.frlv.bull.fr [129.184.62.223]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id QAA13478; Wed, 6 Feb 2002 16:40:26 +0100
Received: from bull.net (frlva3786.frlv.bull.fr [129.184.37.97]) by lvt-mail.frlv.bull.fr (8.9.2/8.9.1) with ESMTP id QAA18292; Wed, 6 Feb 2002 16:38:22 +0100
Message-ID: <[e-mail]>
Date: Wed, 06 Feb 2002 16:38:24 +0100
From: Denis Pinkas <[e-mail]>
Organization: Integris. A Bull Company
X-Mailer: Mozilla 4.7 [fr] (Win98; I)
X-Accept-Language: fr
MIME-Version: 1.0
To: Peter Gutmann <[e-mail]>
CC: [e-mail]
Subject: Re: Candidate for moving OCSP to a Draft Standard
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>

Peter,

> >2) The "good" status has always been misleading. The text says:

> >   The "good" state indicates that the certificate has not been revoked.

> >According to this definition, which is correct, an unambiguous status would
> >better be called: "not revoked" rather than "good".
 
> Uh-oh, the OCSP-status-debate perpetual motion machine has started again :-).
> In case anyone's interested, I've been using a private extension which tries to
> fix the OCSP status problems, for about a year or so.  It's very simple, just a
> boolean when says that the certificate in question exists and is currently
> valid (ie was issued and hasn't expired, been revoked, or whatever).  This was
> rejected for addition to OCSP, but if anyone else is interested in adding
> support for this I'll post the details.

Uh-oh, the OCSP-status-debate about "certificate exists" has started again
:-).
Let us close this debate. :-)

Denis

> Peter.


Received: by above.proper.com (8.11.6/8.11.3) id g16FPUF09315 for ietf-pkix-bks; Wed, 6 Feb 2002 07:25:30 -0800 (PST)
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 g16FPR309308 for <[e-mail]>; Wed, 6 Feb 2002 07:25:27 -0800 (PST)
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 EAA13420; Thu, 7 Feb 2002 04:25:22 +1300 (NZDT) (sender [e-mail])
Received: (from pgut001@localhost) by ruru.cs.auckland.ac.nz (8.9.3/8.8.6/cs-slave) id EAA84738; Thu, 7 Feb 2002 04:25:20 +1300 (NZDT) (sender [e-mail])
Date: Thu, 7 Feb 2002 04:25:20 +1300 (NZDT)
Message-ID: <[e-mail]>
From: [e-mail] (Peter Gutmann)
To: [e-mail], [e-mail]
Subject: Re: Candidate for moving OCSP to a Draft Standard
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>

Denis Pinkas <[e-mail]> writes:

>2) The "good" status has always been misleading. The text says:
>
>   The "good" state indicates that the certificate has not been revoked.
>
>According to this definition, which is correct, an unambiguous status would
>better be called: "not revoked" rather than "good".

Uh-oh, the OCSP-status-debate perpetual motion machine has started again :-).
In case anyone's interested, I've been using a private extension which tries to
fix the OCSP status problems, for about a year or so.  It's very simple, just a
boolean when says that the certificate in question exists and is currently
valid (ie was issued and hasn't expired, been revoked, or whatever).  This was
rejected for addition to OCSP, but if anyone else is interested in adding
support for this I'll post the details.

Peter.


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g15NVTA16897 for ietf-pkix-bks; Tue, 5 Feb 2002 15:31:29 -0800 (PST)
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g15NVS316892 for <[e-mail]>; Tue, 5 Feb 2002 15:31:28 -0800 (PST)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA23694; Tue, 5 Feb 2002 18:31:25 -0500 (EST)
Message-Id: <[e-mail]>
To: IETF-Announce: ;
Cc: RFC Editor <[e-mail]>, Internet Architecture Board <[e-mail]>, [e-mail]
From: The IESG <[e-mail]>
Subject: Protocol Action: Internet X.509 Public Key Infrastructure Certificate and CRL Profile to Proposed Standard
Date: Tue, 05 Feb 2002 18:31:25 -0500
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>

The IESG has approved the Internet-Drafts 'Internet X.509 Public Key
Infrastructure' <draft-ietf-pkix-new-part1-12.txt> and 'Algorithms and
Identifiers for the Internet X.509 Public Key Infrastructure'
<draft-ietf-pkix-ipki-pkalgs-05.txt> as Proposed Standards. These
documents are the product of the Internet X.509 Public Key
Infrastructure (PKIX) Working Group. The IESG contact persons are Jeff
Schiller and Marcus Leech.

Technical Summary

  These document defines a profile for X.509 Version 3 certificates and
  X.509 Version 2 Certificate Revocation Lists (CRLs) for use on the
  Internet. It addresses both the cryptographic issues (what has to sign
  what) as well as introduces a rich policy framework for determining
  whether or not a particular certificate should be trusted or not in a
  given context.

  Document formats (Certificates and CRL) are defined as are operation
  and management protocols.

Working Group Summary

  These documents are the product of significant discussion and effort
  on the part of the members of the PKIX Working Group. There is Working
  Group Consensus on them.

Protocol Quality

  These specifications were reviewed for the IESG by Jeffrey
  I. Schiller. In addition these documents received significant review
  in the security community and are believed to be correct.



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g15Jtoj05959 for ietf-pkix-bks; Tue, 5 Feb 2002 11:55:50 -0800 (PST)
Received: from SOTTMXS01.entrust.com (mail.entrust.com [216.191.251.35] (may be forged)) by above.proper.com (8.11.6/8.11.3) with ESMTP id g15Jtn305955 for <[e-mail]>; Tue, 5 Feb 2002 11:55:49 -0800 (PST)
Received: by SOTTMXS01.entrust.com with Internet Mail Service (5.5.2653.19) id <1LFVBQTZ>; Tue, 5 Feb 2002 14:57:36 -0500
Message-ID: <8D7EC1912E25D411A32100D0B7695397E1BCED@SCYGMXS01>
From: Santosh Chokhani <[e-mail]>
To: "David A. Cooper" <[e-mail]>, "'[e-mail]'" <[e-mail]>
Subject: RE: New-PKIX-Part1 conflict with X.509 (2000)
Date: Tue, 5 Feb 2002 14:54:05 -0500 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1AE7E.DE105850"
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>

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_01C1AE7E.DE105850
Content-Type: text/plain

David: please see my responses in-line

-----Original Message-----
<snip>

X.509 states the following about the CRL DP extension:

         The distributionPoint component identifies the location from which
the CRL can be obtained.
         If this component is absent, the distribution point name defaults
to the CRL issuer name.

Thus, it is possible for a CRL that contains a distribution point name in
the IDP extension to match a certificate with a CRL DP that does not have a
DP field. This can happen in one of two ways: either (1) the cRLIssuer field
is absent from the CRL DP and the certificate issuer = CRL issuer = DP name
in IDP, or (2) the cRLIssuer field is present and the cRLIssuer in the CRL
DP = CRL issuer = DP name in IDP.

Unlike PKIX, X.509 seems to allow for a DistributionPoint in a CRL DP
extension to be empty (i.e., all three optional elements absent). In this
case, the cRLIssuer defaults to the certificate issuer name and the
distributionPoint defaults to the certificate issuer name as well. A CRL
covering this certificate may have an IDP extension with a DP as long as one
the DPs in the extension is the certificate issuer's name. Given this, it
seems logical that certificate with no CRL DP extension would also be
covered by that CRL. PKIX, in section 6.3.3 explicitly states this:

         For the processing of [a CRL that is not pointed to by a CRL DP],
assume a DP
         with both the reasons and the cRLIssuer fields omitted and a
distribution point
         name of the certificate issuer.

Is this wrong? If so, why?

[The intent of not asserting a DP in CRL DP extension was only if CRL Issuer
field was there so that you do not have to put in the same DN twice.  Thus,
I do not think we should consider case 1.  Granted, standard being vague,
your interpretation is valid.  As far as case 2 is concerned, I agree that
if IDP has a DP, and CRL DP has no DP but cRLIssuer, and the CRL DP
cRLIssuer match the IDP DP; or if the CRL DP cRLIssuer match the CRL Issuer
name and IDP has no DP we have the correct CRL.]

On a related note, there does seem to be a problem with the text in X.509.
At the end of section 8.6.2.1, it states:

         If [the CRL DP] extension is flagged non-critical and a
certificate-using system does
         not recognize the extension field type, then that system should
only use the certificate if:

         - it can acquire and check a complete CRL from the authority (that
the latter CRL is complete
           is indicated by the absence of an issuing distribution point
extension field in the CRL);

It is not necessary, however, to use a complete CRL. If one is checking the
status of an end entity certificate, for example, the CRL could have an IDP
extension with onlyContainsUserCerts asserted. One does not need to be able
to process the CRL DP extension to determine that the certificate is covered
by this CRL. Similarly, the IDP extension in the CRL could have an
onlySomeReasons flag.

[In this case, the standard should reference the Annex for what it means for
a CRL to be complete for its scope (i.e., reason codes of interest and/or
entity type]

Dave


------_=_NextPart_001_01C1AE7E.DE105850
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.2653.12">
<TITLE>RE: New-PKIX-Part1 conflict with X.509 (2000)</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>David: please see my responses in-line</FONT>
</P>

<P><FONT SIZE=3D2>-----Original Message-----</FONT>
<BR><FONT SIZE=3D2>&lt;snip&gt;</FONT>
</P>

<P><FONT SIZE=3D2>X.509 states the following about the CRL DP =
extension:</FONT>
</P>

<P><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; The =
distributionPoint component identifies the location from which the CRL =
can be obtained.</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; If =
this component is absent, the distribution point name defaults to the =
CRL issuer name.</FONT>
</P>

<P><FONT SIZE=3D2>Thus, it is possible for a CRL that contains a =
distribution point name in the IDP extension to match a certificate =
with a CRL DP that does not have a DP field. This can happen in one of =
two ways: either (1) the cRLIssuer field is absent from the CRL DP and =
the certificate issuer =3D CRL issuer =3D DP name in IDP, or (2) the =
cRLIssuer field is present and the cRLIssuer in the CRL DP =3D CRL =
issuer =3D DP name in IDP.</FONT></P>

<P><FONT SIZE=3D2>Unlike PKIX, X.509 seems to allow for a =
DistributionPoint in a CRL DP extension to be empty (i.e., all three =
optional elements absent). In this case, the cRLIssuer defaults to the =
certificate issuer name and the distributionPoint defaults to the =
certificate issuer name as well. A CRL covering this certificate may =
have an IDP extension with a DP as long as one the DPs in the extension =
is the certificate issuer's name. Given this, it seems logical that =
certificate with no CRL DP extension would also be covered by that CRL. =
PKIX, in section 6.3.3 explicitly states this:</FONT></P>

<P><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; For =
the processing of [a CRL that is not pointed to by a CRL DP], assume a =
DP</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
with both the reasons and the cRLIssuer fields omitted and a =
distribution point</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
name of the certificate issuer.</FONT>
</P>

<P><FONT SIZE=3D2>Is this wrong? If so, why?</FONT>
</P>

<P><FONT SIZE=3D2>[The intent of not asserting a DP in CRL DP extension =
was only if CRL Issuer field was there so that you do not have to put =
in the same DN twice.&nbsp; Thus, I do not think we should consider =
case 1.&nbsp; Granted, standard being vague, your interpretation is =
valid.&nbsp; As far as case 2 is concerned, I agree that if IDP has a =
DP, and CRL DP has no DP but cRLIssuer, and the CRL DP cRLIssuer match =
the IDP DP; or if the CRL DP cRLIssuer match the CRL Issuer name and =
IDP has no DP we have the correct CRL.]</FONT></P>

<P><FONT SIZE=3D2>On a related note, there does seem to be a problem =
with the text in X.509. At the end of section 8.6.2.1, it =
states:</FONT>
</P>

<P><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; If =
[the CRL DP] extension is flagged non-critical and a certificate-using =
system does</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; not =
recognize the extension field type, then that system should only use =
the certificate if:</FONT>
</P>

<P><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; - it =
can acquire and check a complete CRL from the authority (that the =
latter CRL is complete</FONT>
<BR><FONT =
SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
is indicated by the absence of an issuing distribution point extension =
field in the CRL);</FONT>
</P>

<P><FONT SIZE=3D2>It is not necessary, however, to use a complete CRL. =
If one is checking the status of an end entity certificate, for =
example, the CRL could have an IDP extension with onlyContainsUserCerts =
asserted. One does not need to be able to process the CRL DP extension =
to determine that the certificate is covered by this CRL. Similarly, =
the IDP extension in the CRL could have an onlySomeReasons =
flag.</FONT></P>

<P><FONT SIZE=3D2>[In this case, the standard should reference the =
Annex for what it means for a CRL to be complete for its scope (i.e., =
reason codes of interest and/or entity type]</FONT></P>

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

</BODY>
</HTML>
------_=_NextPart_001_01C1AE7E.DE105850--


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g15HKMP00977 for ietf-pkix-bks; Tue, 5 Feb 2002 09:20:22 -0800 (PST)
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 g15HKL300973 for <[e-mail]>; Tue, 5 Feb 2002 09:20:21 -0800 (PST)
Received: from krdp2 (krdp2.ncsl.nist.gov [129.6.54.107]) by email.nist.gov (8.12.2/8.12.2) with ESMTP id g15HKKfQ027045 for <[e-mail]>; Tue, 5 Feb 2002 12:20:20 -0500 (EST)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 
Date: Tue, 05 Feb 2002 12:19:48 -0500
To: "'[e-mail]'" <[e-mail]>
From: "David A. Cooper" <[e-mail]>
Subject: RE: New-PKIX-Part1 conflict with X.509 (2000)
In-Reply-To: <8D7EC1912E25D411A32100D0B7695397E1BCC7@SCYGMXS01>
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>

At 10:38 AM 2/5/02 -0500, Santosh Chokhani wrote:

>I agree with Rich on this one. 
>
>I think if the CRL DP does not have DP field, the IDP in the CRL should not have one either. 
>
>That seems that safest thing to do. 
>
>Once a DP field is present a CRL IDP extension, there is no way for a client to determine whether a CRL is complete for its scope.

Santosh,

X.509 states the following about the CRL DP extension:

         The distributionPoint component identifies the location from which the CRL can be obtained.
         If this component is absent, the distribution point name defaults to the CRL issuer name.

Thus, it is possible for a CRL that contains a distribution point name in the IDP extension to match a certificate with a CRL DP that does not have a DP field. This can happen in one of two ways: either (1) the cRLIssuer field is absent from the CRL DP and the certificate issuer = CRL issuer = DP name in IDP, or (2) the cRLIssuer field is present and the cRLIssuer in the CRL DP = CRL issuer = DP name in IDP.

Unlike PKIX, X.509 seems to allow for a DistributionPoint in a CRL DP extension to be empty (i.e., all three optional elements absent). In this case, the cRLIssuer defaults to the certificate issuer name and the distributionPoint defaults to the certificate issuer name as well. A CRL covering this certificate may have an IDP extension with a DP as long as one the DPs in the extension is the certificate issuer's name. Given this, it seems logical that certificate with no CRL DP extension would also be covered by that CRL. PKIX, in section 6.3.3 explicitly states this:

         For the processing of [a CRL that is not pointed to by a CRL DP], assume a DP
         with both the reasons and the cRLIssuer fields omitted and a distribution point
         name of the certificate issuer.

Is this wrong? If so, why?

On a related note, there does seem to be a problem with the text in X.509. At the end of section 8.6.2.1, it states:

         If [the CRL DP] extension is flagged non-critical and a certificate-using system does
         not recognize the extension field type, then that system should only use the certificate if:

         - it can acquire and check a complete CRL from the authority (that the latter CRL is complete
           is indicated by the absence of an issuing distribution point extension field in the CRL);

It is not necessary, however, to use a complete CRL. If one is checking the status of an end entity certificate, for example, the CRL could have an IDP extension with onlyContainsUserCerts asserted. One does not need to be able to process the CRL DP extension to determine that the certificate is covered by this CRL. Similarly, the IDP extension in the CRL could have an onlySomeReasons flag.

Dave




Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g15Fe8625448 for ietf-pkix-bks; Tue, 5 Feb 2002 07:40:08 -0800 (PST)
Received: from SOTTMXS01.entrust.com (mail.entrust.com [216.191.251.35] (may be forged)) by above.proper.com (8.11.6/8.11.3) with ESMTP id g15Fe7325444 for <[e-mail]>; Tue, 5 Feb 2002 07:40:07 -0800 (PST)
Received: by SOTTMXS01.entrust.com with Internet Mail Service (5.5.2653.19) id <1LFVBMDM>; Tue, 5 Feb 2002 10:41:43 -0500
Message-ID: <8D7EC1912E25D411A32100D0B7695397E1BCC7@SCYGMXS01>
From: Santosh Chokhani <[e-mail]>
To: "Nicholas, Richard" <[e-mail]>, "'David A. Cooper'" <[e-mail]>, "'[e-mail]'" <[e-mail]>
Subject: RE: New-PKIX-Part1 conflict with X.509 (2000)
Date: Tue, 5 Feb 2002 10:38:12 -0500 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1AE5B.1EEA8EF0"
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>

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_01C1AE5B.1EEA8EF0
Content-Type: text/plain

I agree with Rich on this one.

I think if the CRL DP does not have DP field, the IDP in the CRL should not
have one either.

That seems that safest thing to do.

Once a DP field is present a CRL IDP extension, there is no way for a client
to determine whether a CRL is complete for its scope.

-----Original Message-----
From: Nicholas, Richard [mailto:[e-mail]]
Sent: Monday, February 04, 2002 3:54 PM
To: 'David A. Cooper'; '[e-mail]'
Subject: RE: New-PKIX-Part1 conflict with X.509 (2000)



Dave,

See my comments below.

> The important question is not whether a CRL is complete, but 
> whether it covers the certificate of interest. On this issue, 
> I believe that PKIX and X.509 are in agreement.
> 
> The text in section 6.3.3 does not say anything about whether 
> a CRL is complete. It merely says that a CRL containing a 
> distribution point field in an IDP CRL extension covers a 
> certificate if the DP name matches the certificate issuer's name.
> 
> In X.509, section B.5.1 provides rules for determining 
> whether a certificate is covered by a CRL. If a CRL meets the 
> criteria in section B.5.1.1 (Complete CRL) then it is a 
> complete CRL and thus covers all certificates issued by the 
> CRL issuer.
> 
> If the CRL contains an IDP extension with a distribution 
> point name, then section B.5.1.4 (Distribution point based 
> CRL/EPRL/CARL) applies. This section states that if the 
> distribution point name in the IDP extension is present, it 
> must match one of the names in the distribution point or CRL 
> issuer field in the CRL DP in the certificate.
> 
> Section 8.6.2.1 in X.509 states that if the distribution 
> point name is absent from the CRL DP extension then "the 
> distribution point name defaults to the CRL issuer name". 
> Thus, under the scenario that you mentioned, an algorithm 
> that follows X.509 will accept the CRL as covering the certificate.
> 
> Dave

The text you quoted from section 8.6.2.1 in X.509 is not meant to imply that
all certs have distribution points, only to specify what name to use when
the optional distributionPoint component is absent.

In the cases where either:
1.  the CRL distribution points extension is absent, or
2.  the CRL distribution points have been processed, but not all revocation
reasons have been checked,
the software will then attempt to acquire and validate a complete CRL that
covers the remaining reason codes for the type of cert (CA or EE).

In those cases, the software follows the X.509 rules specified for complete
CRLs, since that is the type of CRL it requires -- not a distribution point
CRL.  The presence of an IDP extension in a CRL does not make the CRL a DP
CRL -- even complete CRLs can contain IDP extensions.

- Rich

------_=_NextPart_001_01C1AE5B.1EEA8EF0
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.2653.12">
<TITLE>RE: New-PKIX-Part1 conflict with X.509 (2000)</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>I agree with Rich on this one.</FONT>
</P>

<P><FONT SIZE=3D2>I think if the CRL DP does not have DP field, the IDP =
in the CRL should not have one either.</FONT>
</P>

<P><FONT SIZE=3D2>That seems that safest thing to do.</FONT>
</P>

<P><FONT SIZE=3D2>Once a DP field is present a CRL IDP extension, there =
is no way for a client to determine whether a CRL is complete for its =
scope.</FONT></P>

<P><FONT SIZE=3D2>-----Original Message-----</FONT>
<BR><FONT SIZE=3D2>From: Nicholas, Richard [<A =
HREF=3D"mailto:[e-mail]">mailto:Richard.Nichola=
[e-mail]</A>]</FONT>
<BR><FONT SIZE=3D2>Sent: Monday, February 04, 2002 3:54 PM</FONT>
<BR><FONT SIZE=3D2>To: 'David A. Cooper'; '[e-mail]'</FONT>
<BR><FONT SIZE=3D2>Subject: RE: New-PKIX-Part1 conflict with X.509 =
(2000)</FONT>
</P>
<BR>
<BR>

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

<P><FONT SIZE=3D2>See my comments below.</FONT>
</P>

<P><FONT SIZE=3D2>&gt; The important question is not whether a CRL is =
complete, but </FONT>
<BR><FONT SIZE=3D2>&gt; whether it covers the certificate of interest. =
On this issue, </FONT>
<BR><FONT SIZE=3D2>&gt; I believe that PKIX and X.509 are in =
agreement.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; The text in section 6.3.3 does not say anything =
about whether </FONT>
<BR><FONT SIZE=3D2>&gt; a CRL is complete. It merely says that a CRL =
containing a </FONT>
<BR><FONT SIZE=3D2>&gt; distribution point field in an IDP CRL =
extension covers a </FONT>
<BR><FONT SIZE=3D2>&gt; certificate if the DP name matches the =
certificate issuer's name.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; In X.509, section B.5.1 provides rules for =
determining </FONT>
<BR><FONT SIZE=3D2>&gt; whether a certificate is covered by a CRL. If a =
CRL meets the </FONT>
<BR><FONT SIZE=3D2>&gt; criteria in section B.5.1.1 (Complete CRL) then =
it is a </FONT>
<BR><FONT SIZE=3D2>&gt; complete CRL and thus covers all certificates =
issued by the </FONT>
<BR><FONT SIZE=3D2>&gt; CRL issuer.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; If the CRL contains an IDP extension with a =
distribution </FONT>
<BR><FONT SIZE=3D2>&gt; point name, then section B.5.1.4 (Distribution =
point based </FONT>
<BR><FONT SIZE=3D2>&gt; CRL/EPRL/CARL) applies. This section states =
that if the </FONT>
<BR><FONT SIZE=3D2>&gt; distribution point name in the IDP extension is =
present, it </FONT>
<BR><FONT SIZE=3D2>&gt; must match one of the names in the distribution =
point or CRL </FONT>
<BR><FONT SIZE=3D2>&gt; issuer field in the CRL DP in the =
certificate.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Section 8.6.2.1 in X.509 states that if the =
distribution </FONT>
<BR><FONT SIZE=3D2>&gt; point name is absent from the CRL DP extension =
then &quot;the </FONT>
<BR><FONT SIZE=3D2>&gt; distribution point name defaults to the CRL =
issuer name&quot;. </FONT>
<BR><FONT SIZE=3D2>&gt; Thus, under the scenario that you mentioned, an =
algorithm </FONT>
<BR><FONT SIZE=3D2>&gt; that follows X.509 will accept the CRL as =
covering the certificate.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Dave</FONT>
</P>

<P><FONT SIZE=3D2>The text you quoted from section 8.6.2.1 in X.509 is =
not meant to imply that</FONT>
<BR><FONT SIZE=3D2>all certs have distribution points, only to specify =
what name to use when</FONT>
<BR><FONT SIZE=3D2>the optional distributionPoint component is =
absent.</FONT>
</P>

<P><FONT SIZE=3D2>In the cases where either:</FONT>
<BR><FONT SIZE=3D2>1.&nbsp; the CRL distribution points extension is =
absent, or</FONT>
<BR><FONT SIZE=3D2>2.&nbsp; the CRL distribution points have been =
processed, but not all revocation</FONT>
<BR><FONT SIZE=3D2>reasons have been checked,</FONT>
<BR><FONT SIZE=3D2>the software will then attempt to acquire and =
validate a complete CRL that</FONT>
<BR><FONT SIZE=3D2>covers the remaining reason codes for the type of =
cert (CA or EE).</FONT>
</P>

<P><FONT SIZE=3D2>In those cases, the software follows the X.509 rules =
specified for complete</FONT>
<BR><FONT SIZE=3D2>CRLs, since that is the type of CRL it requires -- =
not a distribution point</FONT>
<BR><FONT SIZE=3D2>CRL.&nbsp; The presence of an IDP extension in a CRL =
does not make the CRL a DP</FONT>
<BR><FONT SIZE=3D2>CRL -- even complete CRLs can contain IDP =
extensions.</FONT>
</P>

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

</BODY>
</HTML>
------_=_NextPart_001_01C1AE5B.1EEA8EF0--


Received: by above.proper.com (8.11.6/8.11.3) id g15EqLF23088 for ietf-pkix-bks; Tue, 5 Feb 2002 06:52:21 -0800 (PST)
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g15EqK323079 for <[e-mail]>; Tue, 5 Feb 2002 06:52:20 -0800 (PST)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA02058; Tue, 5 Feb 2002 09:52:18 -0500 (EST)
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-acmc-00.txt
Date: Tue, 05 Feb 2002 09:52:17 -0500
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>

--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		: Attribute Certificate Management Messages over CMS
	Author(s)	: P. Yee
	Filename	: draft-ietf-pkix-acmc-00.txt
	Pages		: 8
	Date		: 04-Feb-02
	
This document specifies modifications to the Certificate Management
Messages over CMS specification ([CMCbis]) to permit the management
of attribute certificates.  This document does not stand alone, but
must be used in conjunction with [CMCbis].  It is expected that the
modifications proposed here will also be used in conjunction with the
Attribute Certificate Request Message Format specification ([ACRMF]).

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

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

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-acmc-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-acmc-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-acmc-00.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-pkix-acmc-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.6/8.11.3) id g15EqGf23076 for ietf-pkix-bks; Tue, 5 Feb 2002 06:52:16 -0800 (PST)
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g15EqF323072 for <[e-mail]>; Tue, 5 Feb 2002 06:52:15 -0800 (PST)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA02040; Tue, 5 Feb 2002 09:52:13 -0500 (EST)
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-rfc2560bis-00.txt
Date: Tue, 05 Feb 2002 09:52:12 -0500
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>

--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		: X.509 Internet Public Key Infrastructure Online 
                          Certificate Status Protocol - OCSP
	Author(s)	: M. Myers et al.
	Filename	: draft-ietf-pkix-rfc2560bis-00.txt
	Pages		: 
	Date		: 04-Feb-02
	
This document specifies a protocol useful in determining the current
status of a digital certificate without requiring CRLs. Additional
mechanisms addressing PKIX operational requirements are specified in
separate documents.

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

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

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-rfc2560bis-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-rfc2560bis-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-rfc2560bis-00.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-pkix-rfc2560bis-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.6/8.11.3) id g15DvQo18305 for ietf-pkix-bks; Tue, 5 Feb 2002 05:57:26 -0800 (PST)
Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g15DvO318299 for <[e-mail]>; Tue, 5 Feb 2002 05:57:25 -0800 (PST)
Received: from lvt-mail.frlv.bull.fr (lvt-mail.frlv.bull.fr [129.184.62.223]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id OAA17630; Tue, 5 Feb 2002 14:58:53 +0100
Received: from bull.net (frlva3786.frlv.bull.fr [129.184.37.97]) by lvt-mail.frlv.bull.fr (8.9.2/8.9.1) with ESMTP id OAA13628; Tue, 5 Feb 2002 14:56:50 +0100
Message-ID: <[e-mail]>
Date: Tue, 05 Feb 2002 14:56:51 +0100
From: Denis Pinkas <[e-mail]>
Organization: Integris. A Bull Company
X-Mailer: Mozilla 4.7 [fr] (Win98; I)
X-Accept-Language: fr
MIME-Version: 1.0
To: Ambarish Malpani <[e-mail]>
CC: "'[e-mail]'" <[e-mail]>
Subject: Re: Candidate for moving OCSP to a Draft Standard
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>

Ambarish,

(...)

> > Three remarks:

> > 1) It would be interresting to say what happens in case an
> > OCSP request is made after the end of the validity period 
> > of a certificate.

> > nextUpdate is currently defined as: "The time at or before which 
> > newer information will be available about the status of *the* 
> > certificate".

> > If the certificate has expired, such information about *that*
> > certificate will never be available. Anyway, since the server 
> > does not necessarily have access to the end-entity certificate, 
> > then it does not even know that the certificate has expired.

> > A more appropriate definition about nextUpdate would be: "The
> > time at or before which newer status revocation information 
> > will be available from the CA which has issued the certificate".
 
> I disagree. A responder can get its information from a CA or some
> other source. Nothing in OCSP restricts or implies restrictions
> on the sources of information for a responder.

You are right, but my point was to stress the fact that the OCSP responder
may not know when newer information about the status of *the* certificate 
will be available. So a correction is needed. What about the following:

"The time at or before which newer status revocation information will be
available". 

or much longer, but still exact:

"The time at or before which newer status revocation information will be
available either from the CA who issued the certificate in question, a
Trusted Responder whose public key is trusted by the requestor, or a CA
Designated Responder (Authorized Responder) who holds a specially marked
certificate issued directly by the CA, indicating that the responder may
issue OCSP responses for that CA."

> > In addition, some guidance, in particular in the security
> > considerations section would be useful. Here is some tentative text:

> > An OCSP response does not indicate that the certificate is in
> > that thisUpdate is within the validity period of the end-entity 
> > certificate, which means that clients MUST be able to parse the 
> > end-entity certificate to interpret the validity period.
 
> This is already present in the text. Are you just asking for it
> to be re-iterated in the Security Considerations section?
> (it is in the section that explains good)

No change in the main body of the document but an addition in the Security
Considerations section to explain the implications.

Denis

(...)


Received: by above.proper.com (8.11.6/8.11.3) id g14M0fu13624 for ietf-pkix-bks; Mon, 4 Feb 2002 14:00:41 -0800 (PST)
Received: from mailf.telia.com (mailf.telia.com [194.22.194.25]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g14M0d313618 for <[e-mail]>; Mon, 4 Feb 2002 14:00:40 -0800 (PST)
Received: from arport (t2o69p100.telia.com [62.20.144.220]) by mailf.telia.com (8.11.6/8.11.6) with SMTP id g14M0dQ21536; Mon, 4 Feb 2002 23:00:39 +0100 (CET)
Message-ID: <010701c1adc7$43ce8670$0500a8c0@arport>
From: "Anders Rundgren" <[e-mail]>
To: "Hallam-Baker, Phillip" <[e-mail]>, <[e-mail]>
References: <[e-mail]>
Subject: Re: Globally unique DNs - Why?
Date: Mon, 4 Feb 2002 22:59:47 +0100
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.50.4133.2400
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
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>

Thanx Phill,
I was also hoping that this was a technically incorrect statement
[not only that it gramatically got a bit weird :-)]

We do though have a practical problem with RPs that handle certificates
from a multitude of CAs that also may issue a multitude of
certificate-types.  I.e. spanning potentially n*m disjunct (and in a few cases
shared), name-spaces.

Therefore I suggested a small XML-schema-inspired X509 "patch", in my reply
to Steve, to reduce name-space hassles a bit.

cheers,
Anders

----- Original Message ----- 
From: "Hallam-Baker, Phillip" <[e-mail]>
To: "Anders Rundgren" <[e-mail]>; <[e-mail]>
Sent: Monday, February 04, 2002 16:44
Subject: RE: Globally unique DNs - Why?


> List,
> In certain, rather "animated" discussions, the statement that an
> X509.v3 Subject DN (if specified) must be globally unique in order
> to be "conformant".

That statement is illogical.

If we have a name A that is in a subject DN and someone else decides
to use the name A then according to the statement made both DNs would
then be non-conformant.

This would mean that someone could perform a non-conformance attack on
any certificate they chose which recalls Deep Thought's ripost to 
Broomfondle "And who would that inconvenience?"

If X.400 mail was likely to suplant SMTP the issue of unique names 
would be relevant and a solution would have been found. As it is
not, no solution is needed.

Phill





Received: by above.proper.com (8.11.6/8.11.3) id g14Knr111804 for ietf-pkix-bks; Mon, 4 Feb 2002 12:49:53 -0800 (PST)
Received: from wfhqex05.gfgsi.com (netva01.getronicsgov.com [67.105.229.98]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g14Knq311800 for <[e-mail]>; Mon, 4 Feb 2002 12:49:52 -0800 (PST)
Received: by wfhqex05.gfgsi.com with Internet Mail Service (5.5.2653.19) id <D64H0ACQ>; Mon, 4 Feb 2002 15:54:20 -0500
Message-ID: <[e-mail]>
From: "Nicholas, Richard" <[e-mail]>
To: "'David A. Cooper'" <[e-mail]>, "'[e-mail]'" <[e-mail]>
Subject: RE: New-PKIX-Part1 conflict with X.509 (2000)
Date: Mon, 4 Feb 2002 15:54:18 -0500 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
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>

Dave,

See my comments below.

> The important question is not whether a CRL is complete, but 
> whether it covers the certificate of interest. On this issue, 
> I believe that PKIX and X.509 are in agreement.
> 
> The text in section 6.3.3 does not say anything about whether 
> a CRL is complete. It merely says that a CRL containing a 
> distribution point field in an IDP CRL extension covers a 
> certificate if the DP name matches the certificate issuer's name.
> 
> In X.509, section B.5.1 provides rules for determining 
> whether a certificate is covered by a CRL. If a CRL meets the 
> criteria in section B.5.1.1 (Complete CRL) then it is a 
> complete CRL and thus covers all certificates issued by the 
> CRL issuer.
> 
> If the CRL contains an IDP extension with a distribution 
> point name, then section B.5.1.4 (Distribution point based 
> CRL/EPRL/CARL) applies. This section states that if the 
> distribution point name in the IDP extension is present, it 
> must match one of the names in the distribution point or CRL 
> issuer field in the CRL DP in the certificate.
> 
> Section 8.6.2.1 in X.509 states that if the distribution 
> point name is absent from the CRL DP extension then "the 
> distribution point name defaults to the CRL issuer name". 
> Thus, under the scenario that you mentioned, an algorithm 
> that follows X.509 will accept the CRL as covering the certificate.
> 
> Dave

The text you quoted from section 8.6.2.1 in X.509 is not meant to imply that
all certs have distribution points, only to specify what name to use when
the optional distributionPoint component is absent.

In the cases where either:
1.  the CRL distribution points extension is absent, or
2.  the CRL distribution points have been processed, but not all revocation
reasons have been checked,
the software will then attempt to acquire and validate a complete CRL that
covers the remaining reason codes for the type of cert (CA or EE).

In those cases, the software follows the X.509 rules specified for complete
CRLs, since that is the type of CRL it requires -- not a distribution point
CRL.  The presence of an IDP extension in a CRL does not make the CRL a DP
CRL -- even complete CRLs can contain IDP extensions.

- Rich


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g14K5jN10569 for ietf-pkix-bks; Mon, 4 Feb 2002 12:05:45 -0800 (PST)
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 g14K5i310565 for <[e-mail]>; Mon, 4 Feb 2002 12:05:44 -0800 (PST)
Received: from CONVERSION-DAEMON by ext-mail.valicert.com (PMDF V5.2-33 #46613) id <[e-mail]> for [e-mail]; Mon, 4 Feb 2002 12:05:46 -0800 (PST)
Received: from polaris.valicert.com ([192.168.2.34]) by ext-mail.valicert.com (PMDF V5.2-33 #46613) with ESMTP id <[e-mail]>; Mon, 04 Feb 2002 12:05:45 -0800 (PST)
Received: by exchange.valicert.com with Internet Mail Service (5.5.2653.19) id <D6WG8QD2>; Mon, 04 Feb 2002 12:05:45 -0800
Content-return: allowed
Date: Mon, 04 Feb 2002 12:05:41 -0800
From: Ambarish Malpani <[e-mail]>
Subject: RE: Candidate for moving OCSP to a Draft Standard
To: "'Denis Pinkas'" <[e-mail]>
Cc: "'[e-mail]'" <[e-mail]>
Message-id: <[e-mail]>
MIME-version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-type: text/plain
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>

Hi Denis,
    Responses inline.

Ambarish

---------------------------------------------------------------------
Ambarish Malpani
Architect                                                650.567.5457
ValiCert, Inc.                                  [e-mail]
339 N. Bernardo Ave.                          http://www.valicert.com
Mountain View, CA 94043


> -----Original Message-----
> From: Denis Pinkas [mailto:[e-mail]]
> Sent: Monday, February 04, 2002 5:05 AM
> To: Ambarish Malpani
> Cc: '[e-mail]'
> Subject: Re: Candidate for moving OCSP to a Draft Standard
> 
> 
> Ambarish,
> 
> Three remarks:
> 
> 1) It would be interresting to say what happens in case an 
> OCSP request
>    is made after the end of the validity period of a certificate.
> 
> nextUpdate is currently defined as: "The time at or before which newer
> information will be available about the status of *the* certificate".
> 
> If the certificate has expired, such information about *that* 
> certificate
> will never be available. Anyway, since the server does not 
> necessarily have
> access to the end-entity certificate, then it does not even 
> know that the
> certificate has expired.
> 
> A more appropriate definition about nextUpdate would be: "The 
> time at or
> before which newer status revocation information will be 
> available from the
> CA which has issued the certificate".

I disagree. A responder can get its information from a CA or some
other source. Nothing in OCSP restricts or implies restrictions
on the sources of information for a responder.

> 
> In addition, some guidance, in particular in the security 
> considerations
> section would be useful. Here is some tentative text:
> 
> An OCSP response does not indicate that the certificate is in 
> its validity
> interval. So, it is up to the clients to make sure that thisUpdate is
> within the validity period of the end-entity certificate, 
> which means that
> clients MUST be able to parse the end-entity certificate to 
> interpret the
> validity period.

This is already present in the text. Are you just asking for it
to be re-iterated in the Security Considerations section?
(it is in the section that explains good)

> 
> 
> 2) The "good" status has always been misleading. The text says: 
> 
>    The "good" state indicates that the certificate has not 
> been revoked.
> 
> According to this definition, which is correct, an 
> unambiguous status would
> better be called: "not revoked" rather than "good".

We went through this discussion a few times around earlier. I believe
"good" has been adequately explained here. I don't see any point in
raising this topic again.

> 
> 
> 3) A typo (suppress one "is"):
> 
>    It does not indicate that the certificate was ever issued,
>    is or is in its validity interval.
> 
> should be changed into:
> 
>    It does not indicate that the certificate was ever issued,
>    or is in its validity interval.

Will fix.

> 
> 
> Denis
> 
>  
> > Hi Guys,
> >     Here is a candidate for moving OCSP to a Draft Standard. There
> > are no changes in the bytes that go across the wire - basically all
> > clarifications.
> > 
> > A list of all the changes between this document and RFC 2560 are
> > in Appendix D (reproduced here).
> > 
> > I hope we can get to the Draft Standard state before this IETF.
> > 
> > Regards,
> > Ambarish
> > 
> > Appendix D. Changes
> > 
> >    This section contains the differences in this document 
> from RFC 2560
> > 
> >    - Mention Appendix D in Section 1 and added an appendix D.
> >    - Added a paragraph in Section 1 equating a client with 
> a requestor and
> >      server with responder
> >    - Section 2.2 - clarified the explanation of good, 
> revoked and unknown
> >    - Added Section 2.8 requiring clients and responders to 
> support HTTP
> >    - Added a note at the end of section 3.2, which allows a 
> client to
> >      accept a response that provides statuses for only some of the
> >      certificates requested.
> >    - Clarified the issuerKeyHash in Section 4.1.1
> >    - Added "DER encoding of the" in the third paragraph 
> Section 4.1.2
> >    - Section 4.2.1 - clarified that the signature is on the 
> DER encoding
> >      of tbsResponseData (and not its hash)
> >    - Section 4.2.1 - specified the use of the certs field in
> >      BasicOCSPResponse
> >    - Section 4.2.1 - clarified how you compute KeyHash when 
> providing
> >      the ResponderID byKey.
> >    - Section 4.2.2.2 - removed an extra quote in point 3
> >    - Section 4.3 - Made RSA mandatory. Also changed the 
> references to
> >      point to the appropriate documents. Added the references to the
> >      References section
> >    - Section 4.4.1 - Clarified that a nonce in the request MUST be
> >    - included in the response for the response to be trusted.
> >    - Appendix A - A.1.1. - Got rid of support for GET - not 
> sure that
> >      anybody does it. It is also unclear how a server would tell a
> >      client to ever use GET in the URL specified in the AIA
> >    - Add the module tag for the ASN.1 in OCSP
> >    - Made SEQUENCE OF Certificate OPTIONAL to SEQUENCE 
> SIZE(1..MAX) of
> >      Certificate OPTIONAL in the ASN.1 defintions. The avoids the
> >      ambiguity of whether the optional sequence may be present, but
> >      with 0 elements. This was done by definining a new 
> element called
> >      Certificates, which is used. Look at the defintion of both
> >      Signature and BasicOCSPResponse.
> >    - Clarified the meaning of nextUpdate being absent (Section 2.4)
> >    - Fixed typo where we referred to id-ad-ocspSigning, to 
> reflect the
> >      correct OID - id-kp-OCSPSigning
> >    - Clarified criteria for response acceptance (Section 3.2)
> >    - Added a line in Section 5 indicating that nonces can be used to
> >      prevent prevent attacks using replays of precomputed responses
> >    - Added a paragraph in Section 5 requiring nonces to be 
> unique for
> >      replay protection
> > 
> > 
> ---------------------------------------------------------------------
> > Ambarish Malpani
> > Architect                                                
> 650.567.5457
> > ValiCert, Inc.                                  
> [e-mail]
> > 339 N. Bernardo Ave.                          
http://www.valicert.com
> Mountain View, CA 94043
> 
>
----------------------------------------------------------------------------
>                         Name: OCSP-draft-03.txt
>    OCSP-draft-03.txt    Type: Plain Text (text/plain)
>                     Encoding: quoted-printable


Received: by above.proper.com (8.11.6/8.11.3) id g14InpF07939 for ietf-pkix-bks; Mon, 4 Feb 2002 10:49:51 -0800 (PST)
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 g14Inm307932 for <[e-mail]>; Mon, 4 Feb 2002 10:49:49 -0800 (PST)
Received: from krdp2 (krdp2.ncsl.nist.gov [129.6.54.107]) by email.nist.gov (8.12.2/8.12.2) with ESMTP id g14IngwM009147; Mon, 4 Feb 2002 13:49:43 -0500 (EST)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 
Date: Mon, 04 Feb 2002 13:49:14 -0500
To: "Nicholas, Richard" <[e-mail]>, "'[e-mail]'" <[e-mail]>
From: "David A. Cooper" <[e-mail]>
Subject: Re: New-PKIX-Part1 conflict with X.509 (2000)
In-Reply-To: <[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>

Rich,

The important question is not whether a CRL is complete, but whether it covers the certificate of interest. On this issue, I believe that PKIX and X.509 are in agreement.

The text in section 6.3.3 does not say anything about whether a CRL is complete. It merely says that a CRL containing a distribution point field in an IDP CRL extension covers a certificate if the DP name matches the certificate issuer's name.

In X.509, section B.5.1 provides rules for determining whether a certificate is covered by a CRL. If a CRL meets the criteria in section B.5.1.1 (Complete CRL) then it is a complete CRL and thus covers all certificates issued by the CRL issuer.

If the CRL contains an IDP extension with a distribution point name, then section B.5.1.4 (Distribution point based CRL/EPRL/CARL) applies. This section states that if the distribution point name in the IDP extension is present, it must match one of the names in the distribution point or CRL issuer field in the CRL DP in the certificate.

Section 8.6.2.1 in X.509 states that if the distribution point name is absent from the CRL DP extension then "the distribution point name defaults to the CRL issuer name". Thus, under the scenario that you mentioned, an algorithm that follows X.509 will accept the CRL as covering the certificate.

Dave

At 12:18 PM 2/4/02 -0500, Nicholas, Richard wrote:

>All,
>
>Even though the new PKIX part 1 Internet Draft references X.509 (06/1997),
>rather than X.509 (03/2000), I wanted to point out the following conflict
>between the new PKIX part 1 text and X.509 (2000).
>
>Annex B to X.509 (2000) provides detailed CRL processing rules for
>validating CRLs prior to their use.  Specifically, for complete CRLs, Annex
>B requires the following to be true:
>
>    Issuing distribution point extension may be present; and
>    Issuing distribution point extension shall not contain
>    distribution point field;
>
>However, the algorithm used in the draft-ietf-pkix-new-part1-12.txt, section
>6.3.3, allows a distribution point field in an IDP CRL extension of a
>complete CRL as long as it matches the either the certificate issuer DN or
>one of the issuer alternative names in the cert.
>
>The result:  Software that processes complete CRLs in accordance with X.509
>(2000) will reject PKIX-compliant complete CRLs that contain distribution
>point fields in the IDP extension.
>
>Recommend the new PKIX part1 Internet Draft be updated to be consistent with
>the algorithm used in X.509 (2000).
>
>- Rich




Received: by above.proper.com (8.11.6/8.11.3) id g14HEJr04753 for ietf-pkix-bks; Mon, 4 Feb 2002 09:14:19 -0800 (PST)
Received: from wfhqex05.gfgsi.com (netva01.getronicsgov.com [67.105.229.98]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g14HEI304748 for <[e-mail]>; Mon, 4 Feb 2002 09:14:18 -0800 (PST)
Received: by wfhqex05.gfgsi.com with Internet Mail Service (5.5.2653.19) id <D64H98MY>; Mon, 4 Feb 2002 12:18:45 -0500
Message-ID: <[e-mail]>
From: "Nicholas, Richard" <[e-mail]>
To: "'[e-mail]'" <[e-mail]>
Subject: New-PKIX-Part1 conflict with X.509 (2000)
Date: Mon, 4 Feb 2002 12:18:44 -0500 
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>

All,

Even though the new PKIX part 1 Internet Draft references X.509 (06/1997),
rather than X.509 (03/2000), I wanted to point out the following conflict
between the new PKIX part 1 text and X.509 (2000).

Annex B to X.509 (2000) provides detailed CRL processing rules for
validating CRLs prior to their use.  Specifically, for complete CRLs, Annex
B requires the following to be true:

   Issuing distribution point extension may be present; and
   Issuing distribution point extension shall not contain
   distribution point field;

However, the algorithm used in the draft-ietf-pkix-new-part1-12.txt, section
6.3.3, allows a distribution point field in an IDP CRL extension of a
complete CRL as long as it matches the either the certificate issuer DN or
one of the issuer alternative names in the cert.

The result:  Software that processes complete CRLs in accordance with X.509
(2000) will reject PKIX-compliant complete CRLs that contain distribution
point fields in the IDP extension.

Recommend the new PKIX part1 Internet Draft be updated to be consistent with
the algorithm used in X.509 (2000).

- Rich
---------------------------
Richard E. Nicholas
Principal Secure Systems Engineer
Getronics Government Solutions, LLC
[e-mail]
[phone]


Received: by above.proper.com (8.11.6/8.11.3) id g14FhRE28322 for ietf-pkix-bks; Mon, 4 Feb 2002 07:43:27 -0800 (PST)
Received: from peacock.verisign.com (peacock.verisign.com [65.205.251.73]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g14FhP328318 for <[e-mail]>; Mon, 4 Feb 2002 07:43:25 -0800 (PST)
Received: from vhqpostal-gw1.verisign.com (verisign.com [65.205.251.55]) by peacock.verisign.com (8.11.3/BCH1.7.5) with ESMTP id g14FdvR01821; Mon, 4 Feb 2002 07:39:57 -0800 (PST)
Received: by vhqpostal-gw1.verisign.com with Internet Mail Service (5.5.2653.19) id <DY1RNM79>; Mon, 4 Feb 2002 07:44:21 -0800
Message-ID: <[e-mail]>
From: "Hallam-Baker, Phillip" <[e-mail]>
To: Anders Rundgren <[e-mail]>, [e-mail]
Subject: RE: Globally unique DNs - Why?
Date: Mon, 4 Feb 2002 07:44:07 -0800 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01C1AD92.C7C15050"
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>

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_000_01C1AD92.C7C15050
Content-Type: text/plain;
	charset="iso-8859-1"

> List,
> In certain, rather "animated" discussions, the statement that an
> X509.v3 Subject DN (if specified) must be globally unique in order
> to be "conformant".

That statement is illogical.

If we have a name A that is in a subject DN and someone else decides
to use the name A then according to the statement made both DNs would
then be non-conformant.

This would mean that someone could perform a non-conformance attack on
any certificate they chose which recalls Deep Thought's ripost to 
Broomfondle "And who would that inconvenience?"

If X.400 mail was likely to suplant SMTP the issue of unique names 
would be relevant and a solution would have been found. As it is
not, no solution is needed.

	Phill


------_=_NextPart_000_01C1AD92.C7C15050
Content-Type: application/octet-stream;
	name="Phillip Hallam-Baker (E-mail).vcf"
Content-Disposition: attachment;
	filename="Phillip Hallam-Baker (E-mail).vcf"

BEGIN:VCARD
VERSION:2.1
N:Hallam-Baker;Phillip
FN:Phillip Hallam-Baker (E-mail)
ORG:VeriSign
TITLE:Principal Consultant
TEL;WORK;VOICE:[phone] x227
EMAIL;PREF;INTERNET:[e-mail]
REV:20010214T163732Z
END:VCARD

------_=_NextPart_000_01C1AD92.C7C15050--


Received: by above.proper.com (8.11.6/8.11.3) id g14FR8Z27841 for ietf-pkix-bks; Mon, 4 Feb 2002 07:27:08 -0800 (PST)
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 g14FR6327832 for <[e-mail]>; Mon, 4 Feb 2002 07:27:07 -0800 (PST)
Received: from [128.89.88.34] (comsec.bbn.com [128.89.88.34]) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id KAA05717; Mon, 4 Feb 2002 10:27:01 -0500 (EST)
Mime-Version: 1.0
X-Sender: [e-mail]
Message-Id: <p05100304b88457dce802@[128.89.88.34]>
In-Reply-To: <[e-mail]>
References: <005201c1ab3d$6c5a8170$0500a8c0@arport> <p05100306b880b1c66c01@[128.89.88.34]> <000e01c1abeb$dbbbb260$0500a8c0@arport> <[e-mail]>
Date: Mon, 4 Feb 2002 10:24:45 -0500
To: jim <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: Re: Globally unique DNs - Why?
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>

At 11:06 PM -0500 2/2/02, jim wrote:
>Point of clarification.  There is a difference between the 
>Distinguished Name (DN) and the Directory Distinguished Name (DDN). 
>The DN is the X.500 naming structure that goes from the root naming 
>structure of the directory to the outer branches and leaf entry for 
>an individual or role.  In LDAP directories, the structure is still 
>used, but from the individual or role moving up to the root entry. 
>The DDN, on the other hand, is the trail of authorizations for a 
>user moving from the issuing Certification Authority up to the root 
>issuing authority, be it a Policy Approving Authority in a very 
>hierarchical structure or the chief CA in a ring set up.  My 
>experience is that confusion of the two, DN and DDN, almost always 
>leads to lack of understanding of how the system needs to work.
>Jim

Jim,

Could you cite the standard from which your definition of DDN comes? 
I have never heard that characterization before.

Steve


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g14Dngp22007 for ietf-pkix-bks; Mon, 4 Feb 2002 05:49:42 -0800 (PST)
Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g14Dnf322002 for <[e-mail]>; Mon, 4 Feb 2002 05:49:41 -0800 (PST)
Received: from lvt-mail.frlv.bull.fr (lvt-mail.frlv.bull.fr [129.184.62.223]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id OAA24502; Mon, 4 Feb 2002 14:51:09 +0100
Received: from bull.net (frlva3786.frlv.bull.fr [129.184.37.97]) by lvt-mail.frlv.bull.fr (8.9.2/8.9.1) with ESMTP id OAA18184; Mon, 4 Feb 2002 14:49:07 +0100
Message-ID: <[e-mail]>
Date: Mon, 04 Feb 2002 10:52:24 +0100
From: Denis Pinkas <[e-mail]>
Organization: Integris. A Bull Company
X-Mailer: Mozilla 4.7 [fr] (Win98; I)
X-Accept-Language: fr
MIME-Version: 1.0
To: Peter Gutmann <[e-mail]>
CC: [e-mail]
Subject: Re: TSP interop update
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>

Peter,

> Denis Pinkas <[e-mail]> writes:
> 
> >>To some extent, although you'd need to allow anyPolicy to allow the client to
> >>specify that if it can't get an exact match, anything will do.
> >
> >If anything will do, then the client does not need to request any specific
> >policy.
> 
> And how does this help if the client wants one of a set of policies, but failing
> that anything will do, as I mentioned in the original text?

You can obtain this by making two requests.

> >In a negotiation protocol, the client states what it is ready to accept and
> >mentions its order of preferences. Then the server chooses among the list.
> 
> But why this obsession with having the *server* make the decision?  

Please, avoid terms like "obsession".
 
> The *client* knows what it wants, so the client should make the decision, not 
> the server.  I'm just wondering here, is there some recommended design philosophy
> which I'm not aware of which says that the client can never make any decisions
> for itself but always has to leave it to others to make on its behalf?

Since you are wondering, a design philosophy about negotation has been
discussed at length in the CAT security working group and has lead to 
RFC 2478: 

The Simple and Protected GSS-API Negotiation Mechanism (December 1998)

Denis

 
> Peter.



Received: by above.proper.com (8.11.6/8.11.3) id g14Di5W21791 for ietf-pkix-bks; Mon, 4 Feb 2002 05:44:05 -0800 (PST)
Received: from ocasey.baltimore.com (ocasey.baltimore.com [193.41.17.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g14Di2321786 for <[e-mail]>; Mon, 4 Feb 2002 05:44:03 -0800 (PST)
Received: from Baltimore-FW1 ([172.19.1.1]) by ocasey.baltimore.com (8.11.6/8.9.3) with SMTP id g14Di3U22010 for <[e-mail]>; Mon, 4 Feb 2002 13:44:03 GMT
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]>; Mon, 4 Feb 2002 13:39:25 +0000
Received: from baltimore.ie (wks140-4.ie.baltimore.com [10.153.4.140]) by bobcat.baltimore.ie (8.9.3/8.9.3) with ESMTP id NAA28365; Mon, 4 Feb 2002 13:43:59 GMT
Message-ID: <[e-mail]>
Date: Mon, 04 Feb 2002 13:45:10 +0000
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: [e-mail]
CC: [e-mail]
Subject: Re: I-D ACTION:draft-ietf-pkix-acrmf-00.txt
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>

Peter,

Glad to see someone's picked up on this topic. Coupla initial 
comments:-

- Shouldn't this say that the ACs in question are to be conformant
  to [ACPROF]? Presumably this'd also mean that some fields in this
  spec have to obey the same profiling rules too, which sounds like
  a good idea.
- What's [ACMC] from november 2001? (Maybe its about to pop out?)
- The old LAAP protocol effectively allowed (the equivalent of) a regInfo
  value to select the "type" of AC to be produced - this draft seems to
  preclude that. Did I read it wrong or don't you think that's needed?
- Lastly, I never did come across a use case where a client would want
  to specify a really complicated AttrCertTemplate - have you? Absent
  that I'd have to say that this is maybe more complex than it needs
  to be.

Stephen.

-- 
____________________________________________________________
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 g14DPCK21188 for ietf-pkix-bks; Mon, 4 Feb 2002 05:25:12 -0800 (PST)
Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g14DPA321184 for <[e-mail]>; Mon, 4 Feb 2002 05:25:10 -0800 (PST)
Received: from lvt-mail.frlv.bull.fr (lvt-mail.frlv.bull.fr [129.184.62.223]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id OAA20596; Mon, 4 Feb 2002 14:26:38 +0100
Received: from bull.net (frlva3786.frlv.bull.fr [129.184.37.97]) by lvt-mail.frlv.bull.fr (8.9.2/8.9.1) with ESMTP id OAA13258; Mon, 4 Feb 2002 14:24:37 +0100
Message-ID: <[e-mail]>
Date: Mon, 04 Feb 2002 14:24:36 +0100
From: Denis Pinkas <[e-mail]>
Organization: Integris. A Bull Company
X-Mailer: Mozilla 4.7 [fr] (Win98; I)
X-Accept-Language: fr
MIME-Version: 1.0
To: Anders Rundgren <[e-mail]>
CC: [e-mail]
Subject: Re: Globally unique DNs - Why?
References: <005201c1ab3d$6c5a8170$0500a8c0@arport> <[e-mail]> <005501c1ab60$2382cf70$0500a8c0@arport>
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>

Anders,

> Denis,
> Note that the word *global* is completely absent from the
> document you refer to.

...  hence why I wondered to which "animated" discussions you refer to, 
where the (wrong) statement would have been made.

We are in strong agreement.

Denis

> That DNs must be unique vs a certain CA is something that it is chrystal-
> clear, but that DNs must be (by themselves) be globally unique is as far I can see
> neither a requirement for general PKIX compliency, nor for QC compliency.
> 
> Anders
> 
> >> List,
> >> In certain, rather "animated" discussions, the statement is that an
> >> X509.v3 Subject DN (if specified) must be globally unique in order
> >> to be "conformant".
> 
> >Please read section  "4.1.2.6  Subject" page 24 from
> ><draft-ietf-pkix-new-part1-12.txt>
> 
> >The DN MUST be unique for each subject entity certified by the one CA
> >as defined by the issuer name field.
> 
> >Denis


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g14D5KB19152 for ietf-pkix-bks; Mon, 4 Feb 2002 05:05:20 -0800 (PST)
Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g14D5I319143 for <[e-mail]>; Mon, 4 Feb 2002 05:05:18 -0800 (PST)
Received: from lvt-mail.frlv.bull.fr (lvt-mail.frlv.bull.fr [129.184.62.223]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id OAA19928; Mon, 4 Feb 2002 14:06:43 +0100
Received: from bull.net (frlva3786.frlv.bull.fr [129.184.37.97]) by lvt-mail.frlv.bull.fr (8.9.2/8.9.1) with ESMTP id OAA10526; Mon, 4 Feb 2002 14:04:42 +0100
Message-ID: <[e-mail]>
Date: Mon, 04 Feb 2002 14:04:41 +0100
From: Denis Pinkas <[e-mail]>
Organization: Integris. A Bull Company
X-Mailer: Mozilla 4.7 [fr] (Win98; I)
X-Accept-Language: fr
MIME-Version: 1.0
To: Ambarish Malpani <[e-mail]>
CC: "'[e-mail]'" <[e-mail]>
Subject: Re: Candidate for moving OCSP to a Draft Standard
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>

Ambarish,

Three remarks:

1) It would be interresting to say what happens in case an OCSP request
   is made after the end of the validity period of a certificate.

nextUpdate is currently defined as: "The time at or before which newer
information will be available about the status of *the* certificate".

If the certificate has expired, such information about *that* certificate
will never be available. Anyway, since the server does not necessarily have
access to the end-entity certificate, then it does not even know that the
certificate has expired.

A more appropriate definition about nextUpdate would be: "The time at or
before which newer status revocation information will be available from the
CA which has issued the certificate".

In addition, some guidance, in particular in the security considerations
section would be useful. Here is some tentative text:

An OCSP response does not indicate that the certificate is in its validity
interval. So, it is up to the clients to make sure that thisUpdate is
within the validity period of the end-entity certificate, which means that
clients MUST be able to parse the end-entity certificate to interpret the
validity period.


2) The "good" status has always been misleading. The text says: 

   The "good" state indicates that the certificate has not been revoked.

According to this definition, which is correct, an unambiguous status would
better be called: "not revoked" rather than "good".


3) A typo (suppress one "is"):

   It does not indicate that the certificate was ever issued,
   is or is in its validity interval.

should be changed into:

   It does not indicate that the certificate was ever issued,
   or is in its validity interval.


Denis

 
> Hi Guys,
>     Here is a candidate for moving OCSP to a Draft Standard. There
> are no changes in the bytes that go across the wire - basically all
> clarifications.
> 
> A list of all the changes between this document and RFC 2560 are
> in Appendix D (reproduced here).
> 
> I hope we can get to the Draft Standard state before this IETF.
> 
> Regards,
> Ambarish
> 
> Appendix D. Changes
> 
>    This section contains the differences in this document from RFC 2560
> 
>    - Mention Appendix D in Section 1 and added an appendix D.
>    - Added a paragraph in Section 1 equating a client with a requestor and
>      server with responder
>    - Section 2.2 - clarified the explanation of good, revoked and unknown
>    - Added Section 2.8 requiring clients and responders to support HTTP
>    - Added a note at the end of section 3.2, which allows a client to
>      accept a response that provides statuses for only some of the
>      certificates requested.
>    - Clarified the issuerKeyHash in Section 4.1.1
>    - Added "DER encoding of the" in the third paragraph Section 4.1.2
>    - Section 4.2.1 - clarified that the signature is on the DER encoding
>      of tbsResponseData (and not its hash)
>    - Section 4.2.1 - specified the use of the certs field in
>      BasicOCSPResponse
>    - Section 4.2.1 - clarified how you compute KeyHash when providing
>      the ResponderID byKey.
>    - Section 4.2.2.2 - removed an extra quote in point 3
>    - Section 4.3 - Made RSA mandatory. Also changed the references to
>      point to the appropriate documents. Added the references to the
>      References section
>    - Section 4.4.1 - Clarified that a nonce in the request MUST be
>    - included in the response for the response to be trusted.
>    - Appendix A - A.1.1. - Got rid of support for GET - not sure that
>      anybody does it. It is also unclear how a server would tell a
>      client to ever use GET in the URL specified in the AIA
>    - Add the module tag for the ASN.1 in OCSP
>    - Made SEQUENCE OF Certificate OPTIONAL to SEQUENCE SIZE(1..MAX) of
>      Certificate OPTIONAL in the ASN.1 defintions. The avoids the
>      ambiguity of whether the optional sequence may be present, but
>      with 0 elements. This was done by definining a new element called
>      Certificates, which is used. Look at the defintion of both
>      Signature and BasicOCSPResponse.
>    - Clarified the meaning of nextUpdate being absent (Section 2.4)
>    - Fixed typo where we referred to id-ad-ocspSigning, to reflect the
>      correct OID - id-kp-OCSPSigning
>    - Clarified criteria for response acceptance (Section 3.2)
>    - Added a line in Section 5 indicating that nonces can be used to
>      prevent prevent attacks using replays of precomputed responses
>    - Added a paragraph in Section 5 requiring nonces to be unique for
>      replay protection
> 
> ---------------------------------------------------------------------
> Ambarish Malpani
> Architect                                                650.567.5457
> ValiCert, Inc.                                  [e-mail]
> 339 N. Bernardo Ave.                          http://www.valicert.com
> Mountain View, CA 94043
> 
>   ----------------------------------------------------------------------------
>                         Name: OCSP-draft-03.txt
>    OCSP-draft-03.txt    Type: Plain Text (text/plain)
>                     Encoding: quoted-printable


Received: by above.proper.com (8.11.6/8.11.3) id g14CLu716139 for ietf-pkix-bks; Mon, 4 Feb 2002 04:21:56 -0800 (PST)
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g14CLt316135 for <[e-mail]>; Mon, 4 Feb 2002 04:21:55 -0800 (PST)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA20014; Mon, 4 Feb 2002 07:21:54 -0500 (EST)
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-scvp-07.txt
Date: Mon, 04 Feb 2002 07:21:53 -0500
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>

--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		: Simple Certificate Validation Protocol (SCVP)
	Author(s)	: A. Malpani, R. Housley, T. Freeman
	Filename	: draft-ietf-pkix-scvp-07.txt
	Pages		: 
	Date		: 01-Feb-02
	
The SCVP protocol allows a client to offload certificate handling to a
server. The server can give a variety of valuable information about
the certificate, such as whether or not the certificate is valid, a
certification path to a trust anchor, and so on. SCVP has many
purposes, including simplifying client implementations and allowing
companies to centralize their trust and policy management.

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

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

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-scvp-07.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-scvp-07.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-scvp-07.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-pkix-scvp-07.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.6/8.11.3) id g14CLpI16131 for ietf-pkix-bks; Mon, 4 Feb 2002 04:21:51 -0800 (PST)
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g14CLo316125 for <[e-mail]>; Mon, 4 Feb 2002 04:21:50 -0800 (PST)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA19996; Mon, 4 Feb 2002 07:21:48 -0500 (EST)
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-acrmf-00.txt
Date: Mon, 04 Feb 2002 07:21:48 -0500
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>

--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		: Attribute Certificate Request Message Format
	Author(s)	: P. Yee
	Filename	: draft-ietf-pkix-acrmf-00.txt
	Pages		: 9
	Date		: 01-Feb-02
	
The Certificate Request Message Format ([CRMF]) specifies a format
for requesting an X.509 public key certificate from a Certification
Authority (CA), possibly with assistance from an Local Registration
Authority (LRA).  This specification, ACRMF, is modeled on CRMF,
extending similar functionality to requests for X.509 attribute cer-
tificates from Attribute Authorities (AA), possibly via an Attribute
Registration Authority (ARA).

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

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

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-acrmf-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-acrmf-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-acrmf-00.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-pkix-acrmf-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.6/8.11.3) id g147n2s16377 for ietf-pkix-bks; Sun, 3 Feb 2002 23:49:02 -0800 (PST)
Received: from phnxpop8.phnx.uswest.net (phnxpop8.phnx.uswest.net [206.80.192.8]) by above.proper.com (8.11.6/8.11.3) with SMTP id g147n1316369 for <[e-mail]>; Sun, 3 Feb 2002 23:49:01 -0800 (PST)
Received: (qmail 98945 invoked by uid 0); 4 Feb 2002 07:48:59 -0000
Received: from vdsl-130-13-82-32.phnx.uswest.net (HELO ?192.168.2.12?) (130.13.82.32) by phnxpop8.phnx.uswest.net with SMTP; 4 Feb 2002 07:48:59 -0000
Date: Mon, 4 Feb 2002 00:48:41 -0700
Message-Id: <a05100303b883e57f339d@[192.168.2.12]>
From: "Hoyt L. Kesterson II" <[e-mail]>
To: "X.509": ;
Mime-Version: 1.0
X-Sender: [e-mail]
Subject: X.509 working documents and defect reports on the server
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>

Hello all

The directory group will be meeting 27 February - 3 March 2002 in Geneva. We will be continuing looking at the enhancements proposed in the current working. It is on the server in Word and PDF at

  ftp://ftp.bull.com/pub/OSIdirectory/Flagstaff2001Output/6N12093CertEnhancement3rdWD.pdf  and
  ftp://ftp.bull.com/pub/OSIdirectory/Flagstaff2001Output/6N12093CertEnhancement3rdWD.doc

There are some unofficial, i.e. not yet submitted by standards organization, Canadian comments on the WD at

  ftp://ftp.bull.com/pub/OSIdirectory/Geneva2002/Input/UnofficialCdnCommentOn509WD.pdf



The ballot on DTC-3 to the 4th (2000) edition of X.509/8584-8 has closed. The ballot comments, which will be resolved in Geneva, can be found at

  ftp://ftp.bull.com/pub/OSIdirectory/Geneva2002/Input/WorkbookSovX.509DTC-3%284th%29.pdf

The DTC itself was previously announced.. It can be found in Word and PDF at

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

The ballot period on DTC-11 to the 3rd edition of X.509 and DTC-4 to the 4th edition will close 27 February 2002. We will resolve any ballot comments at the Geneva meeting. Those DTCs in Word and PDF can be found at

ftp://ftp.bull.com/pub/OSIdirectory/DefectResolution/DraftTechnicalCorrigenda/closing26Feb2002/6N12079X.509DTC-11%283rd%29.pdf
ftp://ftp.bull.com/pub/OSIdirectory/DefectResolution/DraftTechnicalCorrigenda/closing26Feb2002/6N12079X.509DTC-11%283rd%29.doc
ftp://ftp.bull.com/pub/OSIdirectory/DefectResolution/DraftTechnicalCorrigenda/closing26Feb2002/6N12078X.509DTC-4%284th%29.pdf
ftp://ftp.bull.com/pub/OSIdirectory/DefectResolution/DraftTechnicalCorrigenda/closing26Feb2002/6N12078X.509DTC-4%284th%29.doc

The Defect Reports being corrected by these DTCs can be found at

  ftp://ftp.bull.com/pub/OSIdirectory/DefectResolution/DefectReports/X.509andRelated/DR_284.pdf
  ftp://ftp.bull.com/pub/OSIdirectory/DefectResolution/DefectReports/X.509andRelated/DR_285.pdf 
  ftp://ftp.bull.com/pub/OSIdirectory/DefectResolution/DefectReports/X.509andRelated/DR_286.pdf

A new Defect Report, DR 289, will be examined at the Geneva meeting. It can be found at

  ftp://ftp.bull.com/pub/OSIdirectory/DefectResolution/DefectReports/X.509andRelated/DR_289.pdf


Comments on these documents should be sent to me and Sharon Boeyen

   hoyt



   


Received: by above.proper.com (8.11.6/8.11.3) id g147blj14495 for ietf-pkix-bks; Sun, 3 Feb 2002 23:37:47 -0800 (PST)
Received: from relay1.trustworks.com (zuka.trustworks.com [212.114.5.147]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g147bh314478; Sun, 3 Feb 2002 23:37:44 -0800 (PST)
Received: by relay1.trustworks.com (8.8.5/1.14) id KAA27484; Mon, 4 Feb 2002 10:37:28 +0300 (MSK)
Message-Id: <[e-mail]>
Received: from localhost(127.0.0.1) by zuka via smap (V2.0) id xma027461; Mon, 4 Feb 02 10:37:14 +0300
From: "Valery Smyslov" <[e-mail]>
Organization: TWS
To: Paul Hoffman / IMC <[e-mail]>, Dr S N Henson <[e-mail]>
Date: Mon, 4 Feb 2002 10:37:25 +0300
MIME-Version: 1.0
Content-type: text/plain; charset=US-ASCII
Content-transfer-encoding: 7BIT
Subject: Re: I-D ACTION:draft-ietf-pkix-okid-00.txt
CC: Jean-Marc Desperrier <[e-mail]>, [e-mail]
In-reply-to: <[e-mail]>
X-mailer: Pegasus Mail for Win32 (v3.12b)
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>

On 2 Feb 02, at 0:35, Dr S N Henson wrote:

> Paul Hoffman / IMC wrote:
> >
> > Mallory does *not* need to change the public key in an OCID: he can
> > change any value in the certificate to get the right hash.
>
> I think the OCID would be the whole certificate including the digital
> signature. If the client checks the signature that would mean that any
> changes to the signed portion would require the signature to be
> recalculated.

I also think so.

> However as Peter pointed out if the unsigned portion of the certificate
> does not need to be DER encoded then all manner of ASN1 variations could
> be tried without the need to recalculate the signature. These could
> include...
>
> Changing some SEQUENCEs to use indefinite length constructed encoding.
>
> Modifying the encoding of the signature to use lots of constructed
> encoding variations. That by itself is enough if the decoder will
> tolerate it because the BER allow a BIT STRING to be partitioned into
> arbitrary chunks to arbitrary depths IIRC.

This problem is easy to avoid by requiring OCID hash to be always
produced only over DER-encoded certificates. In this case all other-
encoded certificates must be unambiguously reencoded (into DER)
before calculating OCID.

Regards,
Smyslov Valery.

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




Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g13NAtl26576 for ietf-pkix-bks; Sun, 3 Feb 2002 15:10:55 -0800 (PST)
Received: from mail.cablespeed.com ([216.45.96.99]) by above.proper.com (8.11.6/8.11.3) with SMTP id g13NAs326572 for <[e-mail]>; Sun, 3 Feb 2002 15:10:54 -0800 (PST)
Received: (qmail 13910 invoked by uid 0); 3 Feb 2002 23:10:51 -0000
Received: from unknown (HELO cablespeed.com) (216.45.82.31) by mail.cablespeed.com with SMTP; 3 Feb 2002 23:10:51 -0000
Message-ID: <[e-mail]>
Date: Sun, 03 Feb 2002 18:13:16 -0500
From: jim <[e-mail]>
X-Mailer: Mozilla 4.73 [en] (Windows NT 5.0; I)
X-Accept-Language: en
MIME-Version: 1.0
To: Anders Rundgren <[e-mail]>
CC: [e-mail]
Subject: Re: Globally unique DNs - Why?
References: <005201c1ab3d$6c5a8170$0500a8c0@arport> <p05100306b880b1c66c01@[128.89.88.34]> <000e01c1abeb$dbbbb260$0500a8c0@arport> <[e-mail]> <001901c1ac7d$57907920$0500a8c0@arport>
Content-Type: multipart/alternative; boundary="------------DED226EAC051AFF6F54925B2"
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>

--------------DED226EAC051AFF6F54925B2
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Anders,
    The DN is used to find the person in the directory service so that the
electronic path to the recipient (the X.400 address) can be discerned.  The DDN
is used when checking to ensure that the certificate is valid, so I am not sure
that it has much to do with the name-space confusion, but it is used as part of
the validation process overall.  In that regard, globally unique DNs will
enhance the ability of the DDN to be completely accurate.
Jim

Anders Rundgren wrote:

>  Jim,Thanx for the information regarding DDNs!  Pardon an ignorant question:
> Does DDNs in effect set the name-spaces so that the aforementioned name-space
> contamination (Steve's Lotus Notes problem) does not occur?  I.e. there is
> actually no problem to solve using one of the method suggested?  Outside of
> the LDAP-world, I can testify that DN name-space confusion is indeed a serious
> problem, particularly in conjunction with non-directory-oriented
> applications.  It gets particularly bad when a single CA-cert/key is used to
> sign certificates belonging to different name-spaces and entity-types
> (commercial CAs usually don't do that, protecting them from this short-coming
> in the X509 system).  Using globally unique DNs there would be no naming
> problems, but as I tried to show, that may not be a very realistic
> option. Anders
>
>      ----- Original Message -----
>      From: jim
>      To: Anders Rundgren
>      Cc: Stephen Kent ; [e-mail]
>      Sent: Sunday, February 03, 2002 05:06
>      Subject: Re: Globally unique DNs - Why?
>       Point of clarification.  There is a difference between the
>      Distinguished Name (DN) and the Directory Distinguished Name (DDN).
>      The DN is the X.500 naming structure that goes from the root naming
>      structure of the directory to the outer branches and leaf entry for
>      an individual or role.  In LDAP directories, the structure is still
>      used, but from the individual or role moving up to the root entry.
>      The DDN, on the other hand, is the trail of authorizations for a
>      user moving from the issuing Certification Authority up to the root
>      issuing authority, be it a Policy Approving Authority in a very
>      hierarchical structure or the chief CA in a ring set up.  My
>      experience is that confusion of the two, DN and DDN, almost always
>      leads to lack of understanding of how the system needs to work.
>      Jim
>
>      Anders Rundgren wrote:
>
>     > Steve,
>     >
>     >      DNs are directory distinguished names, formally. the
>     >      directory tie-in implies that a DN sequence represents a
>     >      path in a directory tree structure. X.500 assumes a
>     >      universal tree, the DIT, and thus a DN consistent with
>     >      the semantics of X.500 would be globally unique. The DIT
>     >      is not a reality, and probably will never be, but one
>     >      can still note considerable advantages to DNs that are
>     >      globally unique.  No syntactic requirement in X.500
>     >      mandates such uniqueness, any more than it mandates
>     >      common sense re what directory attributes can be used in
>     >      forming a DN. It is certainly legitimate to construct
>     >      private directory trees that would not produce globally
>     >      unique DNs. but, experience with other name spaces
>     >      (e.g., Lotus Notes name spaces) has shown that often
>     >      what was assumed to be "private" ultimately becomes more
>     >      widely connected, and the collisions that arise due to a
>     >      lack of effort to attempt to ensure global uniqueness
>     >      come back to haunt system designers/administrators.
>     >
>     >      Steve
>     >
>     >      P.S.  I don't know from which end the example DN above
>     >      is intended to be read, but either direction yields a
>     >      pretty odd graph :-)
>     >
>     > Actually it was a little bit incorrect, as C=SE has recently been
>     > skipped, so now it is just CN=Name, serialNumber=nnnnn.  I.e. the
>     > DN became even more "private".  But one could also rightfully
>     > claim that a redundant DN item has been removed, as the
>     > certificate anyway requires knowledge of the regime (name-space)
>     > it was issued in. Although there are advantages with globally
>     > unique DNs, IMHO the number of drawbacks outnumber the
>     > advantages.  To name a few of those drawbacks:
>     >
>     >    * It probably requires something close to socialism to
>     >      establish such strictly conforming CAs
>     >    * It is in conflict with commercial disjunct name-spaces (e.g.
>     >      DUNS, VISA etc.)
>     >    * It may expose information that you not want to have in public
>     >    * And last but not least, it leads to a fragile ID-structure,
>     >      as the global schemes typically are based on a multitude of
>     >      attributes used to identify a subject, and if any of these
>     >      change, the link to the subject is broken.  This is in
>     >      contrast to my citizen-ID that is relevant as long as I stay
>     >      a Swedish citizen.  If the CA had been a commercial CA using
>     >      a private name-space, the ID could very well survive changes
>     >      in citizenship, name, and sex (there is a gender-tag in our
>     >      citizen-IDs so transsexuals find them less useful...).
>     >
>     > But as PKI except for web-server certificates, is just a long-time
>     > promise, both views are equally valid at this stage. I do though
>     > see a need for a possible PKIX work-item to support this multi
>     > name-space, "anarchistic" type of PKI, and that is a way for CAs
>     > to specify what private (or public), name-space their issued DNs
>     > belong to.  That would preferably be a URI, like for XML Schemas.
>     > Without such a specifier, we may indeed some day, get the Lotus
>     > Notes problem you referred to.  PIs is one way to achieve this,
>     > but I'm talking about a more neutral scheme as not everyone likes
>     > PIs. cheers,Anders
>

--------------DED226EAC051AFF6F54925B2
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit

<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
<body bgcolor="#FFFFFF">
Anders,
<br>&nbsp;&nbsp;&nbsp; The DN is used to find the person in the directory
service so that the electronic path to the recipient (the X.400 address)
can be discerned.&nbsp; The DDN is used when checking to ensure that the
certificate is valid, so I am not sure that it has much to do with the
name-space confusion, but it is used as part of the validation process
overall.&nbsp; In that regard, globally unique DNs will enhance the ability
of the DDN to be completely accurate.
<br>Jim
<p>Anders Rundgren wrote:
<blockquote TYPE=CITE>&nbsp;<font face="Arial"><font size=-1>Jim,</font></font><font face="Arial"><font size=-1>Thanx
for the information regarding DDNs!&nbsp; Pardon an ignorant question:
Does DDNs in effect set the name-spaces so that the aforementioned name-space
contamination (Steve's Lotus Notes problem) does not occur?&nbsp; I.e.
there is actually no problem to solve using one of the method suggested?&nbsp;
Outside of the LDAP-world, I can testify that DN name-space confusion is
indeed a serious problem, particularly in conjunction with non-directory-oriented
applications.&nbsp; It gets particularly bad when a single CA-cert/key
is used to sign certificates belonging to different name-spaces and entity-types
(commercial CAs usually don't do that, protecting them from this short-coming
in the X509 system).&nbsp; Using globally unique DNs there would be no
naming problems, but as I tried to show, that may not be a very realistic
option.</font></font>&nbsp;<font face="Arial"><font size=-1>Anders</font></font>
<blockquote 
style="BORDER-LEFT: #000000 2px solid; MARGIN-LEFT: 5px; MARGIN-RIGHT: 0px; PADDING-LEFT: 5px; PADDING-RIGHT: 0px">
<div style="FONT: 10pt arial">----- Original Message -----</div>

<div 
  style="BACKGROUND: #e4e4e4; FONT: 10pt arial; font-color: black"><b>From:</b>
<a href="mailto:[e-mail]" title="[e-mail]">jim</a></div>

<div style="FONT: 10pt arial"><b>To:</b> <a href="mailto:[e-mail]" title="[e-mail]">Anders
Rundgren</a></div>

<div style="FONT: 10pt arial"><b>Cc:</b> <a href="mailto:[e-mail]" title="[e-mail]">Stephen
Kent</a> ; <a href="mailto:[e-mail]" title="[e-mail]">[e-mail]</a></div>

<div style="FONT: 10pt arial"><b>Sent:</b> Sunday, February 03, 2002 05:06</div>

<div style="FONT: 10pt arial"><b>Subject:</b> Re: Globally unique DNs -
Why?</div>
&nbsp;Point of clarification.&nbsp; There is a difference between the Distinguished
Name (DN) and the Directory Distinguished Name (DDN).&nbsp; The DN is the
X.500 naming structure that goes from the root naming structure of the
directory to the outer branches and leaf entry for an individual or role.&nbsp;
In LDAP directories, the structure is still used, but from the individual
or role moving up to the root entry.&nbsp; The DDN, on the other hand,
is the trail of authorizations for a user moving from the issuing Certification
Authority up to the root issuing authority, be it a Policy Approving Authority
in a very hierarchical structure or the chief CA in a ring set up.&nbsp;
My experience is that confusion of the two, DN and DDN, almost always leads
to lack of understanding of how the system needs to work.
<br>Jim
<p>Anders Rundgren wrote:
<blockquote TYPE="CITE"><style type=text/css></style>
<font face="Arial"><font size=-1>Steve,</font></font>
<blockquote style="MARGIN-RIGHT: 0px"><font face="Arial"><font color="#008080"><font size=-1>DNs
are directory distinguished names, formally. the directory tie-in implies
that a DN sequence represents a path in a directory tree structure. X.500
assumes a universal tree, the DIT, and thus a DN consistent with the semantics
of X.500 would be globally unique. The DIT is not a reality, and probably
will never be, but one can still note considerable advantages to DNs that
are globally unique.&nbsp; No syntactic requirement in X.500 mandates such
uniqueness, any more than it mandates common sense re what directory attributes
can be used in forming a DN. It is certainly legitimate to construct private
directory trees that would not produce globally unique DNs. but, experience
with other name spaces (e.g., Lotus Notes name spaces) has shown that often
what was assumed to be "private" ultimately becomes more widely connected,
and the collisions that arise due to a lack of effort to attempt to ensure
global uniqueness come back to haunt system designers/administrators.</font></font></font>
<p><font face="Arial"><font color="#008080"><font size=-1>Steve</font></font></font>
<p><font face="Arial"><font color="#008080"><font size=-1>P.S.&nbsp; I
don't know from which end the example DN above is intended to be read,
but either direction yields a pretty odd graph :-)</font></font></font></blockquote>
<font face="Arial"><font size=-1>Actually it was a little bit incorrect,
as C=SE has recently been skipped, so now it is just CN=<i>Name</i>, serialNumber=<i>nnnnn.&nbsp;
I.e. the DN became even more "private".&nbsp; </i>But one could also rightfully
claim that a <i>redundant </i>DN item has been removed, as the certificate
anyway requires knowledge of the regime (name-space) it was issued in.</font></font>
<font face="Arial"><font size=-1>Although there are advantages with globally
unique DNs, IMHO the number of drawbacks outnumber the advantages.&nbsp;
To name a few of those drawbacks:</font></font>
<ul>
<li>
<font face="Arial"><font size=-1>It probably requires something close to
socialism to establish such strictly conforming CAs</font></font></li>

<li>
<font face="Arial"><font size=-1>It is in conflict with commercial disjunct
name-spaces (e.g. DUNS, VISA etc.)</font></font></li>

<li>
<font face="Arial"><font size=-1>It may expose information that you not
want to have in public</font></font></li>

<li>
<font face="Arial"><font size=-1>And last but not least, it leads to a
<i>fragile </i>ID-structure, as the global schemes typically are based
on a multitude of attributes used to identify a subject, and if any of
these change, <i>the link to the subject is broken</i>.&nbsp; This is in
contrast to my citizen-ID that is relevant as long as I stay a Swedish
citizen.&nbsp; If the CA had been a commercial CA using a private name-space,
the ID could very well survive changes in citizenship, name, and sex (there
is a gender-tag in our citizen-IDs so transsexuals find them less useful...).</font></font></li>
</ul>
<font face="Arial"><font size=-1>But as PKI except for web-server certificates,
is just a long-time promise, <i>both views are equally valid at this stage</i>.
I do though see a need for a possible PKIX work-item to support this multi
name-space, "anarchistic" type of PKI, and that is a way for CAs to specify
what private (or public), name-space their issued DNs belong to.&nbsp;
That would preferably be a URI, like for <i>XML Schemas.&nbsp; Without
such a specifier, we may indeed some day, get the Lotus Notes problem you
referred to</i>.&nbsp; PIs is one way to achieve this, but I'm talking
about a more neutral scheme as not everyone likes PIs.</font></font>&nbsp;<font face="Arial"><font size=-1>cheers,</font></font><font face="Arial"><font size=-1>Anders</font></font></blockquote>
</blockquote>
</blockquote>

</body>
</html>

--------------DED226EAC051AFF6F54925B2--



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g136cwi02653 for ietf-pkix-bks; Sat, 2 Feb 2002 22:38:58 -0800 (PST)
Received: from mailc.telia.com (mailc.telia.com [194.22.190.4]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g136cu302648 for <[e-mail]>; Sat, 2 Feb 2002 22:38:57 -0800 (PST)
Received: from arport (t4o69p104.telia.com [62.20.145.224]) by mailc.telia.com (8.11.6/8.11.6) with SMTP id g136csU15146; Sun, 3 Feb 2002 07:38:54 +0100 (CET)
Message-ID: <001901c1ac7d$57907920$0500a8c0@arport>
From: "Anders Rundgren" <[e-mail]>
To: "jim" <[e-mail]>, "Stephen Kent" <[e-mail]>, <[e-mail]>
References: <005201c1ab3d$6c5a8170$0500a8c0@arport> <p05100306b880b1c66c01@[128.89.88.34]> <000e01c1abeb$dbbbb260$0500a8c0@arport> <[e-mail]>
Subject: Re: Globally unique DNs - Why?
Date: Sun, 3 Feb 2002 07:38:06 +0100
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0016_01C1AC85.B7FFFF80"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
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>

This is a multi-part message in MIME format.

------=_NextPart_000_0016_01C1AC85.B7FFFF80
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Jim,
Thanx for the information regarding DDNs!  Pardon an ignorant question: =
Does DDNs in effect set the name-spaces so that the aforementioned =
name-space contamination (Steve's Lotus Notes problem) does not occur?  =
I.e. there is actually no problem to solve using one of the method =
suggested?  Outside of the LDAP-world, I can testify that DN name-space =
confusion is indeed a serious problem, particularly in conjunction with =
non-directory-oriented applications.  It gets particularly bad when a =
single CA-cert/key is used to sign certificates belonging to different =
name-spaces and entity-types (commercial CAs usually don't do that, =
protecting them from this short-coming in the X509 system).  Using =
globally unique DNs there would be no naming problems, but as I tried to =
show, that may not be a very realistic option.

Anders
  ----- Original Message -----=20
  From: jim=20
  To: Anders Rundgren=20
  Cc: Stephen Kent ; [e-mail]=20
  Sent: Sunday, February 03, 2002 05:06
  Subject: Re: Globally unique DNs - Why?


  Point of clarification.  There is a difference between the =
Distinguished Name (DN) and the Directory Distinguished Name (DDN).  The =
DN is the X.500 naming structure that goes from the root naming =
structure of the directory to the outer branches and leaf entry for an =
individual or role.  In LDAP directories, the structure is still used, =
but from the individual or role moving up to the root entry.  The DDN, =
on the other hand, is the trail of authorizations for a user moving from =
the issuing Certification Authority up to the root issuing authority, be =
it a Policy Approving Authority in a very hierarchical structure or the =
chief CA in a ring set up.  My experience is that confusion of the two, =
DN and DDN, almost always leads to lack of understanding of how the =
system needs to work.=20
  Jim=20
  Anders Rundgren wrote:=20

    Steve,=20
      DNs are directory distinguished names, formally. the directory =
tie-in implies that a DN sequence represents a path in a directory tree =
structure. X.500 assumes a universal tree, the DIT, and thus a DN =
consistent with the semantics of X.500 would be globally unique. The DIT =
is not a reality, and probably will never be, but one can still note =
considerable advantages to DNs that are globally unique.  No syntactic =
requirement in X.500 mandates such uniqueness, any more than it mandates =
common sense re what directory attributes can be used in forming a DN. =
It is certainly legitimate to construct private directory trees that =
would not produce globally unique DNs. but, experience with other name =
spaces (e.g., Lotus Notes name spaces) has shown that often what was =
assumed to be "private" ultimately becomes more widely connected, and =
the collisions that arise due to a lack of effort to attempt to ensure =
global uniqueness come back to haunt system designers/administrators.=20
      Steve=20

      P.S.  I don't know from which end the example DN above is intended =
to be read, but either direction yields a pretty odd graph :-)

    Actually it was a little bit incorrect, as C=3DSE has recently been =
skipped, so now it is just CN=3DName, serialNumber=3Dnnnnn.  I.e. the DN =
became even more "private".  But one could also rightfully claim that a =
redundant DN item has been removed, as the certificate anyway requires =
knowledge of the regime (name-space) it was issued in. Although there =
are advantages with globally unique DNs, IMHO the number of drawbacks =
outnumber the advantages.  To name a few of those drawbacks:=20
      a.. It probably requires something close to socialism to establish =
such strictly conforming CAs=20
      b.. It is in conflict with commercial disjunct name-spaces (e.g. =
DUNS, VISA etc.)=20
      c.. It may expose information that you not want to have in public=20
      d.. And last but not least, it leads to a fragile ID-structure, as =
the global schemes typically are based on a multitude of attributes used =
to identify a subject, and if any of these change, the link to the =
subject is broken.  This is in contrast to my citizen-ID that is =
relevant as long as I stay a Swedish citizen.  If the CA had been a =
commercial CA using a private name-space, the ID could very well survive =
changes in citizenship, name, and sex (there is a gender-tag in our =
citizen-IDs so transsexuals find them less useful...).=20
    But as PKI except for web-server certificates, is just a long-time =
promise, both views are equally valid at this stage. I do though see a =
need for a possible PKIX work-item to support this multi name-space, =
"anarchistic" type of PKI, and that is a way for CAs to specify what =
private (or public), name-space their issued DNs belong to.  That would =
preferably be a URI, like for XML Schemas.  Without such a specifier, we =
may indeed some day, get the Lotus Notes problem you referred to.  PIs =
is one way to achieve this, but I'm talking about a more neutral scheme =
as not everyone likes PIs.

    cheers,
    Anders

------=_NextPart_000_0016_01C1AC85.B7FFFF80
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META content=3D"text/html; charset=3Diso-8859-1" =
http-equiv=3DContent-Type>
<META content=3D"MSHTML 5.00.3103.1000" name=3DGENERATOR></HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2>Jim,</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>Thanx for the information regarding =
DDNs!&nbsp;=20
Pardon an ignorant question: Does DDNs in effect set the name-spaces so =
that the=20
aforementioned name-space contamination&nbsp;(Steve's Lotus Notes =
problem) does=20
not occur?&nbsp; I.e. there is&nbsp;actually no problem to solve using =
one=20
of&nbsp;the method suggested?&nbsp; Outside of the LDAP-world, I can =
testify=20
that DN name-space confusion is indeed a serious problem, particularly =
in=20
conjunction with non-directory-oriented applications.&nbsp; It gets =
particularly=20
bad when a single CA-cert/key is used to sign certificates belonging to=20
different name-spaces and entity-types (commercial CAs usually don't do =
that,=20
protecting them&nbsp;from this short-coming in the X509 system).&nbsp; =
Using=20
globally unique DNs there would be no naming problems, but as I tried to =

show,&nbsp;that may not be a very realistic option.</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>Anders</FONT></DIV>
<BLOCKQUOTE=20
style=3D"BORDER-LEFT: #000000 2px solid; MARGIN-LEFT: 5px; MARGIN-RIGHT: =
0px; PADDING-LEFT: 5px; PADDING-RIGHT: 0px">
  <DIV style=3D"FONT: 10pt arial">----- Original Message ----- </DIV>
  <DIV=20
  style=3D"BACKGROUND: #e4e4e4; FONT: 10pt arial; font-color: =
black"><B>From:</B>=20
  <A href=3D"mailto:[e-mail]" =
title=[e-mail]>jim</A>=20
  </DIV>
  <DIV style=3D"FONT: 10pt arial"><B>To:</B> <A=20
  href=3D"mailto:[e-mail]" =
title=[e-mail]>Anders=20
  Rundgren</A> </DIV>
  <DIV style=3D"FONT: 10pt arial"><B>Cc:</B> <A =
href=3D"mailto:[e-mail]"=20
  title=[e-mail]>Stephen Kent</A> ; <A =
href=3D"mailto:[e-mail]"=20
  title=[e-mail]>[e-mail]</A> </DIV>
  <DIV style=3D"FONT: 10pt arial"><B>Sent:</B> Sunday, February 03, 2002 =

  05:06</DIV>
  <DIV style=3D"FONT: 10pt arial"><B>Subject:</B> Re: Globally unique =
DNs -=20
  Why?</DIV>
  <DIV><BR></DIV>Point of clarification.&nbsp; There is a difference =
between the=20
  Distinguished Name (DN) and the Directory Distinguished Name =
(DDN).&nbsp; The=20
  DN is the X.500 naming structure that goes from the root naming =
structure of=20
  the directory to the outer branches and leaf entry for an individual =
or=20
  role.&nbsp; In LDAP directories, the structure is still used, but from =
the=20
  individual or role moving up to the root entry.&nbsp; The DDN, on the =
other=20
  hand, is the trail of authorizations for a user moving from the =
issuing=20
  Certification Authority up to the root issuing authority, be it a =
Policy=20
  Approving Authority in a very hierarchical structure or the chief CA =
in a ring=20
  set up.&nbsp; My experience is that confusion of the two, DN and DDN, =
almost=20
  always leads to lack of understanding of how the system needs to work. =
<BR>Jim=20

  <P>Anders Rundgren wrote:=20
  <BLOCKQUOTE TYPE=3D"CITE">
    <STYLE type=3Dtext/css></STYLE>
    <FONT face=3DArial><FONT size=3D-1>Steve,</FONT></FONT>=20
    <BLOCKQUOTE style=3D"MARGIN-RIGHT: 0px"><FONT face=3DArial><FONT=20
      color=3D#008080><FONT size=3D-1>DNs are directory distinguished =
names,=20
      formally. the directory tie-in implies that a DN sequence =
represents a=20
      path in a directory tree structure. X.500 assumes a universal =
tree, the=20
      DIT, and thus a DN consistent with the semantics of X.500 would be =

      globally unique. The DIT is not a reality, and probably will never =
be, but=20
      one can still note considerable advantages to DNs that are =
globally=20
      unique.&nbsp; No syntactic requirement in X.500 mandates such =
uniqueness,=20
      any more than it mandates common sense re what directory =
attributes can be=20
      used in forming a DN. It is certainly legitimate to construct =
private=20
      directory trees that would not produce globally unique DNs. but,=20
      experience with other name spaces (e.g., Lotus Notes name spaces) =
has=20
      shown that often what was assumed to be "private" ultimately =
becomes more=20
      widely connected, and the collisions that arise due to a lack of =
effort to=20
      attempt to ensure global uniqueness come back to haunt system=20
      designers/administrators.</FONT></FONT></FONT>=20
      <P><FONT face=3DArial><FONT color=3D#008080><FONT=20
      size=3D-1>Steve</FONT></FONT></FONT>=20
      <P><FONT face=3DArial><FONT color=3D#008080><FONT =
size=3D-1>P.S.&nbsp; I don't=20
      know from which end the example DN above is intended to be read, =
but=20
      either direction yields a pretty odd graph=20
    :-)</FONT></FONT></FONT></P></BLOCKQUOTE><FONT face=3DArial><FONT=20
    size=3D-1>Actually it was a little bit incorrect, as C=3DSE has =
recently been=20
    skipped, so now it is just CN=3D<I>Name</I>, =
serialNumber=3D<I>nnnnn.&nbsp; I.e.=20
    the DN became even more "private".&nbsp; </I>But one could also =
rightfully=20
    claim that a <I>redundant </I>DN item has been removed, as the =
certificate=20
    anyway requires knowledge of the regime (name-space) it was issued=20
    in.</FONT></FONT>&nbsp;<FONT face=3DArial><FONT size=3D-1>Although =
there are=20
    advantages with globally unique DNs, IMHO the number of drawbacks =
outnumber=20
    the advantages.&nbsp; To name a few of those =
drawbacks:</FONT></FONT>=20
    <UL>
      <LI><FONT face=3DArial><FONT size=3D-1>It probably requires =
something close to=20
      socialism to establish such strictly conforming CAs</FONT></FONT>=20
      <LI><FONT face=3DArial><FONT size=3D-1>It is in conflict with =
commercial=20
      disjunct name-spaces (e.g. DUNS, VISA etc.)</FONT></FONT>=20
      <LI><FONT face=3DArial><FONT size=3D-1>It may expose information =
that you not=20
      want to have in public</FONT></FONT>=20
      <LI><FONT face=3DArial><FONT size=3D-1>And last but not least, it =
leads to a=20
      <I>fragile </I>ID-structure, as the global schemes typically are =
based on=20
      a multitude of attributes used to identify a subject, and if any =
of these=20
      change, <I>the link to the subject is broken</I>.&nbsp; This is in =

      contrast to my citizen-ID that is relevant as long as I stay a =
Swedish=20
      citizen.&nbsp; If the CA had been a commercial CA using a private=20
      name-space, the ID could very well survive changes in citizenship, =
name,=20
      and sex (there is a gender-tag in our citizen-IDs so transsexuals =
find=20
      them less useful...).</FONT></FONT> </LI></UL>
    <DIV><FONT face=3DArial><FONT size=3D-1>But as PKI except for =
web-server=20
    certificates, is just a long-time promise, <I>both views are equally =
valid=20
    at this stage</I>. I do though see a need for a possible PKIX =
work-item to=20
    support this multi name-space, "anarchistic" type of PKI, and that =
is a way=20
    for CAs to specify what private (or public), name-space their issued =
DNs=20
    belong to.&nbsp; That would preferably be a URI, like for <I>XML=20
    Schemas.&nbsp; Without such a specifier, we may indeed some day, get =
the=20
    Lotus Notes problem you referred to</I>.&nbsp; PIs is one way to =
achieve=20
    this, but I'm talking about a more neutral scheme as not everyone =
likes=20
    PIs.</FONT></FONT><FONT face=3DArial><FONT =
size=3D-1></FONT></FONT></DIV>
    <DIV><FONT face=3DArial><FONT size=3D-1></FONT></FONT>&nbsp;</DIV>
    <DIV><FONT face=3DArial><FONT size=3D-1>cheers,</FONT></FONT><FONT=20
    face=3DArial><FONT size=3D-1></FONT></FONT></DIV>
    <DIV><FONT face=3DArial><FONT=20
size=3D-1>Anders</FONT></FONT></DIV></BLOCKQUOTE></BLOCKQUOTE></BODY></HT=
ML>

------=_NextPart_000_0016_01C1AC85.B7FFFF80--



Received: by above.proper.com (8.11.6/8.11.3) id g135l2U01690 for ietf-pkix-bks; Sat, 2 Feb 2002 21:47:02 -0800 (PST)
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 g135l0301686 for <[e-mail]>; Sat, 2 Feb 2002 21:47:00 -0800 (PST)
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 SAA19207; Sun, 3 Feb 2002 18:46:58 +1300 (NZDT) (sender [e-mail])
Received: (from pgut001@localhost) by ruru.cs.auckland.ac.nz (8.9.3/8.8.6/cs-slave) id SAA516953; Sun, 3 Feb 2002 18:46:57 +1300 (NZDT) (sender [e-mail])
Date: Sun, 3 Feb 2002 18:46:57 +1300 (NZDT)
Message-ID: <[e-mail]>
From: [e-mail] (Peter Gutmann)
To: [e-mail], [e-mail]
Subject: Re: TSP interop update
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>

Denis Pinkas <[e-mail]> writes:

>>To some extent, although you'd need to allow anyPolicy to allow the client to
>>specify that if it can't get an exact match, anything will do.
>
>If anything will do, then the client does not need to request any specific
>policy.

And how does this help if the client wants one of a set of policies, but failing
that anything will do, as I mentioned in the original text?

>In a negotiation protocol, the client states what it is ready to accept and
>mentions its order of preferences. Then the server chooses among the list.

But why this obsession with having the *server* make the decision?  The
*client* knows what it wants, so the client should make the decision, not the
server.  I'm just wondering here, is there some recommended design philosophy
which I'm not aware of which says that the client can never make any decisions
for itself but always has to leave it to others to make on its behalf?

Peter.



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g1344QU29945 for ietf-pkix-bks; Sat, 2 Feb 2002 20:04:26 -0800 (PST)
Received: from mail.cablespeed.com ([216.45.96.99]) by above.proper.com (8.11.6/8.11.3) with SMTP id g1344P329940 for <[e-mail]>; Sat, 2 Feb 2002 20:04:25 -0800 (PST)
Received: (qmail 25212 invoked by uid 0); 3 Feb 2002 04:04:13 -0000
Received: from unknown (HELO cablespeed.com) (216.45.82.31) by mail.cablespeed.com with SMTP; 3 Feb 2002 04:04:13 -0000
Message-ID: <[e-mail]>
Date: Sat, 02 Feb 2002 23:06:37 -0500
From: jim <[e-mail]>
X-Mailer: Mozilla 4.73 [en] (Windows NT 5.0; I)
X-Accept-Language: en
MIME-Version: 1.0
To: Anders Rundgren <[e-mail]>
CC: Stephen Kent <[e-mail]>, [e-mail]
Subject: Re: Globally unique DNs - Why?
References: <005201c1ab3d$6c5a8170$0500a8c0@arport> <p05100306b880b1c66c01@[128.89.88.34]> <000e01c1abeb$dbbbb260$0500a8c0@arport>
Content-Type: multipart/alternative; boundary="------------C5C009F38AE20A6DD84D7857"
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>

--------------C5C009F38AE20A6DD84D7857
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Point of clarification.  There is a difference between the Distinguished Name
(DN) and the Directory Distinguished Name (DDN).  The DN is the X.500 naming
structure that goes from the root naming structure of the directory to the outer
branches and leaf entry for an individual or role.  In LDAP directories, the
structure is still used, but from the individual or role moving up to the root
entry.  The DDN, on the other hand, is the trail of authorizations for a user
moving from the issuing Certification Authority up to the root issuing
authority, be it a Policy Approving Authority in a very hierarchical structure
or the chief CA in a ring set up.  My experience is that confusion of the two,
DN and DDN, almost always leads to lack of understanding of how the system needs
to work.
Jim

Anders Rundgren wrote:

> Steve,
>
>      DNs are directory distinguished names, formally. the directory
>      tie-in implies that a DN sequence represents a path in a directory
>      tree structure. X.500 assumes a universal tree, the DIT, and thus a
>      DN consistent with the semantics of X.500 would be globally unique.
>      The DIT is not a reality, and probably will never be, but one can
>      still note considerable advantages to DNs that are globally unique.
>      No syntactic requirement in X.500 mandates such uniqueness, any more
>      than it mandates common sense re what directory attributes can be
>      used in forming a DN. It is certainly legitimate to construct
>      private directory trees that would not produce globally unique DNs.
>      but, experience with other name spaces (e.g., Lotus Notes name
>      spaces) has shown that often what was assumed to be "private"
>      ultimately becomes more widely connected, and the collisions that
>      arise due to a lack of effort to attempt to ensure global uniqueness
>      come back to haunt system designers/administrators.
>
>      Steve
>
>      P.S.  I don't know from which end the example DN above is intended
>      to be read, but either direction yields a pretty odd graph :-)
>
> Actually it was a little bit incorrect, as C=SE has recently been skipped, so
> now it is just CN=Name, serialNumber=nnnnn.  I.e. the DN became even more
> "private".  But one could also rightfully claim that a redundant DN item has
> been removed, as the certificate anyway requires knowledge of the regime
> (name-space) it was issued in. Although there are advantages with globally
> unique DNs, IMHO the number of drawbacks outnumber the advantages.  To name a
> few of those drawbacks:
>
>    * It probably requires something close to socialism to establish such
>      strictly conforming CAs
>    * It is in conflict with commercial disjunct name-spaces (e.g. DUNS, VISA
>      etc.)
>    * It may expose information that you not want to have in public
>    * And last but not least, it leads to a fragile ID-structure, as the global
>      schemes typically are based on a multitude of attributes used to identify
>      a subject, and if any of these change, the link to the subject is
>      broken.  This is in contrast to my citizen-ID that is relevant as long as
>      I stay a Swedish citizen.  If the CA had been a commercial CA using a
>      private name-space, the ID could very well survive changes in
>      citizenship, name, and sex (there is a gender-tag in our citizen-IDs so
>      transsexuals find them less useful...).
>
> But as PKI except for web-server certificates, is just a long-time promise,
> both views are equally valid at this stage. I do though see a need for a
> possible PKIX work-item to support this multi name-space, "anarchistic" type
> of PKI, and that is a way for CAs to specify what private (or public),
> name-space their issued DNs belong to.  That would preferably be a URI, like
> for XML Schemas.  Without such a specifier, we may indeed some day, get the
> Lotus Notes problem you referred to.  PIs is one way to achieve this, but I'm
> talking about a more neutral scheme as not everyone likes PIs. cheers,Anders

--------------C5C009F38AE20A6DD84D7857
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit

<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
<body bgcolor="#FFFFFF">
Point of clarification.&nbsp; There is a difference between the Distinguished
Name (DN) and the Directory Distinguished Name (DDN).&nbsp; The DN is the
X.500 naming structure that goes from the root naming structure of the
directory to the outer branches and leaf entry for an individual or role.&nbsp;
In LDAP directories, the structure is still used, but from the individual
or role moving up to the root entry.&nbsp; The DDN, on the other hand,
is the trail of authorizations for a user moving from the issuing Certification
Authority up to the root issuing authority, be it a Policy Approving Authority
in a very hierarchical structure or the chief CA in a ring set up.&nbsp;
My experience is that confusion of the two, DN and DDN, almost always leads
to lack of understanding of how the system needs to work.
<br>Jim
<p>Anders Rundgren wrote:
<blockquote TYPE=CITE><style type=text/css></style>
<font face="Arial"><font size=-1>Steve,</font></font>
<blockquote style="MARGIN-RIGHT: 0px"><font face="Arial"><font color="#008080"><font size=-1>DNs
are directory distinguished names, formally. the directory tie-in implies
that a DN sequence represents a path in a directory tree structure. X.500
assumes a universal tree, the DIT, and thus a DN consistent with the semantics
of X.500 would be globally unique. The DIT is not a reality, and probably
will never be, but one can still note considerable advantages to DNs that
are globally unique.&nbsp; No syntactic requirement in X.500 mandates such
uniqueness, any more than it mandates common sense re what directory attributes
can be used in forming a DN. It is certainly legitimate to construct private
directory trees that would not produce globally unique DNs. but, experience
with other name spaces (e.g., Lotus Notes name spaces) has shown that often
what was assumed to be "private" ultimately becomes more widely connected,
and the collisions that arise due to a lack of effort to attempt to ensure
global uniqueness come back to haunt system designers/administrators.</font></font></font>
<p><font face="Arial"><font color="#008080"><font size=-1>Steve</font></font></font>
<p><font face="Arial"><font color="#008080"><font size=-1>P.S.&nbsp; I
don't know from which end the example DN above is intended to be read,
but either direction yields a pretty odd graph :-)</font></font></font></blockquote>
<font face="Arial"><font size=-1>Actually it was a little bit incorrect,
as C=SE has recently been skipped, so now it is just CN=<i>Name</i>, serialNumber=<i>nnnnn.&nbsp;
I.e. the DN became even more "private".&nbsp; </i>But one could also rightfully
claim that a <i>redundant </i>DN item has been removed, as the certificate
anyway requires knowledge of the regime (name-space) it was issued in.</font></font>&nbsp;<font face="Arial"><font size=-1>Although
there are advantages with globally unique DNs, IMHO the number of drawbacks
outnumber the advantages.&nbsp; To name a few of those drawbacks:</font></font>
<ul>
<li>
<font face="Arial"><font size=-1>It probably requires something close to
socialism to establish such strictly conforming CAs</font></font></li>

<li>
<font face="Arial"><font size=-1>It is in conflict with commercial disjunct
name-spaces (e.g. DUNS, VISA etc.)</font></font></li>

<li>
<font face="Arial"><font size=-1>It may expose information that you not
want to have in public</font></font></li>

<li>
<font face="Arial"><font size=-1>And last but not least, it leads to a
<i>fragile </i>ID-structure, as the global schemes typically are based
on a multitude of attributes used to identify a subject, and if any of
these change, <i>the link to the subject is broken</i>.&nbsp; This is in
contrast to my citizen-ID that is relevant as long as I stay a Swedish
citizen.&nbsp; If the CA had been a commercial CA using a private name-space,
the ID could very well survive changes in citizenship, name, and sex (there
is a gender-tag in our citizen-IDs so transsexuals find them less useful...).</font></font></li>
</ul>
<font face="Arial"><font size=-1>But as PKI except for web-server certificates,
is just a long-time promise, <i>both views are equally valid at this stage</i>.
I do though see a need for a possible PKIX work-item to support this multi
name-space, "anarchistic" type of PKI, and that is a way for CAs to specify
what private (or public), name-space their issued DNs belong to.&nbsp;
That would preferably be a URI, like for <i>XML Schemas.&nbsp; Without
such a specifier, we may indeed some day, get the Lotus Notes problem you
referred to</i>.&nbsp; PIs is one way to achieve this, but I'm talking
about a more neutral scheme as not everyone likes PIs.</font></font>&nbsp;<font face="Arial"><font size=-1>cheers,</font></font><font face="Arial"><font size=-1>Anders</font></font></blockquote>

</body>
</html>

--------------C5C009F38AE20A6DD84D7857--



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g12DHXF12363 for ietf-pkix-bks; Sat, 2 Feb 2002 05:17:33 -0800 (PST)
Received: from mailf.telia.com (mailf.telia.com [194.22.194.25]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g12DHV312358 for <[e-mail]>; Sat, 2 Feb 2002 05:17:32 -0800 (PST)
Received: from arport (t7o69p93.telia.com [213.65.46.93]) by mailf.telia.com (8.11.6/8.11.6) with SMTP id g12DHRM25207; Sat, 2 Feb 2002 14:17:28 +0100 (CET)
Message-ID: <000e01c1abeb$dbbbb260$0500a8c0@arport>
From: "Anders Rundgren" <[e-mail]>
To: "Stephen Kent" <[e-mail]>
Cc: <[e-mail]>
References: <005201c1ab3d$6c5a8170$0500a8c0@arport> <p05100306b880b1c66c01@[128.89.88.34]>
Subject: Re: Globally unique DNs - Why?
Date: Sat, 2 Feb 2002 14:16:41 +0100
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_000B_01C1ABF4.3C530C10"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
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>

This is a multi-part message in MIME format.

------=_NextPart_000_000B_01C1ABF4.3C530C10
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Re: Globally unique DNs - Why?Steve,
  DNs are directory distinguished names, formally. the directory tie-in =
implies that a DN sequence represents a path in a directory tree =
structure. X.500 assumes a universal tree, the DIT, and thus a DN =
consistent with the semantics of X.500 would be globally unique. The DIT =
is not a reality, and probably will never be, but one can still note =
considerable advantages to DNs that are globally unique.  No syntactic =
requirement in X.500 mandates such uniqueness, any more than it mandates =
common sense re what directory attributes can be used in forming a DN. =
It is certainly legitimate to construct private directory trees that =
would not produce globally unique DNs. but, experience with other name =
spaces (e.g., Lotus Notes name spaces) has shown that often what was =
assumed to be "private" ultimately becomes more widely connected, and =
the collisions that arise due to a lack of effort to attempt to ensure =
global uniqueness come back to haunt system designers/administrators.

  Steve

  P.S.  I don't know from which end the example DN above is intended to =
be read, but either direction yields a pretty odd graph :-)
Actually it was a little bit incorrect, as C=3DSE has recently been =
skipped, so now it is just CN=3DName, serialNumber=3Dnnnnn.  I.e. the DN =
became even more "private".  But one could also rightfully claim that a =
redundant DN item has been removed, as the certificate anyway requires =
knowledge of the regime (name-space) it was issued in.

Although there are advantages with globally unique DNs, IMHO the number =
of drawbacks outnumber the advantages.  To name a few of those =
drawbacks:
  a.. It probably requires something close to socialism to establish =
such strictly conforming CAs
  b.. It is in conflict with commercial disjunct name-spaces (e.g. DUNS, =
VISA etc.)
  c.. It may expose information that you not want to have in public
  d.. And last but not least, it leads to a fragile ID-structure, as the =
global schemes typically are based on a multitude of attributes used to =
identify a subject, and if any of these change, the link to the subject =
is broken.  This is in contrast to my citizen-ID that is relevant as =
long as I stay a Swedish citizen.  If the CA had been a commercial CA =
using a private name-space, the ID could very well survive changes in =
citizenship, name, and sex (there is a gender-tag in our citizen-IDs so =
transsexuals find them less useful...).
But as PKI except for web-server certificates, is just a long-time =
promise, both views are equally valid at this stage. I do though see a =
need for a possible PKIX work-item to support this multi name-space, =
"anarchistic" type of PKI, and that is a way for CAs to specify what =
private (or public), name-space their issued DNs belong to.  That would =
preferably be a URI, like for XML Schemas.  Without such a specifier, we =
may indeed some day, get the Lotus Notes problem you referred to.  PIs =
is one way to achieve this, but I'm talking about a more neutral scheme =
as not everyone likes PIs.

cheers,
Anders

------=_NextPart_000_000B_01C1ABF4.3C530C10
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD><TITLE>Re: Globally unique DNs - Why?</TITLE>
<META content=3D"text/html; charset=3Diso-8859-1" =
http-equiv=3DContent-Type>
<STYLE type=3Dtext/css></STYLE>

<META content=3D"MSHTML 5.00.3103.1000" name=3DGENERATOR></HEAD>
<BODY background=3D"" bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2>Steve,</FONT></DIV>
<BLOCKQUOTE style=3D"MARGIN-RIGHT: 0px">
  <DIV><FONT color=3D#008080 face=3DArial size=3D2>DNs are directory =
distinguished=20
  names, formally. the directory tie-in implies that a DN sequence =
represents a=20
  path in a directory tree structure. X.500 assumes a universal tree, =
the DIT,=20
  and thus a DN consistent with the semantics of X.500 would be globally =
unique.=20
  The DIT is not a reality, and probably will never be, but one can =
still note=20
  considerable advantages to DNs that are globally unique.&nbsp; No =
syntactic=20
  requirement in X.500 mandates such uniqueness, any more than it =
mandates=20
  common sense re what directory attributes can be used in forming a DN. =
It is=20
  certainly legitimate to construct private directory trees that would =
not=20
  produce globally unique DNs. but, experience with other name spaces =
(e.g.,=20
  Lotus Notes name spaces) has shown that often what was assumed to be =
"private"=20
  ultimately becomes more widely connected, and the collisions that =
arise due to=20
  a lack of effort to attempt to ensure global uniqueness come back to =
haunt=20
  system designers/administrators.<BR><BR>Steve<BR><BR>P.S.&nbsp; I =
don't know=20
  from which end the example DN above is intended to be read, but either =

  direction yields a pretty odd graph :-)</FONT></DIV></BLOCKQUOTE>
<DIV><FONT face=3DArial size=3D2>Actually it was a little bit incorrect, =
as C=3DSE has=20
recently been skipped, so now it is just CN=3D<EM>Name</EM>,=20
serialNumber=3D<EM>nnnnn.&nbsp; I.e. the DN&nbsp;became even=20
more&nbsp;"private".&nbsp; </EM>But one could also rightfully claim that =
a=20
<EM>redundant </EM>DN item&nbsp;has been removed, as the certificate =
anyway=20
requires knowledge of the regime (name-space) it was issued =
in.</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>Although there are&nbsp;advantages with =
globally=20
unique DNs, IMHO&nbsp;the number of drawbacks outnumber the =
advantages.&nbsp; To=20
name a few of those drawbacks:</FONT></DIV>
<UL>
  <LI><FONT face=3DArial size=3D2>It probably requires something close =
to socialism=20
  to establish such strictly conforming CAs</FONT></LI>
  <LI><FONT face=3DArial size=3D2>It is in conflict with&nbsp;commercial =
disjunct=20
  name-spaces (e.g. DUNS, VISA etc.)</FONT></LI>
  <LI><FONT face=3DArial size=3D2>It may expose information that you not =
want to=20
  have in public</FONT></LI>
  <LI><FONT face=3DArial size=3D2>And last but not least, it leads to a =
<EM>fragile=20
  </EM>ID-structure, as the global schemes typically are based on a =
multitude of=20
  attributes used to identify a subject, and if any of these change, =
<EM>the=20
  link to the subject is broken</EM>.&nbsp; This is in contrast to my =
citizen-ID=20
  that is relevant as long as I stay a Swedish citizen.&nbsp; If the CA =
had been=20
  a commercial CA using a private name-space, the ID could very well =
survive=20
  changes in citizenship,&nbsp;name, and sex (there is a gender-tag in =
our=20
  citizen-IDs so transsexuals find them less =
useful...).</FONT></LI></UL>
<DIV><FONT face=3DArial size=3D2>But as PKI except for web-server =
certificates, is=20
just a long-time promise, <EM>both views are equally valid at this=20
stage</EM>.&nbsp;I do though see a need for a possible PKIX work-item to =
support=20
this multi name-space, "anarchistic" type of PKI, and that is a way for =
CAs to=20
specify what private (or public), name-space their issued DNs belong =
to.&nbsp;=20
That would preferably be a URI, like for <EM>XML =
Schemas.&nbsp;&nbsp;Without=20
such a specifier, we may indeed some day, get the Lotus Notes problem =
you=20
referred to</EM>.&nbsp; PIs is one way to achieve this, but I'm talking =
about a=20
more neutral scheme as not everyone likes PIs.</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>cheers,</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>Anders</FONT></DIV></BODY></HTML>

------=_NextPart_000_000B_01C1ABF4.3C530C10--



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g120f6023561 for ietf-pkix-bks; Fri, 1 Feb 2002 16:41:06 -0800 (PST)
Received: from anchor-post-32.mail.demon.net (anchor-post-32.mail.demon.net [194.217.242.90]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g120f5323556 for <[e-mail]>; Fri, 1 Feb 2002 16:41:05 -0800 (PST)
Received: from drh-consultancy.demon.co.uk ([193.237.150.98] helo=gemplus.com) by anchor-post-32.mail.demon.net with esmtp (Exim 2.12 #1) id 16WoEt-000Nor-0W; Sat, 2 Feb 2002 00:41:07 +0000
Message-ID: <[e-mail]>
Date: Sat, 02 Feb 2002 00:39:21 +0000
From: Dr S N Henson <[e-mail]>
X-Mailer: Mozilla 4.79 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Jean-Marc Desperrier <[e-mail]>
CC: [e-mail]
Subject: Re: I-D ACTION:draft-ietf-pkix-okid-00.txt
References: <[e-mail]> <[e-mail]> <p05101360b87f4f6e63ee@[165.227.249.20]> <[e-mail]> <p05101404b87f9917a7aa@[165.227.249.20]> <[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>

Jean-Marc Desperrier wrote:
> 
> 
> Still a few remarks.
> Mallory does not  need a strong key.
> He only needs a key that's OK enough to be used in the RSA algorithm without
> fatal errors.
> That might mean he can speed up the generation process.
> 

As I indicated in another message the RSA key generation process can be
speeded up so that all that is needed is to look up primes from a large
table and calculate their product.

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



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g120f5g23557 for ietf-pkix-bks; Fri, 1 Feb 2002 16:41:05 -0800 (PST)
Received: from anchor-post-32.mail.demon.net (anchor-post-32.mail.demon.net [194.217.242.90]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g120f3323549; Fri, 1 Feb 2002 16:41:03 -0800 (PST)
Received: from drh-consultancy.demon.co.uk ([193.237.150.98] helo=gemplus.com) by anchor-post-32.mail.demon.net with esmtp (Exim 2.12 #1) id 16WoEq-000Niw-0W; Sat, 2 Feb 2002 00:41:05 +0000
Message-ID: <[e-mail]>
Date: Sat, 02 Feb 2002 00:35:39 +0000
From: Dr S N Henson <[e-mail]>
X-Mailer: Mozilla 4.79 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Paul Hoffman / IMC <[e-mail]>
CC: Jean-Marc Desperrier <[e-mail]>, [e-mail]
Subject: Re: I-D ACTION:draft-ietf-pkix-okid-00.txt
References: <[e-mail]> <[e-mail]> <p05101360b87f4f6e63ee@[165.227.249.20]> <[e-mail]> <p05101404b87f9917a7aa@[165.227.249.20]>
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>

Paul Hoffman / IMC wrote:
> 
> Mallory does *not* need to change the public key in an OCID: he can
> change any value in the certificate to get the right hash.
> 

I think the OCID would be the whole certificate including the digital
signature. If the client checks the signature that would mean that any
changes to the signed portion would require the signature to be
recalculated.

However as Peter pointed out if the unsigned portion of the certificate
does not need to be DER encoded then all manner of ASN1 variations could
be tried without the need to recalculate the signature. These could
include...

Changing some SEQUENCEs to use indefinite length constructed encoding.

Modifying the encoding of the signature to use lots of constructed
encoding variations. That by itself is enough if the decoder will
tolerate it because the BER allow a BIT STRING to be partitioned into
arbitrary chunks to arbitrary depths IIRC.

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




Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g11L9eA17262 for ietf-pkix-bks; Fri, 1 Feb 2002 13:09:40 -0800 (PST)
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 g11L9c317258 for <[e-mail]>; Fri, 1 Feb 2002 13:09:38 -0800 (PST)
Received: from [128.89.88.34] (comsec.bbn.com [128.89.88.34]) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id QAA17915; Fri, 1 Feb 2002 16:09:29 -0500 (EST)
Mime-Version: 1.0
X-Sender: [e-mail]
Message-Id: <p05100306b880b1c66c01@[128.89.88.34]>
In-Reply-To: <005201c1ab3d$6c5a8170$0500a8c0@arport>
References: <005201c1ab3d$6c5a8170$0500a8c0@arport>
Date: Fri, 1 Feb 2002 16:07:25 -0500
To: "Anders Rundgren" <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: Re: Globally unique DNs - Why?
Cc: <[e-mail]>
Content-Type: multipart/alternative; boundary="============_-1199524659==_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>

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

At 5:27 PM +0100 2/1/02, Anders Rundgren wrote:
>List,
>In certain, rather "animated" discussions, the statement that an
>X509.v3 Subject DN (if specified) must be globally unique in order
>to be "conformant".
>
>In my view this is not the case.  Referring to my own "citizen-ID"
>with a DN like
>
>      CN=Anders Rundgren, C=SE, serialNumber=nnnnnnnnnnnnnn
>
>which indeed have been created by "PKIX-aware" people, I
>would not call that a globally unique name.
>
>It is unique within its own name-space which happens to be Swedish
>citizen numbers but without that knowledge it could equally well
>be a member certificate of a more obscure community.
>
>But, and that the important thing, it is still a globally unique name
>when using the CA as a name-space indicator.
>
>Anders Rundgren

DNs are directory distinguished names, formally. the directory tie-in 
implies that a DN sequence represents a path in a directory tree 
structure. X.500 assumes a universal tree, the DIT, and thus a DN 
consistent with the semantics of X.500 would be globally unique. The 
DIT is not a reality, and probably will never be, but one can still 
note considerable advantages to DNs that are globally unique.  No 
syntactic requirement in X.500 mandates such uniqueness, any more 
than it mandates common sense re what directory attributes can be 
used in forming a DN. It is certainly legitimate to construct private 
directory trees that would not produce globally unique DNs. but, 
experience with other name spaces (e.g., Lotus Notes name spaces) has 
shown that often what was assumed to be "private" ultimately becomes 
more widely connected, and the collisions that arise due to a lack of 
effort to attempt to ensure global uniqueness come back to haunt 
system designers/administrators.

Steve

P.S.  I don't know from which end the example DN above is intended to 
be read, but either direction yields a pretty odd graph :-)
--============_-1199524659==_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 { padding-top: 0 ; padding-bottom: 0 }
 --></style><title>Re: Globally unique DNs - Why?</title></head><body>
<div>At 5:27 PM +0100 2/1/02, Anders Rundgren wrote:</div>
<blockquote type="cite" cite>List,<br>
In certain, rather &quot;animated&quot; discussions, the statement
that an<br>
X509.v3 Subject DN (if specified) must be globally unique in order<br>
to be &quot;conformant&quot;.<br>
<br>
In my view this is not the case.&nbsp; Referring to my own
&quot;citizen-ID&quot;<br>
with a DN like<br>
<br>
&nbsp;&nbsp;&nbsp;&nbsp; CN=Anders Rundgren, C=SE,
serialNumber=nnnnnnnnnnnnnn<br>
<br>
which indeed have been created by &quot;PKIX-aware&quot; people, I<br>
would not call that a globally unique name.<br>
<br>
It is unique within its own name-space which happens to be Swedish<br>
citizen numbers but without that knowledge it could equally well<br>
be a member certificate of a more obscure community.<br>
<br>
But, and that the important thing, it is still a globally unique
name<br>
when using the CA as a name-space indicator.<br>
<br>
Anders Rundgren</blockquote>
<div><br></div>
<div>DNs are<u> directory</u> distinguished names, formally. the
directory tie-in implies that a DN sequence represents a path in a
directory tree structure. X.500 assumes a universal tree, the DIT, and
thus a DN consistent with the semantics of X.500 would be globally
unique. The DIT is not a reality, and probably will never be, but one
can still note considerable advantages to DNs that are globally
unique.&nbsp; No syntactic requirement in X.500 mandates such
uniqueness, any more than it mandates common sense re what directory
attributes can be used in forming a DN. It is certainly legitimate to
construct private directory trees that would not produce globally
unique DNs. but, experience with other name spaces (e.g., Lotus Notes
name spaces) has shown that often what was assumed to be
&quot;private&quot; ultimately becomes more widely connected, and the
collisions that arise due to a lack of effort to attempt to ensure
global uniqueness come back to haunt system
designers/administrators.</div>
<div><br></div>
<div>Steve</div>
<div><br></div>
<div>P.S.&nbsp; I don't know from which end the example DN above is
intended to be read, but either direction yields a pretty odd graph
:-)</div>
</body>
</html>
--============_-1199524659==_ma============--


Received: by above.proper.com (8.11.6/8.11.3) id g11KbKf16330 for ietf-pkix-bks; Fri, 1 Feb 2002 12:37:20 -0800 (PST)
Received: from mailb.telia.com (mailb.telia.com [194.22.194.6]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g11KbJ316326 for <[e-mail]>; Fri, 1 Feb 2002 12:37:19 -0800 (PST)
Received: from arport (t3o69p93.telia.com [62.20.145.93]) by mailb.telia.com (8.11.6/8.11.6) with SMTP id g11KbJ427060; Fri, 1 Feb 2002 21:37:19 +0100 (CET)
Message-ID: <005501c1ab60$2382cf70$0500a8c0@arport>
From: "Anders Rundgren" <[e-mail]>
To: "Denis Pinkas" <[e-mail]>
Cc: <[e-mail]>
References: <005201c1ab3d$6c5a8170$0500a8c0@arport> <[e-mail]>
Subject: Re: Globally unique DNs - Why?
Date: Fri, 1 Feb 2002 21:36:33 +0100
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.50.4133.2400
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
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>

Denis,
Note that the word *global* is completely absent from the
document you refer to.

That DNs must be unique vs a certain CA is something that it is chrystal-
clear, but that DNs must be (by themselves) be globally unique is as far I can see
neither a requirement for general PKIX compliency, nor for QC compliency.

Anders

>> List,
>> In certain, rather "animated" discussions, the statement is that an
>> X509.v3 Subject DN (if specified) must be globally unique in order
>> to be "conformant".

>Please read section  "4.1.2.6  Subject" page 24 from 
><draft-ietf-pkix-new-part1-12.txt>

>The DN MUST be unique for each subject entity certified by the one CA 
>as defined by the issuer name field.

>Denis




Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g11JO8b14089 for ietf-pkix-bks; Fri, 1 Feb 2002 11:24:08 -0800 (PST)
Received: from [165.227.249.20] (165-227-249-20.client.dsl.net [165.227.249.20]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g11JO6314085 for <[e-mail]>; Fri, 1 Feb 2002 11:24:06 -0800 (PST)
Mime-Version: 1.0
X-Sender: [e-mail]
Message-Id: <p05101416b8809aecac0d@[165.227.249.20]>
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]>	 <p05101360b87f4f6e63ee@[165.227.249.20]> <[e-mail]> <p05101404b87f9917a7aa@[165.227.249.20]> <[e-mail]>
Date: Fri, 1 Feb 2002 11:24:06 -0800
To: [e-mail]
From: Paul Hoffman / IMC <[e-mail]>
Subject: Re: I-D ACTION:draft-ietf-pkix-okid-00.txt
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>

At 8:01 PM +0100 2/1/02, Jean-Marc Desperrier wrote:
>Mallory does not  need a strong key.
>He only needs a key that's OK enough to be used in the RSA algorithm without
>fatal errors.
>That might mean he can speed up the generation process.

If so, such exploits would make Mallory's job easier. However, can 
creating 2^79 weak RSA public keys ever be faster than computing 2^79 
SHA-1 hashes over a small message? That is the balance between 
choosing OKID and OCID.

--Paul Hoffman, Director
--Internet Mail Consortium


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g11J1Ck13410 for ietf-pkix-bks; Fri, 1 Feb 2002 11:01:12 -0800 (PST)
Received: from carbone.certplus.com ([195.101.88.81]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g11J1B313405 for <[e-mail]>; Fri, 1 Feb 2002 11:01:11 -0800 (PST)
Received: from certplus.com ([192.168.212.27]) by carbone.certplus.com with Microsoft SMTPSVC(5.0.2195.2966); Fri, 1 Feb 2002 20:01:18 +0100
Message-ID: <[e-mail]>
Date: Fri, 01 Feb 2002 20:01:17 +0100
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: I-D ACTION:draft-ietf-pkix-okid-00.txt
References: <[e-mail]> <[e-mail]> <p05101360b87f4f6e63ee@[165.227.249.20]> <[e-mail]> <p05101404b87f9917a7aa@[165.227.249.20]>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 01 Feb 2002 19:01:18.0825 (UTC) FILETIME=[D4C23590:01C1AB52]
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>

Paul Hoffman / IMC wrote:

> At 12:28 AM +0100 2/1/02, Jean-Marc Desperrier wrote:
> >Clearly  if finding a collision does not suffice for Mallory in the
> >first case,
> >but that he has to find a collision for valid data, in that case a
> >valid key, then
> >in the second case, he also has to find a collision for valid data,
> >therefore a
> >valid certificate.
> Mallory does *not* need to change the public key in an OCID: he can
> change any value in the certificate to get the right hash.

Right, my reasonning was wrong.

Still a few remarks.
Mallory does not  need a strong key.
He only needs a key that's OK enough to be used in the RSA algorithm without
fatal errors.
That might mean he can speed up the generation process.

If the value of the hash is cleverly calculated on the signature and excludes
non-signed parts, Mallory will have to sign the certificate before
calculating the hash.

This would have to be checked in details before being sure there's that much
speed difference between the two processes.




Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g11IsNh13259 for ietf-pkix-bks; Fri, 1 Feb 2002 10:54:23 -0800 (PST)
Received: from mail-out.secaron.de (druss.secaron.de [195.145.99.123]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g11IsL313255 for <[e-mail]>; Fri, 1 Feb 2002 10:54:21 -0800 (PST)
Received: by mail-out.secaron.de (Postfix, from userid 0) id B926651F27; Fri,  1 Feb 2002 19:54:17 +0100 (MET)
Received: from druss.secaron.de (localhost [127.0.0.1]) by mail-out.secaron.de (Postfix) with ESMTP id 4F50E32574 for <[e-mail]>; Fri,  1 Feb 2002 19:54:17 +0100 (MET)
Received: from marvin.munich.secaron.de (marvin.munich.secaron.de [192.168.1.20]) by druss.secaron.de (Postfix) with ESMTP id C27D34AC5F for <[e-mail]>; Fri,  1 Feb 2002 19:54:16 +0100 (MET)
Received: from MUCDEV101 ([192.168.2.101]) by marvin.munich.secaron.de (Lotus Domino Release 5.0.9a) with SMTP id 2002020119541661:3974 ; Fri, 1 Feb 2002 19:54:16 +0100 
From: "Florian Oelmaier" <[e-mail]>
To: <[e-mail]>
Subject: FW: Candidate for moving OCSP to a Draft Standard
Date: Fri, 1 Feb 2002 19:50:54 +0100
Message-ID: <[e-mail]>
MIME-Version: 1.0
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600
X-MIMETrack: Itemize by SMTP Server on Marvin/Secaron(Release 5.0.9a |January 7, 2002) at 02/01/2002 07:54:16 PM, Serialize by Router on Marvin/Secaron(Release 5.0.9a |January 7, 2002) at 02/01/2002 07:54:17 PM, Serialize complete at 02/01/2002 07:54:17 PM
Content-Transfer-Encoding: 7bit
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>

Thanks for the good work. I am looking forward to an OCSP Draft Standard.

--
Dipl.Inf. Florian Oelmaier
Head of Development
syTrust S.A.


> -----Original Message-----
> From: [e-mail]
> [mailto:[e-mail]]On Behalf Of Ambarish Malpani
> Sent: Thursday, January 31, 2002 9:31 PM
> To: '[e-mail]'
> Subject: Candidate for moving OCSP to a Draft Standard
>
>
>
> Hi Guys,
>     Here is a candidate for moving OCSP to a Draft Standard. There
> are no changes in the bytes that go across the wire - basically all
> clarifications.
>
> A list of all the changes between this document and RFC 2560 are
> in Appendix D (reproduced here).
>
> I hope we can get to the Draft Standard state before this IETF.
>
> Regards,
> Ambarish
>
>
> Appendix D. Changes
>
>    This section contains the differences in this document from RFC 2560
>
>    - Mention Appendix D in Section 1 and added an appendix D.
>    - Added a paragraph in Section 1 equating a client with a requestor and
>      server with responder
>    - Section 2.2 - clarified the explanation of good, revoked and unknown
>    - Added Section 2.8 requiring clients and responders to support HTTP
>    - Added a note at the end of section 3.2, which allows a client to
>      accept a response that provides statuses for only some of the
>      certificates requested.
>    - Clarified the issuerKeyHash in Section 4.1.1
>    - Added "DER encoding of the" in the third paragraph Section 4.1.2
>    - Section 4.2.1 - clarified that the signature is on the DER encoding
>      of tbsResponseData (and not its hash)
>    - Section 4.2.1 - specified the use of the certs field in
>      BasicOCSPResponse
>    - Section 4.2.1 - clarified how you compute KeyHash when providing
>      the ResponderID byKey.
>    - Section 4.2.2.2 - removed an extra quote in point 3
>    - Section 4.3 - Made RSA mandatory. Also changed the references to
>      point to the appropriate documents. Added the references to the
>      References section
>    - Section 4.4.1 - Clarified that a nonce in the request MUST be
>    - included in the response for the response to be trusted.
>    - Appendix A - A.1.1. - Got rid of support for GET - not sure that
>      anybody does it. It is also unclear how a server would tell a
>      client to ever use GET in the URL specified in the AIA
>    - Add the module tag for the ASN.1 in OCSP
>    - Made SEQUENCE OF Certificate OPTIONAL to SEQUENCE SIZE(1..MAX) of
>      Certificate OPTIONAL in the ASN.1 defintions. The avoids the
>      ambiguity of whether the optional sequence may be present, but
>      with 0 elements. This was done by definining a new element called
>      Certificates, which is used. Look at the defintion of both
>      Signature and BasicOCSPResponse.
>    - Clarified the meaning of nextUpdate being absent (Section 2.4)
>    - Fixed typo where we referred to id-ad-ocspSigning, to reflect the
>      correct OID - id-kp-OCSPSigning
>    - Clarified criteria for response acceptance (Section 3.2)
>    - Added a line in Section 5 indicating that nonces can be used to
>      prevent prevent attacks using replays of precomputed responses
>    - Added a paragraph in Section 5 requiring nonces to be unique for
>      replay protection
>
> ---------------------------------------------------------------------
> Ambarish Malpani
> Architect                                                650.567.5457
> ValiCert, Inc.                                  [e-mail]
> 339 N. Bernardo Ave.                          http://www.valicert.com
> Mountain View, CA 94043
>
>



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g11HBH310364 for ietf-pkix-bks; Fri, 1 Feb 2002 09:11:17 -0800 (PST)
Received: from edelweb.fr (edelweb.fr [212.234.46.16]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g11HBF310353 for <[e-mail]>; Fri, 1 Feb 2002 09:11:15 -0800 (PST)
Received: from champagne.edelweb.fr (localhost.edelweb.fr [127.0.0.1]) by edelweb.fr with ESMTP id SAA27402; Fri, 1 Feb 2002 18:11:09 +0100 (MET)
Received: from champagne.edelweb.fr (champagne.edelweb.fr [193.51.14.161]) by edelweb.fr (nospam/1.3); Fri, 1 Feb 2002 18:11:09 +0100 (MET)
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 SAA00878; Fri, 1 Feb 2002 18:11:08 +0100 (MET)
From: Peter Sylvester <[e-mail]>
Received: (sylvest@localhost) by emeriau.edelweb.fr (8.7.6/8.6.6) id SAA10396; Fri, 1 Feb 2002 18:11:07 +0100 (MET)
Date: Fri, 1 Feb 2002 18:11:07 +0100 (MET)
Message-Id: <[e-mail]>
To: [e-mail], [e-mail]
Subject: Re: TSP interop update
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>

> 
> Peter Gutmann wrote:
> > 
> > What if the client prefers policy X, but will accept anything if that's not
> > available?  This is standard procedure for restaurants, libraries, ...
> > 
> The client doesn't request some specific policy just for the kicks. He
> needs the time stamp for proving something to someone. This someone will
> most likely have rules according which he verifies time stamps ("I
> expect time stamps to be signed by TSA X and issued under policy Y").
> Therefore, receiving time stamp with policy which may or may not be
> equal or similar to the one requested, is of little value to the
> time-stamping client. In addition, this makes the protocol more complex
> as the client must implement procedures for dealing with time stamps
> with funny and unexpected policy identifiers.


Nothing in the protocol forbids that the TSA changes a policy.
Thus, a client must be prepared to handle unacceptedPolicy.

If in this situation, the TSA would return a time stamp with
another policy, the client or the application can still throw 
it away as part of a default implementation and simulate an
unacceptedpolicy answer. I wouldn't call this is a very complex
procedure. 

Right now, a TSA is always forced to return unacceptedPolicy. 

I am not describing any particular case for which
the TSA would return another OID as part of a standard
behaviour of whatever kind of desirable or undesirable
negotiation protcol. 

> 
> Margus
>
 



Received: by above.proper.com (8.11.6/8.11.3) id g11H5FV10202 for ietf-pkix-bks; Fri, 1 Feb 2002 09:05:15 -0800 (PST)
Received: from mail-out.secaron.de (druss.secaron.de [195.145.99.123]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g11H5E310198 for <[e-mail]>; Fri, 1 Feb 2002 09:05:14 -0800 (PST)
Received: by mail-out.secaron.de (Postfix, from userid 0) id 3AF2C51F27; Fri,  1 Feb 2002 18:05:10 +0100 (MET)
Received: from druss.secaron.de (localhost [127.0.0.1]) by mail-out.secaron.de (Postfix) with ESMTP id C7F5232574; Fri,  1 Feb 2002 18:05:09 +0100 (MET)
Received: from marvin.munich.secaron.de (marvin.munich.secaron.de [192.168.1.20]) by druss.secaron.de (Postfix) with ESMTP id 444A54AC5F; Fri,  1 Feb 2002 18:05:09 +0100 (MET)
Received: from MUCDEV101 ([192.168.2.101]) by marvin.munich.secaron.de (Lotus Domino Release 5.0.9a) with SMTP id 2002020118050915:3927 ; Fri, 1 Feb 2002 18:05:09 +0100 
From: "Florian Oelmaier" <[e-mail]>
To: <[e-mail]>
Cc: "Denis Pinkas" <[e-mail]>, "Ambarish Malpani" <[e-mail]>
Subject: RE: Candidate for moving OCSP to a Draft Standard
Date: Fri, 1 Feb 2002 18:01:48 +0100
Message-ID: <[e-mail]>
MIME-Version: 1.0
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
In-Reply-To: <[e-mail]>
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600
X-MIMETrack: Itemize by SMTP Server on Marvin/Secaron(Release 5.0.9a |January 7, 2002) at 02/01/2002 06:05:09 PM, Serialize by Router on Marvin/Secaron(Release 5.0.9a |January 7, 2002) at 02/01/2002 06:05:09 PM, Serialize complete at 02/01/2002 06:05:09 PM
Content-Transfer-Encoding: 7bit
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>

> The easiest way would be to delete the support of pre-computed
> responses or
> set a maximum limit in the standard. The basic question would
> first be: who
> is using pre-computed responses with which retention period in the cache ?
> If no-one is using it, then the solution is simple. :-)

Just to clarify: You can always replace the term "pre-computed responses"
with "cached responses". Please be aware of that before dropping support for
pre-computed responses. It is hard enough for caching Responders with the
current nonce-requirements: A client using a nonce will disallow caching on
the OCSP-Responder.

Having a setup like 10 Sub-CAs, each certifying 1000 servers for SSL or
1.000.000 users for S/MIME, this will easily result in 30.000 OCSP-req/min
per Sub-CA. This means that in the course of the chain-validation, the
root-Responder will get 5.000 OCSP-requests per second. Given that I will
place the root-Responder in a specially secured network-envirmonment these
figures will make caching/pre-computed responses an issue. Within this
scenario the possiblity of a client to disallow caching at the responder
(with sending a nonce that MUST be answered) is a network and production
problem. But as the RfC correctly states, not using nonces will leave the
somewhat problematic producedAt time as our last defense-line regarding
replay-attacks.

Please discuss this controversly as it will determine the usability of the
protocol.

ciao, Fl0

BTW: I agree to Denis suggestion to invert point 7. and 8.

--
Dipl.Inf. Florian Oelmaier
Head of Development
syTrust S.A.




Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g11Gx6I10100 for ietf-pkix-bks; Fri, 1 Feb 2002 08:59:06 -0800 (PST)
Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g11Gx5310096 for <[e-mail]>; Fri, 1 Feb 2002 08:59:05 -0800 (PST)
Received: from lvt-mail.frlv.bull.fr (lvt-mail.frlv.bull.fr [129.184.62.223]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id SAA22494; Fri, 1 Feb 2002 18:00:32 +0100
Received: from bull.net (frlva3786.frlv.bull.fr [129.184.37.97]) by lvt-mail.frlv.bull.fr (8.9.2/8.9.1) with ESMTP id RAA15040; Fri, 1 Feb 2002 17:58:30 +0100
Message-ID: <[e-mail]>
Date: Fri, 01 Feb 2002 17:58:16 +0100
From: Denis Pinkas <[e-mail]>
Organization: Integris. A Bull Company
X-Mailer: Mozilla 4.7 [fr] (Win98; I)
X-Accept-Language: fr
MIME-Version: 1.0
To: Anders Rundgren <[e-mail]>
CC: [e-mail]
Subject: Re: Globally unique DNs - Why?
References: <005201c1ab3d$6c5a8170$0500a8c0@arport>
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>

Anders,

> List,
> In certain, rather "animated" discussions, the statement that an
> X509.v3 Subject DN (if specified) must be globally unique in order
> to be "conformant".

Please read section  "4.1.2.6  Subject" page 24 from 
<draft-ietf-pkix-new-part1-12.txt>

The DN MUST be unique for each subject entity certified by the one CA 
as defined by the issuer name field.

Denis

> In my view this is not the case.  Referring to my own "citizen-ID"
> with a DN like
> 
>      CN=Anders Rundgren, C=SE, serialNumber=nnnnnnnnnnnnnn
> 
> which indeed have been created by "PKIX-aware" people, I
> would not call that a globally unique name.
> 
> It is unique within its own name-space which happens to be Swedish
> citizen numbers but without that knowledge it could equally well
> be a member certificate of a more obscure community.
> 
> But, and that the important thing, it is still a globally unique name
> when using the CA as a name-space indicator.
> 
> Anders Rundgren


Received: by above.proper.com (8.11.6/8.11.3) id g11GSuu09350 for ietf-pkix-bks; Fri, 1 Feb 2002 08:28:56 -0800 (PST)
Received: from mail.utfors.se (mail.utfors.se [195.58.103.125]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g11GSs309346 for <[e-mail]>; Fri, 1 Feb 2002 08:28:54 -0800 (PST)
Received: from arport ([62.119.75.13]) by mail.utfors.se (8.8.8/8.8.8) with SMTP id RAA03467 for <[e-mail]>; Fri, 1 Feb 2002 17:28:43 +0100 (MET)
Message-ID: <005201c1ab3d$6c5a8170$0500a8c0@arport>
From: "Anders Rundgren" <[e-mail]>
To: <[e-mail]>
Subject: Globally unique DNs - Why?
Date: Fri, 1 Feb 2002 17:27:58 +0100
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.50.4133.2400
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
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,
In certain, rather "animated" discussions, the statement that an
X509.v3 Subject DN (if specified) must be globally unique in order
to be "conformant".

In my view this is not the case.  Referring to my own "citizen-ID"
with a DN like

     CN=Anders Rundgren, C=SE, serialNumber=nnnnnnnnnnnnnn

which indeed have been created by "PKIX-aware" people, I
would not call that a globally unique name.

It is unique within its own name-space which happens to be Swedish
citizen numbers but without that knowledge it could equally well
be a member certificate of a more obscure community.

But, and that the important thing, it is still a globally unique name
when using the CA as a name-space indicator.

Anders Rundgren



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g11G6S608523 for ietf-pkix-bks; Fri, 1 Feb 2002 08:06:28 -0800 (PST)
Received: from mtiwmhc22.worldnet.att.net (mtiwmhc22.worldnet.att.net [204.127.131.47]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g11G6Q308519 for <[e-mail]>; Fri, 1 Feb 2002 08:06:26 -0800 (PST)
Received: from tsg1 ([12.81.71.28]) by mtiwmhc22.worldnet.att.net (InterMail vM.4.01.03.27 201-229-121-127-20010626) with SMTP id <20020201160616.VQMW941.mtiwmhc22.worldnet.att.net@tsg1>; Fri, 1 Feb 2002 16:06:16 +0000
Message-ID: <03ba01c1ab3a$55a76090$020aff0c@tsg1>
From: "todd glassey" <[e-mail]>
To: "Denis Pinkas" <[e-mail]>
Cc: "IETF PKIX" <[e-mail]>
References: <[e-mail]> <[e-mail]>
Subject: Re: TSP interop update
Date: Fri, 1 Feb 2002 08:05:56 -0800
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 6.00.2600.0000
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
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>

----- Original Message -----
From: "Denis Pinkas" <[e-mail]>
To: "Peter Gutmann" <[e-mail]>
Cc: <[e-mail]>
Sent: Friday, February 01, 2002 6:15 AM
Subject: Re: TSP interop update


>
> Peter,
>
> > Denis Pinkas <[e-mail]> writes:
> > >IF, I did say "IF", we go into that direction, then it would mean
changing the
> > >reqPolicy field in TimeStampReq by allowing a sequence of TSA policies
instead
> > >of a single policy.
> > >
> > >Would this fit the concern from Peter ?
> >
> > To some extent, although you'd need to allow anyPolicy to allow the
client to
> > specify that if it can't get an exact match, anything will do.
>
> If anything will do, then the client does not need to request any specific
> policy.
>
> :-)
>
> > Consider for
> > example electronic tax filing, in which I have to get my submission
timestamped
> > to prove I filed on time.

Bad model - the IRS and the other tax collection bureaus care only when they
claim they recieved the document and unless there is a "rush to the
Courthouse" going on there - you have nothing to say about it other than
"err uhhhh Thanks." In order to have any effect here the Tax Bureau would
have to need to acknowledge independantly that you had paid your taxes and
there is no such tax process that needs that today - so this TSP is really
useless in taxation processing models.

>> Before I submit the return to irs.gov I go to
> > time.gov and get my return stamped.

No - Wrong - What matters is when the IRS.GOV site responds that it got the
filing not what time you submitted it. Who cares what time you submitted it
if the network eats the filing it is still your responsibility.


> > Ideally I'd want it notarised under the
> > 2002 tax policy, or failing that the 2000 tax policy, or the general tax
> > policy, but if all else fails I can probably get it done under the
dog-license
> > policy because if it goes to court all that matters is that it's
timestamped.
> > If it was under any of the standard tax policies I wouldn't need to go
to
> > court, but the dog-license policy is always better than having nothing
at all.

The problem is that in this model there is assumed to be some agent between
you and the Tax Collector and that is just not how its being rolled out. The
Tax Bureaus are allowing people to tunnel into secured forms on their sites
and by that creating a session level connection to the transaction servers
and as this the only thing that is an issue is what time the server tells
you this filing was recieved - what time you submitted it is irrelevant in a
legal sense in most all instances.

> > However:
> >
> > It's still making the decision at the wrong place.  Instead of the
client being
> > able to decide what's acceptable, it now has to communicate more and
more state
> > information to the server and still ask the server to make the decision
for it.

This is feature creep because no real use model existed. All the Server
needs to be able to do is to "Create and Verify" tokens and that to
accomplish this it should have a verification service model built into the
client-side protocol to support the working within the cause of "Verifying
the individual externally provided data points" for the Marque to be
created.

> > It's turning into an uglier and uglier kludge because the client, who
should be
> > making the decision, is banned from doing so, so all it can do is throw
a
> > mountain of state at the server and ask it to make the decision for it.

yes but this is true becuase the WG as a whole refuses to do what is clearly
necessary, which is to setup a set of use models for the protocol.

> > In the
> > case of the tax-timestamping above I can easily encode this process at
the
> > client, but I have no idea how I'd communicate that decision-making
process to
> > the server.  The real solution, which is relatively straightforward, is
to
> > allow the client to device what it wants to accept, not to require the
server
> > to make the decision for it.
>
> In a negotiation protocol, the client states what it is ready to accept
and
> mentions its order of preferences. Then the server chooses among the list.
>
> Denis
>
> > Peter.
>



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g11FL5m07173 for ietf-pkix-bks; Fri, 1 Feb 2002 07:21:05 -0800 (PST)
Received: from mtiwmhc26.worldnet.att.net (mtiwmhc26.worldnet.att.net [204.127.131.51]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g11FL3307164; Fri, 1 Feb 2002 07:21:03 -0800 (PST)
Received: from tsg1 ([12.81.71.28]) by mtiwmhc26.worldnet.att.net (InterMail vM.4.01.03.27 201-229-121-127-20010626) with SMTP id <20020201152059.UUPW13869.mtiwmhc26.worldnet.att.net@tsg1>; Fri, 1 Feb 2002 15:20:59 +0000
Message-ID: <03a301c1ab34$01dffc70$020aff0c@tsg1>
From: "todd glassey" <[e-mail]>
To: <[e-mail]>, "Paul Hoffman / IMC" <[e-mail]>, "Stephen Kent" <[e-mail]>
Cc: "IETF IESG" <[e-mail]>, <[e-mail]>
References: <[e-mail]> <[e-mail]> <p05101360b87f4f6e63ee@[165.227.249.20]>
Subject: PKIX reform issues - Was Re: I-D ACTION:draft-ietf-pkix-okid-00.txt
Date: Fri, 1 Feb 2002 07:20:38 -0800
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 6.00.2600.0000
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
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>

Paul

>
> Where in the document did it say this? CAs and non-CA self-signers
> are allowed to do whatever they want.

The sentence you are looking for is not in the document, or any document
that PKIX has produced. It is in fact in everything that this WG (PKIX) does
by virtue of the fact that PKIX refesues to put in place Working Models for
how to use its protocols and its management refuses to consider this as a
requirement to separating submitted projects and their work products from
those that would more rightly belong in the realm of the IRTF.

This is a critical realization because what it implies is that SO LITTLE OF
WHAT PKIX IS DOING WILL EVER GET USED  in the commercial world and likely
much of it really does belong in a PKI group under the IRTF and not here.

And by the way Dr. Stephen Kent - That is your responsibility as the Senior
Chair of the WG... yours and the rest of the management's fault - and once
again I suggest that you personally consider moving-on becuase of it and
letting some fresher blood get into PKIX management with Tim.

>
> >  which is indeed a restriction that is
> >    not acceptable.
>
> Agree; that's why it doesn't say it.
>
> >    So the document should be changed to consider the hash of the
certificate
> >    instead of only the hash of the public key (and of the algorithm
> >    identifier).
>
> You then make Mallory's job many orders of magnitude easier. Instead
> of having to create 2^79 key pairs, he only has to create 2^79 hashes
> looking for one that matches Alice's OKID. That doesn't seem like a
> good security choice, particularly because we can assume that it is
> more likely that people will work on hardware hash acceleration than
> they will on hardware key generation.
>
> >    If we do so, then the "protocol" will also be usable for any type of
> >    certificate, not only self-signed certificates.
>
> Correct, but at the cost of making the protocol much easier to break.
>
> >2) The abstract should rephrased as:
> >
> >    The Out-of-Band Key Identifier Protocol (OKID) is a user-friendly
> >    out-of-band way to install certificates.
>
> Disagree. This protocol does not install certificates. It helps with
> only one step of that process.
>
> --Paul Hoffman, Director
> --Internet Mail Consortium



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g11FGWe07027 for ietf-pkix-bks; Fri, 1 Feb 2002 07:16:32 -0800 (PST)
Received: from edelweb.fr (edelweb.fr [212.234.46.16]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g11FGT307023 for <[e-mail]>; Fri, 1 Feb 2002 07:16:30 -0800 (PST)
Received: from champagne.edelweb.fr (localhost.edelweb.fr [127.0.0.1]) by edelweb.fr with ESMTP id QAA26957 for <[e-mail]>; Fri, 1 Feb 2002 16:16:30 +0100 (MET)
Received: from champagne.edelweb.fr (champagne.edelweb.fr [193.51.14.161]) by edelweb.fr (nospam/1.3); Fri, 1 Feb 2002 16:16:30 +0100 (MET)
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 QAA00379 for <[e-mail]>; Fri, 1 Feb 2002 16:16:29 +0100 (MET)
From: Peter Sylvester <[e-mail]>
Received: (sylvest@localhost) by emeriau.edelweb.fr (8.7.6/8.6.6) id QAA10371 for [e-mail]; Fri, 1 Feb 2002 16:16:28 +0100 (MET)
Date: Fri, 1 Feb 2002 16:16:28 +0100 (MET)
Message-Id: <[e-mail]>
To: [e-mail]
Subject: RE: TSP interop update
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>

> Denis:
> >
> > IF, I did say "IF", we go into that direction, then it would
> > mean changing
> > the reqPolicy field in TimeStampReq by allowing a sequence of
> > TSA policies
> > instead of a single policy.
> >
> 
> why not to introduce in the request message an extension to express the
> ordered list containing the preferred policies?
> 
> This way, expressing which policy is preferred or requested could be a
> little more tricky, but it could achieve the task to preserve backward
> compatibility.
> 
> Gianluca
I support in pronciple Gianluca's approach, see below. But this
seems another discussion: 

Are we sure that we understand the meaning of SHOULD?

3. SHOULD   This word, or the adjective "RECOMMENDED", mean that there
   may exist valid reasons in particular circumstances to ignore a
   particular item, but the full implications must be understood and
   carefully weighed before choosing a different course.

4. SHOULD NOT   This phrase, or the phrase "NOT RECOMMENDED" mean that
   there may exist valid reasons in particular circumstances when the
   particular behavior is acceptable or even useful, but the full
   implications should be understood and the case carefully weighed
   before implementing any behavior described with this label.

It seems that on one side we have people that say that the
policy used by the service MUST be identical. 

Just allowing 'SHOULD' does not mean that any particular 
interpretation is attempted, any kind of conspiracy
between clients and TSA about a particular way to request a policy,
could be possible. 

The current spec forces the TSA to return unacceptablepolicy.
in this case a client implementation needs procedure to recover 
from this problem.  

Returning a timestamp with another policy does not mean that
the client MUST accept it. It can locally simply implement
logic to throw away the time stamp because it doesn't like it
and simulate that error. The behaviour for the rest of the
application would be identical. I don't see that this means
an enormous additional complexity for the client implementation. 

Well, yes, if the nasty TSA makes You pay for something that
You haven't requested, and then claims that the standard says
that are not required to return the exact policy, so You have
to pay .... :-) 

-----

I am not in favour to change any ASN1 syntax or add
an extension to start some sort of policy negotiation. As
indicated by Gianluca, extensions seem a better way:

Just proposing a list of OIDs doesn't seem sufficient to me, it
would be a first small hack. If at some time one would be
able to formalise policies as a combination of smaller
elements, then one might end up asking that:
Please use a policy that has feature A + feature B or
fetaure A + C + D etc. 

Peter


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g11FGGh07013 for ietf-pkix-bks; Fri, 1 Feb 2002 07:16:16 -0800 (PST)
Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g11FGE307004 for <[e-mail]>; Fri, 1 Feb 2002 07:16:14 -0800 (PST)
Received: from lvt-mail.frlv.bull.fr (lvt-mail.frlv.bull.fr [129.184.62.223]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id QAA17976; Fri, 1 Feb 2002 16:17:32 +0100
Received: from bull.net (frlva3786.frlv.bull.fr [129.184.37.97]) by lvt-mail.frlv.bull.fr (8.9.2/8.9.1) with ESMTP id QAA10690; Fri, 1 Feb 2002 16:15:29 +0100
Message-ID: <[e-mail]>
Date: Fri, 01 Feb 2002 16:15:22 +0100
From: Denis Pinkas <[e-mail]>
Organization: Integris. A Bull Company
X-Mailer: Mozilla 4.7 [fr] (Win98; I)
X-Accept-Language: fr
MIME-Version: 1.0
To: Olle Mulmo <[e-mail]>
CC: Ambarish Malpani <[e-mail]>, [e-mail]
Subject: Re: Candidate for moving OCSP to a Draft Standard
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>

Olle,

> I don't quite agree with Denis on assuming a few hours to be OK 
> in a general scheme. Clearly, the value of the maximum lag time 
> on the producedAt field in an OCSP response must be defined in 
> the Operational Requirements section of the CA's CPS -- to be 
> defined and thought of months (or at least a few hours...) 
> before the OCSP service is to come online.

The problem is that an OCSP client is a client from different OCSP 
servers, each one may have different Operational Requirements. 
Since unfortunately Operational Requirement of the CA's CPS are 
not machine readable, there is no way for a client to automatically 
adjust the timing according to each CA, unless clients work in 
a closed environment with CAs that they all know in advance.

Denis

 
> However, revoked is revoked is revoked: shouldn't a client 
> accept an OCSP response containing a SingleResponse with 
> (status=revoked and reasonCode!=onHold), even though 
> the producedAt field is long by gone?
> 
> Regards,
> 
> Olle
> 
> -----Original Message-----
> From: Denis Pinkas [mailto:[e-mail]]
> Sent: Friday, February 01, 2002 10:34 AM
> To: Ambarish Malpani
> Cc: '[e-mail]'
> Subject: Re: Candidate for moving OCSP to a Draft Standard
> 
> Ambarish,,
> 
> > Hi Guys,
> 
> >     Here is a candidate for moving OCSP to a Draft Standard. There
> > are no changes in the bytes that go across the wire - basically all
> > clarifications.
> 
> > A list of all the changes between this document and RFC 2560 are
> > in Appendix D (reproduced here).
> 
> > I hope we can get to the Draft Standard state before this IETF.
> 
> I have the following remarks:
> 
> The current text states:
> 
>    7. The producedAt time in the response is sufficiently recent.
> 
>    8. If the request contained a nonce, the response must contain the
>       same nonce (see section 4.4.1).
> 
> If the nonce is used, then the value of the producedAt field does not matter
> anymore and no test needs to be made on it. So I would first propose to
> invert items 8 and 7.
> 
> Then it is questionable on how implementers can interpret what "sufficiently
> recent" means for the producedAt time and set a value (a few minutes, hours
> or days ?).
> 
> In fact if no pre-computed response were being used, this could simply be
> set to a few minutes.
> 
> If pre-computed responses are being used, setting it to a few minutes will
> probably lead to rejections.
> 
> This means that using pre-computed responses is a real problem, since this
> value cannot even be fixed but is even dependent upon each server supporting
> pre-computed responses.
> 
> The easiest way would be to delete the support of pre-computed responses or
> set a maximum limit in the standard. The basic question would first be: who
> is using pre-computed responses with which retention period in the cache ?
> If no-one is using it, then the solution is simple. :-)
> 
> In the following proposal, I have not yet "crossed the line".
> 
> Proposed rephrasing:
> 
> [Prior to accepting a signed response as valid, OCSP clients SHALL
>  confirm that:]
> 
>    7. If the request contained a nonce, the response contains the
>       same nonce (see section 4.4.1).
> 
>    8. If the request did not contained a nonce, the producedAt time
>       in the response is considered as "sufficiently recent".
>       This means computing the difference between the current time
>       and the producedAt time and then comparing it with a time
>       period that will be set to a few minutes, or to a few hours
>       in the case where the OCSP servers accessed by the client
>       are supporting pre-computed responses.
> 
>       Note: when pre-computed responses are being used by servers,
>       it may be hard for clients to set a single maximum common value.
> 
> Denis
> 
> 
> > Regards,
> > Ambarish
> >
> > Appendix D. Changes
> >
> >    This section contains the differences in this document from RFC 2560
> >
> >    - Mention Appendix D in Section 1 and added an appendix D.
> >    - Added a paragraph in Section 1 equating a client with a requestor and
> >      server with responder
> >    - Section 2.2 - clarified the explanation of good, revoked and unknown
> >    - Added Section 2.8 requiring clients and responders to support HTTP
> >    - Added a note at the end of section 3.2, which allows a client to
> >      accept a response that provides statuses for only some of the
> >      certificates requested.
> >    - Clarified the issuerKeyHash in Section 4.1.1
> >    - Added "DER encoding of the" in the third paragraph Section 4.1.2
> >    - Section 4.2.1 - clarified that the signature is on the DER encoding
> >      of tbsResponseData (and not its hash)
> >    - Section 4.2.1 - specified the use of the certs field in
> >      BasicOCSPResponse
> >    - Section 4.2.1 - clarified how you compute KeyHash when providing
> >      the ResponderID byKey.
> >    - Section 4.2.2.2 - removed an extra quote in point 3
> >    - Section 4.3 - Made RSA mandatory. Also changed the references to
> >      point to the appropriate documents. Added the references to the
> >      References section
> >    - Section 4.4.1 - Clarified that a nonce in the request MUST be
> >    - included in the response for the response to be trusted.
> >    - Appendix A - A.1.1. - Got rid of support for GET - not sure that
> >      anybody does it. It is also unclear how a server would tell a
> >      client to ever use GET in the URL specified in the AIA
> >    - Add the module tag for the ASN.1 in OCSP
> >    - Made SEQUENCE OF Certificate OPTIONAL to SEQUENCE SIZE(1..MAX) of
> >      Certificate OPTIONAL in the ASN.1 defintions. The avoids the
> >      ambiguity of whether the optional sequence may be present, but
> >      with 0 elements. This was done by definining a new element called
> >      Certificates, which is used. Look at the defintion of both
> >      Signature and BasicOCSPResponse.
> >    - Clarified the meaning of nextUpdate being absent (Section 2.4)
> >    - Fixed typo where we referred to id-ad-ocspSigning, to reflect the
> >      correct OID - id-kp-OCSPSigning
> >    - Clarified criteria for response acceptance (Section 3.2)
> >    - Added a line in Section 5 indicating that nonces can be used to
> >      prevent prevent attacks using replays of precomputed responses
> >    - Added a paragraph in Section 5 requiring nonces to be unique for
> >      replay protection
> >
> > ---------------------------------------------------------------------
> > Ambarish Malpani
> > Architect                                                650.567.5457
> > ValiCert, Inc.                                  [e-mail]
> > 339 N. Bernardo Ave.                          http://www.valicert.com
> > Mountain View, CA 94043
> >
> >   ----------------------------------------------------------------------------
> >                         Name: OCSP-draft-03.txt
> >    OCSP-draft-03.txt    Type: Plain Text (text/plain)
> >                     Encoding: quoted-printable


Received: by above.proper.com (8.11.6/8.11.3) id g11FEbD06938 for ietf-pkix-bks; Fri, 1 Feb 2002 07:14:37 -0800 (PST)
Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g11FEZ306930 for <[e-mail]>; Fri, 1 Feb 2002 07:14:35 -0800 (PST)
Received: from lvt-mail.frlv.bull.fr (lvt-mail.frlv.bull.fr [129.184.62.223]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id QAA17968; Fri, 1 Feb 2002 16:16:01 +0100
Received: from bull.net (frlva3786.frlv.bull.fr [129.184.37.97]) by lvt-mail.frlv.bull.fr (8.9.2/8.9.1) with ESMTP id QAA18078; Fri, 1 Feb 2002 16:13:59 +0100
Message-ID: <[e-mail]>
Date: Fri, 01 Feb 2002 16:13:52 +0100
From: Denis Pinkas <[e-mail]>
Organization: Integris. A Bull Company
X-Mailer: Mozilla 4.7 [fr] (Win98; I)
X-Accept-Language: fr
MIME-Version: 1.0
To: [e-mail]
CC: "'Antonio Lioy'" <[e-mail]>, [e-mail]
Subject: Re: TSP interop update
References: <000001c1ab28$1d6cddc0$df01c082@RAMUNNO>
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>

Gianluca,

> Denis,

> > IF, I did say "IF", we go into that direction, then it would
> > mean changing
> > the reqPolicy field in TimeStampReq by allowing a sequence of
> > TSA policies
> > instead of a single policy.

> why not to introduce in the request message an extension to express the
> ordered list containing the preferred policies?

Before defining a solution, the first question is the following: 
is this feature really needed ?
 
> This way, expressing which policy is preferred or requested could be a
> little more tricky, but it could achieve the task to preserve backward
> compatibility.

Thenafter we may define a solution. I have the same concern that you have:
"backward compatibility". Making a sequence of policies is simpler but
incompatible with the current document, hence why I asked first the question
to implementers whether they would be ready or have have problems to make
such a change.

Adding a new extension is a solution that I would like to avoid, but would
achieve backward ASN.1 compatibility, with the burden of defining things
like what happens when the new extension is present but not reqPolicy, 
or when both are present. :-(

Once again, the first question is the following: 
is this feature really needed ?

I would like to hear opinions.

Denis

> Gianluca


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g11F59C06695 for ietf-pkix-bks; Fri, 1 Feb 2002 07:05:09 -0800 (PST)
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 g11F58306690 for <[e-mail]>; Fri, 1 Feb 2002 07:05:08 -0800 (PST)
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 KAA234610; Fri, 1 Feb 2002 10:01:57 -0500
Received: from d01ml062.pok.ibm.com (d01ml062.pok.ibm.com [9.117.250.163]) by northrelay02.pok.ibm.com (8.11.1m3/NCO v5.01) with ESMTP id g11F52O20324; Fri, 1 Feb 2002 10:05:02 -0500
Importance: Normal
Sensitivity: 
Subject: Re: draft-ietf-pkix-pi
To: Denis Pinkas <[e-mail]>
Cc: Massimiliano Pala <[e-mail]>, [e-mail]
X-Mailer: Lotus Notes Release 5.0.7  March 21, 2001
Message-ID: <[e-mail]>
From: "Tom Gindin" <[e-mail]>
Date: Fri, 1 Feb 2002 10:04:46 -0500
X-MIMETrack: Serialize by Router on D01ML062/01/M/IBM(Release 5.0.9 |November 26, 2001) at 02/01/2002 10:05:02 AM
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>

      Denis:

      I have only one independent comment on this.  In the current draft,
the identifier is a DN.  There is no restriction in the definition of the
AttributeTypeAndValue type which would prevent an attribute with type OCTET
STRING from being used within it, even though that's not very user-friendly
naming.  There is even provision made to do LDAP lookups for such things in
RFC 2253 section 2.4, although the DER tag and length get included in the
value format, and X.520 predefines an OCTET STRING exact match.  So all we
need to do is define an attribute name and OID with that matching rule.
      If you want to specify conversion to hex or base 64 instead, that's
fine with me.

            Tom Gindin

Denis Pinkas <[e-mail]> on 02/01/2002 09:27:55 AM

To:    Massimiliano Pala <[e-mail]>
cc:    [e-mail], Tom Gindin/Watson/IBM@IBMUS
Subject:    Re: draft-ietf-pkix-pi


Massimiliano,

Your e-mail was sent yesterday. You are quite impatient to get an anwser.

Some quick comments:

1) The type of permanent identifier being used should rather be either an
  OID or a "persistant URL" (for the XML world that uses persitant URLs).
  This would certainly please Tom Guidin, my co-editor. :-)

  The full text identifier (identifierDesc) you propose would be subject
  to collisions and does not add anything: Permanent Identifiers are not
  for human users but machines.

2) The novelty you propose is to allow the use of a hash of the value
  instead of the value itself, without a rational but one reason has been
  given by Roberto Opazo Gazmuri on January 30 about the case of Hong Kong.

  The hash can really hide the value if the value is long enough. It would
  be interresting first to provide some figures about how long it would
take
  to invert a hash value, e.g. for the Hong Kong Identifier (HKID) case.

Should the WG decide to support a hash of the value (in addtion to the
value
itself), we could avoid overloading the syntax by simply defining an OID
that tells that the value is the hash of, e.g., the HKID instead of the
value of the HKID itsef.

Denis


> Hi all,
>
> no comments about my previous message on the subject ??? All of them are
> to be thrown off or there is something worth discussing ?
>
> Let me know.
>
> Can we submit a new version of the draft with proposed changes included ?

Within the IETF the rule is to submit change proposals to the editors so
they can incorporate them in the documents. So you should not submit a full
new version of the draft, but you can certainly propose detailed changes,
as
you have already done.

Denis

> --
>
> C'you,
>
>         Massimiliano Pala
>
>
--o-------------------------------------------------------------------------

> Massimiliano Pala [OpenCA Project Manager]               madwolf at
cpan.org
>                                                        madwolf at
openca.org
> http://www.openca.org                             madwolf at
hackmasters.net
> http://openca.sourceforge.net                    Mobile: [phone]
365






Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g11EtWe06463 for ietf-pkix-bks; Fri, 1 Feb 2002 06:55:32 -0800 (PST)
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 g11EtQ306459 for <[e-mail]>; Fri, 1 Feb 2002 06:55:30 -0800 (PST)
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 JAA190634; Fri, 1 Feb 2002 09:52:14 -0500
Received: from d01ml062.pok.ibm.com (d01ml062.pok.ibm.com [9.117.250.163]) by northrelay02.pok.ibm.com (8.11.1m3/NCO v5.01) with ESMTP id g11EtJO31394; Fri, 1 Feb 2002 09:55:19 -0500
Importance: Normal
Sensitivity: 
To: Massimiliano Pala <[e-mail]>
Cc: [e-mail]
X-Mailer: Lotus Notes Release 5.0.7  March 21, 2001
Message-ID: <[e-mail]>
From: "Tom Gindin" <[e-mail]>
Date: Fri, 1 Feb 2002 09:55:00 -0500
Subject: Re: draft-ietf-pkix-pi
X-MIMETrack: Serialize by Router on D01ML062/01/M/IBM(Release 5.0.9 |November 26, 2001) at 02/01/2002 09:55:20 AM
MIME-Version: 1.0
Content-type: multipart/mixed;  Boundary="0__=0ABBE1C0DFC2715D8f9e8a93df938690918c0ABBE1C0DFC2715D"
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>

--0__=0ABBE1C0DFC2715D8f9e8a93df938690918c0ABBE1C0DFC2715D
Content-type: text/plain; charset=us-ascii


      Massimiliano:

      I agree with Al's point about the hash (that a hash solely on ID
numbers is too weak to be very valuable).  Also, the type of identifierDesc
would probably be better as DirectoryString or PrintableString than as
Name, which is the type for a DN.
      Your point about what the CA is certifying is correct, of course.
However, it should be pointed out that cross-CA comparisons of PI's are
valid if both CA's do their jobs correctly, although responsibility for a
false match could not be determined by automated procedures.

            Tom Gindin


Massimiliano Pala <[e-mail]>@mail.imc.org on 01/31/2002
05:56:53 AM

Sent by:    [e-mail]


To:    [e-mail]
cc:
Subject:    draft-ietf-pkix-pi



Hi all,

I have some points I'd like to highlight about the PI. Current comments are
made against the http://www.imc.org/draft-ietf-pkix-pi.

First of all some general considerations. My personal point on the PI is
that this should be used only within the subjectAltName ext. and this to
prevent the Subject DN from ever growing and keep as human readable as
possible. I know that there could be established policies following the
Subject DN's but I support this option.

Let's get through the draft in order.

I would change the paragraph:

<< A permanent identifier is a name assigned by an organization,
   unique within that organization, that singles out a particular
   individual from all other individuals.  A CA which includes such
   an identifier in a certificate is certifying that any different
   public key certificate containing that identifier refers to the
   same individual. >>


Adding a phrase to clearly state that the "public key certificate..."
is from the CA in subject, something like:

<< A permanent identifier is a name assigned by an organization,
   unique within that organization, that singles out a particular
   individual from all other individuals.  A CA which includes such
   an identifier in a certificate is certifying that any different
   public key certificate issued by that CA and containing that
   identifier refers to the same individual. >>

I would like to extend the structure of the PersonalIdentifier to
something like this:

   PermanentIdentifier ::=     SEQUENCE {
           assignerAuthority        GeneralName OPTIONAL,
           identifierDesc           Name,
           identifierValue          IdentifierValue }

   IdentifierValue ::= CHOICE {
           permanentId        [1]       Name,
         permanentIdHash      [2]       IDHash }

   PermanentIdHash ::= SEQUENCE {
           identifierHash         OCTET STRING,  --- original identifier's
Hash
         identifierHashAlgorithm  AlgorithmIdentifier }

(there can be errors as I am not a master in structure definition :-D )

This structure (if correct) could solve problems tied to different current
situations, indeed there is the possibility to hide the "real" assigned ID
using the hash value instead. Usage of the Hash instead of the "real" ID
is therefore clearly stated when used. (this could be required if the
original
value carries sensible data like date of birth, etc... ).

The identifierDesc field is used to give a text identifier of the id used,
i.e. "RUN" or "ABN", depending on the description adopted by the
assignerAuthority
(I am not sure if this could be coded using different techniques, if so,
please,
point it out - thanks).

I'd also change the word "responsible" when talking about the
assignerAuthority some paragraph behind: this to state that this field
carries an indication not directly stated by the assignerAuthority's
subject (it is no liable for the contents of the field).

It could also be simply stripped off, something like:

<< The assignerAuthority field of this attribute, when present,
   identifies the organization assigning the content of the identifier
   field. When the assignerAuthority field is missing, the assignee
   Authority is the CA itself and it is assumed  to be the issuer
   name of the certificate. >>

Some comments ? Denis ?

--

C'you,

      Massimiliano Pala

--o-------------------------------------------------------------------------

Massimiliano Pala [OpenCA Project Manager]               madwolf at
cpan.org
                                                       madwolf at
openca.org
http://www.openca.org                             madwolf at
hackmasters.net
http://openca.sourceforge.net                    Mobile: [phone]
365



--0__=0ABBE1C0DFC2715D8f9e8a93df938690918c0ABBE1C0DFC2715D
Content-type: application/octet-stream; 
	name="smime.p7s"
Content-Disposition: attachment; filename="smime.p7s"
Content-transfer-encoding: base64

MIIF+gYJKoZIhvcNAQcCoIIF6zCCBecCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCCBFow
ggRWMIIDPqADAgECAgIDITANBgkqhkiG9w0BAQQFADBAMSAwHgYDVQQDExdDZXJ0aWZpY2F0aW9u
IEF1dGhvcml0eTEPMA0GA1UEChMGT3BlbkNBMQswCQYDVQQGEwJJVDAeFw0wMTAyMjcxMzQ0NTRa
Fw0wMjAyMjcxMzQ0NTRaMIGFMSYwJAYJKoZIhvcNAQkBFhdtYWR3b2xmQGhhY2ttYXN0ZXJzLm5l
dDEaMBgGA1UEAxMRTWFzc2ltaWxpYW5vIFBhbGExFDASBgNVBAsTC09wZW5DQSBVc2VyMRwwGgYD
VQQKExNPcGVuQ0EgT3JnYW5pemF0aW9uMQswCQYDVQQGEwJJVDCBnzANBgkqhkiG9w0BAQEFAAOB
jQAwgYkCgYEAs7c/i7zt8oRbF/MO3/Xq1bWb2h3y5VdRsm0EMT22pFX7yjaKp4pSF36NDPJb4ss6
aqqGLSiyyI/Wy+7124JDOzXhY4S0XPbZ6MmLUy4vp3Ze+jmgJNyO2j+BtRQarUaEno+JIUizU4pc
EtUO4BaPkxRqaL02raR61i3+foCQb/MCAwEAAaOCAZYwggGSMAkGA1UdEwQCMAAwEQYJYIZIAYb4
QgEBBAQDAgWgMAsGA1UdDwQEAwIF4DAmBglghkgBhvhCAQ0EGRYXT3BlbkNBIFVzZXIgQ2VydGlm
aWNhdGUwHQYDVR0OBBYEFPtjrGNl7QbDnNY0rT2UFmtDF8doMGgGA1UdIwRhMF+AFAtL08ix9MbK
XM950at8v/yRSMd7oUSkQjBAMSAwHgYDVQQDExdDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEPMA0G
A1UEChMGT3BlbkNBMQswCQYDVQQGEwJJVIIBADAJBgNVHREEAjAAMAkGA1UdEgQCMAAwNAYJYIZI
AYb4QgEEBCcWJWh0dHBzOi8vd3d3Lm9wZW5jYS5vcmcvY2dpLWJpbi9nZXRjcmwwNAYJYIZIAYb4
QgEDBCcWJWh0dHBzOi8vd3d3Lm9wZW5jYS5vcmcvY2dpLWJpbi9nZXRjcmwwMgYJYIZIAYb4QgEH
BCUWI2h0dHBzOi8vd3d3Lm9wZW5jYS5vcmc6NDQ0My9yZW5ld2FsMA0GCSqGSIb3DQEBBAUAA4IB
AQBbbzeNMZcl2K68tfAzCD72PB+hnwBuFBebVwVg5vWNJh/Zu0y2HAzy5pv9EcqLwS/2d5lqhwzG
6a2HW0HrrPbKxaLdQ4bZzDLG6zUohXzlCH0l2sq4BVuQF/dLVY/Gj2T9azYE0Yf2pOVG1VCC7zCR
9EtXsM51MbHzgxvOpUZD9sti2Y7UHmwxpr8vYodNLGQgR0B4tyWgCo5/LWyRk+u+4S0fFLslFISF
pqNsTtDQxRWvmDD8BZhH5OFMHgCN73Wsngq2Hopo7QeKR2Ghwc+cIZHtk2Huoaj059Nz/WXixzez
Zm5j3G1JWAzHfLo17n+nDdbF+OBODEhhuSIIBMI+MYIBaDCCAWQCAQEwRjBAMSAwHgYDVQQDExdD
ZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEPMA0GA1UEChMGT3BlbkNBMQswCQYDVQQGEwJJVAICAyEw
CQYFKw4DAhoFAKB6MBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwGwYJKoZIhvcNAQkPMQ4wDDAK
BggqhkiG9w0DBzAcBgkqhkiG9w0BCQUxDxcNMDIwMTMxMTA1NjUzWjAjBgkqhkiG9w0BCQQxFgQU
U5LN9/b15MvkCJBJsocYH7JQxrwwDQYJKoZIhvcNAQEBBQAEgYBn2W3xCFu/fQnynajjOk3t0pTc
GjmfixtHFtMScAZRwr4rlKIKKIPl+plkU02bWGOJy3UPxuWhsKrEWOSVlmSsyspzCJgpn/DUrTMD
uASuRTXecwB8qu09Bl8lQnn6Dm3P1wTuzTt7cJyS9SWwZBgpHIng7kkzX1z56c5MUaSlYgAA

--0__=0ABBE1C0DFC2715D8f9e8a93df938690918c0ABBE1C0DFC2715D--



Received: by above.proper.com (8.11.6/8.11.3) id g11EblN06071 for ietf-pkix-bks; Fri, 1 Feb 2002 06:37:47 -0800 (PST)
Received: from mtiwmhc25.worldnet.att.net (mtiwmhc25.worldnet.att.net [204.127.131.50]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g11Ebj306067 for <[e-mail]>; Fri, 1 Feb 2002 06:37:45 -0800 (PST)
Received: from tsg1 ([12.81.71.28]) by mtiwmhc25.worldnet.att.net (InterMail vM.4.01.03.27 201-229-121-127-20010626) with SMTP id <20020201143730.CYQR28721.mtiwmhc25.worldnet.att.net@tsg1>; Fri, 1 Feb 2002 14:37:30 +0000
Message-ID: <039701c1ab2d$ef4be110$020aff0c@tsg1>
From: "todd glassey" <[e-mail]>
To: "Peter Sylvester" <[e-mail]>, <[e-mail]>
References: <[e-mail]>
Subject: Re: TSP interop update
Date: Fri, 1 Feb 2002 06:37:10 -0800
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 6.00.2600.0000
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
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>

Or perhaps a graphical use model needs to be constructed showing the
decision points in the protocol and its use - otherwise how could we really
be sure ? Adding a statement of use, intent and constraints - no one seems
to want to do this? Why?

Todd
----- Original Message -----
From: "Peter Sylvester" <[e-mail]>
To: <[e-mail]>
Sent: Friday, February 01, 2002 3:03 AM
Subject: Re: TSP interop update


>
> folks,
>
> May I remind that my intervention addressed the situation that
> there are several phrases 3161 regarding the Policy ID,
> one of them was changed to a MUST which seems to me
> having the effect that the three sentences are no longer
> consistent.
>
> If nobody agrees with me then I might take a break and
> a course in IETF English or else.
>
> If people agree that the three phrases need to be changed,
> then :
>
> I had expressed my preference of a solution.
>
> Note also that in earlier drafts the OID was a "PolicyInformation".
>
> Peter
>
>



Received: by above.proper.com (8.11.6/8.11.3) id g11ESaK05163 for ietf-pkix-bks; Fri, 1 Feb 2002 06:28:36 -0800 (PST)
Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g11ESY305154 for <[e-mail]>; Fri, 1 Feb 2002 06:28:34 -0800 (PST)
Received: from lvt-mail.frlv.bull.fr (lvt-mail.frlv.bull.fr [129.184.62.223]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id PAA16584; Fri, 1 Feb 2002 15:30:00 +0100
Received: from bull.net (frlva3786.frlv.bull.fr [129.184.37.97]) by lvt-mail.frlv.bull.fr (8.9.2/8.9.1) with ESMTP id PAA15642; Fri, 1 Feb 2002 15:27:58 +0100
Message-ID: <[e-mail]>
Date: Fri, 01 Feb 2002 15:27:55 +0100
From: Denis Pinkas <[e-mail]>
Organization: Integris. A Bull Company
X-Mailer: Mozilla 4.7 [fr] (Win98; I)
X-Accept-Language: fr
MIME-Version: 1.0
To: Massimiliano Pala <[e-mail]>
CC: [e-mail], Tom Gindin <[e-mail]>
Subject: Re: draft-ietf-pkix-pi
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[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>

Massimiliano,

Your e-mail was sent yesterday. You are quite impatient to get an anwser.

Some quick comments:

1) The type of permanent identifier being used should rather be either an
  OID or a "persistant URL" (for the XML world that uses persitant URLs). 
  This would certainly please Tom Guidin, my co-editor. :-) 

  The full text identifier (identifierDesc) you propose would be subject 
  to collisions and does not add anything: Permanent Identifiers are not 
  for human users but machines.

2) The novelty you propose is to allow the use of a hash of the value
  instead of the value itself, without a rational but one reason has been
  given by Roberto Opazo Gazmuri on January 30 about the case of Hong Kong.

  The hash can really hide the value if the value is long enough. It would 
  be interresting first to provide some figures about how long it would take
  to invert a hash value, e.g. for the Hong Kong Identifier (HKID) case.

Should the WG decide to support a hash of the value (in addtion to the value
itself), we could avoid overloading the syntax by simply defining an OID
that tells that the value is the hash of, e.g., the HKID instead of the 
value of the HKID itsef.

Denis  


> Hi all,
> 
> no comments about my previous message on the subject ??? All of them are
> to be thrown off or there is something worth discussing ?
> 
> Let me know.
> 
> Can we submit a new version of the draft with proposed changes included ?

Within the IETF the rule is to submit change proposals to the editors so
they can incorporate them in the documents. So you should not submit a full
new version of the draft, but you can certainly propose detailed changes, as
you have already done. 

Denis

> --
> 
> C'you,
> 
>         Massimiliano Pala
> 
> --o-------------------------------------------------------------------------
> Massimiliano Pala [OpenCA Project Manager]               madwolf at cpan.org
>                                                        madwolf at openca.org
> http://www.openca.org                             madwolf at hackmasters.net
> http://openca.sourceforge.net                    Mobile: [phone]


Received: by above.proper.com (8.11.6/8.11.3) id g11EGWt04304 for ietf-pkix-bks; Fri, 1 Feb 2002 06:16:32 -0800 (PST)
Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g11EGV304298 for <[e-mail]>; Fri, 1 Feb 2002 06:16:31 -0800 (PST)
Received: from lvt-mail.frlv.bull.fr (lvt-mail.frlv.bull.fr [129.184.62.223]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id PAA23192; Fri, 1 Feb 2002 15:17:57 +0100
Received: from bull.net (frlva3786.frlv.bull.fr [129.184.37.97]) by lvt-mail.frlv.bull.fr (8.9.2/8.9.1) with ESMTP id PAA18542; Fri, 1 Feb 2002 15:15:54 +0100
Message-ID: <[e-mail]>
Date: Fri, 01 Feb 2002 15:15:51 +0100
From: Denis Pinkas <[e-mail]>
Organization: Integris. A Bull Company
X-Mailer: Mozilla 4.7 [fr] (Win98; I)
X-Accept-Language: fr
MIME-Version: 1.0
To: Peter Gutmann <[e-mail]>
CC: [e-mail]
Subject: Re: TSP interop update
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>

Peter,

> Denis Pinkas <[e-mail]> writes:
> >IF, I did say "IF", we go into that direction, then it would mean changing the
> >reqPolicy field in TimeStampReq by allowing a sequence of TSA policies instead
> >of a single policy.
> >
> >Would this fit the concern from Peter ?
> 
> To some extent, although you'd need to allow anyPolicy to allow the client to
> specify that if it can't get an exact match, anything will do.  

If anything will do, then the client does not need to request any specific
policy. 

:-)

> Consider for
> example electronic tax filing, in which I have to get my submission timestamped
> to prove I filed on time.  Before I submit the return to irs.gov I go to
> time.gov and get my return stamped.  Ideally I'd want it notarised under the
> 2002 tax policy, or failing that the 2000 tax policy, or the general tax
> policy, but if all else fails I can probably get it done under the dog-license
> policy because if it goes to court all that matters is that it's timestamped.
> If it was under any of the standard tax policies I wouldn't need to go to
> court, but the dog-license policy is always better than having nothing at all.
> 
> However:
> 
> It's still making the decision at the wrong place.  Instead of the client being
> able to decide what's acceptable, it now has to communicate more and more state
> information to the server and still ask the server to make the decision for it.
> It's turning into an uglier and uglier kludge because the client, who should be
> making the decision, is banned from doing so, so all it can do is throw a
> mountain of state at the server and ask it to make the decision for it.  In the
> case of the tax-timestamping above I can easily encode this process at the
> client, but I have no idea how I'd communicate that decision-making process to
> the server.  The real solution, which is relatively straightforward, is to
> allow the client to device what it wants to accept, not to require the server
> to make the decision for it.

In a negotiation protocol, the client states what it is ready to accept and
mentions its order of preferences. Then the server chooses among the list.

Denis
 
> Peter.


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g11EF3404264 for ietf-pkix-bks; Fri, 1 Feb 2002 06:15:03 -0800 (PST)
Received: from mail.smarttrust.com ([213.212.5.232]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g11EF1304259 for <[e-mail]>; Fri, 1 Feb 2002 06:15:01 -0800 (PST)
Received: from sek43.smarttrust.com ([172.16.0.43]) by mail.smarttrust.com with Microsoft SMTPSVC(5.0.2195.2966); Fri, 1 Feb 2002 15:14:56 +0100
X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Subject: RE: Candidate for moving OCSP to a Draft Standard
Date: Fri, 1 Feb 2002 15:14:58 +0100
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Candidate for moving OCSP to a Draft Standard
Thread-Index: AcGrF+rB8172HPNaTkaAiiPKRJ1ECwAD5Bhw
From: "Olle Mulmo" <[e-mail]>
To: "Denis Pinkas" <[e-mail]>, "Ambarish Malpani" <[e-mail]>
Cc: <[e-mail]>
X-OriginalArrivalTime: 01 Feb 2002 14:14:56.0955 (UTC) FILETIME=[D390E8B0:01C1AB2A]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id g11EF2304260
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>

I don't quite agree with Denis on assuming a few hours to be OK in a general scheme. Clearly, the value of the maximum lag time on the producedAt field in an OCSP response must be defined in the Operational Requirements section of the CA's CPS -- to be defined and thought of months (or at least a few hours...) before the OCSP service is to come online.

However, revoked is revoked is revoked: shouldn't a client accept an OCSP response containing a SingleResponse with (status=revoked and reasonCode!=onHold), even though the producedAt field is long by gone?

Regards,

Olle

-----Original Message-----
From: Denis Pinkas [mailto:[e-mail]]
Sent: Friday, February 01, 2002 10:34 AM
To: Ambarish Malpani
Cc: '[e-mail]'
Subject: Re: Candidate for moving OCSP to a Draft Standard



Ambarish,,

> Hi Guys,

>     Here is a candidate for moving OCSP to a Draft Standard. There
> are no changes in the bytes that go across the wire - basically all
> clarifications.
 
> A list of all the changes between this document and RFC 2560 are
> in Appendix D (reproduced here).
 
> I hope we can get to the Draft Standard state before this IETF.

I have the following remarks:

The current text states:

   7. The producedAt time in the response is sufficiently recent.

   8. If the request contained a nonce, the response must contain the
      same nonce (see section 4.4.1).

If the nonce is used, then the value of the producedAt field does not matter 
anymore and no test needs to be made on it. So I would first propose to 
invert items 8 and 7.

Then it is questionable on how implementers can interpret what "sufficiently
recent" means for the producedAt time and set a value (a few minutes, hours 
or days ?).
 
In fact if no pre-computed response were being used, this could simply be
set to a few minutes.

If pre-computed responses are being used, setting it to a few minutes will
probably lead to rejections.

This means that using pre-computed responses is a real problem, since this
value cannot even be fixed but is even dependent upon each server supporting
pre-computed responses.

The easiest way would be to delete the support of pre-computed responses or
set a maximum limit in the standard. The basic question would first be: who
is using pre-computed responses with which retention period in the cache ?
If no-one is using it, then the solution is simple. :-)

In the following proposal, I have not yet "crossed the line".  

Proposed rephrasing:

[Prior to accepting a signed response as valid, OCSP clients SHALL
 confirm that:]

   7. If the request contained a nonce, the response contains the
      same nonce (see section 4.4.1).

   8. If the request did not contained a nonce, the producedAt time 
      in the response is considered as "sufficiently recent". 
      This means computing the difference between the current time 
      and the producedAt time and then comparing it with a time 
      period that will be set to a few minutes, or to a few hours 
      in the case where the OCSP servers accessed by the client 
      are supporting pre-computed responses. 

      Note: when pre-computed responses are being used by servers,
      it may be hard for clients to set a single maximum common value.


Denis

 
> Regards,
> Ambarish
> 
> Appendix D. Changes
> 
>    This section contains the differences in this document from RFC 2560
> 
>    - Mention Appendix D in Section 1 and added an appendix D.
>    - Added a paragraph in Section 1 equating a client with a requestor and
>      server with responder
>    - Section 2.2 - clarified the explanation of good, revoked and unknown
>    - Added Section 2.8 requiring clients and responders to support HTTP
>    - Added a note at the end of section 3.2, which allows a client to
>      accept a response that provides statuses for only some of the
>      certificates requested.
>    - Clarified the issuerKeyHash in Section 4.1.1
>    - Added "DER encoding of the" in the third paragraph Section 4.1.2
>    - Section 4.2.1 - clarified that the signature is on the DER encoding
>      of tbsResponseData (and not its hash)
>    - Section 4.2.1 - specified the use of the certs field in
>      BasicOCSPResponse
>    - Section 4.2.1 - clarified how you compute KeyHash when providing
>      the ResponderID byKey.
>    - Section 4.2.2.2 - removed an extra quote in point 3
>    - Section 4.3 - Made RSA mandatory. Also changed the references to
>      point to the appropriate documents. Added the references to the
>      References section
>    - Section 4.4.1 - Clarified that a nonce in the request MUST be
>    - included in the response for the response to be trusted.
>    - Appendix A - A.1.1. - Got rid of support for GET - not sure that
>      anybody does it. It is also unclear how a server would tell a
>      client to ever use GET in the URL specified in the AIA
>    - Add the module tag for the ASN.1 in OCSP
>    - Made SEQUENCE OF Certificate OPTIONAL to SEQUENCE SIZE(1..MAX) of
>      Certificate OPTIONAL in the ASN.1 defintions. The avoids the
>      ambiguity of whether the optional sequence may be present, but
>      with 0 elements. This was done by definining a new element called
>      Certificates, which is used. Look at the defintion of both
>      Signature and BasicOCSPResponse.
>    - Clarified the meaning of nextUpdate being absent (Section 2.4)
>    - Fixed typo where we referred to id-ad-ocspSigning, to reflect the
>      correct OID - id-kp-OCSPSigning
>    - Clarified criteria for response acceptance (Section 3.2)
>    - Added a line in Section 5 indicating that nonces can be used to
>      prevent prevent attacks using replays of precomputed responses
>    - Added a paragraph in Section 5 requiring nonces to be unique for
>      replay protection
> 
> ---------------------------------------------------------------------
> Ambarish Malpani
> Architect                                                650.567.5457
> ValiCert, Inc.                                  [e-mail]
> 339 N. Bernardo Ave.                          http://www.valicert.com
> Mountain View, CA 94043
> 
>   ----------------------------------------------------------------------------
>                         Name: OCSP-draft-03.txt
>    OCSP-draft-03.txt    Type: Plain Text (text/plain)
>                     Encoding: quoted-printable


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g11DubA02716 for ietf-pkix-bks; Fri, 1 Feb 2002 05:56:37 -0800 (PST)
Received: from taurus.polito.it (taurus.polito.it [130.192.1.8]) by above.proper.com (8.11.6/8.11.3) with SMTP id g11DuZ302712 for <[e-mail]>; Fri, 1 Feb 2002 05:56:36 -0800 (PST)
Received: (qmail 28197 invoked from network); 1 Feb 2002 13:58:16 -0000
Received: from unknown (HELO RAMUNNO) (130.192.1.223) by taurus.polito.it with SMTP; 1 Feb 2002 13:58:16 -0000
Reply-To: <[e-mail]>
From: "Gianluca Ramunno" <[e-mail]>
To: "'Denis Pinkas'" <[e-mail]>
Cc: "'Antonio Lioy'" <[e-mail]>, "'Peter Gutmann'" <[e-mail]>, <[e-mail]>, <[e-mail]>
Subject: RE: TSP interop update
Date: Fri, 1 Feb 2002 14:55:31 +0100
Message-ID: <000001c1ab28$1d6cddc0$df01c082@RAMUNNO>
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 CWS, Build 9.0.2416 (9.0.2911.0)
Importance: Normal
In-Reply-To: <[e-mail]>
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
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>

Denis,

>
>
> IF, I did say "IF", we go into that direction, then it would
> mean changing
> the reqPolicy field in TimeStampReq by allowing a sequence of
> TSA policies
> instead of a single policy.
>

why not to introduce in the request message an extension to express the
ordered list containing the preferred policies?

This way, expressing which policy is preferred or requested could be a
little more tricky, but it could achieve the task to preserve backward
compatibility.

Gianluca



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g11DPO901860 for ietf-pkix-bks; Fri, 1 Feb 2002 05:25:24 -0800 (PST)
Received: from femail22.sdc1.sfba.home.com (femail22.sdc1.sfba.home.com [24.0.95.147]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g11DPN301856 for <[e-mail]>; Fri, 1 Feb 2002 05:25:23 -0800 (PST)
Received: from SJOSEPH ([68.55.160.145]) by femail22.sdc1.sfba.home.com (InterMail vM.4.01.03.20 201-229-121-120-20010223) with SMTP id <20020201132524.SLM14927.femail22.sdc1.sfba.home.com@SJOSEPH>; Fri, 1 Feb 2002 05:25:24 -0800
Message-ID: <00d701c1ab23$665b9e90$6501a8c0@SJOSEPH>
From: "Al Arsenault" <[e-mail]>
To: "Massimiliano Pala" <[e-mail]>, <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Subject: Re: draft-ietf-pkix-pi
Date: Fri, 1 Feb 2002 08:21:46 -0500
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.50.4133.2400
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
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>

Massimiliano,

    A few comments on your proposal.  Comments are in-line, prefaced by my
initials, "AWA".

----- Original Message -----
From: "Massimiliano Pala" <[e-mail]>
To: <[e-mail]>
Sent: Thursday, January 31, 2002 5:56 AM
Subject: draft-ietf-pkix-pi


> Hi all,
>
> I have some points I'd like to highlight about the PI. Current comments
are
> made against the http://www.imc.org/draft-ietf-pkix-pi.
>
> First of all some general considerations. My personal point on the PI is
> that this should be used only within the subjectAltName ext. and this to
> prevent the Subject DN from ever growing and keep as human readable as
> possible. I know that there could be established policies following the
> Subject DN's but I support this option.
>

AWA:  I agree with this.

> Let's get through the draft in order.
>
> I would change the paragraph:
>
> << A permanent identifier is a name assigned by an organization,
>    unique within that organization, that singles out a particular
>    individual from all other individuals.  A CA which includes such
>    an identifier in a certificate is certifying that any different
>    public key certificate containing that identifier refers to the
>    same individual. >>
>
>
> Adding a phrase to clearly state that the "public key certificate..."
> is from the CA in subject, something like:
>
> << A permanent identifier is a name assigned by an organization,
>    unique within that organization, that singles out a particular
>    individual from all other individuals.  A CA which includes such
>    an identifier in a certificate is certifying that any different
>    public key certificate issued by that CA and containing that
>    identifier refers to the same individual. >>
>

AWA:  I agree.

> I would like to extend the structure of the PersonalIdentifier to
> something like this:
>
>    PermanentIdentifier ::=     SEQUENCE {
>            assignerAuthority        GeneralName OPTIONAL,
>            identifierDesc           Name,
>            identifierValue          IdentifierValue }
>
>    IdentifierValue ::= CHOICE {
>            permanentId [1]     Name,
>    permanentIdHash [2]     IDHash }
>
>    PermanentIdHash ::= SEQUENCE {
>            identifierHash     OCTET STRING,  --- original identifier's
Hash
>    identifierHashAlgorithm  AlgorithmIdentifier }
>
> (there can be errors as I am not a master in structure definition :-D )
>
> This structure (if correct) could solve problems tied to different current
> situations, indeed there is the possibility to hide the "real" assigned ID
> using the hash value instead. Usage of the Hash instead of the "real" ID
> is therefore clearly stated when used. (this could be required if the
original
> value carries sensible data like date of birth, etc... ).
>

AWA:  I don't know that we can/should necessarily define a particular
structure for this.  We've already seen on this list that a number of
different places have different formats and requirements for the uses of
PI's; it's not going to be easy to find a single structure that will fit
them all.

AWA:  The use of a hash to protect PI's that are supposed to be private data
is generally insufficient. The problem is that the PI space is generally not
that big; it's easy enough for an attacker to build a table of the hashes of
all possible PIs, and then pick the values out of the certificates.  For
example, in the US, the most likely PI would be the Social Security Number,
which consists of 9 digits.  So the total SSN space consists of (10 to the
9th) values, which means that hashing all possible SSNs represents only
about 30 bits worth of work. (I've been told, but don't know for a fact,
that the SSN space is actually smaller, because not all digits are
independent.  If that's the case, it's easier for the attacker.)

AWA: That's the reason for the scheme used in Hong Kong, that I pointed out
earlier.  If I understand correctly, there are only about 26 million unique
HKIDs.  One of the folks in our HK office told me that, several years ago,
they constructed the table of all possible hashed-HKID values on a 200-mHz
Pentium I machine, using not-fully-optimized code, in about 15 minutes.  It
clearly ruled out the use of a hash by itself to protect the data!

> The identifierDesc field is used to give a text identifier of the id used,
> i.e. "RUN" or "ABN", depending on the description adopted by the
> assignerAuthority
> (I am not sure if this could be coded using different techniques, if so,
please,
> point it out - thanks).
>
> I'd also change the word "responsible" when talking about the
> assignerAuthority some paragraph behind: this to state that this field
> carries an indication not directly stated by the assignerAuthority's
> subject (it is no liable for the contents of the field).
>
> It could also be simply stripped off, something like:
>
> << The assignerAuthority field of this attribute, when present,
>    identifies the organization assigning the content of the identifier
>    field. When the assignerAuthority field is missing, the assignee
>    Authority is the CA itself and it is assumed  to be the issuer
>    name of the certificate. >>
>
> Some comments ? Denis ?
>
> --
>
> C'you,
>
> Massimiliano Pala


        Al Arsenault
        Chief Security Architect
        Diversinet Corp.





Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g11CHTk27145 for ietf-pkix-bks; Fri, 1 Feb 2002 04:17:29 -0800 (PST)
Received: from SOTTMXS01.entrust.com ([216.191.251.35]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g11CHS327141 for <[e-mail]>; Fri, 1 Feb 2002 04:17:28 -0800 (PST)
Received: by SOTTMXS01.entrust.com with Internet Mail Service (5.5.2653.19) id <1A7CDH1G>; Fri, 1 Feb 2002 07:18:57 -0500
Message-ID: <8D7EC1912E25D411A32100D0B7695397B4180E@SCYGMXS01>
From: Santosh Chokhani <[e-mail]>
To: "'[e-mail]'" <[e-mail]>
Subject: RE: Candidate for moving OCSP to a Draft Standard
Date: Fri, 1 Feb 2002 07:15:38 -0500 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1AB1A.28C67A40"
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>

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_01C1AB1A.28C67A40
Content-Type: text/plain

All:

Please note the following:

1.  producedAt will always be at or later than thisUpdate.

2.  The current RFC has a rule for thisUpdate with language similar to the
one proposed for thisUpdate.

Simple arithmetic tells me that if we want to caveat the producedAt rule, we
should have the same caveat for thisUpdate rule.

That said, I am happy with the language proposed by Ambarish for producedAt.

However, if the community feels that the language for producedAt should
change, then we should make even more of a change for thisUpdate language
(since thisUpdate is always earlier than producedAt).

-----Original Message-----
From: Denis Pinkas [mailto:[e-mail]]
Sent: Friday, February 01, 2002 4:34 AM
To: Ambarish Malpani
Cc: '[e-mail]'
Subject: Re: Candidate for moving OCSP to a Draft Standard



Ambarish,,

> Hi Guys,

>     Here is a candidate for moving OCSP to a Draft Standard. There
> are no changes in the bytes that go across the wire - basically all
> clarifications.
 
> A list of all the changes between this document and RFC 2560 are
> in Appendix D (reproduced here).
 
> I hope we can get to the Draft Standard state before this IETF.

I have the following remarks:

The current text states:

   7. The producedAt time in the response is sufficiently recent.

   8. If the request contained a nonce, the response must contain the
      same nonce (see section 4.4.1).

If the nonce is used, then the value of the producedAt field does not matter

anymore and no test needs to be made on it. So I would first propose to 
invert items 8 and 7.

Then it is questionable on how implementers can interpret what "sufficiently
recent" means for the producedAt time and set a value (a few minutes, hours 
or days ?).
 
In fact if no pre-computed response were being used, this could simply be
set to a few minutes.

If pre-computed responses are being used, setting it to a few minutes will
probably lead to rejections.

This means that using pre-computed responses is a real problem, since this
value cannot even be fixed but is even dependent upon each server supporting
pre-computed responses.

The easiest way would be to delete the support of pre-computed responses or
set a maximum limit in the standard. The basic question would first be: who
is using pre-computed responses with which retention period in the cache ?
If no-one is using it, then the solution is simple. :-)

In the following proposal, I have not yet "crossed the line".  

Proposed rephrasing:

[Prior to accepting a signed response as valid, OCSP clients SHALL
 confirm that:]

   7. If the request contained a nonce, the response contains the
      same nonce (see section 4.4.1).

   8. If the request did not contained a nonce, the producedAt time 
      in the response is considered as "sufficiently recent". 
      This means computing the difference between the current time 
      and the producedAt time and then comparing it with a time 
      period that will be set to a few minutes, or to a few hours 
      in the case where the OCSP servers accessed by the client 
      are supporting pre-computed responses. 

      Note: when pre-computed responses are being used by servers,
      it may be hard for clients to set a single maximum common value.


Denis

 
> Regards,
> Ambarish
> 
> Appendix D. Changes
> 
>    This section contains the differences in this document from RFC 2560
> 
>    - Mention Appendix D in Section 1 and added an appendix D.
>    - Added a paragraph in Section 1 equating a client with a requestor and
>      server with responder
>    - Section 2.2 - clarified the explanation of good, revoked and unknown
>    - Added Section 2.8 requiring clients and responders to support HTTP
>    - Added a note at the end of section 3.2, which allows a client to
>      accept a response that provides statuses for only some of the
>      certificates requested.
>    - Clarified the issuerKeyHash in Section 4.1.1
>    - Added "DER encoding of the" in the third paragraph Section 4.1.2
>    - Section 4.2.1 - clarified that the signature is on the DER encoding
>      of tbsResponseData (and not its hash)
>    - Section 4.2.1 - specified the use of the certs field in
>      BasicOCSPResponse
>    - Section 4.2.1 - clarified how you compute KeyHash when providing
>      the ResponderID byKey.
>    - Section 4.2.2.2 - removed an extra quote in point 3
>    - Section 4.3 - Made RSA mandatory. Also changed the references to
>      point to the appropriate documents. Added the references to the
>      References section
>    - Section 4.4.1 - Clarified that a nonce in the request MUST be
>    - included in the response for the response to be trusted.
>    - Appendix A - A.1.1. - Got rid of support for GET - not sure that
>      anybody does it. It is also unclear how a server would tell a
>      client to ever use GET in the URL specified in the AIA
>    - Add the module tag for the ASN.1 in OCSP
>    - Made SEQUENCE OF Certificate OPTIONAL to SEQUENCE SIZE(1..MAX) of
>      Certificate OPTIONAL in the ASN.1 defintions. The avoids the
>      ambiguity of whether the optional sequence may be present, but
>      with 0 elements. This was done by definining a new element called
>      Certificates, which is used. Look at the defintion of both
>      Signature and BasicOCSPResponse.
>    - Clarified the meaning of nextUpdate being absent (Section 2.4)
>    - Fixed typo where we referred to id-ad-ocspSigning, to reflect the
>      correct OID - id-kp-OCSPSigning
>    - Clarified criteria for response acceptance (Section 3.2)
>    - Added a line in Section 5 indicating that nonces can be used to
>      prevent prevent attacks using replays of precomputed responses
>    - Added a paragraph in Section 5 requiring nonces to be unique for
>      replay protection
> 
> ---------------------------------------------------------------------
> Ambarish Malpani
> Architect                                                650.567.5457
> ValiCert, Inc.                                  [e-mail]
> 339 N. Bernardo Ave.                          http://www.valicert.com
> Mountain View, CA 94043
> 
>
----------------------------------------------------------------------------
>                         Name: OCSP-draft-03.txt
>    OCSP-draft-03.txt    Type: Plain Text (text/plain)
>                     Encoding: quoted-printable

------_=_NextPart_001_01C1AB1A.28C67A40
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.2653.12">
<TITLE>RE: Candidate for moving OCSP to a Draft Standard</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>All:</FONT>
</P>

<P><FONT SIZE=3D2>Please note the following:</FONT>
</P>

<P><FONT SIZE=3D2>1.&nbsp; producedAt will always be at or later than =
thisUpdate.</FONT>
</P>

<P><FONT SIZE=3D2>2.&nbsp; The current RFC has a rule for thisUpdate =
with language similar to the one proposed for thisUpdate.</FONT>
</P>

<P><FONT SIZE=3D2>Simple arithmetic tells me that if we want to caveat =
the producedAt rule, we should have the same caveat for thisUpdate =
rule.</FONT></P>

<P><FONT SIZE=3D2>That said, I am happy with the language proposed by =
Ambarish for producedAt.</FONT>
</P>

<P><FONT SIZE=3D2>However, if the community feels that the language for =
producedAt should change, then we should make even more of a change for =
thisUpdate language (since thisUpdate is always earlier than =
producedAt).</FONT></P>

<P><FONT SIZE=3D2>-----Original Message-----</FONT>
<BR><FONT SIZE=3D2>From: Denis Pinkas [<A =
HREF=3D"mailto:[e-mail]">mailto:[e-mail]</A>]<=
/FONT>
<BR><FONT SIZE=3D2>Sent: Friday, February 01, 2002 4:34 AM</FONT>
<BR><FONT SIZE=3D2>To: Ambarish Malpani</FONT>
<BR><FONT SIZE=3D2>Cc: '[e-mail]'</FONT>
<BR><FONT SIZE=3D2>Subject: Re: Candidate for moving OCSP to a Draft =
Standard</FONT>
</P>
<BR>
<BR>

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

<P><FONT SIZE=3D2>&gt; Hi Guys,</FONT>
</P>

<P><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp; Here is a candidate for =
moving OCSP to a Draft Standard. There</FONT>
<BR><FONT SIZE=3D2>&gt; are no changes in the bytes that go across the =
wire - basically all</FONT>
<BR><FONT SIZE=3D2>&gt; clarifications.</FONT>
<BR><FONT SIZE=3D2>&nbsp;</FONT>
<BR><FONT SIZE=3D2>&gt; A list of all the changes between this document =
and RFC 2560 are</FONT>
<BR><FONT SIZE=3D2>&gt; in Appendix D (reproduced here).</FONT>
<BR><FONT SIZE=3D2>&nbsp;</FONT>
<BR><FONT SIZE=3D2>&gt; I hope we can get to the Draft Standard state =
before this IETF.</FONT>
</P>

<P><FONT SIZE=3D2>I have the following remarks:</FONT>
</P>

<P><FONT SIZE=3D2>The current text states:</FONT>
</P>

<P><FONT SIZE=3D2>&nbsp;&nbsp; 7. The producedAt time in the response =
is sufficiently recent.</FONT>
</P>

<P><FONT SIZE=3D2>&nbsp;&nbsp; 8. If the request contained a nonce, the =
response must contain the</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; same nonce (see =
section 4.4.1).</FONT>
</P>

<P><FONT SIZE=3D2>If the nonce is used, then the value of the =
producedAt field does not matter </FONT>
<BR><FONT SIZE=3D2>anymore and no test needs to be made on it. So I =
would first propose to </FONT>
<BR><FONT SIZE=3D2>invert items 8 and 7.</FONT>
</P>

<P><FONT SIZE=3D2>Then it is questionable on how implementers can =
interpret what &quot;sufficiently</FONT>
<BR><FONT SIZE=3D2>recent&quot; means for the producedAt time and set a =
value (a few minutes, hours </FONT>
<BR><FONT SIZE=3D2>or days ?).</FONT>
<BR><FONT SIZE=3D2>&nbsp;</FONT>
<BR><FONT SIZE=3D2>In fact if no pre-computed response were being used, =
this could simply be</FONT>
<BR><FONT SIZE=3D2>set to a few minutes.</FONT>
</P>

<P><FONT SIZE=3D2>If pre-computed responses are being used, setting it =
to a few minutes will</FONT>
<BR><FONT SIZE=3D2>probably lead to rejections.</FONT>
</P>

<P><FONT SIZE=3D2>This means that using pre-computed responses is a =
real problem, since this</FONT>
<BR><FONT SIZE=3D2>value cannot even be fixed but is even dependent =
upon each server supporting</FONT>
<BR><FONT SIZE=3D2>pre-computed responses.</FONT>
</P>

<P><FONT SIZE=3D2>The easiest way would be to delete the support of =
pre-computed responses or</FONT>
<BR><FONT SIZE=3D2>set a maximum limit in the standard. The basic =
question would first be: who</FONT>
<BR><FONT SIZE=3D2>is using pre-computed responses with which retention =
period in the cache ?</FONT>
<BR><FONT SIZE=3D2>If no-one is using it, then the solution is simple. =
:-)</FONT>
</P>

<P><FONT SIZE=3D2>In the following proposal, I have not yet =
&quot;crossed the line&quot;.&nbsp; </FONT>
</P>

<P><FONT SIZE=3D2>Proposed rephrasing:</FONT>
</P>

<P><FONT SIZE=3D2>[Prior to accepting a signed response as valid, OCSP =
clients SHALL</FONT>
<BR><FONT SIZE=3D2>&nbsp;confirm that:]</FONT>
</P>

<P><FONT SIZE=3D2>&nbsp;&nbsp; 7. If the request contained a nonce, the =
response contains the</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; same nonce (see =
section 4.4.1).</FONT>
</P>

<P><FONT SIZE=3D2>&nbsp;&nbsp; 8. If the request did not contained a =
nonce, the producedAt time </FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; in the response is =
considered as &quot;sufficiently recent&quot;. </FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; This means computing =
the difference between the current time </FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; and the producedAt =
time and then comparing it with a time </FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; period that will be =
set to a few minutes, or to a few hours </FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; in the case where the =
OCSP servers accessed by the client </FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; are supporting =
pre-computed responses. </FONT>
</P>

<P><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Note: when =
pre-computed responses are being used by servers,</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; it may be hard for =
clients to set a single maximum common value.</FONT>
</P>
<BR>

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

<P><FONT SIZE=3D2>&nbsp;</FONT>
<BR><FONT SIZE=3D2>&gt; Regards,</FONT>
<BR><FONT SIZE=3D2>&gt; Ambarish</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Appendix D. Changes</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp; This section contains the =
differences in this document from RFC 2560</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp; - Mention Appendix D in =
Section 1 and added an appendix D.</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp; - Added a paragraph in =
Section 1 equating a client with a requestor and</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; server with =
responder</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp; - Section 2.2 - clarified the =
explanation of good, revoked and unknown</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp; - Added Section 2.8 requiring =
clients and responders to support HTTP</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp; - Added a note at the end of =
section 3.2, which allows a client to</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; accept a response =
that provides statuses for only some of the</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; certificates =
requested.</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp; - Clarified the issuerKeyHash =
in Section 4.1.1</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp; - Added &quot;DER encoding of =
the&quot; in the third paragraph Section 4.1.2</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp; - Section 4.2.1 - clarified =
that the signature is on the DER encoding</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; of =
tbsResponseData (and not its hash)</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp; - Section 4.2.1 - specified =
the use of the certs field in</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
BasicOCSPResponse</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp; - Section 4.2.1 - clarified =
how you compute KeyHash when providing</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; the ResponderID =
byKey.</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp; - Section 4.2.2.2 - removed =
an extra quote in point 3</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp; - Section 4.3 - Made RSA =
mandatory. Also changed the references to</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; point to the =
appropriate documents. Added the references to the</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; References =
section</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp; - Section 4.4.1 - Clarified =
that a nonce in the request MUST be</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp; - included in the response =
for the response to be trusted.</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp; - Appendix A - A.1.1. - Got =
rid of support for GET - not sure that</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; anybody does it. =
It is also unclear how a server would tell a</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; client to ever =
use GET in the URL specified in the AIA</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp; - Add the module tag for the =
ASN.1 in OCSP</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp; - Made SEQUENCE OF =
Certificate OPTIONAL to SEQUENCE SIZE(1..MAX) of</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Certificate =
OPTIONAL in the ASN.1 defintions. The avoids the</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ambiguity of =
whether the optional sequence may be present, but</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; with 0 elements. =
This was done by definining a new element called</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Certificates, =
which is used. Look at the defintion of both</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Signature and =
BasicOCSPResponse.</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp; - Clarified the meaning of =
nextUpdate being absent (Section 2.4)</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp; - Fixed typo where we =
referred to id-ad-ocspSigning, to reflect the</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; correct OID - =
id-kp-OCSPSigning</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp; - Clarified criteria for =
response acceptance (Section 3.2)</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp; - Added a line in Section 5 =
indicating that nonces can be used to</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; prevent prevent =
attacks using replays of precomputed responses</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp; - Added a paragraph in =
Section 5 requiring nonces to be unique for</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; replay =
protection</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; =
---------------------------------------------------------------------</F=
ONT>
<BR><FONT SIZE=3D2>&gt; Ambarish Malpani</FONT>
<BR><FONT SIZE=3D2>&gt; =
Architect&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;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp; 650.567.5457</FONT>
<BR><FONT SIZE=3D2>&gt; ValiCert, =
Inc.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
[e-mail]</FONT>
<BR><FONT SIZE=3D2>&gt; 339 N. Bernardo =
Ave.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp; <A HREF=3D"http://www.valicert.com" =
TARGET=3D"_blank">http://www.valicert.com</A></FONT>
<BR><FONT SIZE=3D2>&gt; Mountain View, CA 94043</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp; =
------------------------------------------------------------------------=
----</FONT>
<BR><FONT =
SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp; Name: OCSP-draft-03.txt</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp; OCSP-draft-03.txt&nbsp;&nbsp;&=
nbsp; Type: Plain Text (text/plain)</FONT>
<BR><FONT =
SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Encoding: =
quoted-printable</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C1AB1A.28C67A40--


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g11B45d23772 for ietf-pkix-bks; Fri, 1 Feb 2002 03:04:05 -0800 (PST)
Received: from mail.hackmasters.net ([217.133.235.63]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g11B3l323763 for <[e-mail]>; Fri, 1 Feb 2002 03:03:49 -0800 (PST)
Received: from hackmasters.net (galadriel.mpnet.hackmasters.net [10.5.122.180]) by mail.hackmasters.net (Postfix) with ESMTP id AB9C69289 for <[e-mail]>; Fri,  1 Feb 2002 12:07:58 +0100 (CET)
Message-ID: <[e-mail]>
Date: Fri, 01 Feb 2002 11:58:49 +0100
From: Massimiliano Pala <[e-mail]>
Organization: OpenCA
X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.2.19 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: [e-mail]
Subject: Re: draft-ietf-pkix-pi
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms00CF14B10D648459252D8621"
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>

This is a cryptographically signed message in MIME format.

--------------ms00CF14B10D648459252D8621
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Hi all,

no comments about my previous message on the subject ??? All of them are
to be thrown off or there is something worth discussing ?

Let me know.

Can we submit a new version of the draft with proposed changes included ?

-- 

C'you,

	Massimiliano Pala

--o-------------------------------------------------------------------------
Massimiliano Pala [OpenCA Project Manager]               madwolf at cpan.org
                                                       madwolf at openca.org
http://www.openca.org                             madwolf at hackmasters.net
http://openca.sourceforge.net                    Mobile: [phone]
--------------ms00CF14B10D648459252D8621
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIIF+gYJKoZIhvcNAQcCoIIF6zCCBecCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC
BFowggRWMIIDPqADAgECAgIDITANBgkqhkiG9w0BAQQFADBAMSAwHgYDVQQDExdDZXJ0aWZp
Y2F0aW9uIEF1dGhvcml0eTEPMA0GA1UEChMGT3BlbkNBMQswCQYDVQQGEwJJVDAeFw0wMTAy
MjcxMzQ0NTRaFw0wMjAyMjcxMzQ0NTRaMIGFMSYwJAYJKoZIhvcNAQkBFhdtYWR3b2xmQGhh
Y2ttYXN0ZXJzLm5ldDEaMBgGA1UEAxMRTWFzc2ltaWxpYW5vIFBhbGExFDASBgNVBAsTC09w
ZW5DQSBVc2VyMRwwGgYDVQQKExNPcGVuQ0EgT3JnYW5pemF0aW9uMQswCQYDVQQGEwJJVDCB
nzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAs7c/i7zt8oRbF/MO3/Xq1bWb2h3y5VdRsm0E
MT22pFX7yjaKp4pSF36NDPJb4ss6aqqGLSiyyI/Wy+7124JDOzXhY4S0XPbZ6MmLUy4vp3Ze
+jmgJNyO2j+BtRQarUaEno+JIUizU4pcEtUO4BaPkxRqaL02raR61i3+foCQb/MCAwEAAaOC
AZYwggGSMAkGA1UdEwQCMAAwEQYJYIZIAYb4QgEBBAQDAgWgMAsGA1UdDwQEAwIF4DAmBglg
hkgBhvhCAQ0EGRYXT3BlbkNBIFVzZXIgQ2VydGlmaWNhdGUwHQYDVR0OBBYEFPtjrGNl7QbD
nNY0rT2UFmtDF8doMGgGA1UdIwRhMF+AFAtL08ix9MbKXM950at8v/yRSMd7oUSkQjBAMSAw
HgYDVQQDExdDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEPMA0GA1UEChMGT3BlbkNBMQswCQYD
VQQGEwJJVIIBADAJBgNVHREEAjAAMAkGA1UdEgQCMAAwNAYJYIZIAYb4QgEEBCcWJWh0dHBz
Oi8vd3d3Lm9wZW5jYS5vcmcvY2dpLWJpbi9nZXRjcmwwNAYJYIZIAYb4QgEDBCcWJWh0dHBz
Oi8vd3d3Lm9wZW5jYS5vcmcvY2dpLWJpbi9nZXRjcmwwMgYJYIZIAYb4QgEHBCUWI2h0dHBz
Oi8vd3d3Lm9wZW5jYS5vcmc6NDQ0My9yZW5ld2FsMA0GCSqGSIb3DQEBBAUAA4IBAQBbbzeN
MZcl2K68tfAzCD72PB+hnwBuFBebVwVg5vWNJh/Zu0y2HAzy5pv9EcqLwS/2d5lqhwzG6a2H
W0HrrPbKxaLdQ4bZzDLG6zUohXzlCH0l2sq4BVuQF/dLVY/Gj2T9azYE0Yf2pOVG1VCC7zCR
9EtXsM51MbHzgxvOpUZD9sti2Y7UHmwxpr8vYodNLGQgR0B4tyWgCo5/LWyRk+u+4S0fFLsl
FISFpqNsTtDQxRWvmDD8BZhH5OFMHgCN73Wsngq2Hopo7QeKR2Ghwc+cIZHtk2Huoaj059Nz
/WXixzezZm5j3G1JWAzHfLo17n+nDdbF+OBODEhhuSIIBMI+MYIBaDCCAWQCAQEwRjBAMSAw
HgYDVQQDExdDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEPMA0GA1UEChMGT3BlbkNBMQswCQYD
VQQGEwJJVAICAyEwCQYFKw4DAhoFAKB6MBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwGwYJ
KoZIhvcNAQkPMQ4wDDAKBggqhkiG9w0DBzAcBgkqhkiG9w0BCQUxDxcNMDIwMjAxMTA1ODQ5
WjAjBgkqhkiG9w0BCQQxFgQUn8yOXxyfff2dtsytRI0OGZV3/bIwDQYJKoZIhvcNAQEBBQAE
gYBKJWaLuUIhXqblU09aop1TpAFBMqLZr1DL/iG0JUAD/sCikteHOi44j9BgDCEPH/yz5qMN
xLfwNsW5CD9u+9iN2F0YRme68wGZmCGaiAuQKAlmbSqvlCS5I+wEe4TOBTIJNmPob4FUqnIR
bKD8H/cXhFT48pFSqIhoIZK1NqAL8g==
--------------ms00CF14B10D648459252D8621--



Received: by above.proper.com (8.11.6/8.11.3) id g11B3SU23758 for ietf-pkix-bks; Fri, 1 Feb 2002 03:03:28 -0800 (PST)
Received: from edelweb.fr (edelweb.fr [212.234.46.16]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g11B3Q323753 for <[e-mail]>; Fri, 1 Feb 2002 03:03:26 -0800 (PST)
Received: from champagne.edelweb.fr (localhost.edelweb.fr [127.0.0.1]) by edelweb.fr with ESMTP id MAA25981 for <[e-mail]>; Fri, 1 Feb 2002 12:03:26 +0100 (MET)
Received: from champagne.edelweb.fr (champagne.edelweb.fr [193.51.14.161]) by edelweb.fr (nospam/1.3); Fri, 1 Feb 2002 12:03:26 +0100 (MET)
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 MAA29347 for <[e-mail]>; Fri, 1 Feb 2002 12:03:24 +0100 (MET)
From: Peter Sylvester <[e-mail]>
Received: (sylvest@localhost) by emeriau.edelweb.fr (8.7.6/8.6.6) id MAA10307 for [e-mail]; Fri, 1 Feb 2002 12:03:24 +0100 (MET)
Date: Fri, 1 Feb 2002 12:03:24 +0100 (MET)
Message-Id: <[e-mail]>
To: [e-mail]
Subject: Re: TSP interop update
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>

folks,

May I remind that my intervention addressed the situation that
there are several phrases 3161 regarding the Policy ID,
one of them was changed to a MUST which seems to me 
having the effect that the three sentences are no longer
consistent. 

If nobody agrees with me then I might take a break and
a course in IETF English or else.

If people agree that the three phrases need to be changed,
then :

I had expressed my preference of a solution.

Note also that in earlier drafts the OID was a "PolicyInformation".

Peter
 



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g11Ad0U22133 for ietf-pkix-bks; Fri, 1 Feb 2002 02:39:00 -0800 (PST)
Received: from ocasey.baltimore.com (ocasey.baltimore.com [193.41.17.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g11Acw322122; Fri, 1 Feb 2002 02:38:58 -0800 (PST)
Received: from Baltimore-FW1 ([172.19.1.1]) by ocasey.baltimore.com (8.11.6/8.9.3) with SMTP id g11AcwU29319; Fri, 1 Feb 2002 10:38:58 GMT
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]>; Fri, 1 Feb 2002 10:34:23 +0000
Received: from baltimore.ie (wks140-4.ie.baltimore.com [10.153.4.140]) by bobcat.baltimore.ie (8.9.3/8.9.3) with ESMTP id KAA15081; Fri, 1 Feb 2002 10:38:54 GMT
Message-ID: <[e-mail]>
Date: Fri, 01 Feb 2002 10:40:02 +0000
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: Peter Gutmann <[e-mail]>
CC: [e-mail], [e-mail], [e-mail]
Subject: Re: I-D ACTION:draft-ietf-pkix-okid-00.txt
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>

Peter Gutmann wrote:
> Actually I think the main problem with this draft (which others have also
> alluded to indirectly) is that it's trying to do two things at once: Identify
> certs using a hash, and provide a way of encoding binary values as user-
> friendly keys.  I think it'd be better to split the two, create a universal
> user-friendly key-encoding RFC and then move the identifying-certs bit
> elsewhere.  The key-encoding is useful in lots of other places, for example
> I've been using it with CMP for enrolment details.

I kind of like this idea, since I might want to be able 
to do the equivalent trick in an xmldsig context where 
I'd (probably) be hashing over a ds:KeyInfo.

Stephen.


-- 
____________________________________________________________
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 g11Abkn21921 for ietf-pkix-bks; Fri, 1 Feb 2002 02:37:46 -0800 (PST)
Received: from edelweb.fr (edelweb.fr [212.234.46.16]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g11Abh321912 for <[e-mail]>; Fri, 1 Feb 2002 02:37:44 -0800 (PST)
Received: from champagne.edelweb.fr (localhost.edelweb.fr [127.0.0.1]) by edelweb.fr with ESMTP id LAA25864; Fri, 1 Feb 2002 11:37:34 +0100 (MET)
Received: from champagne.edelweb.fr (champagne.edelweb.fr [193.51.14.161]) by edelweb.fr (nospam/1.3); Fri, 1 Feb 2002 11:37:34 +0100 (MET)
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 LAA29288; Fri, 1 Feb 2002 11:37:33 +0100 (MET)
From: Peter Sylvester <[e-mail]>
Received: (sylvest@localhost) by emeriau.edelweb.fr (8.7.6/8.6.6) id LAA10299; Fri, 1 Feb 2002 11:37:32 +0100 (MET)
Date: Fri, 1 Feb 2002 11:37:32 +0100 (MET)
Message-Id: <[e-mail]>
To: [e-mail], [e-mail]
Subject: Re: TSP interop update
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>

> 
> Peter,
> 
> > >It is simmple: if a client requests a policy and if the server supports that
> > >policy, why should the server choose a different policy ? Just to annoy the
> > >client ?
> > 
> > What if the client prefers policy X, but will accept anything if that's not
> > available?  

Cl:      want something to eat but I am not very hungry.
service: in this case we propose You our small sandwich.
 
> Simple.
>  
> First exchange:  he asks for a given policy and does not get it.
> Second exchange: he does not use the optional field reqPolicy and 
>                  thus gets what the server has.

This doesn't work if the TSA supports more than one incompatible
policies. 

> 
> Denis 
> 
> > This is standard procedure for restaurants, libraries, ...
> > 
> > Twitchen: "We'll have the duck".
> > Fawlty: "Duck's off, sorry".
> > Twitchen: "We'll have the trifle then".
> > 
> > TSP however requires:
> > 
> > Twitchen: "We'll have the duck".
> > Fawlty: "You ponce in here expecting to be waited on hand and foot. Well, I'm
> >          trying to run a TSA here. Have you any idea how much there is to do?
> >          Go away".
> > 
> > Ah, we have an RFC which standardises Fawlty Towers.
> > 
> > Peter.
> 


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g11AMxV18533 for ietf-pkix-bks; Fri, 1 Feb 2002 02:22:59 -0800 (PST)
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 g11AMv318525 for <[e-mail]>; Fri, 1 Feb 2002 02:22:57 -0800 (PST)
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 XAA17974; Fri, 1 Feb 2002 23:22:38 +1300 (NZDT) (sender [e-mail])
Received: (from pgut001@localhost) by ruru.cs.auckland.ac.nz (8.9.3/8.8.6/cs-slave) id XAA474194; Fri, 1 Feb 2002 23:22:38 +1300 (NZDT) (sender [e-mail])
Date: Fri, 1 Feb 2002 23:22:38 +1300 (NZDT)
Message-ID: <[e-mail]>
From: [e-mail] (Peter Gutmann)
To: [e-mail], [e-mail]
Subject: Re: TSP interop update
Cc: [e-mail], [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>

Denis Pinkas <[e-mail]> writes:
>IF, I did say "IF", we go into that direction, then it would mean changing the
>reqPolicy field in TimeStampReq by allowing a sequence of TSA policies instead
>of a single policy.
>
>Would this fit the concern from Peter ?

To some extent, although you'd need to allow anyPolicy to allow the client to
specify that if it can't get an exact match, anything will do.  Consider for
example electronic tax filing, in which I have to get my submission timestamped
to prove I filed on time.  Before I submit the return to irs.gov I go to
time.gov and get my return stamped.  Ideally I'd want it notarised under the
2002 tax policy, or failing that the 2000 tax policy, or the general tax
policy, but if all else fails I can probably get it done under the dog-license
policy because if it goes to court all that matters is that it's timestamped.
If it was under any of the standard tax policies I wouldn't need to go to
court, but the dog-license policy is always better than having nothing at all.

However:

It's still making the decision at the wrong place.  Instead of the client being
able to decide what's acceptable, it now has to communicate more and more state
information to the server and still ask the server to make the decision for it.
It's turning into an uglier and uglier kludge because the client, who should be
making the decision, is banned from doing so, so all it can do is throw a
mountain of state at the server and ask it to make the decision for it.  In the
case of the tax-timestamping above I can easily encode this process at the
client, but I have no idea how I'd communicate that decision-making process to
the server.  The real solution, which is relatively straightforward, is to
allow the client to device what it wants to accept, not to require the server
to make the decision for it.

Peter.


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g119Y5n14955 for ietf-pkix-bks; Fri, 1 Feb 2002 01:34:05 -0800 (PST)
Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g119Y4314951 for <[e-mail]>; Fri, 1 Feb 2002 01:34:04 -0800 (PST)
Received: from lvt-mail.frlv.bull.fr (lvt-mail.frlv.bull.fr [129.184.62.223]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id KAA10718; Fri, 1 Feb 2002 10:35:29 +0100
Received: from bull.net (frlva3786.frlv.bull.fr [129.184.37.97]) by lvt-mail.frlv.bull.fr (8.9.2/8.9.1) with ESMTP id KAA17920; Fri, 1 Feb 2002 10:33:27 +0100
Message-ID: <[e-mail]>
Date: Fri, 01 Feb 2002 10:33:31 +0100
From: Denis Pinkas <[e-mail]>
Organization: Integris. A Bull Company
X-Mailer: Mozilla 4.7 [fr] (Win98; I)
X-Accept-Language: fr
MIME-Version: 1.0
To: Ambarish Malpani <[e-mail]>
CC: "'[e-mail]'" <[e-mail]>
Subject: Re: Candidate for moving OCSP to a Draft Standard
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>

Ambarish,,

> Hi Guys,

>     Here is a candidate for moving OCSP to a Draft Standard. There
> are no changes in the bytes that go across the wire - basically all
> clarifications.
 
> A list of all the changes between this document and RFC 2560 are
> in Appendix D (reproduced here).
 
> I hope we can get to the Draft Standard state before this IETF.

I have the following remarks:

The current text states:

   7. The producedAt time in the response is sufficiently recent.

   8. If the request contained a nonce, the response must contain the
      same nonce (see section 4.4.1).

If the nonce is used, then the value of the producedAt field does not matter 
anymore and no test needs to be made on it. So I would first propose to 
invert items 8 and 7.

Then it is questionable on how implementers can interpret what "sufficiently
recent" means for the producedAt time and set a value (a few minutes, hours 
or days ?).
 
In fact if no pre-computed response were being used, this could simply be
set to a few minutes.

If pre-computed responses are being used, setting it to a few minutes will
probably lead to rejections.

This means that using pre-computed responses is a real problem, since this
value cannot even be fixed but is even dependent upon each server supporting
pre-computed responses.

The easiest way would be to delete the support of pre-computed responses or
set a maximum limit in the standard. The basic question would first be: who
is using pre-computed responses with which retention period in the cache ?
If no-one is using it, then the solution is simple. :-)

In the following proposal, I have not yet "crossed the line".  

Proposed rephrasing:

[Prior to accepting a signed response as valid, OCSP clients SHALL
 confirm that:]

   7. If the request contained a nonce, the response contains the
      same nonce (see section 4.4.1).

   8. If the request did not contained a nonce, the producedAt time 
      in the response is considered as "sufficiently recent". 
      This means computing the difference between the current time 
      and the producedAt time and then comparing it with a time 
      period that will be set to a few minutes, or to a few hours 
      in the case where the OCSP servers accessed by the client 
      are supporting pre-computed responses. 

      Note: when pre-computed responses are being used by servers,
      it may be hard for clients to set a single maximum common value.


Denis

 
> Regards,
> Ambarish
> 
> Appendix D. Changes
> 
>    This section contains the differences in this document from RFC 2560
> 
>    - Mention Appendix D in Section 1 and added an appendix D.
>    - Added a paragraph in Section 1 equating a client with a requestor and
>      server with responder
>    - Section 2.2 - clarified the explanation of good, revoked and unknown
>    - Added Section 2.8 requiring clients and responders to support HTTP
>    - Added a note at the end of section 3.2, which allows a client to
>      accept a response that provides statuses for only some of the
>      certificates requested.
>    - Clarified the issuerKeyHash in Section 4.1.1
>    - Added "DER encoding of the" in the third paragraph Section 4.1.2
>    - Section 4.2.1 - clarified that the signature is on the DER encoding
>      of tbsResponseData (and not its hash)
>    - Section 4.2.1 - specified the use of the certs field in
>      BasicOCSPResponse
>    - Section 4.2.1 - clarified how you compute KeyHash when providing
>      the ResponderID byKey.
>    - Section 4.2.2.2 - removed an extra quote in point 3
>    - Section 4.3 - Made RSA mandatory. Also changed the references to
>      point to the appropriate documents. Added the references to the
>      References section
>    - Section 4.4.1 - Clarified that a nonce in the request MUST be
>    - included in the response for the response to be trusted.
>    - Appendix A - A.1.1. - Got rid of support for GET - not sure that
>      anybody does it. It is also unclear how a server would tell a
>      client to ever use GET in the URL specified in the AIA
>    - Add the module tag for the ASN.1 in OCSP
>    - Made SEQUENCE OF Certificate OPTIONAL to SEQUENCE SIZE(1..MAX) of
>      Certificate OPTIONAL in the ASN.1 defintions. The avoids the
>      ambiguity of whether the optional sequence may be present, but
>      with 0 elements. This was done by definining a new element called
>      Certificates, which is used. Look at the defintion of both
>      Signature and BasicOCSPResponse.
>    - Clarified the meaning of nextUpdate being absent (Section 2.4)
>    - Fixed typo where we referred to id-ad-ocspSigning, to reflect the
>      correct OID - id-kp-OCSPSigning
>    - Clarified criteria for response acceptance (Section 3.2)
>    - Added a line in Section 5 indicating that nonces can be used to
>      prevent prevent attacks using replays of precomputed responses
>    - Added a paragraph in Section 5 requiring nonces to be unique for
>      replay protection
> 
> ---------------------------------------------------------------------
> Ambarish Malpani
> Architect                                                650.567.5457
> ValiCert, Inc.                                  [e-mail]
> 339 N. Bernardo Ave.                          http://www.valicert.com
> Mountain View, CA 94043
> 
>   ----------------------------------------------------------------------------
>                         Name: OCSP-draft-03.txt
>    OCSP-draft-03.txt    Type: Plain Text (text/plain)
>                     Encoding: quoted-printable


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g118siv08736 for ietf-pkix-bks; Fri, 1 Feb 2002 00:54:44 -0800 (PST)
Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g118sg308730; Fri, 1 Feb 2002 00:54:42 -0800 (PST)
Received: from lvt-mail.frlv.bull.fr (lvt-mail.frlv.bull.fr [129.184.62.223]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id JAA09080; Fri, 1 Feb 2002 09:56:08 +0100
Received: from bull.net (frlva3786.frlv.bull.fr [129.184.37.97]) by lvt-mail.frlv.bull.fr (8.9.2/8.9.1) with ESMTP id JAA05910; Fri, 1 Feb 2002 09:54:06 +0100
Message-ID: <[e-mail]>
Date: Fri, 01 Feb 2002 09:54:10 +0100
From: Denis Pinkas <[e-mail]>
Organization: Integris. A Bull Company
X-Mailer: Mozilla 4.7 [fr] (Win98; I)
X-Accept-Language: fr
MIME-Version: 1.0
To: Paul Hoffman / IMC <[e-mail]>
CC: [e-mail]
Subject: Re: I-D ACTION:draft-ietf-pkix-okid-00.txt
References: <[e-mail]> <[e-mail]> <p05101360b87f4f6e63ee@[165.227.249.20]>
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>

Paul,

> At 5:11 PM +0100 1/31/02, Denis Pinkas wrote:
> >1) The current document addresses only the verification of self-signed
> >    certificates, but is subject to security attacks (i.e. substitution
> >    of self-signed certificates) because only the hash of the public key
> >    contained in the self-signed certificate is verified:
> 
> Correct. I have yet to hear of an interesting attack where Mallory
> has some good reason to substitute "Alice A" for "Alice B" on Bob's
> system when "Alice A" and "Alice B" are both self-signed.

We are talking of trust anchors. A self-signed certificate contains among
other things a validity period and naming constraints.

1) The validity period limits the duration of the trust anchor.

It is not mandatory to change the value of the public key when a self-signed
certificate is renewed. Hence a replay attack is possible by re-installing
the current self-signed certifiace instead of a new one.

2) Clients may install different self-signed certificates that contain
different naming constraints. If naming constraints are not part of the
hash, then substitution of trust anchors with different naming constraints
is possible.

So the requirement is to have the hash of the certificate, not simply 
the hash of the public key (and of the algorithm identifier).  

The question of the security comes just *after*.

As soon as a hash is truncated, the security is indeed lower. I let
cryptographers discuss this issue, since I am not a cryptographer. We might
consider different levels of security: the bigger the number of characters
being typed will be, the better the security will be.

Denis

 
> >  this would mandate
> >    that a CA is not allowed to issue more than one self-signed certificate
> >    with the same public key in it,
> 
> Where in the document did it say this? CAs and non-CA self-signers
> are allowed to do whatever they want.
> 
> >  which is indeed a restriction that is
> >    not acceptable.
> 
> Agree; that's why it doesn't say it.
> 
> >    So the document should be changed to consider the hash of the certificate
> >    instead of only the hash of the public key (and of the algorithm
> >    identifier).
> 
> You then make Mallory's job many orders of magnitude easier. Instead
> of having to create 2^79 key pairs, he only has to create 2^79 hashes
> looking for one that matches Alice's OKID. That doesn't seem like a
> good security choice, particularly because we can assume that it is
> more likely that people will work on hardware hash acceleration than
> they will on hardware key generation.
> 
> >    If we do so, then the "protocol" will also be usable for any type of
> >    certificate, not only self-signed certificates.
> 
> Correct, but at the cost of making the protocol much easier to break.
> 
> >2) The abstract should rephrased as:
> >
> >    The Out-of-Band Key Identifier Protocol (OKID) is a user-friendly
> >    out-of-band way to install certificates.
> 
> Disagree. This protocol does not install certificates. It helps with
> only one step of that process.
> 
> --Paul Hoffman, Director
> --Internet Mail Consortium


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g118oNK08236 for ietf-pkix-bks; Fri, 1 Feb 2002 00:50:23 -0800 (PST)
Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g118oM308230 for <[e-mail]>; Fri, 1 Feb 2002 00:50:22 -0800 (PST)
Received: from lvt-mail.frlv.bull.fr (lvt-mail.frlv.bull.fr [129.184.62.223]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id JAA16666; Fri, 1 Feb 2002 09:51:47 +0100
Received: from bull.net (frlva3786.frlv.bull.fr [129.184.37.97]) by lvt-mail.frlv.bull.fr (8.9.2/8.9.1) with ESMTP id JAA13708; Fri, 1 Feb 2002 09:49:41 +0100
Message-ID: <[e-mail]>
Date: Fri, 01 Feb 2002 09:49:45 +0100
From: Denis Pinkas <[e-mail]>
Organization: Integris. A Bull Company
X-Mailer: Mozilla 4.7 [fr] (Win98; I)
X-Accept-Language: fr
MIME-Version: 1.0
To: Antonio Lioy <[e-mail]>
CC: Peter Gutmann <[e-mail]>, [e-mail], [e-mail]
Subject: Re: TSP interop update
References: <[e-mail]> <[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>

Antonio,

> Peter Gutmann wrote:
> >
> > Margus Freudenthal <[e-mail]> writes:
> >
> > >In addition, this makes the protocol more complex as the client must implement
> > >procedures for dealing with time stamps with funny and unexpected policy
> > >identifiers.
> >
> > It's far easier to compare the returned ID with a known-good set than to submit
> > a string of requests going down a list of acceptable policies trying to find
> > one the TSA won't reject.
 
> No, only the client knowns which are the acceptable policies to it,
> while the TSA issue a TST under one specific policy. So the client MUST
> send its list of acceptable policies, listed in order of preference, and
> the TSA MUST issue a TST with the policy of highest preference
> available, or MUST return an error "no acceptable policy here".

Your proposal is leading into a direction I am quite familiar with:
Negotiation (see RFC 2478 - The Simple and Protected GSS-API Negotiation
Mechanism).

IF, I did say "IF", we go into that direction, then it would mean changing
the reqPolicy field in TimeStampReq by allowing a sequence of TSA policies
instead of a single policy.

Would this fit the concern from Peter ?
What would be the opinion of the current implementers, and of the WG ?

Denis

 
> Antonio


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g118aSK06520 for ietf-pkix-bks; Fri, 1 Feb 2002 00:36:28 -0800 (PST)
Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g118aR306510 for <[e-mail]>; Fri, 1 Feb 2002 00:36:27 -0800 (PST)
Received: from lvt-mail.frlv.bull.fr (lvt-mail.frlv.bull.fr [129.184.62.223]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id JAA20592; Fri, 1 Feb 2002 09:37:52 +0100
Received: from bull.net (frlva3786.frlv.bull.fr [129.184.37.97]) by lvt-mail.frlv.bull.fr (8.9.2/8.9.1) with ESMTP id JAA17356; Fri, 1 Feb 2002 09:35:50 +0100
Message-ID: <[e-mail]>
Date: Fri, 01 Feb 2002 09:35:53 +0100
From: Denis Pinkas <[e-mail]>
Organization: Integris. A Bull Company
X-Mailer: Mozilla 4.7 [fr] (Win98; I)
X-Accept-Language: fr
MIME-Version: 1.0
To: Peter Gutmann <[e-mail]>
CC: [e-mail], [e-mail]
Subject: Re: TSP interop update
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>

Peter,

> >It is simmple: if a client requests a policy and if the server supports that
> >policy, why should the server choose a different policy ? Just to annoy the
> >client ?
> 
> What if the client prefers policy X, but will accept anything if that's not
> available?  

Simple.
 
First exchange:  he asks for a given policy and does not get it.
Second exchange: he does not use the optional field reqPolicy and 
                 thus gets what the server has.

Denis 

> This is standard procedure for restaurants, libraries, ...
> 
> Twitchen: "We'll have the duck".
> Fawlty: "Duck's off, sorry".
> Twitchen: "We'll have the trifle then".
> 
> TSP however requires:
> 
> Twitchen: "We'll have the duck".
> Fawlty: "You ponce in here expecting to be waited on hand and foot. Well, I'm
>          trying to run a TSA here. Have you any idea how much there is to do?
>          Go away".
> 
> Ah, we have an RFC which standardises Fawlty Towers.
> 
> Peter.


Received: by above.proper.com (8.11.6/8.11.3) id g118aIv06476 for ietf-pkix-bks; Fri, 1 Feb 2002 00:36:18 -0800 (PST)
Received: from relay1.trustworks.com (zuka.trustworks.com [212.114.5.147]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g118aF306466; Fri, 1 Feb 2002 00:36:16 -0800 (PST)
Received: by relay1.trustworks.com (8.8.5/1.14) id LAA06018; Fri, 1 Feb 2002 11:36:15 +0300 (MSK)
Message-Id: <[e-mail]>
Received: from localhost(127.0.0.1) by zuka via smap (V2.0) id xma005942; Fri, 1 Feb 02 11:35:35 +0300
From: "Valery Smyslov" <[e-mail]>
Organization: TWS
To: Jean-Marc Desperrier <[e-mail]>, [e-mail], Paul Hoffman / IMC <[e-mail]>
Date: Fri, 1 Feb 2002 11:35:39 +0300
MIME-Version: 1.0
Content-type: text/plain; charset=US-ASCII
Content-transfer-encoding: 7BIT
Subject: Re: I-D ACTION:draft-ietf-pkix-okid-00.txt
In-reply-to: <p05101404b87f9917a7aa@[165.227.249.20]>
References: <[e-mail]>
X-mailer: Pegasus Mail for Win32 (v3.12b)
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>

On 31 Jan 02, at 17:03, Paul Hoffman / IMC wrote:

Paul,

[...]

> We disagree here. Given Alice's OCID (it is now a cert ID, not a key
> ID), Mallory creates a template certificate with his own public key
> in it. In the template, he adds an extension that has an octet stream
> of length 10. He then cycles through all the combinations of 2^80
> values in the octet stream until the hash over the template
> certificate matches Alice's OCID, signs the cert, and is done.
>
> Mallory does *not* need to change the public key in an OCID: he can
> change any value in the certificate to get the right hash.

But doesn't he still need to sign certificate before hashing?
Clearly, signing is less computationly expensive than creating public
key, but it is still much more expensive than just hashing.

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

Regards,
Valery Smyslov.



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g118PsY04131 for ietf-pkix-bks; Fri, 1 Feb 2002 00:25:54 -0800 (PST)
Received: from taurus.polito.it (taurus.polito.it [130.192.1.8]) by above.proper.com (8.11.6/8.11.3) with SMTP id g118Pq304121 for <[e-mail]>; Fri, 1 Feb 2002 00:25:52 -0800 (PST)
Received: (qmail 26355 invoked from network); 1 Feb 2002 08:27:31 -0000
Received: from t750u.polito.it (HELO polito.it) (130.192.1.29) by taurus.polito.it with SMTP; 1 Feb 2002 08:27:31 -0000
Message-ID: <[e-mail]>
Date: Fri, 01 Feb 2002 09:26:17 +0100
From: Antonio Lioy <[e-mail]>
Organization: Politecnico di Torino
X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Peter Gutmann <[e-mail]>
CC: [e-mail], [e-mail]
Subject: Re: TSP interop update
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>

Peter Gutmann wrote:
> 
> Margus Freudenthal <[e-mail]> writes:
> 
> >In addition, this makes the protocol more complex as the client must implement
> >procedures for dealing with time stamps with funny and unexpected policy
> >identifiers.
> 
> It's far easier to compare the returned ID with a known-good set than to submit
> a string of requests going down a list of acceptable policies trying to find
> one the TSA won't reject.

No, only the client knowns which are the acceptable policies to it,
while the TSA issue a TST under one specific policy. So the client MUST
send its list of acceptable policies, listed in order of preference, and
the TSA MUST issue a TST with the policy of highest preference
available, or MUST return an error "no acceptable policy here".

Antonio


Received: by above.proper.com (8.11.6/8.11.3) id g118I1703393 for ietf-pkix-bks; Fri, 1 Feb 2002 00:18:01 -0800 (PST)
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 g118Hw303383 for <[e-mail]>; Fri, 1 Feb 2002 00:17:59 -0800 (PST)
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 VAA15606; Fri, 1 Feb 2002 21:17:44 +1300 (NZDT) (sender [e-mail])
Received: (from pgut001@localhost) by ruru.cs.auckland.ac.nz (8.9.3/8.8.6/cs-slave) id VAA472193; Fri, 1 Feb 2002 21:17:44 +1300 (NZDT) (sender [e-mail])
Date: Fri, 1 Feb 2002 21:17:44 +1300 (NZDT)
Message-ID: <[e-mail]>
From: [e-mail] (Peter Gutmann)
To: [e-mail], [e-mail]
Subject: Re: TSP interop update
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>

Margus Freudenthal <[e-mail]> writes:

>In addition, this makes the protocol more complex as the client must implement
>procedures for dealing with time stamps with funny and unexpected policy
>identifiers.

It's far easier to compare the returned ID with a known-good set than to submit
a string of requests going down a list of acceptable policies trying to find
one the TSA won't reject.

Peter.