Subject: IT Services at the most competitive price

From: [email-masked]
Date: Wed, 31 Jan 2001 18:01:21 -0800

Hello,
Visual Consultancy Services provides Information
Technology Services at the most competitive price.
Our services include a) Web Site Development b)
Application Development c) Product Development
d) E-Commerce e) Man Power Resources to meet IT
requirements

We are based in Bangalore, India, a prolific source
for efficient and innovative Software Engineers and
offer one of the most competitive rates oriented
towards global competitiveness.

Please contact us for a free estimate. For more
details visit
http://www.vcssystems.com

Regards,
Chandini
Email: [email-masked]

To be removed from this list, please reply with REMOVE in the subject line.

Received: from smtppop3pub.verizon.net (smtppop3pub.gte.net [206.46.170.22]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id SAA11731; Wed, 31 Jan 2001 18:08:50 -0800 (PST)
From: [email-masked]
Received: from korky.net.au.jp.tw (2Cust49.tnt8.lax3.da.uu.net [63.23.74.177]) by smtppop3pub.verizon.net with SMTP ; id TAA102513468 Wed, 31 Jan 2001 19:55:42 -0600 (CST)
Message-Id: <[email-masked]>
To: <>
Subject: IT Services at the most competitive price
Date: Wed, 31 Jan 2001 18:01:21 -0800
X-Sender: [email-masked]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1
Content-Type: text/html; charset="iso-8859-1"
X-Priority: 3
X-MSMail-Priority: Normal

Hello,
Visual Consultancy Services provides Information
Technology Services at the most competitive price.
Our services include a) Web Site Development b)
Application Development c) Product Development
d) E-Commerce e) Man Power Resources to meet IT
requirements

We are based in Bangalore, India, a prolific source
for efficient and innovative Software Engineers and
offer one of the most competitive rates oriented
towards global competitiveness.

Please contact us for a free estimate. For more
details visit
http://www.vcssystems.com

Regards,
Chandini
Email: [email-masked]

To be removed from this list, please reply with REMOVE in the subject line.

Received: from exchange.cylink.com (exchange.cylink.com [192.43.161.25]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id RAA11290 for ; Wed, 31 Jan 2001 17:59:10 -0800 (PST)
Received: from COVEY (cpe-24-221-22-222.az.sprintbbd.net [24.221.22.222]) by exchange.cylink.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id 1AM7R19Q; Wed, 31 Jan 2001 18:05:03 -0800
From: "Carlin Covey"
To: "Stephen Kent"
Cc:
Subject: RE: DPD & DPV requirements - to nonce or not to nonce?
Date: Wed, 31 Jan 2001 19:04:41 -0700
Message-ID:
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:
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400

Steve,

I see the "nonce issue" as being different for DPD and for DPV.
See below.

-----Original Message-----
From: Stephen Kent [mailto:[email-masked]]
Sent: Wednesday, January 31, 2001 5:02 PM
To: Carlin Covey
Cc: [email-masked]
Subject: RE: DPD & DPV requirements - to nonce or not to nonce?

Not sure I see the problem clearly, yet. The communication between
the end user client and a DPV server should employ security
mechanisms that address the replay attack at least from the client
side. The response from the server already has to ensure integrity,
so I would expect it to bundle components of the response, e.g., OCSP
responses acquired by the DPV server from OCSP servers, in a fashion
that ensures integrity. Thus, I'm not sure why a nonce used by a
client in its exchange with a DPV server need to be related to nonces
in OCSP responses returned by the DPV server to this client. It's up
to the DPV server to ensure that its interactions with OCSP servers
are not replays, which is a local nonce management concern for the
DPV server. The client of the DPV server relies on that server to do
this properly and may not (need not?) be concerned with how this was
accomplished.

[Carlin]:
I agree that if the client is going to trust the DPV server
to give a correct status response, the client should also trust the
DPV server to check the nonces in any responses that the server receives
from queries that it relays to other servers.

But what about a DPD query? The client gets back a list of certificates
and a set of certificate status information that may contain OCSP responses
with nonces in them. But the client can't use the nonces to protect itself
against replay, because the client didn't generate those nonces. Some
server downstream (upstream? which way does this stream flow?) put the
nonces in queries that were relayed to other servers. If the client can
make do without replay protection, why were nonces put in the OCSP protocol
in the first place? Note that this isn't a deficiency of OCSP. The same
thing would be true of DPV, DPD or SCVP if those responses were returned
in DPD responses.

Regards,

Carlin

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

- Carlin Covey
Cylink Corp.

Received: from po1.bbn.com (PO1.BBN.COM [192.1.50.38]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA06525 for ; Wed, 31 Jan 2001 15:58:47 -0800 (PST)
Received: from [128.33.4.39] (comsec.bbn.com [128.33.4.39]) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id TAA09103; Wed, 31 Jan 2001 19:05:15 -0500 (EST)
Mime-Version: 1.0
X-Sender: [email-masked]
Message-Id:
In-Reply-To:
References:
Date: Wed, 31 Jan 2001 19:01:56 -0500
To: "Carlin Covey"
From: Stephen Kent
Subject: RE: DPD & DPV requirements - to nonce or not to nonce?
Cc:
Content-Type: text/plain; charset="us-ascii" ; format="flowed"

carlin,

>
>
>
>>Carlin addressed some valuable issues at the outset of
>>this thread. They concerned the handling of nonces
>>in the circumstance that one protocol is dependent
>>upon completion of another - as between the DPV server and
>>supporting OCSP servers. One should refer to the thread's
>>first memo, as appropriate.
>
>A DPV server is a client of an OCSP server, so it is not clear at the
>outset that this is a special case, vs. regular client/server
>interaction.
>
>
>
>
>The context of the OCSP (RFC 2560) discussion focuses only on client
>use of nonces, although the client could be an end user or another
>OCSP server.
>
>
>[Carlin's Jan 31 comment: I agree that a chain of relayed OCSP queries
> is a series of regular client/server interactions, but the issue I
> raised concerned the fact that nonces ordinarily provide replay
> protection for a client, not the client of a client. The purpose
> of DPD is to return a chain of evidence to be evaluated by the
> end-client, but this end-client does not have the benefit of the
> replay protection afforded by the nonces exchanged between servers
> farther down the relay chain. I had earlier raised the possibility that
> these nonces could be made meaningful to the end-client if the server
> used the client's same nonce when the server relayed an OCSP request
> to another server. I observed that this may make the protocol vulnerable
> to some attacks, unless the server ensures that the nonce is not
>repeated.
> I bemoaned the fact that keeping track of previously-used nonces might be
> expensive. Peter pointed out a working implementation that minimized
> the expense.]

Not sure I see the problem clearly, yet. The communication between
the end user client and a DPV server should employ security
mechanisms that address the replay attack at least from the client
side. The response from the server already has to ensure integrity,
so I would expect it to bundle components of the response, e.g., OCSP
responses acquired by the DPV server from OCSP servers, in a fashion
that ensures integrity. Thus, I'm not sure why a nonce used by a
client in its exchange with a DPV server need to be related to nonces
in OCSP responses returned by the DPV server to this client. It's up
to the DPV server to ensure that its interactions with OCSP servers
are not replays, which is a local nonce management concern for the
DPV server. The client of the DPV server relies on that server to do
this properly and may not (need not?) be concerned with how this was
accomplished.

>
>
>I agree that, on this one point the X.509 authentication protocols
>seem to have done a very good job. But. in fairness, at least one
>member of that protocol suite was found to contain security holes
>that were the topic of publications in the late 80s or early 90s, so
>the suite is hardly without flaws, as are protocols like OCSP.
>
>[Carlin's Jan 31 comment: Steve, did you mean that OCSP is without flaws,
> or that OCSP is not without flaws?]

I meant that OCSP is not without flaws, just as X.509 authentication
protocols were not without flaws.

Steve

Received: from exchange.cylink.com (exchange.cylink.com [192.43.161.25]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA19498 for ; Wed, 31 Jan 2001 11:10:44 -0800 (PST)
Received: from COVEY (cpe-24-221-22-222.az.sprintbbd.net [24.221.22.222]) by exchange.cylink.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id 1AM7RD26; Wed, 31 Jan 2001 11:16:38 -0800
From: "Carlin Covey"
To: "Stephen Kent"
Cc:
Subject: RE: DPD & DPV requirements - to nonce or not to nonce?
Date: Wed, 31 Jan 2001 12:16:19 -0700
Message-ID:
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)
Importance: Normal
In-Reply-To:
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400

Steve,

Please see my comments embedded below.

- Regards,

Carlin

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

- Carlin Covey
Cylink Corp.

-----Original Message-----
From: Stephen Kent [mailto:[email-masked]]
Sent: Wednesday, January 31, 2001 11:26 AM
To: Peter Williams
Cc: [email-masked]
Subject: RE: DPD & DPV requirements - to nonce or not to nonce?

>Carlin addressed some valuable issues at the outset of
>this thread. They concerned the handling of nonces
>in the circumstance that one protocol is dependent
>upon completion of another - as between the DPV server and
>supporting OCSP servers. One should refer to the thread's
>first memo, as appropriate.

A DPV server is a client of an OCSP server, so it is not clear at the
outset that this is a special case, vs. regular client/server
interaction.

The context of the OCSP (RFC 2560) discussion focuses only on client
use of nonces, although the client could be an end user or another
OCSP server.

[Carlin's Jan 31 comment: I agree that a chain of relayed OCSP queries
is a series of regular client/server interactions, but the issue I
raised concerned the fact that nonces ordinarily provide replay
protection for a client, not the client of a client. The purpose
of DPD is to return a chain of evidence to be evaluated by the
end-client, but this end-client does not have the benefit of the
replay protection afforded by the nonces exchanged between servers
farther down the relay chain. I had earlier raised the possibility that
these nonces could be made meaningful to the end-client if the server
used the client's same nonce when the server relayed an OCSP request
to another server. I observed that this may make the protocol vulnerable
to some attacks, unless the server ensures that the nonce is not
repeated.
I bemoaned the fact that keeping track of previously-used nonces might be
expensive. Peter pointed out a working implementation that minimized
the expense.]

I agree that, on this one point the X.509 authentication protocols
seem to have done a very good job. But. in fairness, at least one
member of that protocol suite was found to contain security holes
that were the topic of publications in the late 80s or early 90s, so
the suite is hardly without flaws, as are protocols like OCSP.

[Carlin's Jan 31 comment: Steve, did you mean that OCSP is without flaws,
or that OCSP is not without flaws?]

Received: from po1.bbn.com (PO1.BBN.COM [192.1.50.38]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA17200 for ; Wed, 31 Jan 2001 10:24:44 -0800 (PST)
Received: from [128.33.4.39] (comsec.bbn.com [128.33.4.39]) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id NAA25912; Wed, 31 Jan 2001 13:31:31 -0500 (EST)
Mime-Version: 1.0
X-Sender: [email-masked]
Message-Id:
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Date: Wed, 31 Jan 2001 13:26:04 -0500
To: Peter Williams
From: Stephen Kent
Subject: RE: DPD & DPV requirements - to nonce or not to nonce?
Cc: [email-masked]
Content-Type: text/plain; charset="us-ascii" ; format="flowed"

At 6:21 PM -0800 1/26/01, Peter Williams wrote:
>Steve
>
>Thank you for your instruction notes on style and your
>designation of terseness as inappropriate. Forgive the length
>of the note that follows: it is not terse.

Ah, again you miss the point! Concise communication is preferred, so
long as it is understandable. Verbose communication can be just as
poor (from a communication perspective) as terse communication, in
the right hands. Parts of the rest of this message illustrate my
point.

>Carlin addressed some valuable issues at the outset of
>this thread. They concerned the handling of nonces
>in the circumstance that one protocol is dependent
>upon completion of another - as between the DPV server and
>supporting OCSP servers. One should refer to the thread's
>first memo, as appropriate.

A DPV server is a client of an OCSP server, so it is not clear at the
outset that this is a special case, vs. regular client/server
interaction.

>The PKI vendor community has worked with two PKI-using protocols that
>share this dependency characteristic. OCSP is used, in practice,
>mostly in chained mode where one server relies upon another to
>satisfy a client request. The Directory's bound DAP queries, used
>in products like Baltimore UniCert, can similarly be chained
>over DSP.

This is different from your opening example, i.e., OCSP has an
ability to chain requests but is it not well described in the RFC,
whereas DAP has a well defined chaining procedure that receives
considerable attention in the X.500 standard. But, a request from a
DPV server to an OCSP server does not seem exactly equivalent (though
perhaps analogous), as one has crossed protocol boundaries, which
might impose limits on nonce formats, etc.

>(A) OCSP
>
>The OCSP work does not say how nonces (used as part of mutual
>authentication procedures to prove the intended request
>recipient is the respondent) should be handled (see 2560/3.2)
>during
>
>(1) chaining (2560/4.4.6), and
>(2) when a downstream server's OCSP response is forwarded
>to a client, either unchanged or resigned, via the final,
>upstream OCSP responder.

OK.

>(B) X.509
>
>The 1986 directory work was more diligent than IETF's OCSP, as its
>signed operations use X.509 procedures for strong authentication. (I
>could not take part in IETF work during OCSP design, due to an
>intervention by a US govt employee.) The X.509 procedures were
>designed for the case that RPC requests and responses requiring
>strong authentication would be operating in a chained, multi-protocol,
>distributed, server-server environment.

A "US govt employee?" Someone from the FDA, NIH, OSHA? That's
intriguing, but not clearly relevant to the cause of clearly
explaining the issue at hand.

>The requirement comments that Carlin outlined cites cases where
>a DPV server signs a response only after having completed a
>request/response dialogue with an OCSP server. Upon reading this,
>I recalled that a conforming OCSP server may be potentially operating
>in chained mode, in which the OCSP request (or response) signature
>verification may start a further round of DPV interaction, which may
>require another round of OCSP interaction, which... In summary, this
>requires that one designs for looping, and one addresses the associated
>requirements to assure a security-critical level of availability.

Ah, finally getting to the point.

>Then, I generalized for a moment. Where had I seen security experts apply
>their talents to such an operational environment - one in which security
>servers themselves issue requests to get critical knowledge in order
>to respond, and those knowledge requests may need recursively securing?
>The answer was the Directory, when using X.509 to satisfy
>its security model (See X.501, 10). Furthermore, I half remembered
>replay issues were discussed in the security considerations
>of http://www.ietf.org/rfc/rfc2560.txt. So, I did some requirements
>homework.

The context of the OCSP (RFC 2560) discussion focuses only on client
use of nonces, although the client could be an end user or another
OCSP server.

>When I considered contributing a memo to the requirements
>discussion (with tremor in my terrorised typing fingers in case I
>be the next Juan to be blackballed or fall foul of a co-chair's
>"appropriate conduct" edict) I read the material that Carlin had responded
>to, again. Nothing in those excerpts suggested that the persons who
>originated the requirements were contemplating the need to address security
>
>requirements in a distributed, server-server, operations environment.

You begin the paragraph with an irrelevant aside (and a poor excuse),
which demonstrates how verbose writing can be as obfuscatory as terse
writing, in the right hands. The end of the paragraph merely
continues this pattern.

>Given my access to considerable practical experience in deploying
>and/or enhancing chained-OCSP and chained-directories, and having seen
>what careful architects had done to either augment the OCSP facilities or
>fully implement the X.509 specification, I began to engage Carlin in
>developing these requirement by introducing the issues of information
>element vs PDU timeliness,. I also gave an example of distributed
>operations. As is the custom, I copied the mail to the list, for all to
>see, enjoy, and consider - as they think and learn on the issues
>as a community.

I, for one, learn better when the information is communicated in a
fashion that is clear.

>For my part, I can only write this note, clearly, now that I have had the
>benefit of the very dialogue and inputs which flush out the issues.
>Whilst no well-reasoned conclusion is evident, at least the requirement
>issues are well framed.

This note does not, in my opinion, do a good job of framing the
issues. Most of it was an extended background discussion justifying
your original messages, and making critical asides in your defense.

>My final substantive point notes that TSP contributors have
>previously thought about server-side nonce-handling. The WG
>seemingly and evidently knowingly punted the matter, despite known
>vulnerabilities and use-case issues. I continue to be awe of the
>simplicity of the expression and the foresight of those who
>designed X.509's reusable, PKI-based, strong authentication
>procedures, back in 1986.

I agree that, on this one point the X.509 authentication protocols
seem to have done a very good job. But. in fairness, at least one
member of that protocol suite was found to contain security holes
that were the topic of publications in the late 80s or early 90s, so
the suite is hardly without flaws, as are protocols like OCSP.

>If you need any additional context, please identify the topics. I will
>respond in full.

What is useful for the DPV/DPD requirements development is a concise,
self-contained proposal for nonce management in this context. It
should define propose requirements for clients and servers, justify
the requirements in this context, describe implications for chaining
(or motivations derived from an assumption of support for chaining),
and note what requirements might be relaxed if recursion within these
protocols, is not supported. That, would be useful.

Steve

Received: from exchange.cylink.com (exchange.cylink.com [192.43.161.25]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA12412 for ; Wed, 31 Jan 2001 09:26:26 -0800 (PST)
Received: from COVEY (cpe-24-221-22-222.az.sprintbbd.net [24.221.22.222]) by exchange.cylink.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id 1AM7RCX7; Wed, 31 Jan 2001 09:32:20 -0800
From: "Carlin Covey"
To: "Peter Williams" , "'Stephen Kent'"
Cc:
Subject: RE: DPD & DPV requirements - to nonce or not to nonce?
Date: Wed, 31 Jan 2001 10:31:59 -0700
Message-ID:
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: <[email-masked]>
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400

Thank you Peter, for summarizing this thread so eloquently.
It certainly helped to put my befuddled questions into better
perspective.

Regards,

Carlin

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

- Carlin Covey
Cylink Corp.

-----Original Message-----
From: Peter Williams [mailto:[email-masked]]
Sent: Friday, January 26, 2001 7:21 PM
To: 'Stephen Kent'
Cc: [email-masked]
Subject: RE: DPD & DPV requirements - to nonce or not to nonce?

Steve

Thank you for your instruction notes on style and your
designation of terseness as inappropriate. Forgive the length
of the note that follows: it is not terse.

Carlin addressed some valuable issues at the outset of
this thread. They concerned the handling of nonces
in the circumstance that one protocol is dependent
upon completion of another - as between the DPV server and
supporting OCSP servers. One should refer to the thread's
first memo, as appropriate.

The PKI vendor community has worked with two PKI-using protocols that
share this dependency characteristic. OCSP is used, in practice,
mostly in chained mode where one server relies upon another to
satisfy a client request. The Directory's bound DAP queries, used
in products like Baltimore UniCert, can similarly be chained
over DSP.

(A) OCSP

The OCSP work does not say how nonces (used as part of mutual
authentication procedures to prove the intended request
recipient is the respondent) should be handled (see 2560/3.2)
during

(1) chaining (2560/4.4.6), and
(2) when a downstream server's OCSP response is forwarded
to a client, either unchanged or resigned, via the final,
upstream OCSP responder.

(B) X.509

The 1986 directory work was more diligent than IETF's OCSP, as its
signed operations use X.509 procedures for strong authentication. (I
could not take part in IETF work during OCSP design, due to an
intervention by a US govt employee.) The X.509 procedures were
designed for the case that RPC requests and responses requiring
strong authentication would be operating in a chained, multi-protocol,
distributed, server-server environment.

The requirement comments that Carlin outlined cites cases where
a DPV server signs a response only after having completed a
request/response dialogue with an OCSP server. Upon reading this,
I recalled that a conforming OCSP server may be potentially operating
in chained mode, in which the OCSP request (or response) signature
verification may start a further round of DPV interaction, which may
require another round of OCSP interaction, which... In summary, this
requires that one designs for looping, and one addresses the associated
requirements to assure a security-critical level of availability.

Then, I generalized for a moment. Where had I seen security experts apply
their talents to such an operational environment - one in which security
servers themselves issue requests to get critical knowledge in order
to respond, and those knowledge requests may need recursively securing?
The answer was the Directory, when using X.509 to satisfy
its security model (See X.501, 10). Furthermore, I half remembered
replay issues were discussed in the security considerations
of http://www.ietf.org/rfc/rfc2560.txt. So, I did some requirements
homework.

When I considered contributing a memo to the requirements
discussion (with tremor in my terrorised typing fingers in case I
be the next Juan to be blackballed or fall foul of a co-chair's
"appropriate conduct" edict) I read the material that Carlin had responded
to, again. Nothing in those excerpts suggested that the persons who
originated the requirements were contemplating the need to address security

requirements in a distributed, server-server, operations environment.

Given my access to considerable practical experience in deploying
and/or enhancing chained-OCSP and chained-directories, and having seen
what careful architects had done to either augment the OCSP facilities or
fully implement the X.509 specification, I began to engage Carlin in
developing these requirement by introducing the issues of information
element vs PDU timeliness,. I also gave an example of distributed
operations. As is the custom, I copied the mail to the list, for all to
see, enjoy, and consider - as they think and learn on the issues
as a community.

For my part, I can only write this note, clearly, now that I have had the
benefit of the very dialogue and inputs which flush out the issues.
Whilst no well-reasoned conclusion is evident, at least the requirement
issues are well framed.

My final substantive point notes that TSP contributors have
previously thought about server-side nonce-handling. The WG
seemingly and evidently knowingly punted the matter, despite known
vulnerabilities and use-case issues. I continue to be awe of the
simplicity of the expression and the foresight of those who
designed X.509's reusable, PKI-based, strong authentication
procedures, back in 1986.

If you need any additional context, please identify the topics. I will
respond in full.

Peter.

-----Original Message-----
From: Stephen Kent [mailto:[email-masked]]
Sent: Wednesday, January 24, 2001 6:29 PM
To: Peter Williams
Cc: [email-masked]
Subject: RE: DPD & DPV requirements - to nonce or not to nonce?

Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA29913 for ; Wed, 31 Jan 2001 06:53:28 -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 QAA65292; Wed, 31 Jan 2001 16:07:20 +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 PAA16956; Wed, 31 Jan 2001 15:59:29 +0100
Message-ID: <[email-masked]>
Date: Wed, 31 Jan 2001 15:59:31 +0100
From: Denis Pinkas
Organization: Bull
X-Mailer: Mozilla 4.7 [fr] (Win98; I)
X-Accept-Language: fr
MIME-Version: 1.0
To: [email-masked]
CC: PKIX-List
Subject: Re: Post-facto queries [Was: RE: DPD & DPV requirements]
References:
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Yuriy,

> I think Tom captures the essence of why post-facto queries are needed. I
> don't think we can assume that every RP will maintain its own information to
> support non-repudiation disputes in the future.

If you are interrested to support non-repudiation, then you had better to
save the proof. You can save it on a server if you wish. But that server is
only providing a safe storage.

> RPs should have a
> capability to rely on a service to do this for them, especially smaller
> institutions that do not want to go through the effort to implement such a
> capability within their organization.

At the time you first receive a signature you had better to make sure that
it is a valid one. So at the time you make the first verification, either
yourself or using a remote server (like DPV), it is easy to grasp the proof
and save it either locally or remotely. There is thus no need for
post-validation.

> In addition, I think it is helpful to have a capability to perform
> post-facto queries when for some reason the DPV service is originally
> unavailable.

Making a query an hour later is fairly different from making the query 10
years later.

> For example, I am a contractor submitting a proposal to the
> Federal Government, and the proposal needs to be in by noon on Friday. I
> complete my proposal, sign and timestamp it, and submit it at 11:55A. The
> Federal Agency receives my proposal, but for some reason their DPV service
> is down for a few hours; therefore, the agency cannot validate my signature
> on the proposal at that time.

There is no need to do what you describe. An acknowledge of receipt may be
sent to the sender without the need to validate the signature, if any. Note
also that the sender may be different from the sender.

> When it comes back up, the agency will want
> to know if my signature was valid when the proposal was submitted (at
> 11:55A), and not when the service comes back up.

If the service was down for only a few hours, this can easily be be done.
Doing it, 10 years later is a different story.

Denis

> Yuriy

Received: from monet.digsigtrust.com (mail.digsigtrust.com [208.30.69.30]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA29268 for ; Wed, 31 Jan 2001 06:40:07 -0800 (PST)
Received: from CC474623A (cc474623-a.abdn1.md.home.com [24.18.83.123]) by monet.digsigtrust.com (8.10.2/8.10.2) with SMTP id f0VEdil15649; Wed, 31 Jan 2001 07:39:44 -0700 (MST)
Reply-To:
From: "Yuriy Dzambasow"
To: "Tom Gindin" , "Denis Pinkas"
Cc: "Russ Housley" , "PKIX-List"
Subject: RE: Post-facto queries [Was: RE: DPD & DPV requirements]
Date: Wed, 31 Jan 2001 09:37:35 -0500
Message-ID:
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:
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600

I think Tom captures the essence of why post-facto queries are needed. I
don't think we can assume that every RP will maintain its own information to
support non-repudiation disputes in the future. RPs should have a
capability to rely on a service to do this for them, especially smaller
institutions that do not want to go through the effort to implement such a
capability within their organization.

In addition, I think it is helpful to have a capability to perform
post-facto queries when for some reason the DPV service is originally
unavailable. For example, I am a contractor submitting a proposal to the
Federal Government, and the proposal needs to be in by noon on Friday. I
complete my proposal, sign and timestamp it, and submit it at 11:55A. The
Federal Agency receives my proposal, but for some reason their DPV service
is down for a few hours; therefore, the agency cannot validate my signature
on the proposal at that time. When it comes back up, the agency will want
to know if my signature was valid when the proposal was submitted (at
11:55A), and not when the service comes back up.

Yuriy

-----Original Message-----
From: Tom Gindin [mailto:[email-masked]]
Sent: Tuesday, January 23, 2001 12:56 PM
To: Denis Pinkas
Cc: Russ Housley; PKIX-List
Subject: Re: Post-facto queries [Was: RE: DPD & DPV requirements]

Denis:

Is your primary objection to post-facto queries that they pose a
temptation to NR relying parties to avoid archiving contemporary
verification information? If we look at the actual verifications performed
in NR, I think that you and I are in agreement that to have the RP keep the
(signed) revocation data supporting his initial determination is more
robust than to have the RP rely on the subsequent verifier acquiring the
revocation data through a post-facto query. IMO this is not a reason why
post-facto queries would be useless in all cases, however - an auditor
attempting to find whether a strong login had occurred before a revocation
or after it (in a case where CRL publication is typically delayed) would
find them useful.
These queries have their place when there is no better alternative,
but I think NR RP's are better off not relying on them. If such an RP (or
the escrow holder for 2-way NR in my draft) maintains contemporary
revocation information, it cannot be affected by the CA ceasing operations
or failing to maintain archives.

Tom Gindin

Denis Pinkas on 01/23/2001 12:04:14 PM

To: Russ Housley
cc: PKIX-List
Subject: Re: Post-facto queries [Was: RE: DPD & DPV requirements]

Russ,

Your statement is too short so that I can understand what you do not
understand. :-)

Could you elaborate a little bit more, or maybe some one else could explain
better than I can.

Denis

> Denis:
>
> I do not understand your point.
>
> Russ
>
> At 04:48 PM 1/23/2001 +0100, Denis Pinkas wrote:
> >[Denis]
> >
> >The additional problem to be considered is that the structure of the
answer
> >in case (a) would be different from the answer in the case of a
current-time
> >checking, since one structure would include individual time stamps while
the
> >other would not.
> >
> >[Russ]
> >
> >Why does the DPV need a 3rd party time stamp on the CRLs? It can keep
> >track using its own clock as long as it has a trusted time source. The
> >STIME working group is going to provide a straightforward mechanism for
> >that...
> >
> >[Denis * new answer]
> >
> >If you use the evidence, it is because you do not trust the "valid"
answer
> >from the server (otherwise, you would not need the evidence). Hence you
> >would not trust either the clock from the server.

Received: from geos.coastside.net (geos.coastside.net [207.213.212.4]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id RAA29034 for ; Tue, 30 Jan 2001 17:02:36 -0800 (PST)
Received: from heatherdale (dsl-63-194-153-52.coastside.net [63.194.153.52]) by geos.coastside.net (8.11.0/8.11.1) with SMTP id f0V19LO29953 for ; Tue, 30 Jan 2001 17:09:21 -0800 (PST)
From: "Michael Myers"
To:
Subject: OCSPv2, DPV and DPD Recursion
Date: Tue, 30 Jan 2001 17:14:01 -0800
Message-ID:
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:
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300

Carlin, All:

RFC 2560(OCSP), the OCSPv2 I-D, and the proposed DPV and DPD extensions to
OCSP already enable recursion. That's not to say that the practice is made
explicit enough, nor do the I-Ds full (yet!) take into account issues such
as Peter Sylvester's loop detection observation, but as things stand today
we have the following to build on as we go forward.

DPV RECURSION
-------------
Recall that at the very top level, RFC 2560 defines (and the OCSPv2 I-D
maintains) OCSPResponse as:

OCSPResponse ::= SEQUENCE {
responseStatus OCSPResponseStatus,
responseBytes [0] EXPLICIT ResponseBytes OPTIONAL }

ResponseBytes ::= SEQUENCE {
responseType OBJECT IDENTIFIER,
response OCTET STRING }

So basically we have a triplet of (status, OID, data).

The DPV I-D states:

"In the responseBytes field of OCSPResponse, responseType MUST have a value
of id-pkix-ocsp-valid-rsp and response MUST have a value of
DPVOCSPResponse, where

DPVOCSPResponse ::= BasicOCSPResponse"

Abbreviating BasicOCSPResponse and it's subordinated elements for the
purpose of this discussion, we have:

BasicOCSPResponse
tbsResponseData ResponseData,

ResponseData
responses SEQUENCE OF SingleResponse

SingleResponse
singleExtensions EXPLICIT Extensions

Note that: 1) there exists no constraints on the value of the
singleExtensions field in any context; and 2) import of Extensions in the
plural from 2459 yields a SEQ OF Extension (i.e. {OID, value} pairs).

Hence a DPV response may contain one or more OCSP extensions, of which DPV
is one.

DPD RECURSION
-------------
DPD recursion is a bit easier to observe. As with the DPV I-D, the DPD I-D
states:

"In the responseBytes field of OCSPResponse, responseType MUST have a value
of id-pkix-ocsp-path-rsp and response MUST have a value of DPDOCSPResponse.

DPDOCSPResponse ::= SEQUENCE OF PathResponse
-- one for each certificate included in the requestList field
-- of TBSRequest

PathResponse ::= SEQUENCE

retryReference BIT STRING,
certificates SEQUENCE OF Certificate,
crls SEQUENCE SIZE (1..MAX) OF CertificateList OPTIONAL,
ocspReps SEQUENCE SIZE (1..MAX) OF OCSPResponse OPTIONAL
}

Note the recursive inclusion of OCSPResponse in PathResponse.

Note also that I failed to include OCSPResponse in the IMPORT statements of
the DPD I-D. This oversight will be corrected in the next version.

Mike

Received: from geos.coastside.net (geos.coastside.net [207.213.212.4]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA16659 for ; Tue, 30 Jan 2001 12:14:27 -0800 (PST)
Received: from heatherdale (dsl-63-194-153-52.coastside.net [63.194.153.52]) by geos.coastside.net (8.11.0/8.11.1) with SMTP id f0UKL5O05827 for ; Tue, 30 Jan 2001 12:21:05 -0800 (PST)
From: "Michael Myers"
To:
Subject: OCSPv2, DPV and DPD issues summary (long)
Date: Tue, 30 Jan 2001 12:25:46 -0800
Message-ID:
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: <[email-masked]>
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300

All,

I've been compiling over the roughly 250 messages posted to PKIX since
10 Nov 00 regarding OCSPv2, DPV and DPD. I thought others might find
this compilation useful as well.

This is by no means definitive, just a tool I'm using to track issues.
Please accept my apology in advance if I overlooked a concern you
raised or if I overly compressed your position on a point. You may
email me at [email-masked] with corrections.

A summary is immediately below. See details section further on for
additional context. Thanks for all for your interest in what I thought
four years ago would be a simple answer to a fundamental problem.

Mike

SUMMARY

1. Ambiguity in requirement 2.2 re: single certs [Covey, 1/2/01]
(Kent to to update rqmts spec)

2. Lack of specificity in rqmt 2.2 re: sort order [Covey, 1/2/01]
(Kent is comfortable with proposal)

3. Server usage of data proferred by client [Covey, 1/3/01]
(Kent to to update rqmts spec)

4. Should a DPD server nonce a DPV server? [Covey, 1/3/01]
(Rqmt under study; no consensus to mandate).

5. Should DPD response syntax enable recursion? [Covey, 1/4/01]
(OCSP framework already enables recusion)

6. There exists a need for loop detection. [Sylvester, 1/11/01]
(proposed: amend OCSPv2 and DPV I-Ds)

7. Transitive trust and recursion [Covey, 1/10/01]
(proposed: amend OCSPv2 and DPV I-Ds)

8. Should DPD responses be signed? [Manger, 1/24/01]
(No, DPD responses do not need to be signed.)

9. A signature is not needed for DPV in all cases. [Kent, 1/24/01]
(proposed: OCSPv2 and DPV I-Ds will continue to
mandate sigs pending WG discussion and consensus
to the contrary.)

10. Support for non-ASN.1-capable clients [Hanna, 1/17/01]
(The OCSPv2, DPV and DPD efforts as authored
will not address XML.)

11. Are post-facto queries a requirement? [Linn, 1/20/01]
(Existing support for post-facto queries in
RFC 2560 will be enhanced in the OCSPv2
and DPV I-Ds.)

12. Updates to I-Ds in response to rqmts [Pinkas, 1/23/01]
(Pending rqmts consensus and list response to
proposals. Ad-hoc working session(s) in
Minneapolis are likely.)

13. Need for validation controls beyond 2459 rules [Pinkas, 1/23/01]
(DPD paths should (shall?) be valid.)

14. Ability to mandate name forms in DPD responses. [Housley, 1/24/01]
(Name constraints are preferable, esp. wrt to
cross certs).

DETAILS

Ambiguity in requirement 2.2 re: single certs [Covey, 1/2/01]
-------------------------------------------------------------
Current text:
"2.2 A server must be able to return one or more sets of certification paths
and associated revocation data as a result of path discovery/validation . .
. ."

Proposed text:
"2.2 A server must be able to return one or more sets of certification paths
and associated revocation data as a result of path discovery/validation
related to a single target certificate."

Resolution/Action:
Kent to update rqmts spec accordingly subject WG consensus re: multiple
certificates [Kent, 1/4/01].

Comment:
RFC 2560 already enables a single message to specify multiple certificates
via the requestList SEQUENCE OF Request syntax (cf. section 4.1.1 Request
Syntax of 2560). This syntax is carried forward in the OCSPv2 draft.
Historically, this is the "validate my entire address book in one message"
OCSP requirement.

Lack of specificity in rqmt 2.2 re: sort order [Covey, 1/2/01]
--------------------------------------------------------------
Current text:
"2.2 A server must be able to return one or more sets of certification paths
and associated revocation data as a result of path discovery/validation.
Each set shall consist of an ordered list of certificates and associated
CRLs and/or OCSP responses."

Proposed text:
"Each set shall consist of a list of pairs of certificates and CRLs and/or
OCSP responses, in certificate path order."

Resolution/Action:
Kent is comfortable with proposal, subject to WG objections [Kent, 1/4/01].

Issue: Server usage of data proferred by client [Covey, 1/3/01]
---------------------------------------------------------------
Current text:
"1.1 A client request can contain a single certificate or a certificate
chain terminating in the "target" certificate, to assist the server in path
construction."

"1.2 A client request can contain one or more revocation data items, to
assist the server in path validation."

Proposed text:
[Augment above with]
"The server may use a certificate chain proffered by the client, but is not
obligated to do so. If revocation data proffered by the client indicates
that a certificate is revoked, the server must reject as invalid any
certificate paths containing this certificate. If revocation data proffered
by the client indicates that a certificate is not revoked, the server must
independently verify this data before accepting as valid any certificate
paths containing this certificate."

Resolution/Action:
Kent to incorporate into rqmts doc [Kent, 1/4/01].

Issue: Should a DPD server nonce a DPV server? [Covey, 1/3/01]
--------------------------------------------------------------
Clarification:
Nonces are optional in RFC 2560 and the OCSPv2 I-D. One OCSPv2 server
servicing a DPD request may nonce a DPV request to a subordinate OCSPv2
server while the client to the first server did not do so.

Resolution/Action:
Rqmt under study [Kent, 1/4/01].
No consensus to mandate nonces [Kent & Williams, 1/15/01 - 1/24/01].

Issue: Should DPD response syntax enable recursion? [Covey, 1/4/01].
---------------------------------------------------------------------
Clarification:
The DPD I-D is intended to enable clients to acquire certificate path
validation data. These data may be accumulated from multiple and diverse
sources, including another DPD server. So the question is, should the DPD
syntax (and, implicitly, the corresponding elements of the OCSPv2 framework
to the extent it's relevant) be amended to accomodate inclusion of DPD
responses within DPD responses? Among other effects, doing so would
preserve the timestamp(s) (if any) on the embedded DPD response(s).

Discussion:
This is still an R&D topic for now, not yet ready for standardization [Kent,
1/5/01].

Solve the immediate problem then generalize if possible [Kent, 1/5/01].

"A server should have the ability to return in the response a rather limited
set of well-known protocol elements, certs, crls, ocsp response, pkistatus,
DPV response, at least those that he had used to make up its decision or
which it wishes to communicate to the client for whatever reason."
[Sylvester, 1/10/01]

"I second Peter's strawman proposal." [Covey, 1/10/01]

"I thinbk [sic] we are in agreement that the set of data returned by a DPD
or DPV server will be limited in scope and well defined, i.e., sequences of
certs, CRLs, and OCSP responses are the initial set. Whether we allow
recursion and allow DPV responses is still an open question." [Kent,
1/10/01]

Resolution:
Unresolved; need to push on-list for further clarity re: Kent's 1/10/01 msg
above.

Issue: There exists a need for loop detection [Sylvester, 1/11/01].
--------------------------------------------------------------------
Proposed text:
"In some environment a DPV server may be operated as a relay/broker to other
services. In order to cover possible misconfigurations in such situations,
the protocols must provide an efficient means to detect request loops. hop
counts or 'Received and relayed by XXX' trace elements are possible means.
It is up to the relaying server how to interprete and transform a response
from another server. In any case a DPV must add apply its own authentication
mecanism, e;g. its own signature. Possible reponses include an encapsulation
of the initial reponse, or simple replacement of the securiy envelope."
[Sylvester, 1/11/01]

Comment:
OCSP servers today are known to be operated in relayed configuration (cf.
the "four corner" model).

Resolution:
(proposed) Since OCSP servers today are known to operate in a relay
configuration (cf. the "four corner" trust model) and further, that prior
system-level architectural practices strongly suggest that this feature is
inevitable (e.g. DNS), the loop detection requirement MUST be addressed on
an OPTIONAL basis.

Issue: Transitive trust and recursion [Covey, 1/10/01]
-------------------------------------------------------
Clarification:
"If the protocol permits a DPV/DPD response to include embedded DPD/DPD
responses from other servers, then the syntax will be a bit more complex
than it might be otherwise." [Covey, 1/10/01]

Proposed:
Provide hooks in the protocol to limit the extent of transitive trust.
[Covey, 1/10/01]

Discussion:
(largely via "Recursion Issues" thread)

"A DPV/DPD server could contact another server and repackage the response
that it receives." [Covey, 1/10/01]

" . . . unless OCSP allows for recursion itself, I think we have an inherent
limit in this case, i.e., it's not recursive, just 1-level delegation."
[Kent, 1/11/01].

"My preference is for server 1 to publicize the fact that it trusts
information obtained from certain other servers, and the client can take
that fact into account when deciding whether to trust server 1." [Covey,
1/12/01]

Do OCSP responses carry data that tie a response to a requestor? [Kent,
1/12/01]

"Only if the requestor uses a nonce." [Salz, 1/12/01]

"It is better to repackage the response instead of using a recursive
approach, because the client should be unaware
of the recursion." [Jakhar, 1/12/01].

". . . I'm not sure I want the DPV response to be used recursively, yet."
[Kent, 1/12/01]

". . . it seems useful to keep it [a DPV response] as is when used by a
client, even if this client uses the content of the response to create some
other statement or whatever to its type of client." [Sylvester, 1/14/01].

RFC 2560/OCSP, OCSPv2, DPV and DPD all enable recursion today [Myers, to be
posted].

Proposed Action:
Draft language in OCSPv2, DPV and DPD as appropriate regarding OPTIONAL
constraints on transitive trust, drawing notice to the inherent recursive
capabilities of the protocol as defined, propose updated drafts to the list
for WG consensus.

Issue: Should DPD responses be signed? [Manger, 1/24/01]
---------------------------------------------------------
Comments:
Since the objects being returned via DPD (certs, CRLs and potentially
recursive OCSP responses) are themselves signed, there exists no integrity
or authentication risks that require signing DPD responses. Some
environments might wish to architect at the system level a solution that
confirms the identity of approved responders. [Myers, this note]

"Signing is not required, but some form of authentication and integrity
checking should be employed to detect attacks on the
communications between the client and server, e.g., as a countermeasure for
more subtle DoS attacks." [Kent, 1/24/01].

Resolution:
DPD responses do not need to be signed.

Issue: Should DPV responses be signed?
--------------------------------------
Resolution:
"A signature is not needed for DPV in all cases either. Only if the client
wants NR for the DPV response is it necessary." [Kent, 1/24/01]

Comments:
DPV exists largely to enable NR arguments wrt existing and emerging digital
signature legislation. [Myers, this note]

Resolution:
RFC 2560 requires digital signatures on all "definitive" responses. OCSPv2
and DPV draft maintains this mandate subject to WG consensus to the
contrary. [Myers, this note]

Issue: "Do we need to support non-PKI aware, non-ASN.1-capable DPV clients?"
[Hanna, 1/17/01]
----------------------------------------------------------------------------
-----------------
Comments:
The OCSPv2/DPV/DPD team concluded in Pittsburg to not address XML issues.
[Myers, this note].

[Such clients should not be supported by PKIX]. "We have not submitted XKMS
to the PKIX list because (amongst other reasons) the group have 20 odd
drafts to clear from the pipeline as it is." [Hallam-Baker, 1/17/01]

" . . . the consensus answer is "No, we do not need to support non-PKI
aware, non-ASN.1-capable DPV clients."" [Hanna, 1/19/01]

"I have to concur - ASN.1 decoders can be relatively small. Steve's
suggestion simplifies this issue and makes it easier for us to move forward
on solutions." [Cross, 1/19/01]

"We do not need to support non-ASN.1-capable DPV clients." [Pinkas,
1/22/01].

Resolution:
The OCSPv2, DPV and DPD efforts as authored will not address XML.

Issue: Are post-facto queries a requirement? [Linn, 1/20/01]
---------------------------------------------------------------
Discussion:
"I think it'd be useful to be able to support post-facto queries in the DPV
framework." [Linn, 1/20/01]

"I think this is a very good idea. I strongly encourage us to do it."
[Housley, 1/22/01].

We agree. [Myers, Pinkas, Scheibelhofer et. al. in various public and
private exchanges over the past several years. One is Myers, 8/31/00 with
the subject, "OCSP support for historical reference to certificate
suspension".]

Bear in mind the effects of suspension on historial references. [Myers,
Covey and others.]

"1. If such service would exist, then it should be clear that it should only
be optional." [Pinkas, 1/22/01]

"2.a) Such a service would not work as soon as revocation status would be
obtained through OCSP responses. There is a move to get the revocation
status of the leaf certificate using OCSP. Such service would thus be
unusable in that case." [Pinkas, 1/22/01]

"2.b) Such a service would work if CRLs and delta CRls were all captured by
a TTP *different* from the CA. The size of the storage might become quite
important." [Pinkas, 1/22/01]

"2.c) Such a service would degrade the security. Let me explain. If people
can say: "We will check later, since we have a server always giving us the
right answer", then will rely on it and will not ask for the certificatio
path and revocation information at the time of initial verification. What
can happen between initial verification and a later verification ? The
answer is: a key compromise of a CA issuing key." [Pinkas, 1/22/01]

"I agree with 1, 2a, and 2b. I cannot accept 2c." [Housley, 1/22/01]

"As long as it is understood that a non-repudiation service (whether
technical or a stronger variant) should not rely primarily on post-facto
validation queries, supporting them is IMO not harmful." [Gindin, 1/22/01]

DPV does not need to specify a 3rd party time stamp on CRLs. "The STIME
working group is going to provide a straightforward mechanism for [a 3rd
party time stamp on the CRLs]". [Housley, 1/23/01].

"A DPV server should not be restricted to use an external timestamp. . . .
having TWO signatures seems some overhead to me." [Sylvester, 1/23/01]

Resolution:
(proposed) The OCSPv2 and DPV drafts will address historical references,
incorporating the concept of suspension, but will NOT mandate support for
CRL-based suspension in order to deliver on OCSP-based suspension. The
proposed standard will enable non-CRL means of maintaining records
suspension subject assertions regarding the integrity and authenticity of
those records in the Security Considerations section. Final syntax and
semantics are TBD subject to WG consensus on the amendments to the DPV and
DPD I-Ds entering the next IETF, especially as they relate to a linkage to
timestamping.

Updates to I-Ds in response to rqmts [Pinkas, 1/23/01]
------------------------------------------------------
Denis proposes ASN.1 and implementation-level updates to DPV and DPD I-Ds in
response to requirements consensus.

Resolution:
Pending consensus on rqmts and list-based response to proposals. Ad-hoc
working sessions in Minneapolis are likely although it would be very useful
to get this all resolved on-list.

Need for validation controls beyond 2459 rules [Pinkas, 1/23/01]
----------------------------------------------------------------
Comments:

". . . some validation policies may request some (even private)extensions in
the leaf certificate to be present for a certificate to be "valid" according
to a validation policy. Hence a response "valid", should be interpreted as a
minimum condition to be valid, but not always as a sufficient condition. We
would have to be very careful when explaining what a "valid" status means."
[Pinkas, 1/23/01]

Resolution:
"Good point. . . . I think we have some flexibility here, but we need to
pick a set of parameters and go forward." [Kent, 1/23/01]

DPD paths should be valid. [Pinkas, 1/23/01]
---------------------------------------------
Clarification:
"DPD only *helps* a PKI-aware client to know whether a certificate is valid.
It is better to return what can be returned as far a revocation information
is concerned rather than nothing. You also noticed that a client may only
request the certification path, without the revocation information."

Resolution:
"I still want DPD paths to be valid." [Kent, 1/23/01]

Comment:
This does not seem to imply a SHALL for inclusion of revocation information.

Ability to mandate name forms in DPD responses. [Housley, 1/24/01]
------------------------------------------------------------------
Clarification:
"One thing that I think we should add to DPD is the ability to mandate the
presence of a particular name form in the end entity certificate. For
example, and IPsec client might want an IP address or DNS name in the
certificate. An S/MIME client might want an RFC 822 address in the
certificate." [Housley, 1/24/01]

Comment:
MUST name constraints in a DPD query force the presence of name constraints
in related certificates?

Resolution:
"I agree with the need for name constraints, and I have been persuaded
that associating them with trust anchors is preferable to creating cross
certs." [Kent, 1/24/01]

Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id QAA01659 for ; Mon, 29 Jan 2001 16:24:54 -0800 (PST)
Received: from ISI.EDU (jet.isi.edu [128.9.160.87]) by boreas.isi.edu (8.9.3/8.9.3) with ESMTP id QAA10854; Mon, 29 Jan 2001 16:31:29 -0800 (PST)
Message-Id: <[email-masked]>
To: IETF-Announce: ;
Subject: RFC 3039 on Qualified Certificates Profile
Cc: [email-masked], [email-masked]
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary=NextPart
Date: Mon, 29 Jan 2001 16:31:28 -0800
From: RFC Editor

--NextPart

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

RFC 3039

Title: Internet X.509 Public Key Infrastructure Qualified
Certificates Profile
Author(s): S. Santesson, W. Polk, P. Barzin, M. Nystrom
Status: Standards Track
Date: January 2001
Mailbox: [email-masked], [email-masked],
[email-masked], [email-masked]
Pages: 35
Characters: 67619
Updates/Obsoletes/SeeAlso: None

I-D Tag: draft-ietf-pkix-qc-06.txt

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

This document forms a certificate profile for Qualified Certificates,
based on RFC 2459, for use in the Internet. The term Qualified
Certificate is used to describe a certificate with a certain
qualified status within applicable governing law. Further, Qualified
Certificates are issued exclusively to physical persons.

The goal of this document is to define a general syntax independent of
local legal requirements. The profile is however designed to allow
further profiling in order to meet specific local needs.

It is important to note that the profile does not define any legal
requirements for Qualified Certificates.

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

This is now a Proposed Standard Protocol.

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

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

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

To: [email-masked]
Subject: getting rfcs

help: ways_to_get_rfcs

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

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

...

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

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

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

Content-Type: text/plain
Content-ID: <[email-masked]>

RETRIEVE: rfc
DOC-ID: rfc3039

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

Content-Type: text/plain
Content-ID: <[email-masked]>

--OtherAccess--
--NextPart--

Received: from dfw-smtpout1.email.verio.net (dfw-smtpout1.email.verio.net [129.250.36.41]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA28179; Mon, 29 Jan 2001 15:05:04 -0800 (PST)
Received: from [129.250.38.62] (helo=dfw-mmp2.email.verio.net) by dfw-smtpout1.email.verio.net with esmtp id 14NNRG-0003wb-00; Mon, 29 Jan 2001 23:10:22 +0000
Received: from [206.133.83.14] (helo=localhost) by dfw-mmp2.email.verio.net with esmtp id 14NNPk-0002Od-00; Mon, 29 Jan 2001 23:08:48 +0000
X-Sender: [email-masked]
From: Dave
To: "customer"
Date: Mon, 29 Jan 2001 14:25:17 -0500
Subject: I could go to JAIL for selling this CD!
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_001__10618077_51917.11"
Message-Id:

This is a Multipart MIME message.

------=_NextPart_000_001__10618077_51917.11
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 7bit

------=_NextPart_000_001__10618077_51917.11
Content-Type: text/html; charset=iso-8859-1
Content-Transfer-Encoding: base64

PCFkb2N0eXBlIGh0bWwgcHVibGljICItLy93M2MvL2R0ZCBodG1sIDQuMCB0cmFuc2l0aW9u
YWwvL2VuIj4NCjxodG1sPg0KPGhlYWQ+DQogICA8bWV0YSBodHRwLWVxdWl2PSJDb250ZW50
LVR5cGUiIGNvbnRlbnQ9InRleHQvaHRtbDsgY2hhcnNldD1pc28tODg1OS0xIj4NCiAgIDxt
ZXRhIG5hbWU9IkdFTkVSQVRPUiIgY29udGVudD0iTW96aWxsYS80LjYxIFtlbl0gKFdpbjk4
OyBJKSBbTmV0c2NhcGVdIj4NCiAgIDx0aXRsZT5UaGUgQkFOTkVEIENEITwvdGl0bGU+DQo8
L2hlYWQ+DQo8Ym9keT4NCjxmb250IHNpemU9KzE+SGksPC9mb250Pg0KPHA+PGZvbnQgc2l6
ZT0rMT5JIGhhdmUgYmVlbiByZWNpZXZpbmcgZW1haWxzIHNheWluZyB0aGF0IEknbSBjb250
cmlidXRpbmcNCnRvPC9mb250Pg0KPGJyPjxmb250IHNpemU9KzE+dGhlICJtb3JhbCBkZWNh
eSBvZiBzb2NpZXR5IiBieSBzZWxsaW5nIHRoZSBCYW5uZWQgQ0QuJm5ic3A7DQpUaGF0PC9m
b250Pg0KPGJyPjxmb250IHNpemU9KzE+bWF5IGJlLCBidXQgSSBmZWVsIHN0cm9uZ2x5IHRo
YXQgeW91IGhhdmUgYSByaWdodCB0bw0KYmVuZWZpdCBmcm9tPC9mb250Pg0KPGJyPjxmb250
IHNpemU9KzE+dGhpcyBoYXJkLXRvLWZpbmQgaW5mb3JtYXRpb24uPC9mb250Pg0KPHA+PGZv
bnQgY29sb3I9IiNDQzAwMDAiPjxmb250IHNpemU9KzE+U28gSSBhbSBnaXZpbmcgeW91IE9O
RSBMQVNUIENIQU5DRQ0KdG8gb3JkZXI8L2ZvbnQ+PC9mb250Pg0KPGJyPjxmb250IGNvbG9y
PSIjQ0MwMDAwIj48Zm9udCBzaXplPSsxPnRoZSBCYW5uZWQgQ0QhPC9mb250PjwvZm9udD4N
Cjxicj4mbmJzcDsNCjx0YWJsZSBCT1JERVI9MCBDT0xTPTIgV0lEVEg9Ijc1JSIgPg0KPHRy
Pg0KPHRkIFdJRFRIPSIxJSI+PGltZyBTUkM9Imh0dHA6Ly9jb21wdXpvbmV1c2EuY29tL2lt
YWdlcy9zcHkuanBnIiBoZWlnaHQ9MTI4IHdpZHRoPTg2PjwvdGQ+DQoNCjx0ZD48Zm9udCBz
aXplPSsxPldpdGggdGhpcyBwb3dlcmZ1bCBDRCwgeW91IHdpbGwgYmUgYWJsZSB0byBpbnZl
c3RpZ2F0ZQ0KeW91ciBmcmllbmRzLCBlbmVtaWVzIGFuZCBsb3ZlcnMgaW4ganVzdCBtaW51
dGVzIHVzaW5nIHRoZSBJbnRlcm5ldC4mbmJzcDsNCllvdSBjYW4gdHJhY2sgZG93biBvbGQg
ZmxhbWVzIGZyb20gY29sbGVnZSwgb3IgeW91IGNhbiBkaWcgdXAgc29tZSBkaXJ0DQpvbiB5
b3VyIGJvc3MgdG8gbWFrZSBzdXJlIHlvdSBnZXQgdGhhdCBuZXh0IHByb21vdGlvbiE8L2Zv
bnQ+PC90ZD4NCjwvdHI+DQo8L3RhYmxlPg0KDQo8cD48Zm9udCBzaXplPSsxPk9yIG1heWJl
IHlvdSB3YW50IGEgZmFrZSBkaXBsb21hIHRvIGhhbmcgb24geW91ciBiZWRyb29tPC9mb250
Pg0KPGJyPjxmb250IHNpemU9KzE+d2FsbC4mbmJzcDsgWW91J2xsIGZpbmQgYWRkcmVzc2Vz
IGZvciBjb21wYW5pZXMgdGhhdA0KbWFrZSB0aGVzZTwvZm9udD4NCjxicj48Zm9udCBzaXpl
PSsxPmRpcGxvbWFzIG9uIHRoZSBCYW5uZWQgQ0QuPC9mb250Pg0KPHA+PGZvbnQgc2l6ZT0r
MT5OZWVkIHRvIGRpc2FwcGVhciBmYXN0IGFuZCBuZXZlciBsb29rIGJhY2s/Jm5ic3A7IE5v
IHByb2JsZW0hPC9mb250Pg0KPGJyPjxmb250IHNpemU9KzE+VXNpbmcgdGhlIEJhbm5lZCBD
RCwgeW91IHdpbGwgbGVhcm4gaG93IHRvIGJ1aWxkIGEgY29tcGxldGVseTwvZm9udD4NCjxi
cj48Zm9udCBzaXplPSsxPm5ldyBpZGVudGl0eS48L2ZvbnQ+DQo8cD48Zm9udCBzaXplPSsx
Pk9idmlvdXNseSwgdGhlIFBvd2VycyBUaGF0IEJlIGRvbid0IHdhbnQgeW91IHRvIGhhdmUg
dGhlPC9mb250Pg0KPGJyPjxmb250IHNpemU9KzE+QmFubmVkIENELiZuYnNwOyBUaGV5IGhh
dmUgdGhyZWF0ZW5lZCBtZSB3aXRoIGxhd3N1aXRzLA0KZmluZXMsPC9mb250Pg0KPGJyPjxm
b250IHNpemU9KzE+YW5kIGV2ZW4gaW1wcmlzb25tZW50IHVubGVzcyBJIHN0b3Agc2VsbGlu
ZyBpdCBpbW1lZGlhdGVseS48L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0rMT5CdXQgSSBmZWVs
IHRoYXQgWU9VIGhhdmUgYSBDb25zdGl0dXRpb25hbCByaWdodCB0byBhY2Nlc3M8L2ZvbnQ+
DQo8YnI+PGZvbnQgc2l6ZT0rMT50aGlzIHR5cGUgb2YgaW5mb3JtYXRpb24sIGFuZCBJIGNh
bid0IGJlIGludGltaWRhdGVkLjwvZm9udD4NCjxicj4mbmJzcDsNCjx0YWJsZSBCT1JERVI9
MCBDT0xTPTIgV0lEVEg9IjUwJSIgPg0KPHRyPg0KPHRkIFdJRFRIPSIxMDAlIj48aT48Zm9u
dCBjb2xvcj0iIzMzMzNGRiI+PGZvbnQgc2l6ZT0rMT5VbmNsZSBTYW0gYW5kIHlvdXINCmNy
ZWRpdG9ycyBhcmUgaG9ycmlmaWVkIHRoYXQgSSBhbSBzdGlsbCBzZWxsaW5nIHRoaXMgcHJv
ZHVjdCEmbmJzcDsgVGhlcmUNCm11c3QgYmUgYSBwcmljZSBvbiBteSBoZWFkITwvZm9udD48
L2ZvbnQ+PC9pPjwvdGQ+DQoNCjx0ZCBXSURUSD0iMSUiPjxpbWcgU1JDPSJodHRwOi8vY29t
cHV6b25ldXNhLmNvbS9pbWFnZXMvb3V0bGF3LmpwZyIgaGVpZ2h0PTEyOCB3aWR0aD05Mz48
L3RkPg0KPC90cj4NCjwvdGFibGU+DQoNCjxwPjxmb250IHNpemU9KzE+V2h5IGFyZSB0aGV5
IHNvIHVwc2V0PyBCZWNhdXNlIHRoaXMgQ0QgZ2l2ZXMgeW91IGZyZWVkb20uPC9mb250Pg0K
PGJyPjxmb250IHNpemU9KzE+QW5kIHlvdSBjYW4ndCBidXkgZnJlZWRvbSBhdCB5b3VyIGxv
Y2FsIFdhbG1hcnQuJm5ic3A7DQpZb3Ugd2lsbDwvZm9udD4NCjxicj48Zm9udCBzaXplPSsx
PmhhdmUgdGhlIGZyZWVkb20gdG8gYXZvaWQgY3JlZGl0b3JzLCBqdWRnbWVudHMsIGxhd3N1
aXRzLA0KSVJTPC9mb250Pg0KPGJyPjxmb250IHNpemU9KzE+dGF4IGNvbGxlY3RvcnMsIGNy
aW1pbmFsIGluZGljdG1lbnRzLCB5b3VyIGdyZWVkeSBleC13aWZlDQpvcjwvZm9udD4NCjxi
cj48Zm9udCBzaXplPSsxPmV4LWh1c2JhbmQsIGFuZCBNVUNIIG1vcmUhPC9mb250Pg0KPHA+
PGZvbnQgc2l6ZT0rMT5KdXN0IGxvb2sgYXQgc29tZSBvZiB0aGUgdGhpbmdzIHlvdSBjYW4g
ZG8gd2l0aCB0aGlzIENEDQouLi48L2ZvbnQ+DQo8dWw+DQo8bGk+DQo8Yj48Zm9udCBjb2xv
cj0iIzAwMDA5OSI+U2F2ZSBodW5kcmVkcyBvciBldmVuIHRob3VzYW5kcyBvZiBkb2xsYXJz
IG9uDQp5b3VyIHRheGVzIGJ5IHVzaW5nIHRoZSBzZWNyZXQgdGF4IHRpcHMgY29udGFpbmVk
IGluIHRoaXMgcGFja2FnZS4mbmJzcDsNClRoZSBJUlMgZG9lcyBOT1Qgd2FudCB5b3UgdG8g
a25vdyB0aGVzZSBsb29waG9sZXMhPC9mb250PjwvYj48L2xpPg0KDQo8bGk+DQo8Yj48Zm9u
dCBjb2xvcj0iIzAwMDA5OSI+VHJhY2sgZG93biBmcmllbmRzIGFuZCBvbGQgZmxhbWVzIGZy
b20gdGhlIGNvbWZvcnQNCm9mIHlvdXIgb3duIGhvbWUgd2l0aCBvdXIgSW50ZXJuZXQgaW52
ZXN0aWdhdGlvbiByZXNvdXJjZXMhPC9mb250PjwvYj48L2xpPg0KDQo8bGk+DQo8Yj48Zm9u
dCBjb2xvcj0iIzAwMDA5OSI+RmluZCBvdXQgd2hlcmUgeW91ciBFWCBpcyBoaWRpbmcgdGhl
aXIgbW9uZXkgdG8NCmF2b2lkIGFsaW1vbnksIGNoaWxkIHN1cHBvcnQsIG9yIGRpdm9yY2Ug
c2V0dGxlbWVudHMuIFRoZW4gZ2V0IHlvdXIgaGFuZHMNCm9uIHRoYXQgbW9uZXkuJm5ic3A7
IEJsZWVkICdlbSBkcnkhJm5ic3A7IFByaXZhdGUgaW52ZXN0aWdhdG9ycyBjaGFyZ2UNCnRo
b3VzYW5kcyBvZiBkb2xsYXJzIGZvciB0aGlzIHNlcnZpY2UsIGJ1dCB5b3UgY2FuIGRvIGl0
IHdpdGggYSBjb21wdXRlcg0KYW5kIGFuIGludGVybmV0IGNvbmVjdGlvbiB3aGVuIHlvdSBi
dXkgdGhlIEJhbm5lZCBDRCE8L2ZvbnQ+PC9iPjwvbGk+DQoNCjxsaT4NCjxiPjxmb250IGNv
bG9yPSIjMDAwMDk5Ij5MZWFybiBob3cgdG8gdXNlIG9mZnNob3JlIG1vbmV5IGhhdmVucyBh
bmQgYXNzZXQNCnByb3RlY3Rpb24gdHJ1c3RzIHRvIGF2b2lkIGxhd3N1aXRzLCBqdWRnbWVu
dHMsIGFuZCBmb29sIHRoZSBtb3N0IGFnZ3Jlc3NpdmUNCnRheCBjb2xsZWN0b3IhJm5ic3A7
IElmIHlvdXIgbW9uZXkgaXMgc2l0dGluZyBpbiBhIFVTIGJhbmsgYWNjb3VudCwgeW91cg0K
ZnVuZHMgY2FuIGJlIGxldmllZCBvciBmcm96ZW4gY29tcGxldGVseSBhdCBhbnkgdGltZS4m
bmJzcDsgVGhlIFVTIGdvdmVybm1lbnQNCnVzZXMgImNpdmlsIGFzc2V0IGZvcmZlaXR1cmUi
IHRvIHN0ZWFsIGJpbGxpb25zIG9mIGRvbGxhcnMgZWFjaCB5ZWFyIGZyb20NCmhhcmQtd29y
a2luZywgbGF3IGFiaWRpbmcgY2l0aXplbnMuJm5ic3A7IEdldCB5b3VyIG1vbmV5IG91dCBv
ZiB0aGUgY291bnRyeQ0KYmVmb3JlIFVuY2xlIFNhbSBzbmF0Y2hlcyBpdCBhbGwuPC9mb250
PjwvYj48L2xpPg0KDQo8bGk+DQo8Yj48Zm9udCBjb2xvcj0iIzAwMDA5OSI+RmluZCBvdXQg
d2hlcmUgdG8gYnV5ICJmb3JiaWRkZW4gcHJvZHVjdHMiIG9uDQp0aGUgSW50ZXJuZXQuIEZ1
cnRoZXIgZWxhYm9yYXRpb24gc2hvdWxkIG5vdCBiZSBuZWNlc3Nhcnk7IGp1c3QgdXNlIHlv
dXINCmltYWdpbmF0aW9uLjwvZm9udD48L2I+PC9saT4NCg0KPGxpPg0KPGI+PGZvbnQgY29s
b3I9IiMwMDAwOTkiPkdldCBhIGJldHRlciBqb2IgYnkgcHVyY2hhc2luZyBhIGNvbGxlZ2Ug
ZGVncmVlDQooaW5jbHVkaW5nIGEgUGhkISkgZm9yIGEgdmVyeSBsb3cgZmVlLiBObyBzdHVk
eSByZXF1aXJlZCE8L2ZvbnQ+PC9iPjwvbGk+DQoNCjxsaT4NCjxiPjxmb250IGNvbG9yPSIj
MDAwMDk5Ij5JZiB5b3VyIEVYIGlzIGNvbWluZyBhZnRlciB5b3VyIG1vbmV5LCBzdGF5IG9u
ZQ0Kc3RlcCBhaGVhZCBvZiB0aGUgbGF3eWVycyBhbmQga2VlcCB0aGVpciBncmVlZHkgaGFu
ZHMgb2ZmIHlvdXIgbG9vdC4gRmluZA0Kb3V0IGhvdyB0byBoaWRlIHlvdXIgbW9uZXkgd2hl
cmUgaXQgd2lsbCBuZXZlciBiZSBmb3VuZC48L2ZvbnQ+PC9iPjwvbGk+DQoNCjxsaT4NCjxi
Pjxmb250IGNvbG9yPSIjMDAwMDk5Ij5Bdm9pZCBsZWdhbCBwcm9ibGVtcywganVkZ21lbnRz
LCBjb252aWN0aW9ucywNCmFuZCBldmVuIHByaXNvbiBzZW50ZW5jZXMgYnkgb2J0YWluaW5n
IGEgY29tcGxldGVseSBuZXcgaWRlbnRpdHkgYW5kIGRpc2FwcGVhcmluZw0Kd2l0aG91dCBh
IHRyYWNlITwvZm9udD48L2I+PC9saT4NCg0KPGxpPg0KPGI+PGZvbnQgY29sb3I9IiMwMDAw
OTkiPkVyYXNlIHlvdXIgY3JpbWluYWwgcmVjb3JkIGFuZCBvYnRhaW4gYSBjb3B5IG9mDQp5
b3VyIEZCSSBmaWxlIHVzaW5nIHRoZSBGcmVlZG9tIG9mIEluZm9ybWF0aW9uIEFjdC4mbmJz
cDsgRmluZCBvdXQgaWYgdGhlDQpnb3Zlcm5tZW50IGlzIGludmVzdGlnYXRpbmcgeW91IE5P
VyBiZWZvcmUgaXQncyB0b28gTEFURSE8L2ZvbnQ+PC9iPjwvbGk+DQo8L3VsPg0KPGZvbnQg
c2l6ZT0rMT5JZiB5b3UgaGF2ZSBiZWVuIHB1dHRpbmcgb2ZmIGJ1eWluZyBUaGUgQmFubmVk
IENELCB3aGF0IGFyZQ0KeW91PC9mb250Pg0KPGJyPjxmb250IHNpemU9KzE+d2FpdGluZyBm
b3I/Jm5ic3A7IEJpZyBCcm90aGVyIGlzIGFscmVhZHkgYnJlYXRoaW5nIGRvd24NCm15IG5l
Y2ssIHNvPC9mb250Pg0KPGJyPjxmb250IHNpemU9KzE+SSBjYW4ndCBrZWVwIHNlbGxpbmcg
aXQgZm9yZXZlci4mbmJzcDsgSWYgeW91IGtlZXAgd2FpdGluZw0KdG8gcGxhY2U8L2ZvbnQ+
DQo8YnI+PGZvbnQgc2l6ZT0rMT55b3VyIG9yZGVyLCB5b3UgbWF5IG5ldmVyIGZpbmQgVGhl
IEJhbm5lZCBDRCBhZ2Fpbi4mbmJzcDsNCkZvciBvbmx5PC9mb250Pg0KPGJyPjxmb250IHNp
emU9KzE+JDE5Ljk5LCB5b3Ugd2lsbCBnYWluIHZhbHVhYmxlIHBlYWNlLW9mLW1pbmQga25v
d2luZw0KaG93IHRvPC9mb250Pg0KPGJyPjxmb250IHNpemU9KzE+c2FmZWd1YXJkIHlvdXJz
ZWxmLCB5b3VyIGZhbWlseSwgYW5kIHlvdXIgbW9uZXkuJm5ic3A7DQpXaG8gY2FuIHB1dCBh
PC9mb250Pg0KPGJyPjxmb250IHNpemU9KzE+cHJpY2Ugb24gZnJlZWRvbT8hPC9mb250Pg0K
PHA+PGk+PHU+PGZvbnQgc2l6ZT0rMT5IZXJlIGlzIGFub3RoZXIgbG9vayBhdCB0aGUgY29u
dGVudHMgb2YgdGhlIEJBTk5FRA0KQ0Q6PC9mb250PjwvdT48L2k+DQo8cD48aW1nIFNSQz0i
aHR0cDovL2NvbXB1em9uZXVzYS5jb20vaW1hZ2VzL2J1dHRvbi5naWYiIGhlaWdodD0xOSB3
aWR0aD0xOT48Zm9udCBjb2xvcj0iIzY2NjY2NiI+PGZvbnQgc2l6ZT0rMT4NCkZpbmQgY29u
ZmlkZW50aWFsIGluZm8gb24gYW55b25lIGluIDMwIG1pbnV0ZXMgb3I8L2ZvbnQ+PC9mb250
Pg0KPGJyPjxmb250IGNvbG9yPSIjNjY2NjY2Ij48Zm9udCBzaXplPSsxPmxlc3Mgb24gdGhl
IEludGVybmV0LiBZb3UnbGwgYmUNCmFibGUgdG8gdHJhY2sgZG93biB5b3VyPC9mb250Pjwv
Zm9udD4NCjxicj48Zm9udCBjb2xvcj0iIzY2NjY2NiI+PGZvbnQgc2l6ZT0rMT5vbGQgZmxh
bWUsIGZpbmQgb3V0IGhvdyBtdWNoIG1vbmV5DQp5b3VyIGV4IGlzIGhpZGluZzwvZm9udD48
L2ZvbnQ+DQo8YnI+PGZvbnQgY29sb3I9IiM2NjY2NjYiPjxmb250IHNpemU9KzE+aW4gdGhl
aXIgYmFuayBhY2NvdW50LCBvciBydW4gYQ0KYmFja2dyb3VuZCBjaGVjayBvbjwvZm9udD48
L2ZvbnQ+DQo8YnI+PGZvbnQgY29sb3I9IiM2NjY2NjYiPjxmb250IHNpemU9KzE+cHJvZXNw
ZWN0aXZlIGNsaWVudCBvciBlbXBsb3llZS4NCkV2ZW4gZ292ZXJubWVudDwvZm9udD48L2Zv
bnQ+DQo8YnI+PGZvbnQgY29sb3I9IiM2NjY2NjYiPjxmb250IHNpemU9KzE+YWdlbmNpZXMg
aGF2ZSB0cm91YmxlIG9idGFpbmluZw0KbXVjaCBvZiB0aGlzIGluZm9ybWF0aW9uLjwvZm9u
dD48L2ZvbnQ+DQo8YnI+PGZvbnQgY29sb3I9IiM2NjY2NjYiPjxmb250IHNpemU9KzE+WW91
IHdpbGwgaGF2ZSBhbGwgdGhlIHJlc291cmNlcw0Kb2YgYW55IHByb2Zlc3Npb25hbDwvZm9u
dD48L2ZvbnQ+DQo8YnI+PGZvbnQgY29sb3I9IiM2NjY2NjYiPjxmb250IHNpemU9KzE+aW52
ZXN0aWdhdG9yIHJpZ2h0IGF0IHlvdXIgZmluZ2VydGlwcw0KLSBvbiB5b3VyIGhvbWU8L2Zv
bnQ+PC9mb250Pg0KPGJyPjxmb250IGNvbG9yPSIjNjY2NjY2Ij48Zm9udCBzaXplPSsxPmNv
bXB1dGVyITwvZm9udD48L2ZvbnQ+DQo8cD48aW1nIFNSQz0iaHR0cDovL2NvbXB1em9uZXVz
YS5jb20vaW1hZ2VzL2J1dHRvbi5naWYiIGhlaWdodD0xOSB3aWR0aD0xOT48Zm9udCBjb2xv
cj0iIzY2NjY2NiI+PGZvbnQgc2l6ZT0rMT4NCkxpc3Qgb2YgY29tcGFuaWVzIHdobyB3aWxs
IGlzc3VlIHlvdSBhIGNvbGxlZ2U8L2ZvbnQ+PC9mb250Pg0KPGJyPjxmb250IGNvbG9yPSIj
NjY2NjY2Ij48Zm9udCBzaXplPSsxPmRlZ3JlZSAoaW5jbHVkaW5nIGEgUGhkLikgZm9yIGEN
CmZlZS4gTm8gc3R1ZHkgcmVxdWlyZWQhPC9mb250PjwvZm9udD4NCjxwPjxpbWcgU1JDPSJo
dHRwOi8vY29tcHV6b25ldXNhLmNvbS9pbWFnZXMvYnV0dG9uLmdpZiIgaGVpZ2h0PTE5IHdp
ZHRoPTE5Pjxmb250IGNvbG9yPSIjNjY2NjY2Ij48Zm9udCBzaXplPSsxPg0KTGVhcm4gaG93
IHRvIGdldCBGUkVFIGNhYmxlIGFuZCBEU1MgY2hhbm5lbHMsPC9mb250PjwvZm9udD4NCjxi
cj48Zm9udCBjb2xvcj0iIzY2NjY2NiI+PGZvbnQgc2l6ZT0rMT5pbmNsdWRpbmcgdGhlIGFk
dWx0IHN0YXRpb25zIGFuZA0KUGF5LVBlci1WaWV3ITwvZm9udD48L2ZvbnQ+DQo8cD48aW1n
IFNSQz0iaHR0cDovL2NvbXB1em9uZXVzYS5jb20vaW1hZ2VzL2J1dHRvbi5naWYiIGhlaWdo
dD0xOSB3aWR0aD0xOT48Zm9udCBjb2xvcj0iIzY2NjY2NiI+PGZvbnQgc2l6ZT0rMT4NCkhv
dyB0byBPYnRhaW4gTWljcm9zb2Z0IFByb2R1Y3RzIGFic29sdXRlbHk8L2ZvbnQ+PC9mb250
Pg0KPGJyPjxmb250IGNvbG9yPSIjNjY2NjY2Ij48Zm9udCBzaXplPSsxPkZSRUUsIHRoZSBz
YWZlIGFuZCBMRUdBTCB3YXkhPC9mb250PjwvZm9udD4NCjxwPjxpbWcgU1JDPSJodHRwOi8v
Y29tcHV6b25ldXNhLmNvbS9pbWFnZXMvYnV0dG9uLmdpZiIgaGVpZ2h0PTE5IHdpZHRoPTE5
Pjxmb250IGNvbG9yPSIjNjY2NjY2Ij48Zm9udCBzaXplPSsxPg0KTGlzdCBvZiBzdXBwbGll
cnMgb2YgInF1ZXN0aW9uYWJsZSIgaXRlbXMsIHN1Y2g8L2ZvbnQ+PC9mb250Pg0KPGJyPjxm
b250IGNvbG9yPSIjNjY2NjY2Ij48Zm9udCBzaXplPSsxPmFzIGZjYyBiYW5uZWQgY29tbXVu
aWNhdGlvbnMgZGV2aWNlcywNCnNjYW5uZXJzLDwvZm9udD48L2ZvbnQ+DQo8YnI+PGZvbnQg
Y29sb3I9IiM2NjY2NjYiPjxmb250IHNpemU9KzE+bmlnaHQgdmlzaW9uIGdvZ2dsZXMsIHBh
c3Nwb3J0cywNCmZha2UgaWRlbnRpZmljYXRpb24sPC9mb250PjwvZm9udD4NCjxicj48Zm9u
dCBjb2xvcj0iIzY2NjY2NiI+PGZvbnQgc2l6ZT0rMT5hbmQgZXZlcnl0aGluZyBlbHNlIHRo
YXQgeW91IHdvbid0DQpmaW5kIGluIHRoZSBiYWNrPC9mb250PjwvZm9udD4NCjxicj48Zm9u
dCBjb2xvcj0iIzY2NjY2NiI+PGZvbnQgc2l6ZT0rMT5vZiBTb2xkaWVyIG9mIEZvcnR1bmUg
bWFnYXppbmUhPC9mb250PjwvZm9udD4NCjxwPjxpbWcgU1JDPSJodHRwOi8vY29tcHV6b25l
dXNhLmNvbS9pbWFnZXMvYnV0dG9uLmdpZiIgaGVpZ2h0PTE5IHdpZHRoPTE5Pjxmb250IGNv
bG9yPSIjNjY2NjY2Ij48Zm9udCBzaXplPSsxPg0KRmluZCBwcm9kdWN0cyB0byByZXNlbGwg
b24gdGhlIEludGVybmV0IHdpdGggb3VyPC9mb250PjwvZm9udD4NCjxicj48Zm9udCBjb2xv
cj0iIzY2NjY2NiI+PGZvbnQgc2l6ZT0rMT5XaG9sZXNhbGUgRGlyZWN0b3J5IGNvbnRhaW5p
bmcNCm92ZXIgMSBtaWxsaW9uPC9mb250PjwvZm9udD4NCjxicj48Zm9udCBjb2xvcj0iIzY2
NjY2NiI+PGZvbnQgc2l6ZT0rMT4odGhhdCdzIHJpZ2h0LCBvbmUgbWlsbGlvbiEpIHdob2xl
c2FsZQ0Kc291cmNlcyBmb3I8L2ZvbnQ+PC9mb250Pg0KPGJyPjxmb250IGNvbG9yPSIjNjY2
NjY2Ij48Zm9udCBzaXplPSsxPmNvbXB1dGVycywgZWxlY3Ryb25pY3MsIGJlYW5pZXMsDQp0
cmVuZCBpdGVtcyw8L2ZvbnQ+PC9mb250Pg0KPGJyPjxmb250IGNvbG9yPSIjNjY2NjY2Ij48
Zm9udCBzaXplPSsxPmpld2VscnksIGNhcnMsIGNvbGxlY3RpYmxlcywgYW5kDQpldmVyeXRo
aW5nIGVsc2UhPC9mb250PjwvZm9udD4NCjxwPjxpbWcgU1JDPSJodHRwOi8vY29tcHV6b25l
dXNhLmNvbS9pbWFnZXMvYnV0dG9uLmdpZiIgaGVpZ2h0PTE5IHdpZHRoPTE5Pjxmb250IGNv
bG9yPSIjNjY2NjY2Ij48Zm9udCBzaXplPSsxPg0KT3ZlciAyNSBtaWxsaW9uIGVtYWlsIGFk
ZHJlc3NlcywgZnJlc2ggYW5kPC9mb250PjwvZm9udD4NCjxicj48Zm9udCBjb2xvcj0iIzY2
NjY2NiI+PGZvbnQgc2l6ZT0rMT50YXJnZXRlZCEgWW91IGNhbiB1c2UgdGhlc2UgdG8NCmNv
bnRhY3QgdGhlIHBlb3BsZTwvZm9udD48L2ZvbnQ+DQo8YnI+PGZvbnQgY29sb3I9IiM2NjY2
NjYiPjxmb250IHNpemU9KzE+YW5kIHNlbmQgdGhlbSB5b3VyIGFkdmVydGlzZW1lbnRzLjwv
Zm9udD48L2ZvbnQ+DQo8cD48aW1nIFNSQz0iaHR0cDovL2NvbXB1em9uZXVzYS5jb20vaW1h
Z2VzL2J1dHRvbi5naWYiIGhlaWdodD0xOSB3aWR0aD0xOT48Zm9udCBjb2xvcj0iIzY2NjY2
NiI+PGZvbnQgc2l6ZT0rMT4NCkZpbmQgb3V0IGhvdyB0byBnZXQgYSBjb21wbGV0ZWx5IG5l
dyBpZGVudGl0eS48L2ZvbnQ+PC9mb250Pg0KPGJyPjxmb250IGNvbG9yPSIjNjY2NjY2Ij48
Zm9udCBzaXplPSsxPkRpc2FwcGVhciB3aXRob3V0IGEgdHJhY2UhPC9mb250PjwvZm9udD4N
CjxwPjxpbWcgU1JDPSJodHRwOi8vY29tcHV6b25ldXNhLmNvbS9pbWFnZXMvYnV0dG9uLmdp
ZiIgaGVpZ2h0PTE5IHdpZHRoPTE5Pjxmb250IGNvbG9yPSIjNjY2NjY2Ij48Zm9udCBzaXpl
PSsxPg0KRmluZCBvdXQgaG93IHRvIEVSQVNFIGJhZCBjcmVkaXQgYW5kIGV2ZW48L2ZvbnQ+
PC9mb250Pg0KPGJyPjxmb250IGNvbG9yPSIjNjY2NjY2Ij48Zm9udCBzaXplPSsxPmNyZWF0
ZSBhIHdob2xlIG5ldyBmaWxlIGluIHRoZQ0KY3JlZGl0IGJ1cmVhdSBjb21wdXRlcnMuPC9m
b250PjwvZm9udD4NCjxwPjxpbWcgU1JDPSJodHRwOi8vY29tcHV6b25ldXNhLmNvbS9pbWFn
ZXMvYnV0dG9uLmdpZiIgaGVpZ2h0PTE5IHdpZHRoPTE5Pjxmb250IGNvbG9yPSIjNjY2NjY2
Ij48Zm9udCBzaXplPSsxPg0KTGVhcm4gaG93IHRvIGJlYXQgdGhlIElSUy4gVGF4IHRpcHMg
Zm9yIHRoZTwvZm9udD48L2ZvbnQ+DQo8YnI+PGZvbnQgY29sb3I9IiM2NjY2NjYiPjxmb250
IHNpemU9KzE+cmVzdCBvZiB1cy48L2ZvbnQ+PC9mb250Pg0KPHA+PGltZyBTUkM9Imh0dHA6
Ly9jb21wdXpvbmV1c2EuY29tL2ltYWdlcy9idXR0b24uZ2lmIiBoZWlnaHQ9MTkgd2lkdGg9
MTk+PGZvbnQgY29sb3I9IiM2NjY2NjYiPjxmb250IHNpemU9KzE+DQpDb21wbGV0ZSBndWlk
ZSBvbiBob3cgdG8gY2xhaW0gcHVibGljIGxhbmQ8L2ZvbnQ+PC9mb250Pg0KPGJyPjxmb250
IGNvbG9yPSIjNjY2NjY2Ij48Zm9udCBzaXplPSsxPm9mZmVyZWQgYnkgdGhlIEdvdmVybm1l
bnQuIFlvdQ0KY2FuIGZpbmQgeW91cjwvZm9udD48L2ZvbnQ+DQo8YnI+PGZvbnQgY29sb3I9
IiM2NjY2NjYiPjxmb250IHNpemU9KzE+ZHJlYW0gaG9tZSBmb3IgYSByaWRpY3Vsb3VzbHkg
bG93DQpwcmljZSBvciBidXk8L2ZvbnQ+PC9mb250Pg0KPGJyPjxmb250IGNvbG9yPSIjNjY2
NjY2Ij48Zm9udCBzaXplPSsxPnByb3BlcnRpZXMgdG8gcmVzZWxsIGZvciBhIGh1Z2UNCnBy
b2ZpdCE8L2ZvbnQ+PC9mb250Pg0KPHA+PGltZyBTUkM9Imh0dHA6Ly9jb21wdXpvbmV1c2Eu
Y29tL2ltYWdlcy9idXR0b24uZ2lmIiBoZWlnaHQ9MTkgd2lkdGg9MTk+PGZvbnQgY29sb3I9
IiM2NjY2NjYiPjxmb250IHNpemU9KzE+DQpBY2NlcHQgY2hlY2tzIGZyb20geW91ciBjdXN0
b21lcnMgYnkgZmF4LDwvZm9udD48L2ZvbnQ+DQo8YnI+PGZvbnQgY29sb3I9IiM2NjY2NjYi
Pjxmb250IHNpemU9KzE+cGhvbmUgYW5kIGVtYWlsIHdpdGggdGhlIGZ1bGwgd29ya2luZw0K
dmVyc2lvbiBvZjwvZm9udD48L2ZvbnQ+DQo8YnI+PGZvbnQgY29sb3I9IiM2NjY2NjYiPjxm
b250IHNpemU9KzE+Q2hlY2tlciBTb2Z0d2FyZSBpbmNsdWRlZCE8L2ZvbnQ+PC9mb250Pg0K
PHA+PGltZyBTUkM9Imh0dHA6Ly9jb21wdXpvbmV1c2EuY29tL2ltYWdlcy9idXR0b24uZ2lm
IiBoZWlnaHQ9MTkgd2lkdGg9MTk+PGZvbnQgY29sb3I9IiM2NjY2NjYiPjxmb250IHNpemU9
KzE+DQpCdXNpbmVzcyBzb2Z0d2FyZSB0byBoZWxwIHlvdSBydW4geW91ciBzbWFsbDwvZm9u
dD48L2ZvbnQ+DQo8YnI+PGZvbnQgY29sb3I9IiM2NjY2NjYiPjxmb250IHNpemU9KzE+YnVz
aW5lc3MsIGluY2x1ZGluZyBsYWJlbCBtYWtlcg0Kc29mdHdhcmUsIG1vbmV5PC9mb250Pjwv
Zm9udD4NCjxicj48Zm9udCBjb2xvcj0iIzY2NjY2NiI+PGZvbnQgc2l6ZT0rMT5tYW5hZ2Vt
ZW50IHNvZnR3YXJlLCBJUlMgZm9yZ2l2ZW5lc3MNCnByb2dyYW0sPC9mb250PjwvZm9udD4N
Cjxicj48Zm9udCBjb2xvcj0iIzY2NjY2NiI+PGZvbnQgc2l6ZT0rMT5kYXRhYmFzZSBzb2Z0
d2FyZSwgYW5kIG11Y2ggbW9yZS48L2ZvbnQ+PC9mb250Pg0KPHA+PGltZyBTUkM9Imh0dHA6
Ly9jb21wdXpvbmV1c2EuY29tL2ltYWdlcy9idXR0b24uZ2lmIiBoZWlnaHQ9MTkgd2lkdGg9
MTk+PGZvbnQgY29sb3I9IiM2NjY2NjYiPjxmb250IHNpemU9KzE+DQpBIGh1Z2UgY29sbGVj
dGlvbiBvZiBzY3JlZW5zYXZlcnMsIGdyYXBoaWNzLDwvZm9udD48L2ZvbnQ+DQo8YnI+PGZv
bnQgY29sb3I9IiM2NjY2NjYiPjxmb250IHNpemU9KzE+Y2xpcGFydCwgYW5kIGRlc2t0b3Ag
dGhlbWVzIHRvDQpzcGljZSB1cCB5b3VyIGNvbXB1dGVyLjwvZm9udD48L2ZvbnQ+DQo8cD48
aW1nIFNSQz0iaHR0cDovL2NvbXB1em9uZXVzYS5jb20vaW1hZ2VzL2J1dHRvbi5naWYiIGhl
aWdodD0xOSB3aWR0aD0xOT48Zm9udCBjb2xvcj0iIzY2NjY2NiI+PGZvbnQgc2l6ZT0rMT4N
Ck1VQ0gsIE1VQ0ggTU9SRSB0aGF0IHdlIGRvbid0IGhhdmUgcm9vbSB0byBsaXN0ITwvZm9u
dD48L2ZvbnQ+DQo8cD48Zm9udCBzaXplPSsxPldlIGFyZSBzbyBjb25maWRlbnQgdGhhdCB5
b3Ugd2lsbCBsb3ZlIHRoaXMgQ0QgdGhhdCB3ZTwvZm9udD4NCjxicj48Zm9udCBzaXplPSsx
Pm9mZmVyIGEgZnVsbCAzMC1kYXksIG5vIHF1ZXN0aW9ucyBhc2tlZCBtb25leS1iYWNrPC9m
b250Pg0KPGJyPjxmb250IHNpemU9KzE+Z3VhcmFudGVlLiBUbyBvcmRlciB0aGUgIkJhbm5l
ZCBDRCIgcmlnaHQgbm93IGZvciB0aGU8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0rMT5zdXBl
ciBsb3cgcHJpY2Ugb2Ygb25seSAkMTkuOTksIGp1c3QgY2xpY2sgb24gdGhlIGxpbms8L2Zv
bnQ+DQo8YnI+PGZvbnQgc2l6ZT0rMT5iZWxvdyB0byBwYXkgd2l0aCBhIFZpc2Egb3IgTWFz
dGVyY2FyZDo8L2ZvbnQ+DQo8YnI+Jm5ic3A7DQo8dGFibGUgQk9SREVSPTAgQ09MUz0yIFdJ
RFRIPSI1MCUiID4NCjx0cj4NCjx0ZD48Zm9udCBzaXplPSsyPjxhIGhyZWY9Imh0dHA6Ly93
d3cuY29tcHV6b25ldXNhLmNvbS9jY3BheW1lbnQvYmFubmVkY2Q3Mi5odG0iPk9yZGVyDQpO
b3chPC9hPjwvZm9udD48L3RkPg0KDQo8dGQ+DQo8Y2VudGVyPjxpbWcgU1JDPSJodHRwOi8v
Y29tcHV6b25ldXNhLmNvbS9pbWFnZXMvZ3VhcmFudGVlLmdpZiIgaGVpZ2h0PTk2IHdpZHRo
PTk1PjwvY2VudGVyPg0KPC90ZD4NCjwvdHI+DQo8L3RhYmxlPg0KDQo8cD5PciB5b3UgbWF5
IHBheSB3aXRoIGNhc2gsIGNoZWNrIG9yIG1vbmV5IG9yZGVyIGJ5IHByaW50aW5nIHRoZSBv
cmRlcg0KPGJyPmZvcm0gYmVsb3cgYW5kIHNlbmRpbmcgaXQgd2l0aCB5b3VyIHBheW1lbnQu
DQo8cD48Yj4tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tIENVVCBIRVJFIC0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tPC9iPg0KPHA+UHJvZHVjdDogIlRoZSBCYW5uZWQgQ0QiDQo8YnI+UHJp
Y2U6ICQxOS45OSArICQ0LjAxIHNoaXBwaW5nL2hhbmRsaW5nDQo8cD5IT1cgVE8gT1JERVIg
QlkgTUFJTDogUHJpbnQgb3V0IHRoaXMgb3JkZXIgZm9ybSBhbmQgc2VuZCBjYXNoLA0KPGJy
PnBlcnNvbmFsIGNoZWNrLCBtb25leSBvcmRlciBvciBjYXNoaWVyJ3MgY2hlY2sgdG8gdGhl
IGFkZHJlc3MgbGlzdGVkDQpiZWxvdzoNCjxwPlF1aWtzaWx2ZXIgRW50ZXJwcmlzZXMgSW5j
Lg0KPGJyPjM3OTIgQnJvYWR3YXkgIzM5OA0KPGJyPk5ldyBZb3JrLCBOWSAxMDAzMg0KPHA+
WW91ciBTaGlwcGluZyBJbmZvcm1hdGlvbjoNCjxwPllvdXIgTmFtZV9fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPGJyPllvdXIgQWRkcmVzc19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPGJyPllvdXIgQ2l0eV9f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPGJyPlN0YXRl
IC8gWmlwX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPGJy
PlBob25lICM6IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
Xw0KPGJyPihGb3IgcHJvYmxlbXMgd2l0aCB5b3VyIG9yZGVyIG9ubHkuIE5vIHNhbGVzbWVu
IHdpbGwgY2FsbC4pDQo8cD5FbWFpbCBBZGRyZXNzX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fXw0KPHA+UGxlYXNlIG5vdGUgdGhhdCBtYWlsLWluIG9yZGVycyBt
YXkgYmUgZGVsYXllZCAyLTQgd2Vla3MuDQo8cD5bIF0gSSBhbSBlbmNsb3NpbmcgYSBjaGVj
ayBvciBtb25leSBvcmRlciBmb3IgJDI0LjAwDQo8cD5bIF0gSSBhbSBtYWlsaW5nIG15IGNy
ZWRpdCBjYXJkIG51bWJlci4gKE5vdGUgeW91ciBjYXJkIHdpbGwgYmUgY2hhcmdlZA0KZm9y
ICQyNC4wMCkNCjxwPklmIHBheWluZyBieSBjcmVkaXQgY2FyZCwgcGxlYXNlIGZpbGwgaW4g
dGhlIGluZm9ybWF0aW9uIGJlbG93Og0KPHA+Q3JlZGl0IENhcmQgTnVtYmVyOl9fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fDQo8YnI+RXhwaXJhdGlvbiBEYXRlOl9fX19fX19f
X19fX19fX19fX19fX19fX19fXw0KPGJyPlNpZ25hdHVyZTpfX19fX19fX19fX19fX19fX19f
X19fX19fDQo8YnI+RGF0ZTpfX19fX19fX19fX19fX19fX19fXw0KPHA+Tk9URTogVGhpcyBD
RCBpcyBmb3IgaW5mb3JtYXRpb25hbCwgZWR1Y2F0aW9uYWwsIG9yDQo8YnI+ZW50ZXJ0YWlu
bWVudCBwdXJwb3NlcyBvbmx5LiZuYnNwOyBTb21lIG9mIHRoZSBhY3Rpdml0aWVzDQo8YnI+
ZGVzY3JpYmVkIG9uIHRoaXMgQ0QgbWF5IGJlIGlsbGVnYWwgaWYgY2FycmllZCBvdXQuDQo8
YnI+VGhpcyBDRCBjb250YWlucyBsaW5rcyBhbmQgYWRkcmVzc2VzIG9mIGNvbXBhbmllcw0K
PGJyPmFuZCBpbmRpdmlkdWFscyB3aGljaCBwcm9kdWNlIHZhcmlvdXMgcHJvZHVjdHMsIG9y
DQo8YnI+b2ZmZXIgdmFyaW91cyBzZXJ2aWNlcywgd2hpY2ggbWF5IGJlIGlsbGVnYWwgaW4g
eW91cg0KPGJyPmNvdW50cnksIHN0YXRlLCBvciBjaXR5LiZuYnNwOyBIb3dldmVyLCBpdCBp
cyBwZXJmZWN0bHkNCjxicj5MRUdBTCB0byBwdXJjaGFzZSBhbmQgcG9zc2VzcyB0aGUgQmFu
bmVkIENEIGluIHRoZQ0KPGJyPlVuaXRlZCBTdGF0ZXMgb2YgQW1lcmljYS4mbmJzcDsgQ29u
dGFpbnMgYXBwcm94aW1hdGVseQ0KPGJyPjEwMCBtZWdzIG9mIGluZm9ybWF0aW9uLg0KPHA+
U2hpcHBpbmcgb3V0c2lkZSBVU0EgYWRkICQxMC4wMA0KPHA+KioqKioqKioqKioqKioqKioq
KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioNCjxicj5Zb3UgYXJl
IHJlY2lldmluZyBhbiB1bnNvbGljaXRlZCBjb21tZXJjaWFsIGVtYWlsIGZyb20NCjxicj5R
dWlrc2lsdmVyIEVudGVycHJpc2VzIEluYy4mbmJzcDsgV2UgcmVjb2duaXplIHRoYXQgeW91
IG1heQ0KPGJyPm5vdCB3aXNoIHRvIHJlY2lldmUgc3VjaCBlbWFpbHMgaW4gdGhlIGZ1dHVy
ZSwgYW5kIHdlDQo8YnI+aGF2ZSBwcm92aWRlZCBhIGxpbmsgdG8gYXV0b21hdGljYWxseSBh
bmQgaW5zdGFudGx5DQo8YnI+cmVtb3ZlIHlvdXJzZWxmOiA8YSBocmVmPSJodHRwOi8vd3d3
LmNvbXB1em9uZXVzYS5jb20vcmVtb3ZlLmh0bSI+UkVNT1ZFPC9hPg0KPGJyPlRoaXMgbWVz
c2FnZSBpcyBiZWluZyBzZW50IHRvIHlvdSBpbiBjb21wbGlhbmNlIHdpdGgNCjxicj5mZWRl
cmFsIGd1aWRlbGluZXMgZ292ZXJuaW5nIHRoZSB0cmFuc21pc3Npb24gb2YNCjxicj51bnNv
bGljaXRlZCBjb21tZXJjaWFsIGVtYWlsLCBpbmNsdWRpbmcgdGhlIHByb3Zpc2lvbiBvZg0K
PGJyPmNvbnRhY3QgaW5mb3JtYXRpb24gZm9yIG91ciBjb21wYW55IHdpdGhpbiB0aGlzIGVt
YWlsLCBhDQo8YnI+dmFsaWQgcmV0dXJuIGVtYWlsIGFkZHJlc3MsIGFuZCBhIHdheSBmb3Ig
Y3VzdG9tZXJzDQo8YnI+dG8gcmVtb3ZlIHRoZW1zZWx2ZXMuJm5ic3A7IFBsZWFzZSBub3Rl
LCBob3dldmVyLCB0aGF0IG91cg0KPGJyPmVtYWlsIGFkZHJlc3Mgd2FzIHZhbGlkIGF0IHRo
ZSB0aW1lIG9mIHNlbmRpbmcsIGJ1dCBtYXkNCjxicj5iZSBjYW5jZWxsZWQgYnkgdGhlIElT
UCBzaG9ydGx5IHRoZXJlYWZ0ZXIgZHVlIHRvIG91cg0KPGJyPnVzZSBvZiB1bnNvbGljaXRl
ZCBlbWFpbC4mbmJzcDsgWW91IGNhbiByZWFkIGFib3V0IHRoZSB2YXJpb3VzDQo8YnI+bGF3
cyBnb3Zlcm5pbmcgdW5zb2xpY2l0ZWQgZW1haWw6IGh0dHA6Ly9zcGFtbGF3cy5jb20NCjxi
cj4iVW5zb2xpY2l0ZWQgY29tbWVyY2lhbCBlbGVjdHJvbmljIG1haWwgY2FuIGJlIGFuIGlt
cG9ydGFudA0KPGJyPm1lY2hhbmlzbSB0aHJvdWdoIHdoaWNoIGJ1c2luZXNzZXMgYWR2ZXJ0
aXNlIGFuZCBhdHRyYWN0DQo8YnI+Y3VzdG9tZXJzIGluIHRoZSBvbmxpbmUgZW52aXJvbm1l
bnQuIiZuYnNwOyAtLSBVLlMuIENvbmdyZXNzLA0KPGJyPkguUi4gMTA2dGggQ09OR1JFU1Mg
MmQgU2Vzc2lvbiBILiBSLiAzMTEzIFNlYy4gMiAoYSkzIEp1bHkNCjxicj4xOSwgMjAwMCBo
dHRwOi8vd3d3LnNwYW1sYXdzLmNvbS9mZWRlcmFsL2hyMzExMy5odG1sDQo8YnI+KioqKioq
KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioN
Cjxicj4mbmJzcDsNCjxicj4mbmJzcDsNCjwvYm9keT4NCjwvaHRtbD4NCg==

------=_NextPart_000_001__10618077_51917.11--

Received: from blueorbit.cranitesystems.com (IDENT:[email-masked] [64.163.143.195]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA16916 for ; Mon, 29 Jan 2001 11:19:30 -0800 (PST)
Received: from dnai.com (192_168_2_128 [192.168.2.128]) (authenticated) by blueorbit-eth1.cranitesystems.com (8.10.2/8.10.2) with ESMTP id f0TJOno11301; Mon, 29 Jan 2001 11:24:49 -0800
Message-ID: <[email-masked]>
Date: Mon, 29 Jan 2001 11:25:43 -0800
From: Michael Sierchio
X-Mailer: Mozilla 4.76 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Bob Jueneman
CC: [email-masked], [email-masked]
Subject: Re: (DVD to DVP ga fajii shisutemu desu ka?)
References:
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Bob Jueneman wrote:
>
> Back in 1989, I wrote a paper entitled "Integrity Controls for
> Military and Commercial Applications". as a contribution to an
> Invitational Workshop on Data Integrity held at NIST.

Arrived Saturday, thanks. More later...

Michael

Received: from front002.cluster1.charter.net (outbound.charter.net [24.216.159.200]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA26325 for ; Sat, 27 Jan 2001 09:34:22 -0800 (PST)
Received: from [24.240.162.93] (HELO abenaki) by front002.cluster1.charter.net (CommuniGate Pro SMTP 3.4b8) with SMTP id 38564026 for [email-masked]; Sat, 27 Jan 2001 12:39:39 -0500
From: "Ray Beauregard"
To: "Ietf-Pkix"
Subject: OCSP performance metrics
Date: Sat, 27 Jan 2001 12:38:21 -0500
Message-ID:
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
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400

To all,

I am trying to help out a client who has an OCSP responder to frame some
"real world" performance metrics for testing. I have scoured the net looking
for any information on this and have been unsuccessful so far. I am hoping
the folks on this mail list might be able to point me in a beneficial
direction.
Specifically, I would like to find out what are reasonable test numbers for
some of the following:
OCSP request response time (i.e., what is an acceptable response time? 1
second? 3 seconds? .5 seconds?
OCSP concurrent threads (i.e., how many concurrent OCSP requests should the
responder be able to service in an acceptable time?)
Directory publishing and size (i.e., how much and how often will companies
publish certs to the directory? Will it be more "typical" that companies
will do a large bulk publish at inception, then just publish intermittently
thereafter? Or, are there implementations that would publish large numbers
of certs (and CRLs, etc.) on a continuous basis?
I sincerely hope that I have sent this to the appropriate mail list, and I
thank anyone in advance for helping out.

Ray Beauregard
Boss Rhino Systems, Inc.
39 Old Grafton Road
Upton, MA 01568

email: [email-masked]
phone: 508.529.6169
cell: 508.259.1810
http://webpages.charter.net/rayb

Received: from ext-mail.valicert.com (ns1.valicert.com [63.65.221.10]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id SAA26906 for ; Fri, 26 Jan 2001 18:19:46 -0800 (PST)
Received: from CONVERSION-DAEMON by ext-mail.valicert.com (PMDF V5.2-33 #46613) id <[email-masked]> for [email-masked]; Fri, 26 Jan 2001 18:26:06 -0800 (PST)
Received: from polaris.valicert.com ([192.168.2.34]) by ext-mail.valicert.com (PMDF V5.2-33 #46613) with ESMTP id <[email-masked]>; Fri, 26 Jan 2001 18:26:06 -0800 (PST)
Received: by exchange.valicert.com with Internet Mail Service (5.5.2650.21) id ; Fri, 26 Jan 2001 18:21:30 -0800
Content-return: allowed
Date: Fri, 26 Jan 2001 18:21:29 -0800
From: Peter Williams
Subject: RE: DPD & DPV requirements - to nonce or not to nonce?
To: "'Stephen Kent'"
Cc: [email-masked]
Message-id: <[email-masked]>
MIME-version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-type: text/plain; charset="iso-8859-1"

Steve

Thank you for your instruction notes on style and your
designation of terseness as inappropriate. Forgive the length
of the note that follows: it is not terse.

Carlin addressed some valuable issues at the outset of
this thread. They concerned the handling of nonces
in the circumstance that one protocol is dependent
upon completion of another - as between the DPV server and
supporting OCSP servers. One should refer to the thread's
first memo, as appropriate.

The PKI vendor community has worked with two PKI-using protocols that
share this dependency characteristic. OCSP is used, in practice,
mostly in chained mode where one server relies upon another to
satisfy a client request. The Directory's bound DAP queries, used
in products like Baltimore UniCert, can similarly be chained
over DSP.

(A) OCSP

The OCSP work does not say how nonces (used as part of mutual
authentication procedures to prove the intended request
recipient is the respondent) should be handled (see 2560/3.2)
during

(1) chaining (2560/4.4.6), and
(2) when a downstream server's OCSP response is forwarded
to a client, either unchanged or resigned, via the final,
upstream OCSP responder.

(B) X.509

The 1986 directory work was more diligent than IETF's OCSP, as its
signed operations use X.509 procedures for strong authentication. (I
could not take part in IETF work during OCSP design, due to an
intervention by a US govt employee.) The X.509 procedures were
designed for the case that RPC requests and responses requiring
strong authentication would be operating in a chained, multi-protocol,
distributed, server-server environment.

The requirement comments that Carlin outlined cites cases where
a DPV server signs a response only after having completed a
request/response dialogue with an OCSP server. Upon reading this,
I recalled that a conforming OCSP server may be potentially operating
in chained mode, in which the OCSP request (or response) signature
verification may start a further round of DPV interaction, which may
require another round of OCSP interaction, which... In summary, this
requires that one designs for looping, and one addresses the associated
requirements to assure a security-critical level of availability.

Then, I generalized for a moment. Where had I seen security experts apply
their talents to such an operational environment - one in which security
servers themselves issue requests to get critical knowledge in order
to respond, and those knowledge requests may need recursively securing?
The answer was the Directory, when using X.509 to satisfy
its security model (See X.501, 10). Furthermore, I half remembered
replay issues were discussed in the security considerations
of http://www.ietf.org/rfc/rfc2560.txt. So, I did some requirements
homework.

When I considered contributing a memo to the requirements
discussion (with tremor in my terrorised typing fingers in case I
be the next Juan to be blackballed or fall foul of a co-chair's
"appropriate conduct" edict) I read the material that Carlin had responded
to, again. Nothing in those excerpts suggested that the persons who
originated the requirements were contemplating the need to address security

requirements in a distributed, server-server, operations environment.

Given my access to considerable practical experience in deploying
and/or enhancing chained-OCSP and chained-directories, and having seen
what careful architects had done to either augment the OCSP facilities or
fully implement the X.509 specification, I began to engage Carlin in
developing these requirement by introducing the issues of information
element vs PDU timeliness,. I also gave an example of distributed
operations. As is the custom, I copied the mail to the list, for all to
see, enjoy, and consider - as they think and learn on the issues
as a community.

For my part, I can only write this note, clearly, now that I have had the
benefit of the very dialogue and inputs which flush out the issues.
Whilst no well-reasoned conclusion is evident, at least the requirement
issues are well framed.

My final substantive point notes that TSP contributors have
previously thought about server-side nonce-handling. The WG
seemingly and evidently knowingly punted the matter, despite known
vulnerabilities and use-case issues. I continue to be awe of the
simplicity of the expression and the foresight of those who
designed X.509's reusable, PKI-based, strong authentication
procedures, back in 1986.

If you need any additional context, please identify the topics. I will
respond in full.

Peter.

-----Original Message-----
From: Stephen Kent [mailto:[email-masked]]
Sent: Wednesday, January 24, 2001 6:29 PM
To: Peter Williams
Cc: [email-masked]
Subject: RE: DPD & DPV requirements - to nonce or not to nonce?

Received: from karon.dynas.se (karon.dynas.se [192.71.43.4]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id XAA06830 for ; Thu, 25 Jan 2001 23:59:50 -0800 (PST)
Received: (qmail 80478 invoked from network); 26 Jan 2001 08:05:50 -0000
Received: from spirit.sto.dynas.se (HELO spirit.dynas.se) (172.16.1.10) by karon.sto.dynas.se with SMTP; 26 Jan 2001 08:05:50 -0000
Received: (qmail 1778 invoked from network); 26 Jan 2001 08:05:50 -0000
Received: from mnystrom-lap.d.dynas.se (HELO mnystrom-lap) (172.16.13.246) by spirit.dynas.se with SMTP; 26 Jan 2001 08:05:50 -0000
Date: Fri, 26 Jan 2001 09:06:28 +0100 (W. Europe Standard Time)
From: Magnus Nystrom
Reply-To:
To: Amit Kapoor
cc: , , "Richards, Gareth"
Subject: Re: WG Last Call, RFC 2510bis
In-Reply-To: <[email-masked]>
Message-ID:
X-X-Sender: [email-masked]
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

On Thu, 25 Jan 2001, Amit Kapoor wrote:

> Magnus Nystrom on 01/25/2001 03:32:21 PM
[...]
> Carlisle,
>
> Thanks for your response. Some follow-up remarks below.
>
> On Fri, 19 Jan 2001, Carlisle Adams wrote:
>
> > Hi Magnus,
> >
> > Very sorry for the frustratingly long delay in responding, but a
> [...]
>
> No problem.
>
> > > From: Magnus Nystrom[SMTP:[email-masked]]
> > > Sent: Friday, December 22, 2000 9:01 AM
> > > To: [email-masked]
> > > Subject: Re: WG Last Call, RFC 2510bis
> > >
> > > Dear CMP and CRMF editors,
> > >
> > > In response to the last-call on rfc2510bis and rfc2511bis, we do have a
> > > couple of related questions. While answers to these may exist in the
> > > documents we have not been able to find them.
> > >
> > > a) What is a CMP client which receives a PKIMessage response with a
> > > PKIStatus of "waiting" supposed to do? A procedure for CMP using TCP
> > > as transport seems to be to use the pollRep/pollReq pair, but it
> > > seems as if polling should be part of CMP rather than dependent on
> > > its transport?
>
> > A long discussion/debate occurred some time ago on the ca-talk list
> > regarding whether or not polling belonged in CMP or in the transport
> > layer. There certainly was not consensus, but "rough consensus"
> > (very rough!) seemed to lean toward the transport layer.
> > Therefore, the transport layer needs to deal with this in some way
> > (e.g., a polling mechanism for TCP; perhaps nothing for e-mail --
> > the client simply waits for an e-mail that contains more of the
> > response). In any case, nailing this down for the various
> > transports is something that could/should be done in the transport
> > draft.
>
> If this is the case, then I suggest this to be documented in
> rfc2510bis itself (the decision to defer polling to the transport
> layer). But even if it is implemented in the transport layer there is
> still the waiting status in CMP. What is supposed to happen if the CA
> returns this?
>
> Assume that the CMP enrollment is taking place in a browser script and
> the browser may be terminated before the polling is complete. Then a
> way of saving state and continuing the polling at a later date is
> needed. If the polling is done in CMP then this is possible by
> reissuing the request or whatever but if it is done by the transport
> layer then it does not seem clear how this is going to be done.
>
> AK> As Carlisle said we have had a long discussion/argument on this in the
> ca-talk. For exactly the same reasons
> AK> outlined by you, Ronald and I wanted two new messages (pollRequest and
> pollResponse) added at the CMP
> AK> level to allow for polling. This also addressed a concern raised by Peter
> Biltzinger (TrustCenter) that there was
> AK> no security at the transport level.

Hm. Perhaps there is some support for this modification to CMP then? I
must say it appears cleaner, if the protocoll already includes a
"Wait-Come back later" status message, to also include a "I'm back,
what's the status" request.

-- Magnus

Received: from mail.ca.certicom.com ([209.121.99.6]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA21188 for ; Thu, 25 Jan 2001 11:22:49 -0800 (PST)
Received: from smtpmail.certicom.com (domino2.certicom.com [10.0.1.25]) by mail.ca.certicom.com (8.9.3/8.9.3) with SMTP id OAA16996; Thu, 25 Jan 2001 14:22:56 -0500 (EST)
Received: by smtpmail.certicom.com(Lotus SMTP MTA v4.6.4 (830.2 3-23-1999)) id 852569DF.006A799E ; Thu, 25 Jan 2001 14:22:59 -0500
X-Lotus-FromDomain: CERTICOM
From: "Amit Kapoor"
To: [email-masked]
cc: [email-masked], [email-masked], "Richards, Gareth"
Message-ID: <[email-masked]>
Date: Thu, 25 Jan 2001 11:25:07 -0800
Subject: Re: WG Last Call, RFC 2510bis
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline

Magnus Nystrom on 01/25/2001 03:32:21 PM

Please respond to [email-masked]

To: [email-masked]
cc: [email-masked], "Richards, Gareth" (bcc:
Amit Kapoor/Certicom)

Subject: Re: WG Last Call, RFC 2510bis

Carlisle,

Thanks for your response. Some follow-up remarks below.

On Fri, 19 Jan 2001, Carlisle Adams wrote:

> Hi Magnus,
>
> Very sorry for the frustratingly long delay in responding, but a
[...]

No problem.

> > From: Magnus Nystrom[SMTP:[email-masked]]
> > Sent: Friday, December 22, 2000 9:01 AM
> > To: [email-masked]
> > Subject: Re: WG Last Call, RFC 2510bis
> >
> > Dear CMP and CRMF editors,
> >
> > In response to the last-call on rfc2510bis and rfc2511bis, we do have a
> > couple of related questions. While answers to these may exist in the
> > documents we have not been able to find them.
> >
> > a) What is a CMP client which receives a PKIMessage response with a
> > PKIStatus of "waiting" supposed to do? A procedure for CMP using TCP
> > as transport seems to be to use the pollRep/pollReq pair, but it
> > seems as if polling should be part of CMP rather than dependent on
> > its transport?

> A long discussion/debate occurred some time ago on the ca-talk list
> regarding whether or not polling belonged in CMP or in the transport
> layer. There certainly was not consensus, but "rough consensus"
> (very rough!) seemed to lean toward the transport layer.
> Therefore, the transport layer needs to deal with this in some way
> (e.g., a polling mechanism for TCP; perhaps nothing for e-mail --
> the client simply waits for an e-mail that contains more of the
> response). In any case, nailing this down for the various
> transports is something that could/should be done in the transport
> draft.

If this is the case, then I suggest this to be documented in
rfc2510bis itself (the decision to defer polling to the transport
layer). But even if it is implemented in the transport layer there is
still the waiting status in CMP. What is supposed to happen if the CA
returns this?

Assume that the CMP enrollment is taking place in a browser script and
the browser may be terminated before the polling is complete. Then a
way of saving state and continuing the polling at a later date is
needed. If the polling is done in CMP then this is possible by
reissuing the request or whatever but if it is done by the transport
layer then it does not seem clear how this is going to be done.

AK> As Carlisle said we have had a long discussion/argument on this in the
ca-talk. For exactly the same reasons
AK> outlined by you, Ronald and I wanted two new messages (pollRequest and
pollResponse) added at the CMP
AK> level to allow for polling. This also addressed a concern raised by Peter
Biltzinger (TrustCenter) that there was
AK> no security at the transport level.

Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA15980 for ; Thu, 25 Jan 2001 10:00:36 -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 TAA39886; Thu, 25 Jan 2001 19:14:05 +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 TAA21740; Thu, 25 Jan 2001 19:06:19 +0100
Message-ID: <[email-masked]>
Date: Thu, 25 Jan 2001 19:06:23 +0100
From: Denis Pinkas
Organization: Bull
X-Mailer: Mozilla 4.7 [fr] (Win98; I)
X-Accept-Language: fr
MIME-Version: 1.0
To: Stephen Kent
CC: [email-masked]
Subject: Re: DVD & DVP requirements
References: <[email-masked]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Steve,

> My spec requires that the server be able to be configured with these
> policies. That will ensure that we have a definition of a minimum
> parameter set well defined for all servers.

There are two approaches to define a policy, either by passing all the
parameters in the request using ASN.1 or by referencing a policy which has
been defined using e.g. English text. It is much faster to say in English :
the leaf certificate must have either this field present or that other field
present with the value X or Y, rather than saying the same thing using
ASN.1.

> If we allow for external references, then we have to define a reference format

For external references we do not NEED to define such a reference format,
plain English is sufficient, unless you prefer plain French. :-)

> (do you already have one in mind?), select a protocol and format for transport of the parameters, etc.

I do have in mind such a format which has been defined ASN.1. It could be
used for describing the format as a parameter.

You could derive it from a subset of the Electronic Signature Policies

Here is a copy of sections which could be useful to define some (not all !)
conditions:

3.6 Certificate and Revocation Requirement

The SigningCertTrustCondition, TimestampTrustCondition and
AttributeTrustCondition (defined in subsequent sub-clauses) make use of
two ASN1 structures which are defined below: CertificateTrustTrees and
CertRevReq.

3.6.1 Certificate Requirements

The certificateTrustTrees identifies a set of self signed certificates
for the trust points used to start (or end) certificate path processing
and the initial conditions for certificate path validation as defined
RFC 2459 [7] section 4. This ASN1 structure is used to define policy
for validating the signing certificate, the TSA's certificate and
attribute certificates.

CertificateTrustTrees ::= SEQUENCE OF CertificateTrustPoint

CertificateTrustPoint ::= SEQUENCE {
trustpoint Certificate,
-- self-signed certificate
pathLenConstraint [0] PathLenConstraint OPTIONAL,
acceptablePolicySet [1] AcceptablePolicySet OPTIONAL,
-- If not present "any policy"
nameConstraints [2] NameConstraints OPTIONAL,
policyConstraints [3] PolicyConstraints OPTIONAL }

The trustPoint field gives the self signed certificate for the CA that
is used as the trust point for the start of certificate path
processing.

The pathLenConstraint field gives the maximum number of CA certificates
that may be in a certification path following the trustpoint. A value
of zero indicates that only the given trustpoint certificate and an
end-entity certificate may be used. If present, the pathLenConstraint
field must be greater than or equal to zero. Where pathLenConstraint
is not present, there is no limit to the allowed length of the
certification path.

PathLenConstraint ::= INTEGER (0..MAX)

The acceptablePolicySet field identifies the initial set of certificate
policies, any of which are acceptable under the signature policy.
AcceptablePolicySet ::= SEQUENCE OF CertPolicyId

CertPolicyId ::= OBJECT IDENTIFIER

The nameConstraints field indicates a name space within which all
subject names in subsequent certificates in a certification path must
be located. Restrictions may apply to the subject distinguished name or
subject alternative names. Restrictions apply only when the specified
name form is present. If no name of the type is in the certificate, the
certificate is acceptable.

Restrictions are defined in terms of permitted or excluded name
subtrees. Any name matching a restriction in the excludedSubtrees field
is invalid regardless of information appearing in the ermittedSubtrees.

NameConstraints ::= SEQUENCE {
permittedSubtrees [0] GeneralSubtrees OPTIONAL,
excludedSubtrees [1] GeneralSubtrees OPTIONAL }

GeneralSubtrees ::= SEQUENCE SIZE (1..MAX) OF GeneralSubtree

GeneralSubtree ::= SEQUENCE {
base GeneralName,
minimum [0] BaseDistance DEFAULT 0,
maximum [1] BaseDistance OPTIONAL }

BaseDistance ::= INTEGER (0..MAX)

The policyConstraints extension constrains path processing in two ways.
It can be used to prohibit policy mapping or require that each
certificate in a path contain an acceptable policy identifier.

The policyConstraints field, if present specifies requirement for
explicit indication of the certificate policy and/or the constraints on
policy mapping.

PolicyConstraints ::= SEQUENCE {
requireExplicitPolicy [0] SkipCerts OPTIONAL,
inhibitPolicyMapping [1] SkipCerts OPTIONAL }

SkipCerts ::= INTEGER (0..MAX)

If the inhibitPolicyMapping field is present, the value indicates the
number of additional certificates that may appear in the path
(including the trustpoint's self certificate) before policy mapping is
no longer permitted. For example, a value of one indicates that policy
mapping may be processed in certificates issued by the subject of this
certificate, but not in additional certificates in the path.

If the requireExplicitPolicy field is present, subsequent certificates
must include an acceptable policy identifier. The value of
requireExplicitPolicy indicates the number of additional certificates
that may appear in the path (including the trustpoint's self
certificate) before an explicit policy is required. An acceptable
policy identifier is the identifier of a policy required by the user of
the certification path or the identifier of a policy which has been
declared equivalent through policy mapping.

3.6.2 Revocation Requirements

The RevocRequirements field specifies minimum requirements for
revocation information, obtained through CRLs and/or OCSP responses, to
be used in checking the revocation status of certificates. This ASN1
structure is used to define policy for validating the signing
certificate, the TSA's certificate and attribute certificates.

CertRevReq ::= SEQUENCE {
endCertRevReq RevReq,
caCerts [0] RevReq
}

Certificate revocation requirements are specified in terms of checks
required on:
* endCertRevReq: end certificates (i.e. the signers certificate,
the attribute certificate or the timestamping authority
certificate).

* caCerts: CA certificates.

RevReq ::= SEQUENCE {
enuRevReq EnuRevReq,
exRevReq SignPolExtensions OPTIONAL}

An authority certificate is certificate issued to an authority (e.g.
either to a certification authority or to an attribute authority (AA)).

A TimeStamping Authority (TSA) is a trusted third party that creates
time stamp tokens in order to indicate that a datum existed at a
particular point in time. See [TSP]

EnuRevReq ::= ENUMERATED {
clrCheck (0),
--Checks must be made against current CRLs
-- (or authority revocation lists (ARL))
ocspCheck (1), -- The revocation status must be checked
-- using the Online Certificate Status Protocol
-- (OCSP),RFC 2450.
bothCheck (2),
-- Both CRL and OCSP checks must be carried out
eitherCheck (3),
-- At least one of CRL or OCSP checks must be
-- carried out
noCheck (4),
-- no check is mandated
other (5)
-- Other mechanism as defined by signature policy
-- extension
}

Revocation requirements are specified in terms of:
* clrCheck: Checks must be made against current CRLs (or
authority revocation lists);
* ocspCheck: The revocation status must be checked using the
Online Certificate Status Protocol (RFC 2450);
* bothCheck: Both OCSP and CRL checks must be carried out;
* eitherCheck: Either OCSP or CRL checks must be carried out;
* noCheck: No check is mandated.

> So, while it may be OK to have external references,

Fine. On that point we both agree.

> I really want to keep the local config requirement as a base, and

I am confused with the term that you use :"local configuration requirement".
If the parameters, passed at the time of the request, define the validation
policy then there is no such local configuration.

Do you have in mind a protocol where you could define with one call the
validation policy and then in another call ask for the validation using a
refrence to that policy ? If so, I agree.

In that case, I would understand what a local configuration is, and then
both calls would look the same.

The case where the validation policy is referenced would have one call,
while the case where the validation policy is locally defined would have two
calls.

> I think the addition of external references adds complexity.

Validation policies passed as a parameter add complexity.

> > > but only to the extent that the policies make use of standard
> > > cert attribute validation parameters.
> >
> >Validation policies may include more controls than specified in RFC 2459bis.
> >If these validation policies are defined using external references, then it
> >is easy to point to them and thus avoids to describe them at the interface
> >level.
>
> Yes, and that leads to potential ambiguities and potentially
> undefined server operation.

Not exactly. See above.

> > > To do what you propose would
> > > require adding support for private extensions at the server and
> > > perhaps in client requests. This could be done if the WG wants, but
> > > it would be a supplement to the mandatory, 2459bis validation
> > > criteria.
> >
> >Describing parameters additional to the traditional validation algorithm
> >described in RFC2459, is indeed not that easy. For simplicity, these
> >addtional parameters should be limited to indicate conditions on the leaf
> >certificates.
>
> I'm not comfortable with pushing the problem under the rug in this
> fashion. We all love the power of indirection, but the reason I
> called for server config of parameters was to ensure that we had a
> well-defined list and that a compliant server implementation could be
> managed based on that list, without reference to some vendor-specific
> mechanisms.

There is nothing such as "endor-specific mechanisms", but more "specific
validation policies".

> >As a summary:
> >
> >1) Using validation policy references allows a simple interface and hides
> >the details (and complexity) of the validation policy.
>
> Are you suggesting that we not have a facility for the client to pass
> in validation parameters, but only have references to policies, or
> are you proposing external references in addition to explicit
> parameters in the request? I'm not sure I want to hide details of the
> policy. I think references to a policy are attractive as a means of
> centralizing management.
>
> >2) Using an explicit validation policy by describing all the parameters at
> >the interface level is more complex and in any case will have some
> >limitations when compared to referenced validation policies. I agree with
> >Steve, that it would be a supplement to the mandatory 2459bis validation
> >criteria.
>
> Not sure I know how to parse this last sentence, although I think I
> sense an overall disparagement of support for explicit parameters,
> which I still think is necessary.

Explicit validation policies passed as a parameter are more complex. Now
this is not a reason of not supporting them.

So I am advocating the support of both cases:

a) explicit validation policies AND
b) referenced validation policies,

Denis

> Steve

Received: from correo.e-netfinger.com ([193.127.39.200]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA10465 for ; Thu, 25 Jan 2001 08:53:23 -0800 (PST)
Received: from e-netfinger.com ([193.127.39.195]) by correo.e-netfinger.com (Netscape Messaging Server 4.15) with ESMTP id G7Q9WX00.DRX for ; Thu, 25 Jan 2001 18:00:33 +0100
Message-ID: <[email-masked]>
Date: Thu, 25 Jan 2001 17:59:04 +0000
From: "Jose Manuel Molina"
Organization: e-netfinger
X-Mailer: Mozilla 4.7 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
To: "[email-masked] '"
Subject: OCSP
Content-Type: multipart/mixed; boundary="------------C6FAB8AB1D0C8CFC75C71C34"

This is a multi-part message in MIME format.
--------------C6FAB8AB1D0C8CFC75C71C34
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Hello.

What is DER code of id-pkix-ocsp?
In PSM 1.4 of Netscape is 0x2B, 0x06, 0x01, 0x05, 0x05, 0x07, 0x30,
0x01, 0x01.

--------------C6FAB8AB1D0C8CFC75C71C34
Content-Type: text/x-vcard; charset=us-ascii;
name="jmolina.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for José Manuel Molina Gómez
Content-Disposition: attachment;
filename="jmolina.vcf"

begin:vcard
n:Molina Gómez;José Manuel
tel;work:+34 91 634 75 29
x-mozilla-html:FALSE
org:;e-Technology
adr:;;;;;;
version:2.1
email;internet:[email-masked]
end:vcard

--------------C6FAB8AB1D0C8CFC75C71C34--

Received: from karon.dynas.se (karon.dynas.se [192.71.43.4]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id GAA29930 for ; Thu, 25 Jan 2001 06:25:27 -0800 (PST)
Received: (qmail 70076 invoked from network); 25 Jan 2001 14:31:43 -0000
Received: from spirit.sto.dynas.se (HELO spirit.dynas.se) (172.16.1.10) by karon.sto.dynas.se with SMTP; 25 Jan 2001 14:31:43 -0000
Received: (qmail 13539 invoked from network); 25 Jan 2001 14:31:43 -0000
Received: from mnystrom-lap.d.dynas.se (HELO mnystrom-lap) (172.16.13.246) by spirit.dynas.se with SMTP; 25 Jan 2001 14:31:43 -0000
Date: Thu, 25 Jan 2001 15:32:21 -0800 (Pacific Standard Time)
From: Magnus Nystrom
Reply-To:
To:
cc: , "Richards, Gareth"
Subject: Re: WG Last Call, RFC 2510bis
Message-ID:
X-X-Sender: [email-masked]
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

Carlisle,

Thanks for your response. Some follow-up remarks below.

On Fri, 19 Jan 2001, Carlisle Adams wrote:

> Hi Magnus,
>
> Very sorry for the frustratingly long delay in responding, but a
[...]

No problem.

> > From: Magnus Nystrom[SMTP:[email-masked]]
> > Sent: Friday, December 22, 2000 9:01 AM
> > To: [email-masked]
> > Subject: Re: WG Last Call, RFC 2510bis
> >
> > Dear CMP and CRMF editors,
> >
> > In response to the last-call on rfc2510bis and rfc2511bis, we do have a
> > couple of related questions. While answers to these may exist in the
> > documents we have not been able to find them.
> >
> > a) What is a CMP client which receives a PKIMessage response with a
> > PKIStatus of "waiting" supposed to do? A procedure for CMP using TCP
> > as transport seems to be to use the pollRep/pollReq pair, but it
> > seems as if polling should be part of CMP rather than dependent on
> > its transport?

> A long discussion/debate occurred some time ago on the ca-talk list
> regarding whether or not polling belonged in CMP or in the transport
> layer. There certainly was not consensus, but "rough consensus"
> (very rough!) seemed to lean toward the transport layer.
> Therefore, the transport layer needs to deal with this in some way
> (e.g., a polling mechanism for TCP; perhaps nothing for e-mail --
> the client simply waits for an e-mail that contains more of the
> response). In any case, nailing this down for the various
> transports is something that could/should be done in the transport
> draft.

If this is the case, then I suggest this to be documented in
rfc2510bis itself (the decision to defer polling to the transport
layer). But even if it is implemented in the transport layer there is
still the waiting status in CMP. What is supposed to happen if the CA
returns this?

Assume that the CMP enrollment is taking place in a browser script and
the browser may be terminated before the polling is complete. Then a
way of saving state and continuing the polling at a later date is
needed. If the polling is done in CMP then this is possible by
reissuing the request or whatever but if it is done by the transport
layer then it does not seem clear how this is going to be done.

> > b) In ir, cr and kur message types, the CertReqMessages SEQUENCE
> > has the following restrictions (see Appendix B4 and rfc2510bis-02):
[...]

> Having said that, however, I will note that you are not the first
> person to ask about this, and that this request seems perfectly
> reasonable. Therefore, I will modify CertReq and KeyUpdateReq to
> remove restrictions 2 and 3 above (the restrictions will still apply
> to InitReq).

Thanks for this.

> > c) Related to b), when a CMP client chooses not to include a
> > public key in a certTemplate, how shall it inform the RA/CA of the
> > particular algorithm it wishes the CA to generate a key for? And
> > parameters - e.g. "Please generate a 1024 bit RSA key with F4 as
> > public exponent".

> In general, this could happen with a separate genMsg/genRep exchange
> (e.g., keyPairParamReq / keyPairParamRep, or perhaps a new pair as
> yet undefined). Alternatively, a control could be defined to carry
> this information. But there is no syntax available to do this
> within CertTemplate today. (Note that RSA presents a bit of a
> difficulty because "parameters" have not been defined for this
> AlgId, otherwise the keyPairParamReq/Rep could conceivably be used
> for this algorithm.)

Ok. Presumably, it would be an advantage to include this in the cr or
ir message, which means that the PKIHeader.generalInfo alternative
would be suitable, since there doesn't seem to be much point in having a
genMsg/genRep exchange to establish the parameters. Seems more logical
to place the InfoTypeAndValue in the generalInfo.

Note however, that the meaning of 3.3.19.8 may change slightly now -
what we want to do is to send the AlgorithmIdentifer to the CA so the
EE would have to send a keyPairParamRep. This is a bit odd.

-- Magnus

Received: from edelweb.fr (edelweb.fr [212.234.46.16]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id EAA22155 for ; Thu, 25 Jan 2001 04:20:51 -0800 (PST)
Received: from champagne.edelweb.fr (localhost.edelweb.fr [127.0.0.1]) by edelweb.fr with ESMTP id NAA26949; Thu, 25 Jan 2001 13:27:07 +0100 (MET)
Received: from champagne.edelweb.fr (champagne.edelweb.fr [193.51.14.161]) by edelweb.fr (nospam/1.3); Thu, 25 Jan 2001 13:27:07 +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 NAA24690; Thu, 25 Jan 2001 13:27:06 +0100 (MET)
From: Peter Sylvester
Received: (sylvest@localhost) by emeriau.edelweb.fr (8.7.6/8.6.6) id NAA23185; Thu, 25 Jan 2001 13:27:06 +0100 (MET)
Date: Thu, 25 Jan 2001 13:27:06 +0100 (MET)
Message-Id: <[email-masked]>
To: [email-masked], [email-masked]
Subject: Re: Query about nonce field in Time-stamp response.

>
> > Time-Stamp Protocol Response contains Nonce field as a part of signed
> > TimeStamptoken. It will be stored as a part of timestamp token. But
> > the nonce will be checkedat the time of receiption of Time-Stamp token
> > against the client generated nonce.What will be the use of Nonce field
> > stored in the Time-stamp token when in the futurethe that token will
> > be used.Should nonce be a part of TSTInfo in time-stamp token and
> > stored as part of Time-stamp token ?

>
> Replay detection is one thing, but there can be other uses of the nonce
> field.
That usage seems to be the intended one in this protocol.
As far as I remember there is no intended 'future' usage of a nonce
in a time stamp.

> If you think of it, the nonce is an arbitrary choosen user identifier
> for the token ...
You can think about it but this sounds almost against the spirit of
the protocol. Imagine some 'client' saying:

The Nonce is the DER encoding of a structure that contains
the URL of the hashed document, plus a generalname of the entity
who requested it, and whatever else, maybe even the whole document,
etc.

It think there is a good reason for saying 'invalidSenderNonce',
for example not accepting more than n octets, but that can be
covered by a more general error message today.

PS

Received: from edelweb.fr (edelweb.fr [212.234.46.16]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id DAA15801 for ; Thu, 25 Jan 2001 03:12:45 -0800 (PST)
Received: from champagne.edelweb.fr (localhost.edelweb.fr [127.0.0.1]) by edelweb.fr with ESMTP id MAA26683; Thu, 25 Jan 2001 12:18:57 +0100 (MET)
Received: from champagne.edelweb.fr (champagne.edelweb.fr [193.51.14.161]) by edelweb.fr (nospam/1.3); Thu, 25 Jan 2001 12:18:58 +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 MAA24498; Thu, 25 Jan 2001 12:18:53 +0100 (MET)
From: Peter Sylvester
Received: (sylvest@localhost) by emeriau.edelweb.fr (8.7.6/8.6.6) id MAA23172; Thu, 25 Jan 2001 12:18:51 +0100 (MET)
Date: Thu, 25 Jan 2001 12:18:51 +0100 (MET)
Message-Id: <[email-masked]>
To: [email-masked], [email-masked]
Subject: RE: DID & DIP requirements
Cc: [email-masked]

Steve,

since I seem to be in almost violant agreement, this answer can be short.

> Peter,

...

> My starting point are the 2459 bis path validation controls, but if
> we reach consensus on others, we can add them in as well.
There is one proposal on the table, and it was questioned by
asking why or whether this cannot be made by existing means.

This question should always be asked, it means that we give
additional input, and this might be well be suited to modify
the path validation algorithm, thus should be integrated into it.

...
>
> I agree, which is why I am reluctant to put in mechanisms to support
> it at this time. if we can't explain how the procedure will work, and
> provide explicit controls, then we have a placeholder that does not
> permit interoperable implementation, the hallmark of a good IETF
> standard.
No problem.

Received: from certplus.com (facteur.certplus.com [195.101.88.81]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id DAA14370 for ; Thu, 25 Jan 2001 03:08:31 -0800 (PST)
Received: from certplus.com ([192.168.212.178]) by certplus.com (8.11.2/8.11.2) with ESMTP id f0PBG5k18061 for ; Thu, 25 Jan 2001 12:16:05 +0100
Message-ID: <[email-masked]>
Date: Thu, 25 Jan 2001 12:14:14 +0100
From: Jean-Marc Desperrier
Organization: Certplus
X-Mailer: Mozilla 4.75 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: [email-masked]
Subject: Re: Query about nonce field in Time-stamp response.
References: <005701c0868c$b9f330c0$966801c4@insight> <[email-masked]> <006e01c086b4$2bb129c0$966801c4@insight>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Prashant Dambe wrote:

> Is it required that Nonce should be included in TSTInfo i.e the part of
> TimeStampToken ?

Draft version 13 says :
TSTInfo ::= SEQUENCE {
....
nonce INTEGER OPTIONAL,
-- MUST be present if the similar field was present
-- in TimeStampReq. In that case it MUST have the same value.

So it's required, yes.

> Nonce can be a part of Time-stamp response like PKIStatusInfo which will be
> not included in Timestamptoken.

No such possibility is provided in the current form of the TimeStampResp.
Anyway, the nonce would have to be signed by the responder, so what you suggest
requires a second signature, so that the nonce can be removed without breaking
the TSTInfo signature.

If you don't want the nonce payload, the draft suggests to use both a local
clock and a moving time window during which the requester remembers all the
hashes sent during that time window.

Bernd Matthes wrote:
> I think it's a little auxiliary means against double timestamps.
> A TSA should reject a time stamp query if the same
> messageImprint *and* the same nonce found in it's database.
> It's possible to get multiple timestamps ("re-new") for the
> same document,message or whatever,
> but *never* with already issued nonce value.

My understanding until now is that's it's only up to the client to check the
nonce, and not to the server.

So howewer interesting your idea is, the standard does not forbid a client to
do what you describe, for whatever reason, and the systematic rejection could
cause interoperability problems.

If you did it, your clients would have to check their tools will never do that,
especially when resending the same request because the answer wasn't received.

Here's what Denis said recently which is quite related to this question :

>> And additional badSenderNonce(18)?
>This has not been added. I do not want to raise at this time questions like:
>what is a bad nonce ? or how does a server know it is a bad nonce ?

Received: from junker.ms.inka.de (pD9011808.dip.t-dialin.net [217.1.24.8]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id BAA06655 for ; Thu, 25 Jan 2001 01:37:47 -0800 (PST)
Received: from stroeder.com (localhost [127.0.0.1]) by junker.ms.inka.de (Postfix) with ESMTP id 3AAE468087 for ; Thu, 25 Jan 2001 10:42:24 +0100 (CET)
Sender: [email-masked]
Message-ID: <[email-masked]>
Date: Thu, 25 Jan 2001 10:42:24 +0100
From: Michael =?iso-8859-1?Q?Str=F6der?=
Organization: stroeder.com
X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.18 i686)
X-Accept-Language: de-DE, de, en
MIME-Version: 1.0
To: ietf-pkix
Subject: Re: Certificate Matching was:RE: Basic Cert-2-Directory mapping question
References: <[email-masked]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Steven Legg wrote:
>
> I hope you haven't confused the issues.

I hope that too. ;-)

> 1) Should surrogate search attributes or direct matching on certificates
> be used to search for certificates ?

I vote for direct matching on certificates. IMHO surrogate
attributes will cause too much trouble. And I consider the directory
server to be less trustworthy than the CA which issued the
certificates in almost any case.

> Surrogate search attributes generally require
> the clients to be PKI and ASN.1 aware. Direct matching of certificates
> doesn't.

That's why I voted for direct matching on certificates.

> > Another real-world example:
> > [..]
> > In this system the LDAP component itself is not
> > PKI-aware and the PKI-aware component is not capable of speaking
> > LDAP.
>
> When you say that the LDAP component is not PKI-aware I take it you mean
> that it doesn't understand the ASN.1 type of a certificate and supports
> no matching rules for directly matching a certificate.

Yes. (Maybe my english knowledge is sometimes too limited to be very
precise.)

> In such a case
> your hypothetical system administrator would have to use surrogate
> search attributes with all the attendant imprecision. Some sort
> of direct matching capability is required for the LDAP component to
> return only the right certificate.

I hoped that a directory server extension could implement the direct
certificate matching stuff and simply return the right certificate
to the LDAP client not aware of the ASN.1 type of a certificate.

Ciao, Michael.

Received: from brot.celocom.de (brot.celocom.de [212.78.104.200]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id BAA04852 for ; Thu, 25 Jan 2001 01:25:35 -0800 (PST)
Received: from frolic.celocom.de (frolic.celocom.de [212.78.104.90]) by brot.celocom.de (Postfix) with ESMTP id 836892FD2; Thu, 25 Jan 2001 10:31:50 +0100 (CET)
Received: from celocom.de (bernd.celocom.de [212.78.104.41]) by frolic.celocom.de (Postfix) with ESMTP id 3AC3E108003; Thu, 25 Jan 2001 10:31:50 +0100 (CET)
Message-ID: <[email-masked]>
Date: Thu, 25 Jan 2001 10:31:43 +0100
From: Bernd Matthes
Reply-To: [email-masked]
Organization: Celo Communications -- http://www.celocom.com
X-Mailer: Mozilla 4.75 [en] (WinNT; U)
X-Accept-Language: de,en
MIME-Version: 1.0
To: Jean-Marc Desperrier
Cc: [email-masked]
Subject: Re: Query about nonce field in Time-stamp response.
References: <005701c0868c$b9f330c0$966801c4@insight> <[email-masked]>
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms50345134AB70B889528F6381"

This is a cryptographically signed message in MIME format.

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

Jean-Marc Desperrier wrote:
>
> Prashant Dambe wrote:
>
> > Time-Stamp Protocol Response contains Nonce field as a part of signed
> > TimeStamptoken. It will be stored as a part of timestamp token. But
> > the nonce will be checkedat the time of receiption of Time-Stamp token
> > against the client generated nonce.What will be the use of Nonce field
> > stored in the Time-stamp token when in the futurethe that token will
> > be used.Should nonce be a part of TSTInfo in time-stamp token and
> > stored as part of Time-stamp token ?
>
> Replay detection is one thing, but there can be other uses of the nonce
> field.
>
> If you think of it, the nonce is an arbitrary choosen user identifier
> for the token ...
> So it's not so inconvenient if it's included in the payload of the
> TimeStamptoken.

Hi,

I think it's a little auxiliary means against double timestamps.
A TSA should reject a time stamp query if the same
messageImprint *and* the same nonce found in it's database.
It's possible to get multiple timestamps ("re-new") for the
same document,message or whatever,
but *never* with already issued nonce value.

with kind regards
--
Mors certa, hora incerta. In dubio pro mille.
--------------------------------------------------------------------
Bernd Matthes Celo Communications GmbH
Senior Software Engineer Weissenfelser Strasse 46a
Nachrichtentechniker D 06217 Merseburg
Dipl.-Ing.(FH) http://www.celocom.com
f. technische Informatik mailto:[email-masked]
http://www.worldbug.de Tel.: +49 3461/3318-0
mailto:[email-masked] Fax: +49 3461/415072
--------------------------------------------------------------------
Have You kicked Your cat today?
--------------ms50345134AB70B889528F6381
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

MIIKSgYJKoZIhvcNAQcCoIIKOzCCCjcCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC
B9YwggSgMIIECaADAgECAhBsOnTzXfzOOQkJistWSC3oMA0GCSqGSIb3DQEBBAUAMIHMMRcw
FQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y
azFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5
IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRp
dmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTAwMDEyNzAwMDAw
MFoXDTAxMDIwOTIzNTk1OVowggESMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UE
CxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9y
ZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMV
UGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBO
ZXRzY2FwZSBGdWxsIFNlcnZpY2UxFjAUBgNVBAMUDUJlcm5kIE1hdHRoZXMxITAfBgkqhkiG
9w0BCQEWEm1haW5idWdAY2Vsb2NvbS5kZTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA
5XDGxWjDOe+gHZygtVsNACVkbiY27ug06wI9DGzn4+ibdyEoqNnMlqe7dHSHsLG5f9Fl8gBa
ZgwOUnNClgnjCbqoByj4In82wWwUG97DndueKQhN78pYDRBWhGXKo/YSGI2l5rw7fjYnlTlw
6QQF0OGpFNBXzkNCBC4muSaI2YUCAwEAAaOCATgwggE0MAkGA1UdEwQCMAAwgawGA1UdIASB
pDCBoTCBngYLYIZIAYb4RQEHAQEwgY4wKAYIKwYBBQUHAgEWHGh0dHBzOi8vd3d3LnZlcmlz
aWduLmNvbS9DUFMwYgYIKwYBBQUHAgIwVjAVFg5WZXJpU2lnbiwgSW5jLjADAgEBGj1WZXJp
U2lnbidzIENQUyBpbmNvcnAuIGJ5IHJlZmVyZW5jZSBsaWFiLiBsdGQuIChjKTk3IFZlcmlT
aWduMBEGCWCGSAGG+EIBAQQEAwIHgDAwBgpghkgBhvhFAQYHBCIWIDFjNzhjMGNiYWZjMzg2
YzQzYzFmMWFjYTY5NzY4Nzk3MDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNp
Z24uY29tL2NsYXNzMS5jcmwwDQYJKoZIhvcNAQEEBQADgYEAsvJl1q8TirOQUfjbbyZKmVdi
k+2YQmQr64uvnEGf0Vp/laotPE49SR5Vu9GwGA2cPY/CPrb9v/bc3mOnCBlJ2m/xQIITJRxv
A66enfch2KSRLjl+VyU5BeIkq3UZekTAy76DPozOEwd6Azf4fLJy6AIh/DRS0GS9w/l2sLYQ
FAAwggMuMIICl6ADAgECAhEA0nYujRQMPX2yqCVdr+4NdTANBgkqhkiG9w0BAQIFADBfMQsw
CQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xNzA1BgNVBAsTLkNsYXNzIDEg
UHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkwHhcNOTgwNTEyMDAwMDAw
WhcNMDgwNTEyMjM1OTU5WjCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsT
FlZlcmlTaWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVw
b3NpdG9yeS9SUEEgSW5jb3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1Zl
cmlTaWduIENsYXNzIDEgQ0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZh
bGlkYXRlZDCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAu1pEigQWu1X9A3qKLZRPFXg2
uA1Ksm+cVL+86HcqnbnwaLuV2TFBcHqBS7lIE1YtxwjhhEKrwKKSq0RcqkLwgg4C6S/7wju7
vsknCl22sDZCM7VuVIhPh0q/Gdr5FegPh7Yc48zGmo5/aiSS4/zgZbqnsX7vyds3ashKyAkG
5JkCAwEAAaN8MHowEQYJYIZIAYb4QgEBBAQDAgEGMEcGA1UdIARAMD4wPAYLYIZIAYb4RQEH
AQEwLTArBggrBgEFBQcCARYfd3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQTAPBgNV
HRMECDAGAQH/AgEAMAsGA1UdDwQEAwIBBjANBgkqhkiG9w0BAQIFAAOBgQCIuDc73dqUNwCt
qp/hgQFxHpJqbS/28Z3TymQ43BuYDAeGW4UVag+5SYWklfEXfWe0fy0s3ZpCnsM+tI6q5QsG
3vJWKvozx74Z11NMw73I4xe1pElCY+zCphcPXVgaSTyQXFWjZSAA/Rgg5V+CprGoksVYasGN
Azzrw80FopCubjGCAjwwggI4AgEBMIHhMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEf
MB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWdu
LmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYG
A1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29u
YSBOb3QgVmFsaWRhdGVkAhBsOnTzXfzOOQkJistWSC3oMAkGBSsOAwIaBQCggbEwGAYJKoZI
hvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDEwMTI1MDkzMTQ5WjAjBgkq
hkiG9w0BCQQxFgQUn49j5xvwE/HPbGYb6vOSBdpYG54wUgYJKoZIhvcNAQkPMUUwQzAKBggq
hkiG9w0DBzAOBggqhkiG9w0DAgICAIAwBwYFKw4DAgcwDQYIKoZIhvcNAwICAUAwDQYIKoZI
hvcNAwICASgwDQYJKoZIhvcNAQEBBQAEgYB/r+B4R65QORDSfdQpG5TvncJLy6amyttCEFcb
RpOHHm+JsK6E5/ryK9DoIaLV1z5H5TI7Ynjc+KjlJoGEa8Mce315v+TUklsUC9YS5PtUAVQD
992f2tkM0pcDhQynSP5foeSU47xrpSszAWLiMB3xe+JY3XJesoWVM54ldfbzIA==
--------------ms50345134AB70B889528F6381--

Received: from certplus.com (facteur.certplus.com [195.101.88.81]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id BAA02837 for ; Thu, 25 Jan 2001 01:08:27 -0800 (PST)
Received: from certplus.com ([192.168.212.178]) by certplus.com (8.11.2/8.11.2) with ESMTP id f0P9G2k23663 for ; Thu, 25 Jan 2001 10:16:02 +0100
Message-ID: <[email-masked]>
Date: Thu, 25 Jan 2001 10:14:11 +0100
From: Jean-Marc Desperrier
Organization: Certplus
X-Mailer: Mozilla 4.75 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: [email-masked]
Subject: Re: Query about nonce field in Time-stamp response.
References: <005701c0868c$b9f330c0$966801c4@insight>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Prashant Dambe wrote:

> Time-Stamp Protocol Response contains Nonce field as a part of signed
> TimeStamptoken. It will be stored as a part of timestamp token. But
> the nonce will be checkedat the time of receiption of Time-Stamp token
> against the client generated nonce.What will be the use of Nonce field
> stored in the Time-stamp token when in the futurethe that token will
> be used.Should nonce be a part of TSTInfo in time-stamp token and
> stored as part of Time-stamp token ?

Replay detection is one thing, but there can be other uses of the nonce
field.

If you think of it, the nonce is an arbitrary choosen user identifier
for the token ...
So it's not so inconvenient if it's included in the payload of the
TimeStamptoken.

Received: from pdcpune.elock.co.in (pdcpune.elock.co.in [196.1.104.8]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id UAA05236 for ; Wed, 24 Jan 2001 20:47:39 -0800 (PST)
Received: from insight (insight.fcpl.co.in [196.1.104.150]) by pdcpune.elock.co.in with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id DJ333Q0Y; Thu, 25 Jan 2001 10:19:58 +0530
Message-ID: <005701c0868c$b9f330c0$966801c4@insight>
From: "Prashant Dambe"
To:
Subject: Query about nonce field in Time-stamp response.
Date: Thu, 25 Jan 2001 10:37:33 +0530
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0054_01C086BA.D39DB120"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2314.1300
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300

This is a multi-part message in MIME format.

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

Time-Stamp Protocol Response contains Nonce field as a part of signed =
TimeStamp=20
token. It will be stored as a part of timestamp token. But the nonce =
will be checked=20
at the time of receiption of Time-Stamp token against the client =
generated nonce.
What will be the use of Nonce field stored in the Time-stamp token when =
in the future
the that token will be used.
Should nonce be a part of TSTInfo in time-stamp token and stored as part =
of Time-stamp token ?

Prashant

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

Time-Stamp Protocol Response contains =
Nonce field=20
as a part of signed TimeStamp

token. It will be stored as a part of =
timestamp=20
token. But the nonce will be checked

at the time of receiption of Time-Stamp =
token=20
against the client generated nonce.

What will be the use of Nonce field =
stored in the=20
Time-stamp token when in the future

the that token will be =
used.

Should nonce be a part of TSTInfo in =
time-stamp=20
token and stored as part of Time-stamp token ?

Prashant

------=_NextPart_000_0054_01C086BA.D39DB120--

Received: from mailhub.ways.com ([203.129.237.10]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id TAA02736 for ; Wed, 24 Jan 2001 19:14:15 -0800 (PST)
From: [email-masked]
Received: from kmtops ([203.197.250.20]) by mailhub.ways.com (8.9.3/8.8.7) with SMTP id IAA27754 for ; Thu, 25 Jan 2001 08:42:57 +0500
Reply-To:
To:
Subject:
Date: Thu, 25 Jan 2001 08:45:19 +0530
Message-ID:
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="----=_NextPart_000_0009_01C086AB.25D94720"
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

This is a multi-part message in MIME format.

------=_NextPart_000_0009_01C086AB.25D94720
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

unsubscribe

------=_NextPart_000_0009_01C086AB.25D94720
Content-Type: text/x-vcard;
name="Krishnan Mani.vcf"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment;
filename="Krishnan Mani.vcf"

BEGIN:VCARD
VERSION:2.1
N:Mani;Krishnan
FN:Krishnan Mani
ORG:Ways India Limited
TITLE:Senior Manager
TEL;WORK;VOICE:+91 (-22) -7812444
TEL;CELL;VOICE:+91 9821339816
ADR;WORK;ENCODING=3DQUOTED-PRINTABLE:;;Ways India Limited=3D0D=3D0ATower =
3, 5th Floor,=3D0D=3D0AVashi International Infot=3D
ech Park;Navi Mumbai;Maharashtra;400703;India
LABEL;WORK;ENCODING=3DQUOTED-PRINTABLE:Ways India Limited=3D0D=3D0ATower =
3, 5th Floor,=3D0D=3D0AVashi International Infotec=3D
h Park=3D0D=3D0ANavi Mumbai, Maharashtra 400703=3D0D=3D0AIndia
URL:
URL:http://www.ways.com
EMAIL;PREF;INTERNET:[email-masked]
REV:20010124T075513Z
END:VCARD

------=_NextPart_000_0009_01C086AB.25D94720--

Received: from po1.bbn.com (PO1.BBN.COM [192.1.50.38]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id TAA02664 for ; Wed, 24 Jan 2001 19:12:15 -0800 (PST)
Received: from [128.33.238.106] (TC106.BBN.COM [128.33.238.106]) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id WAA08376; Wed, 24 Jan 2001 22:18:23 -0500 (EST)
Mime-Version: 1.0
X-Sender: [email-masked] (Unverified)
Message-Id:
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Date: Wed, 24 Jan 2001 21:28:47 -0500
To: Peter Williams
From: Stephen Kent
Subject: RE: DPD & DPV requirements - to nonce or not to nonce?
Cc: [email-masked]
Content-Type: text/plain; charset="us-ascii" ; format="flowed"

Peter,

>Steve,
>
>Thankyou for your dissmisive comments.

You earned them as a result of many messages over the last several
years; I finally decided to vent.

Peter, you're a very smart guy and I value your contributions. But
your intelligence does not contribute to helping PKIX do its work
when you cloak it in language that is almost impenetrable.

>Thankyou also for your disclosure of what you know about
>the use of hash-trees in patents. Your introduction of
>timestamping IP into a thread on (timed) nonces was
>suprising, per se.

I explained why I did it, confused as I was by your
characteristically terse comments.

>I deduce from the your many memos discussing (somewhat vaguely
>expressed) requirements that you personally see no real
>vulnerability in a validation server responding to
>replayed client requests. Perhaps you view it as a function
>of the underlying transport to be guarding against availability
>threats?

Vaguely expressed requirements? As opposed to the crisp set we had on
the table when I posted my draft requirements? Maybe you sent a
lengthy message contributing to the clarification, but I missed it.

Of course it's preferable to design the protocol to allow for use of
a countermeasure that allow's a server to guard against replays, but
we have many options, depending on the context. In a public DPV
server context one might imagine using IPsec or TLS to authenticates
the client, for billing purposes, and those protocols address the
replay problem. So, the question is whether we want to mandate an
anti-replay facility in DPV and DPD, separate from what might be
provided at a lower layer. And, if so, do we further mandate server
behavior re rejecting replays. The former sounds reasonable, the
latter is less clear. For example, in a corporate environment any
added burden imposed by a countermeasure for server anti-replay may
not be deemed worthwhile. Also, while I do sincerely applaud your
mechanism for keeping track of nonces via a hash tree, it would not
be appropriate in a standard, since it is an optimization of what is
purely a local implementation issue, right?

>As a model for the design of authenication elements of a DPV
>service, which IETF protocol's use of signed, nonce and
>anti-replay handling do you view as examplary and a practice
>to be followed? I will summarize its design for the list.

Thanks for the offer, bit it may be premature. First, we have not
agreed on the form of the service we need to provide here,
specifically whether we need to provide protection for server
anti-replay vs. client anti-replay. Second, I don't think I have held
out any specific IETF protocol as a model for this context. I guess I
could look at what we did for TSP, which the WG and the IESG
approved. I don't recall your commenting on that mechanism as being
deficient re server anti-replay. If you didn't consider it a
requirement for that protocol, why is it a requirement here?

>With this information, we can begin
>to comprehend which security service DPV users will be invoking
>when applying the digital signature mechanism. Understanding
>the authentication requirements is a useful contribution
>at this stage, given the current lack of perceived clarity
>on how intelligent the DPV client is supposed to be.

As a user of this service I doubt that I care whether I am invoking a
server anti-replay service. Also, anti-replay in a connectionless
communication environment is usually viewed as an integrity service,
not an authentication service.

Steve

Received: from arnie.adacel.com.au (arnie.adacel.com.au [203.36.26.147]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id RAA29607 for ; Wed, 24 Jan 2001 17:16:34 -0800 (PST)
Received: (qmail 25311 invoked from network); 25 Jan 2001 01:22:51 -0000
Received: from unknown (HELO osmium) (203.8.85.176) by arnie.adacel.com.au with SMTP; 25 Jan 2001 01:22:51 -0000
Reply-To:
From: "Steven Legg"
To: "'Michael Str der'"
Cc:
Subject: RE: Certificate Matching was:RE: Basic Cert-2-Directory mapping question
Date: Thu, 25 Jan 2001 12:23:43 +1100
Message-ID: <[email-masked]>
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 8.5, Build 4.71.2377.0
In-Reply-To: <[email-masked]>
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2120.0

Michael,

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On Behalf
> Of Michael
> Str der
> Sent: Wednesday, 24 January 2001 23:07
> To: [email-masked]
> Subject: Re: Certificate Matching was:RE: Basic
> Cert-2-Directory mapping
> question
>
>
> Steven Legg wrote:
> >
> > It isn't always appropriate that the value of the surrogate
> attribute
> > matches the value of the corresponding field in the certificate.
> > Maybe the certificate is valid but uses a superseded value for the
> > surrogate attribute (maybe the user has changed ISPs and is
> waiting for
> > an updated certificate).
>
> If I understand your example right you would like to use the cert
> retrieved from the LDAP host containing the old e-mail address to
> encrypt a message for the new e-mail address? This behaviour is not
> what I would like to see in my e-mail application. Think of key
> escrow mechanisms in a company...

It was a general statement not directed at any particular attribute
type. Using surrogate attribute values to search for certificates
imposes a constraint between the certificate contents and the contents
of the other attributes in the same entry. I'm not bold enough or
knowledgeable enough to assert that there are NO current or future
applications where this constraint would cause serious difficulties.

As Tom pointed out, we could define a bunch of new attribute types
to act expressly and only as search attributes for fields in certificates.
It then doesn't matter that there is a constraint between the certificates
and the new attributes, except that the task of managing the correspondence
between the two falls to the large number of client implementations.
It makes more sense to change the small number of server implementations
to support direct searching on certificate contents.

>
> > With surrogate search attributes the client will get back all
> > certificates in the entry and have to filter them itself to find
> > which is the one it actually wants.
>
> IMHO the main benefit of this I-D would be that applications or
> components not dealing with ASN.1 or certificates itself can
> retrieve the appropriate certificate. If you require the
> client-application to do anything else more than just submitting a
> simple LDAP filter string you can stop writing the I-D.

I hope you haven't confused the issues. There are two things being
discussed.

1) Should surrogate search attributes or direct matching on certificates
be used to search for certificates ?

2) Given that there is direct matching, should the matching rules be a
series of special purpose certificate matching rules or a generic matching
capability that works for any syntax (certificates included) ?

With regard to 1), a search on a single surrogate attribute can only
return all certificates in a matched entry. If the entry contains
only one certificate the client can trust it is the right one (hopefully
the surrogate attribute value is the same as the corresponding field
in the certificate). If the entry contains more than one certificate
then it is up to the client to delve into each certificate to work
out which is the one it actually wanted. Searches on a combination
of surrogate attributes can return entries with certificates that
don't have the desired combination. Again it is up to the client
to delve into the certificates to see which entries and certificates
actually match its criteria. Surrogate search attributes generally require
the clients to be PKI and ASN.1 aware. Direct matching of certificates
doesn't.

With regard to 2), I'm drawing a distinction between LDAP filters that
are simple to use versus LDAP filters that look simple. Special
purpose certificate matching rules can be (relatively) simple to use
and also look simple. I contend that I can write component matching
rule templates that are equally simple to use, though they look more
complicated.

> > I recognize that the need to understand ASN.1 in order to
> formulate a
> > query is an obstacle to acceptance.
>
> YES!
>
> Another real-world example: A system administrator wants to pull
> certificates via LDAP and feed them into a PKI-aware application.
> She/He's using her/his favourite scripting language with a primitive
> LDAP module to download the binary blobs containing DER-encoded
> certificates. In this system the LDAP component itself is not
> PKI-aware and the PKI-aware component is not capable of speaking
> LDAP. Therefore the LDAP component is not able to sort out the right
> certificate.

When you say that the LDAP component is not PKI-aware I take it you mean
that it doesn't understand the ASN.1 type of a certificate and supports
no matching rules for directly matching a certificate. In such a case
your hypothetical system administrator would have to use surrogate
search attributes with all the attendant imprecision. Some sort
of direct matching capability is required for the LDAP component to
return only the right certificate.

Regards,
Steven

> Ciao, Michael.

Received: from ext-mail.valicert.com (ns1.valicert.com [63.65.221.10]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA20645 for ; Wed, 24 Jan 2001 13:40:36 -0800 (PST)
Received: from CONVERSION-DAEMON by ext-mail.valicert.com (PMDF V5.2-33 #46613) id <[email-masked]> for [email-masked]; Wed, 24 Jan 2001 13:46:50 -0800 (PST)
Received: from polaris.valicert.com ([192.168.2.34]) by ext-mail.valicert.com (PMDF V5.2-33 #46613) with ESMTP id <[email-masked]>; Wed, 24 Jan 2001 13:46:50 -0800 (PST)
Received: by exchange.valicert.com with Internet Mail Service (5.5.2650.21) id ; Wed, 24 Jan 2001 13:42:19 -0800
Content-return: allowed
Date: Wed, 24 Jan 2001 13:42:15 -0800
From: Peter Williams
Subject: RE: DPD & DPV requirements - to nonce or not to nonce?
To: "'Stephen Kent'"
Cc: [email-masked]
Message-id: <[email-masked]>
MIME-version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-type: text/plain; charset="iso-8859-1"

Steve,

Thankyou for your dissmisive comments.

Thankyou also for your disclosure of what you know about
the use of hash-trees in patents. Your introduction of
timestamping IP into a thread on (timed) nonces was
suprising, per se.

I deduce from the your many memos discussing (somewhat vaguely
expressed) requirements that you personally see no real
vulnerability in a validation server responding to
replayed client requests. Perhaps you view it as a function
of the underlying transport to be guarding against availability
threats?

As a model for the design of authenication elements of a DPV
service, which IETF protocol's use of signed, nonce and
anti-replay handling do you view as examplary and a practice
to be followed? I will summarize its design for the list.

With this information, we can begin
to comprehend which security service DPV users will be invoking
when applying the digital signature mechanism. Understanding
the authentication requirements is a useful contribution
at this stage, given the current lack of perceived clarity
on how intelligent the DPV client is supposed to be.

Peter.

Received: from email.nist.gov (email.nist.gov [129.6.2.7]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA14612 for ; Wed, 24 Jan 2001 12:34:06 -0800 (PST)
Received: from st25 (st25.ncsl.nist.gov [129.6.54.67]) by email.nist.gov (8.9.3/8.9.3) with ESMTP id PAA04254 for ; Wed, 24 Jan 2001 15:40:20 -0500 (EST)
Message-Id: <[email-masked]>
X-Sender: [email-masked]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58
Date: Wed, 24 Jan 2001 15:39:53 -0500
To: [email-masked]
From: Tim Polk
Subject: X.509 path validation test suite
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed

Folks,

NIST, NSA, Getronics, and Cygnacom Solutions have collaborated to develop
an initial test suite for X.509 path validation. We have created seventy
six test paths consisting of X.509 v3 certificates and the corresponding
X.509 v2 CRLs.

The test cover the fields in the base certificate and four extensions:
basic constraints, key usage, certificate policies, and policy constraints.
At a minimum, implementations must support basic constraints and key usage.
If these extensions are not supported, the implementation will not be able
to process any of the tests.

The test data is available at
http://csrc.nist.gov/pki/testing/x509paths.html in a three different forms.
You can download all the paths in a compressed tar file, a zip file, or as
a self-extracting executable. We provide the end entity private keys so
that you can perform "live" testing with your applications; we also provide
CMS signed-data messages for use with S/MIME V3 code.

The certificates and CRLs necessary to perform the tests can also be
retrieved using LDAP. The directory is on the machine seclab7.ncsl.nist.gov
(129.6.20.35) and can be accessed using port 389. The schema specified in
RFC 2587 was used to place the certificates and CRL in the directory.

This test suite is considered a first step. We hope in the future to test
all the features which are MUSTs or SHOULDs in RFC 2459 or its successor.
At the moment, though the tests are limited to the four extensions
identified above. We also make certain limiting assumptions:
* Certificate serial numbers are always positive in these tests.
* Distinguished names only include the attribute types c, o, ou, and cn,
and all of the attribute values are of type PrintableString.
* All certificates are signed with PKCS #1 RSA and SHA-1.

At a minimum, we need at add UTF8String in some DNs. Additional algorithms
would also be nice. We will need to cover additional extensions. Another
goal would be to map every path to the set of path validation processing
steps described in son-of-2459.

We are extremely interested in your feedback on the tests. How can we make
the tests more useful besides extending the range of functionality? For
instance, would the tests more useful in some other format?

David Copper at NIST is the primary contact for comments, questions, or
suggestions on the evolution of this test suite. His email address is
[email-masked]

Thanks,

Tim Polk

Received: from mail.spyrus.com (mail.spyrus.com [207.212.34.20]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA10548 for ; Wed, 24 Jan 2001 11:45:04 -0800 (PST)
Received: from RHOUSLEY-PC.spyrus.com ([209.172.119.210]) by mail.spyrus.com (8.9.3/8.9.3) with ESMTP id LAA12530; Wed, 24 Jan 2001 11:50:30 -0800 (PST)
Message-Id: <[email-masked]>
X-Sender: [email-masked]
X-Mailer: QUALCOMM Windows Eudora Version 5.0.2
Date: Wed, 24 Jan 2001 13:59:32 -0500
To: Stephen Kent
From: Russ Housley
Subject: Re: DPD & DPV requirements
Cc: PKIX-List
In-Reply-To:
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed

One thing that I think we should add to DPD is the ability to mandate the
presence of a particular name form in the end entity certificate. For
example, and IPsec client might want an IP address or DNS name in the
certificate. An S/MIME client might want an RFC 822 address in the
certificate.

Russ

At 12:14 PM 1/23/2001 -0500, Stephen Kent wrote:
>Denis,
>
>>Russ,
>>
>> > I agree. If were were to add any capability, I would consider an
>> input to
>> > the path validation algorithm that allowed a user to provide name
>> > constraints. There is already an input parameter for acceptable
>> policies.
>>
>>This is fine for DPD.
>>
>>The next question is : is this also fine for DPV ?
>>
>>Not sure, some validation policies may request some (even private)
>>extensions in the leaf certificate to be present for a certificate to be
>>"valid" according to a validation policy. Hence a response "valid", should
>>be interpreted as a minimum condition to be valid, but not always as a
>>sufficient condition. We would have to be very careful when explaining what
>>a "valid" status means.
>
>Good point. The issue you're getting at here is how far beyond 2459 do we
>go in providing explicit controls on validation for DPV, since it is not
>unreasonable for folks to impose such constraints in various application
>contexts. I think we have some flexibility here, but we need to pick a
>set of parameters and go forward.
>
>Steve
>

Received: from po1.bbn.com (PO1.BBN.COM [192.1.50.38]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA09962 for ; Wed, 24 Jan 2001 11:38:51 -0800 (PST)
Received: from [128.33.238.51] (TC051.BBN.COM [128.33.238.51]) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id OAA27296; Wed, 24 Jan 2001 14:39:49 -0500 (EST)
Mime-Version: 1.0
X-Sender: [email-masked] (Unverified)
Message-Id:
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Date: Wed, 24 Jan 2001 12:03:41 -0500
To: Peter Williams
From: Stephen Kent
Subject: RE: DPD & DPV requirements - to nonce or not to nonce?
Cc: [email-masked]
Content-Type: text/plain; charset="us-ascii" ; format="flowed"

Peter,

Thanks for the tutorial. I didn't think that (many?) folks
implemented the authentication protocols from the X.500 series
recommendations you cited, so I have to admit to not having paid
close attention to them. Looking at most of the other security
protocols that make use of nonces, it seems that few other folks have
paid close attention to these documents as well.

Now that I fully understand the context in which you referred to hash
trees, I have to withdraw my concerns re possible intellectual
property problems. While we do know of patents on use of hash trees
to deal with cert revocation, I don't know of any that would apply to
the anti-replay feature you mention.

In my defense, I will say that if your messages were clearer, this
sort of confusion would be less likely to arise. For a native
speaker of the English language, the level of obfuscation in your
e-mail is amazing. You often write very concise, almost context-free
sentences that I have trouble relating to the discussion at hand.

Steve

Received: from po1.bbn.com (PO1.BBN.COM [192.1.50.38]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA09340 for ; Wed, 24 Jan 2001 11:34:37 -0800 (PST)
Received: from [128.33.238.51] (TC051.BBN.COM [128.33.238.51]) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id OAA27461; Wed, 24 Jan 2001 14:40:46 -0500 (EST)
Mime-Version: 1.0
X-Sender: [email-masked] (Unverified)
Message-Id:
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Date: Wed, 24 Jan 2001 14:07:27 -0500
To: Denis Pinkas
From: Stephen Kent
Subject: Re: DPD & DPV requirements
Cc: PKIX-List
Content-Type: text/plain; charset="us-ascii" ; format="flowed"

Denis,

>
> > I agree. If were were to add any capability, I would consider an input to
> > the path validation algorithm that allowed a user to provide name
> > constraints. There is already an input parameter for acceptable policies.
> >
> > Russ
>
>I would like to second Russ Housley's comments above for associating name
>constraints with trust anchors. Without naming constraints we would get
>security threats that would imply global trust, which is not a real life
>situation. If other words, I want to be able to detect when company X
>certifies a name from a user (or entity) from company Y, and when this is
>not allowed.

I agree with the need for name constraints, and I have been persuaded
that associating them with trust anchors is preferable to creating
cross certs.

Steve

Received: from po1.bbn.com (PO1.BBN.COM [192.1.50.38]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA09329 for ; Wed, 24 Jan 2001 11:34:36 -0800 (PST)
Received: from [128.33.238.51] (TC051.BBN.COM [128.33.238.51]) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id OAA27455; Wed, 24 Jan 2001 14:40:42 -0500 (EST)
Mime-Version: 1.0
X-Sender: [email-masked] (Unverified)
Message-Id:
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Date: Wed, 24 Jan 2001 14:05:40 -0500
To: Peter Sylvester
From: Stephen Kent
Subject: RE: DID & DIP requirements
Cc: [email-masked], [email-masked]
Content-Type: text/plain; charset="us-ascii" ; format="flowed"

Peter,

> >
> > While it is true that the client puts its faith in a DPV server, that
> > does not mean that the client has no input to the validation process,
> > not is that process "unknowlable" by an external agent armed with
> > knowledge of the validation parameters. It should be possible to
> > predict the results of DPV operation armed with knowledge of the
> > client request, locally configured policies, and knowledge of the
> > other servers to which the DPC server has access.
>
>I accept a locally configured policy harded coded as a representation
>of the 'application'.
>
>For others I would be very careful.
>
> > > In DPD this may be completely the other way around.
> > >
> > > >
> > > > The client and server algorithmic descriptions should help
>resolve this.
> > >
> > >For DPV you have no algorithmic description in the same way as
> > >you don't know how a OCSP responder came to his conclusion.
> >
> > I don't think we agree here. The DPV server must operate on an
> > algorithmic basis and thus have a predictable output. We don't want
> > non-deterministic operation
>
>Hm, even X509 does not operate on an algorithmic basis. It only specified
>what criteria a valid path must follow, but not how to get to a valid path.

You're right that X.509 does not say how to do path discovery. But as
a consumer of these products I want to know that these servers
"work." So, for example, if I know what LDAP servers a DPD server is
configured to access (and the content of these servers) and with
knowledge of the validation policy, I'd like to know that the server
will discover valid paths that I know are available to it. I'm open
to suggestions of how we can specify this.

>The OCSP is also non-deterministic, also the possibilities are smaller,
>you don't know whether the server has access to a CRL, or directly
>to a CA base.

My notion of deterministic assumes that we know what the server
knows. In that sense OCSp is deterministic, even though it can return
a "don't know" answer.

>
> > > > I would argue that having the protocol define a functional
>equivalent path
> > > > discovery algorithm, like RFC 2459 does for path validation, will help
> > > > implementers.
> > >
> > >For a DPV you don't need that. The DPV server verifies against against
> > >his local trust base.
> >
> > Not entirely true, since the client may provide inputs to the
> > validation process which will specify how the process works, mod any
> > overrides configured into the server.
>
>Well, we are back to case 1: What are the possible controls for
>a DPV client? ;-)

My starting point are the 2459 bis path validation controls, but if
we reach consensus on others, we can add them in as well.

> > > for DPD I am not sure at all, it rather sems to me like a search in
> > >a directory
> > >anyway, and you may need to ask the DPD server several times.
> >
> > I'd like to better understand what parameters the client will change
> > between invocations of a DPD server, in a controlled fashion, to make
> > multiple invocations for the same target certificate provide
> > distinct, useful, answers. Do you have some examples that could
> > clarify this scenario?
>
>Well, as a minimum client could just return a 'session id' as we
>had discussed in the OCSP based DPD. This id contains in
>a opaque way (for the client) enough info for the server to resume
>to 'get the next'.

that's a mechanism for referring to state at the server; what I was
looking for were scenarios that show how a client and server would
interact here re refining the search

>If you allow a client to react on the first response to say something
>like: 'oh well, you first answer is really not the right direction,
>instead of using a bottom up algoritm, you'd better do yoyo', then
>this gets rather complicated IMHO.

I agree, which is why I am reluctant to put in mechanisms to support
it at this time. if we can't explain how the procedure will work, and
provide explicit controls, then we have a placeholder that does not
permit interoperable implementation, the hallmark of a good IETF
standard.

Steve

Received: from po1.bbn.com (PO1.BBN.COM [192.1.50.38]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA09158 for ; Wed, 24 Jan 2001 11:34:09 -0800 (PST)
Received: from [128.33.238.51] (TC051.BBN.COM [128.33.238.51]) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id OAA27403; Wed, 24 Jan 2001 14:40:14 -0500 (EST)
Mime-Version: 1.0
X-Sender: [email-masked] (Unverified)
Message-Id:
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Date: Wed, 24 Jan 2001 12:34:06 -0500
To: Denis Pinkas
From: Stephen Kent
Subject: Re: DVD & DVP requirements
Cc: Bob Jueneman , [email-masked]
Content-Type: text/plain; charset="us-ascii" ; format="flowed"

Denis,

>Steve,
>
>I picked up one of your sentences in your response to Bob.
>
>[Bob]
>
> > >In either case, the client can ask the question, "Is this certificate
> > >chain trustworthy with respect to my "Platinum" criteria?" and get one
> > >answer, and later ask the same question with respect to exactly the
> > >same certificate chain, but specifying the "Green" criteria, and perhaps
> > >get a different answer.
>
>[Steve]
>
> > We support this via reference to different policies configured on the
> > server,
>
>Not necessarilly configured, but also accessible by the server using a
>reference.

My spec requires that the server be able to be configured with these
policies. That will ensure that we have a definition of a minimum
parameter set well defined for all servers. If we allow for external
references, then we have to define a reference format (do you already
have one in mind?), select a protocol and format for transport of the
parameters, etc. So, while it may be OK to have external references,
I really want to keep the local config requirement as a base, and I
think the addition of external references adds complexity.

> > but only to the extent that the policies make use of standard
> > cert attribute validation parameters.
>
>Validation policies may include more controls than specified in RFC 2459bis.
>If these validation policies are defined using external references, then it
>is easy to point to them and thus avoids to describe them at the interface
>level.

Yes, and that leads to potential ambiguities and potentially
undefined server operation.

> > To do what you propose would
> > require adding support for private extensions at the server and
> > perhaps in client requests. This could be done if the WG wants, but
> > it would be a supplement to the mandatory, 2459bis validation
> > criteria.
>
>Describing parameters additional to the traditional validation algorithm
>described in RFC2459, is indeed not that easy. For simplicity, these
>addtional parameters should be limited to indicate conditions on the leaf
>certificates.

I'm not comfortable with pushing the problem under the rug in this
fashion. We all love the power of indirection, but the reason I
called for server config of parameters was to ensure that we had a
well-defined list and that a compliant server implementation could be
managed based on that list, without reference to some vendor-specific
mechanisms.

>As a summary:
>
>1) Using validation policy references allows a simple interface and hides
>the details (and complexity) of the validation policy.

Are you suggesting that we not have a facility for the client to pass
in validation parameters, but only have references to policies, or
are you proposing external references in addition to explicit
parameters in the request? I'm not sure I want to hide details of the
policy. I think references to a policy are attractive as a means of
centralizing management.

>2) Using an explicit validation policy by describing all the parameters at
>the interface level is more complex and in any case will have some
>limitations when compared to referenced validation policies. I agree with
>Steve, that it would be a supplement to the mandatory 2459bis validation
>criteria.

Not sure I know how to parse this last sentence, although I think I
sense an overall disparagement of support for explicit parameters,
which I still think is necessary.

Steve

Received: from po1.bbn.com (PO1.BBN.COM [192.1.50.38]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA08943 for ; Wed, 24 Jan 2001 11:33:28 -0800 (PST)
Received: from [128.33.238.51] (TC051.BBN.COM [128.33.238.51]) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id OAA27251; Wed, 24 Jan 2001 14:39:31 -0500 (EST)
Mime-Version: 1.0
X-Sender: [email-masked] (Unverified)
Message-Id:
In-Reply-To: <[email-masked] u>
References: <[email-masked] u>
Date: Wed, 24 Jan 2001 10:39:53 -0500
To: "Manger, James H"
From: Stephen Kent
Subject: RE: DPD & DPV: Strawman proposals - DPD signatures
Cc: IETF-PXIX
Content-Type: text/plain; charset="us-ascii" ; format="flowed"

At 6:35 PM +1100 1/24/01, Manger, James H wrote:
>Does DPD necessarily need to sign the result?
>I thought a DPD server was more analogous to an LDAP directory - you don't
>have to "trust" them (though you may rely on their collective availability).
>D = Discovery

Signing is not required, but some form of authentication and
integrity checking should be employed to detect attacks on the
communications between the client and server, e.g., as a
countermeasure for more subtle DoS attacks.

>A DPD searches out all the required items (certs, CRLs, OCSP responses,
>timestamps, ...), but each of those items has its own signature so the DPD
>server itself does not have to be trusted (in the same sense that you don't
>need to trust a directory that stores certificates).

Right.

>[Note: this is in sharp contrast to DPV (V = validation), where there is
>definite trust placed in the server so it must be authenticated as the
>origin of the result. Another reason for separate protocols.]

A signature is not needed for DPV in all cases either. Only if the
client wants NR for the DPV response is it necessary. If the client
is relying on the DPV server in a context that does not involve NR,
then why would the client require a signed response, vs. an
authenticated response?

A signature is one option for effecting integrity and authentication,
as well as a basis for NR. I think it reasonable to require support
for signatures for DPV responses, and to make them optional for DPD
responses. If so, then we might find great similarity in the DPD and
DPV response formats, at least in this regard.

Steve

Received: from po1.bbn.com (PO1.BBN.COM [192.1.50.38]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA08925 for ; Wed, 24 Jan 2001 11:33:25 -0800 (PST)
Received: from [128.33.238.51] (TC051.BBN.COM [128.33.238.51]) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id OAA27261; Wed, 24 Jan 2001 14:39:35 -0500 (EST)
Mime-Version: 1.0
X-Sender: [email-masked] (Unverified)
Message-Id:
In-Reply-To:
References:
Date: Wed, 24 Jan 2001 11:32:54 -0500
To: "Bob Jueneman"
From: Stephen Kent
Subject: RE: DVD & DVP requirements
Cc:
Content-Type: text/plain; charset="us-ascii" ; format="flowed"

Bob,

>Steve, I didn't intend to "advertise," nor was I in any shape or form
>advocating that the WG endorse or even consider the proprietary
>attributes I was discussing. They were only provided as a reference.
>
>
>You asked for an example of parameters a client could change
>between invocations of a DPD server, where multiple invocations
>would provide distinct, useful answers.
>
>I think that the examples I provided do exactly that. You may or may
>not like those examples, you may prefer to use other mechanisms
>such as Policy OIDs, name subordination, or other techniques
>(although I believe we might differ as to their utility in a general context),
>and that's all fine and good.
>
>All I was attempting to provide were EXAMPLES, per your request,
>not necessarily a proposed change to the standard, etc.

If there had been more concrete examples of such parameters, rather
than a high level discussion, plus the URL, I would have interpreted
the message as addressing my request.

Steve

Received: from edelweb.fr (edelweb.fr [212.234.46.16]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA20003 for ; Wed, 24 Jan 2001 06:49:40 -0800 (PST)
Received: from champagne.edelweb.fr (localhost.edelweb.fr [127.0.0.1]) by edelweb.fr with ESMTP id PAA20484; Wed, 24 Jan 2001 15:55:40 +0100 (MET)
Received: from champagne.edelweb.fr (champagne.edelweb.fr [193.51.14.161]) by edelweb.fr (nospam/1.3); Wed, 24 Jan 2001 15:55:40 +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 PAA20775; Wed, 24 Jan 2001 15:55:38 +0100 (MET)
From: Peter Sylvester
Received: (sylvest@localhost) by emeriau.edelweb.fr (8.7.6/8.6.6) id PAA22819; Wed, 24 Jan 2001 15:55:37 +0100 (MET)
Date: Wed, 24 Jan 2001 15:55:37 +0100 (MET)
Message-Id: <[email-masked]>
To: [email-masked]
Subject: RE: DPD & DPV: Strawman proposals - DPD signatures
Cc: [email-masked]

>
> Does DPD necessarily need to sign the result?
> I thought a DPD server was more analogous to an LDAP directory - you don't
> have to "trust" them (though you may rely on their collective availability).
> D = Discovery

Why not consider using an LDAP query for DPD,
i;e., and define either some additional control if necessary, or
just the data that have to be put into this 'server', and the
queries that have to be send.

This would work in some way with CRLs and certs.

> A DPD searches out all the required items (certs, CRLs, OCSP responses,
> timestamps, ...), but each of those items has its own signature so the DPD
> server itself does not have to be trusted (in the same sense that you don't
> need to trust a directory that stores certificates).
>
>
> [Note: this is in sharp contrast to DPV (V = validation), where there is
> definite trust placed in the server so it must be authenticated as the
> origin of the result. Another reason for separate protocols.]

If the DPV response is not intended to be stored by the client
together with some other data, but just to make a local decision,
then no signature is necessary, only server authentication, for
example by SSL/TLS. If the client application want to store the
result this is different.

It may be necessary that the response can be authenticated later
by another verifying entity, this mean that an appropriate
security envelope is necessary. A signature is one possible way.

----

How many people think that we are talking about two separate
protocols?

Received: from junker.ms.inka.de (pD901146D.dip.t-dialin.net [217.1.20.109]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id EAA10621 for ; Wed, 24 Jan 2001 04:01:56 -0800 (PST)
Received: from stroeder.com (localhost [127.0.0.1]) by junker.ms.inka.de (Postfix) with ESMTP id 5DB8E68089 for ; Wed, 24 Jan 2001 13:01:24 +0100 (CET)
Sender: [email-masked]
Message-ID: <[email-masked]>
Date: Wed, 24 Jan 2001 13:01:23 +0100
From: Michael =?iso-8859-1?Q?Str=F6der?=
Organization: stroeder.com
X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.18 i686)
X-Accept-Language: de-DE, de, en
MIME-Version: 1.0
To: [email-masked]
Subject: Re: Certificate Matching was:RE: Basic Cert-2-Directory mapping question
References: <[email-masked]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Steven Legg wrote:
>
> From: Tom Gindin [mailto:[email-masked]]
> >
> > Users are
> > supposed to be able to formulate LDAP queries by hand, after all, and
> > something as simple as "find certificates with the following e-mail
> > address" shouldn't require a 6 line query.
>
> We should make it clear who we think the "users" are.
> I assume that the users are programmers creating PKI-enabled
> applications. They would be using an LDAP API to access the
> certificate repository. Such folks should be able to
> contend with a six line query template.

I tend to say that even programmers creating PKI-enabled
applications appreciate simple approaches. A simple standard leads
to correct code soon. Standards "too complicated" will not be easily
adopted especially by developers of end-user applications. Bear in
mind that e.g. obtaining a certificate from LDAP in a S/MIME-aware
e-mail application is just a small side-job not very high on the
developer's priority list.

> I don't think the
> users are the PKI application users. The user interfaces
> should protect these folks from ever having to enter an LDAP
> query by hand.

I agree that applications should protect end-users from formulating
a LDAP query by hand.

But IMHO there is another user group: Folks doing customization of
applications. E.g. think of someone modifying a XML search form
template of a generic LDAP client. She/He's not a sophisticated PKI
application programmer nor an naive end user.

> If a new mechanism is going to be used then
> shouldn't it be the one that better fits the requirement and also
> puts most of the implementation effort into the small number of server
> implementations rather than the larger number of client implementations ?

Yes. Writing plug-ins for existing LDAP servers is easier than
modifying all client applications.

> [..lots of discussion about matching rules which made my
> brain hurt deleted..]

Hmm, at this point I would like to make a non-technical statement:
I have the feeling that we don't need so many new I-D's with even
more flexibility. We need I-D's which cut down the possibilities and
make statements about good practices (e.g. how to store certificates
in a directory and how to search them in the most possible simple
way).

I would expect that 90% of the scenarios considered here will never
ever make it into a real-world application. Therefore you can IMHO
safely consider simpler use-cases.

Ciao, Michael.

Received: from junker.ms.inka.de (pD901146D.dip.t-dialin.net [217.1.20.109]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id EAA10622 for ; Wed, 24 Jan 2001 04:01:56 -0800 (PST)
Received: from stroeder.com (localhost [127.0.0.1]) by junker.ms.inka.de (Postfix) with ESMTP id 4C5796808C for ; Wed, 24 Jan 2001 13:07:25 +0100 (CET)
Sender: [email-masked]
Message-ID: <[email-masked]>
Date: Wed, 24 Jan 2001 13:07:24 +0100
From: Michael =?iso-8859-1?Q?Str=F6der?=
Organization: stroeder.com
X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.18 i686)
X-Accept-Language: de-DE, de, en
MIME-Version: 1.0
To: [email-masked]
Subject: Re: Certificate Matching was:RE: Basic Cert-2-Directory mapping question
References: <[email-masked]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Steven Legg wrote:
>
> It isn't always appropriate that the value of the surrogate attribute
> matches the value of the corresponding field in the certificate.
> Maybe the certificate is valid but uses a superseded value for the
> surrogate attribute (maybe the user has changed ISPs and is waiting for
> an updated certificate).

If I understand your example right you would like to use the cert
retrieved from the LDAP host containing the old e-mail address to
encrypt a message for the new e-mail address? This behaviour is not
what I would like to see in my e-mail application. Think of key
escrow mechanisms in a company...

> With surrogate search attributes the client will get back all
> certificates in the entry and have to filter them itself to find
> which is the one it actually wants.

IMHO the main benefit of this I-D would be that applications or
components not dealing with ASN.1 or certificates itself can
retrieve the appropriate certificate. If you require the
client-application to do anything else more than just submitting a
simple LDAP filter string you can stop writing the I-D.

> I recognize that the need to understand ASN.1 in order to formulate a
> query is an obstacle to acceptance.

YES!

Another real-world example: A system administrator wants to pull
certificates via LDAP and feed them into a PKI-aware application.
She/He's using her/his favourite scripting language with a primitive
LDAP module to download the binary blobs containing DER-encoded
certificates. In this system the LDAP component itself is not
PKI-aware and the PKI-aware component is not capable of speaking
LDAP. Therefore the LDAP component is not able to sort out the right
certificate.

Ciao, Michael.

Received: from schzmxs1.europe.entrust.com ([212.249.12.226]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id BAA27916 for ; Wed, 24 Jan 2001 01:41:49 -0800 (PST)
Received: by schzmxs1.europe.entrust.com with Internet Mail Service (5.5.2448.0) id ; Wed, 24 Jan 2001 10:47:07 +0100
Message-ID:
From: Rita Zihlmann
To: [email-masked]
Subject: unsubscribe
Date: Wed, 24 Jan 2001 10:46:57 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain; charset="iso-8859-1"

Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id BAA25920 for ; Wed, 24 Jan 2001 01:27: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 KAA43790; Wed, 24 Jan 2001 10:41:15 +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 KAA17416; Wed, 24 Jan 2001 10:33:31 +0100
Message-ID: <[email-masked]>
Date: Wed, 24 Jan 2001 10:33:33 +0100
From: Denis Pinkas
Organization: Bull
X-Mailer: Mozilla 4.7 [fr] (Win98; I)
X-Accept-Language: fr
MIME-Version: 1.0
To: Russ Housley
CC: PKIX-List
Subject: Re: Post-facto queries [Was: RE: DPD & DPV requirements]
References: <[email-masked]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Russ,

> Denis:

> Let me try again.

OK.

> What evidence are you referring to? I assume that the relying party
> validated the path (using current-time DPV, OCSP, or CRLs).

No. The evidence is : a certification path + associated revocation status
information (i.e. CRLs and/or OCSP responses)

It does not include "current-time DPV". Note that the evidence could be
gathered
by using LDAP and OCSP, if the client were PKI-aware.

The global answer from the DPV server is: the signed "current-time DPV" +
the evidence indicated just above.

The evidence is only returned if requested by the client. Most of the time
the client will be pleased with the signed "valid" DPV answer. In case of a
later dispute about that answer, then the client will have to show the
evidence which supports the signed assertion made by the server. We should
bear in mind that the DPV client may trust the signed answer from the DPV
server, but the other disputing party may not, hence why the "evidence"
is needed.

> Then, later, a
> dispute arises. A third party (arbitrator, judge, lawyer doing discover,
> etc) uses retrospective DPV to confirm that the replying party did the
> processing correctly.

This would work well only when the two following conditions are met:

1) no CRL signing key nor issuing key is compromised,
2) all certificates still valid.

In other words, this would not work when these two conditions are not met,
which is *always* the case a few years after the validation.

> Here, I a trusting the DPV server to be able to

When you say "I trust", the question is : who is "I" ? Surely the client
can trust this, but not the disputing party. The disputing party will not
necessarilly trust the DPV server, but only the current PKI TTPs: CAs, CRL
issuers, OCSP responders and some TSAs.

> reconstruct the response that would have been given at the date and time
> specified in the query.

This only works if the two above conditions are met.

> What does time stamping have to do with it? (That could become a catchy
> song title. :-) )

The reasons are in the TSP document. They have been shortly explained once
again, less than 24 hours, in the e-mail exchange between Tom Guidin and
Carlin Covey.

Denis

> Russ
>
> At 04:48 PM 1/23/2001 +0100, Denis Pinkas wrote:
> >[Denis]
> >
> >The additional problem to be considered is that the structure of the answer
> >in case (a) would be different from the answer in the case of a current-time
> >checking, since one structure would include individual time stamps while the
> >other would not.
> >
> >[Russ]
> >
> >Why does the DPV need a 3rd party time stamp on the CRLs? It can keep
> >track using its own clock as long as it has a trusted time source. The
> >STIME working group is going to provide a straightforward mechanism for
> >that...
> >
> >[Denis * new answer]
> >
> >If you use the evidence, it is because you do not trust the "valid" answer
> >form the server (otherwise, you would not need the evidence). Hence you
> >would not trust either the clock from the server.

Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id BAA25489 for ; Wed, 24 Jan 2001 01:24:45 -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 KAA53254; Wed, 24 Jan 2001 10:38:05 +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 KAA15656; Wed, 24 Jan 2001 10:30:22 +0100
Message-ID: <[email-masked]>
Date: Wed, 24 Jan 2001 10:30:23 +0100
From: Denis Pinkas
Organization: Bull
X-Mailer: Mozilla 4.7 [fr] (Win98; I)
X-Accept-Language: fr
MIME-Version: 1.0
To: Stephen Kent
CC: Bob Jueneman , [email-masked]
Subject: Re: DVD & DVP requirements
References:
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Steve,

I picked up one of your sentences in your response to Bob.

[Bob]

> >In either case, the client can ask the question, "Is this certificate
> >chain trustworthy with respect to my "Platinum" criteria?" and get one
> >answer, and later ask the same question with respect to exactly the
> >same certificate chain, but specifying the "Green" criteria, and perhaps
> >get a different answer.

[Steve]

> We support this via reference to different policies configured on the
> server,

Not necessarilly configured, but also accessible by the server using a
reference.

> but only to the extent that the policies make use of standard
> cert attribute validation parameters.

Validation policies may include more controls than specified in RFC 2459bis.
If these validation policies are defined using external references, then it
is easy to point to them and thus avoids to describe them at the interface
level.

> To do what you propose would
> require adding support for private extensions at the server and
> perhaps in client requests. This could be done if the WG wants, but
> it would be a supplement to the mandatory, 2459bis validation
> criteria.

Describing parameters additional to the traditional validation algorithm
described in RFC2459, is indeed not that easy. For simplicity, these
addtional parameters should be limited to indicate conditions on the leaf
certificates.

As a summary:

1) Using validation policy references allows a simple interface and hides
the details (and complexity) of the validation policy.

2) Using an explicit validation policy by describing all the parameters at
the interface level is more complex and in any case will have some
limitations when compared to referenced validation policies. I agree with
Steve, that it would be a supplement to the mandatory 2459bis validation
criteria.

Denis

> Steve

Received: from mailo.vtcif.telstra.com.au (mailo.vtcif.telstra.com.au [202.12.144.17]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id XAA06273 for ; Tue, 23 Jan 2001 23:30:15 -0800 (PST)
Received: (from uucp@localhost) by mailo.vtcif.telstra.com.au (8.8.2/8.6.9) id SAA05995 for ; Wed, 24 Jan 2001 18:35:55 +1100 (EST)
Received: from maili.vtcif.telstra.com.au(202.12.142.17) via SMTP by mailo.vtcif.telstra.com.au, id smtpd0QuZt3; Wed Jan 24 18:35:40 2001
Received: (from uucp@localhost) by maili.vtcif.telstra.com.au (8.8.2/8.6.9) id SAA25112 for ; Wed, 24 Jan 2001 18:35:39 +1100 (EST)
Received: from localhost(127.0.0.1), claiming to be "mail.cdn.telstra.com.au" via SMTP by localhost, id smtpdLFo1u_; Wed Jan 24 18:35:09 2001
Received: from ntmsg0011.corpmail.telstra.com.au (ntmsg0011.corpmail.telstra.com.au [192.74.168.81]) by mail.cdn.telstra.com.au (8.8.2/8.6.9) with ESMTP id SAA02469 for ; Wed, 24 Jan 2001 18:35:08 +1100 (EST)
Received: by ntmsg0011.corpmail.telstra.com.au with Internet Mail Service (5.5.2650.21) id ; Wed, 24 Jan 2001 18:35:08 +1100
Message-ID: <[email-masked]>
From: "Manger, James H"
To: IETF-PXIX
Subject: RE: DPD & DPV: Strawman proposals - DPD signatures
Date: Wed, 24 Jan 2001 18:35:06 +1100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"

Does DPD necessarily need to sign the result?
I thought a DPD server was more analogous to an LDAP directory - you don't
have to "trust" them (though you may rely on their collective availability).
D = Discovery

A DPD searches out all the required items (certs, CRLs, OCSP responses,
timestamps, ...), but each of those items has its own signature so the DPD
server itself does not have to be trusted (in the same sense that you don't
need to trust a directory that stores certificates).

[Note: this is in sharp contrast to DPV (V = validation), where there is
definite trust placed in the server so it must be authenticated as the
origin of the result. Another reason for separate protocols.]

> ----------
> From: Denis Pinkas [mailto:[email-masked]]
> Sent: Tuesday, 23 January 2001 20:45
> To: IETF-PXIX
> Subject: Strawman proposals for DPV and DPD
>
...
> STRAWMAN PROPOSAL FOR DPD :
..
> Mandatory output : A digital signature over all the outputs (including the
> input parameters as well) in order to provide authentication with
> integrity.
...

Received: from arnie.adacel.com.au (arnie.adacel.com.au [203.36.26.147]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id WAA25567 for ; Tue, 23 Jan 2001 22:08:07 -0800 (PST)
Received: (qmail 6243 invoked from network); 24 Jan 2001 06:14:17 -0000
Received: from unknown (HELO osmium) (203.8.85.176) by arnie.adacel.com.au with SMTP; 24 Jan 2001 06:14:17 -0000
Reply-To:
From: "Steven Legg"
To: "'Tom Gindin'"
Cc:
Subject: RE: Certificate Matching was:RE: Basic Cert-2-Directory mapping question
Date: Wed, 24 Jan 2001 17:15:15 +1100
Message-ID: <[email-masked]>
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 8.5, Build 4.71.2377.0
In-Reply-To:
Importance: Normal
X-Mimeole: Produced By Microsoft MimeOLE V4.72.2120.0

Tom,

> -----Original Message-----
> From: Tom Gindin [mailto:[email-masked]]
> Sent: Friday, 19 January 2001 15:16
> To: [email-masked]
> Cc: [email-masked]
> Subject: Re: Certificate Matching was:RE: Basic
> Cert-2-Directory mapping
> question
>
>
>
> Responses below. I'm not against having a general
> component filter
> matching rule, but I do want some shortcuts for common cases.
> Users are
> supposed to be able to formulate LDAP queries by hand, after all, and
> something as simple as "find certificates with the following e-mail
> address" shouldn't require a 6 line query.

We should make it clear who we think the "users" are. I assume that the
users
are programmers creating PKI-enabled applications. They would be using an
LDAP
API to access the certificate repository. Such folks should be able to
contend
with a six line query template. I don't think the users are the PKI
application
users. The user interfaces should protect these folks from ever having to
enter
an LDAP query by hand.

>
> Tom Gindin
>
> "Steven Legg" on 01/18/2001 07:11:24 PM
>
> Please respond to
>
> To: Tom Gindin/Watson/IBM@IBMUS
> cc:
> Subject: Certificate Matching was:RE: Basic Cert-2-Directory mapping
> question
>
>
>
>
> Tom,
>
> > -----Original Message-----
> > From: Tom Gindin [mailto:[email-masked]]
> > Sent: Tuesday, 16 January 2001 15:30
> > To: [email-masked]
> > Cc: 'Stephen Kent'; [email-masked]
> > Subject: RE: Basic Cert-2-Directory mapping question
> >
> >
> >
> > The technique you documented has some effects equivalent to the
> > alternative 1 I proposed,
>
> But also what I think are important differences. For a start, the use
> of surrogate attributes to search for certificates throws
> responsibility
> for managing the relationship between the surrogates and the
> certificate
> onto the directory clients. It isn't necessarily the case that the
> authority responsible for managing values of the surrogate attribute
> (e.g. email addresses) is the same as the authority that manages
> certificates.
> The different authorities could end up stepping on each
> other's toes, and
> access control policies could get in the way of any one
> authority managing
> the relationship.
>
> It isn't always appropriate that the value of the surrogate attribute
> matches the value of the corresponding field in the certificate.
> Maybe the certificate is valid but uses a superseded value for the
> surrogate attribute (maybe the user has changed ISPs and is
> waiting for
> an updated certificate). Maybe the certificate is in a secondary
> repository that doesn't/can't hold the surrogate attributes (a partial
> replica perhaps). Maybe the certificate is being stored in an entry
> other than the certificate owner's nominal entry. Not requiring there
> to be a relationship between the fields of a certificate and the other
> attributes in an entry gives us more flexibility in how and where to
> store certificates in a directory.
>
> [Tom Gindin] In theory, if one of the values of
> SubjectAltName has been
> superseded, the certificate should be revoked. It might well be
> appropriate to define a separate multi-valued attribute with
> a name like
> "CertificateEMailAddresses" to hold these values, and in that case the
> value goes in the same entry as the cert irrespective of certificate
> ownership.

I did think of this, but this is getting into what Michael termed a
"new technical mechanism". If a new mechanism is going to be used then
shouldn't it be the one that better fits the requirement and also
puts most of the implementation effort into the small number of server
implementations rather than the larger number of client implementations ?

> Using surrogate search attributes to support searching on certificates
> also doesn't help to isolate one of a number of certificates stored in
> the same entry. A matching rule that directly matches a component
> in a certificate can be combined with the valuesReturnFilter control
> so that the directory server only returns the certificate
> that matches.
> With surrogate search attributes the client will get back all
> certificates in the entry and have to filter them itself to find
> which is the one it actually wants.
>
> [Tom Gindin] You're right that it doesn't isolate a single
> cert. It does
> cut down the search space from a whole directory to a single entry,
> however.

There's a second problem with the surrogate search attributes when
searching on more than one at a time. A search for X AND Y returns
the entries that contain a certificate with X and a certificate with Y,
but not necessarily a certificate with both X and Y, so the client
will have to filter out the spurious entries as well as the spurious
certificates in entries.

>
> > although with a syntax which requires
> > considerable knowledge of ASN.1 to formulate an LDAP query
>
> I recognize that the need to understand ASN.1 in order to formulate a
> query is an obstacle to acceptance. To get around that I
> propose adding
> component matching templates to the LDAP/PKI profile for the set of
> matching abilities that are regarded as most important and/or
> most useful.
>
> For example, a section on searching on certificates by the
> email address
> subjectAltName extension would present the following template.
>
> (userCertificate:componentFilterMatch:=item:{
> component "toBeSigned.extensions.*",
> rule componentFilterMatch,
> value and:{
> item:{ component "extnId",
> rule objectIdentifierMatch, value 2.5.29.17 },
> item:{ component "extnValue.content.*.rfc822Name",
> rule caseIgnoreMatch, value "EMAIL-ADDRESS" } } } )
>
> A user doesn't need to know any ASN.1 to form a query. They just copy
> the template and substitute EMAIL-ADDRESS with the name of interest
> (e.g. [email-masked]). There would also be a bit of ABNF
> to describe the syntax of the different blanks to fill in in
> the templates
> but that would be required no matter what approach is taken for the
> LDAP/PKI profiles.
>
> [Tom Gindin] They need to have the exact ASN.1 layout of the
> certificate.
> They also appear to need to know the matching rule names in
> considerable
> detail.

We seem to be on different wavelengths. The above template basically
boils down to:

constant-string-one EMAIL-ADDRESS constant-string-two

The unsophisticated user needs to know how to format an email address
and how to copy a string of characters verbatim. No knowledge of the
Certificate ASN.1 type or of matching rules is required, given
sufficiently clear instructions on how to use the template.

> More sophisticated users can read up on the component matching rules
> and try things not covered by the examples, something that wouldn't
> be possible with ad-hoc specific definitions.

[snip]

> > and with no
> > ability to index on the component field (as opposed to
> > searching on it).
>
> Why do you assume that component fields can't be effectively indexed ?
> I've been implementing the component matching rules as a
> background job
> and lately I've been working on the indexing support. There's a
> variety of approaches, with different space/time characteristics,
> but I've found indexing support for component matching to be
> eminently do-able.
>
> [Tom Gindin] It's possible to create an index out of a
> component value, but
> isn't that more invasive to the implementation of a directory or LDAP
> server than defining a simplified search syntax for those components?

The component matching rules are a generalization of what is already
going on. Effective support for the objectIdentifierFirstComponentMatch
and other *FirstComponentMatch rules means building indexes on a component
of an attribute value. Some of the matching rules defined in the latest
edition of X.509 (e.g. certificateMatch) are "and" component filter
matching rules in disguise. The simplified search syntaxes are only
easier to deal with (with regard to index support) if they don't involve
a conjunction of user supplied component assertion values.

> Also, how does the user control whether the directory indexes on
> SubjectAltName, which is a privacy issue? In my proposal,
> the decision on
> indexing is sent to the CA and RA on a per-user basis (inside CRMF's
> publication control).

This is an access control issue rather than a matching/indexing issue.
Note that the current crop of matching rules in X.509 are already thwarting
a user's ability to prevent searching on particular components
of their certificates. Also, users can't currently control whether a
directory indexes on their simple attributes (e.g. telephoneNumber).

> > This does not mean that I disapprove of the idea of component
> > filtering in
> > LDAP searches, which IMHO will solve a number of important problems.
> > However, in view of the very high proportion of ASN.1 usage within
> > directory attributes actually accounted for by the small number of
> > PKI-based data structures, wouldn't it be reasonable to
> define a search
> > syntax for them which uses keywords to identify fields,
> > rather than the
> > generic ASN.1 facility you proposed?
>
> The problem with defining a specific assertion syntax with assigned
> keywords is that it defines the limits of what matching can
> be performed.
> If there isn't a syntax/keyword for what you want to do you
> have to wait
> until a suitable syntax/keyword is assigned by some standard, if ever.
> A generic facility doesn't have this problem. The component
> references,
> though verbose, are uniform, unambiguous and work for any ASN.1 type
> definition.
>
> [Tom Gindin] A generic facility is desirable as a fallback.
> I do not think
> it is desirable as the normal way to get subfields of
> SubjectAltName or
> KeyUsage, however.

The reason why I'm pushing back on providing short cuts is because it
removes any incentive for server vendors to build in any of the generic
facilities (for matching, or anything else). Defining a bunch of short cuts
is effectively what is happening now, with a growing list of special case
matching rules being defined, each of which has to be separately
implemented.

However, I don't consider your desire for a simpler syntax for commonly used
matches to be unreasonable. If there are to be short cuts then I would
like them to be designed such that it is possible to create a machine
readable description of the relationship of the short cut to the generic
component matching capability. For users, the short cuts can be described
in typical fashion as though they are special case matching rules. Simple
server implementations might support the short cuts directly in this way.
The
advanced server implementations would support the component matching rules,
and the short cut matching rules just become a matter of configuration
rather
than individual hard-coding. Advanced users (of advanced servers) can use
the
component matching rules directly, or configure their own shortcut matching
rules. Adding a layer of short cut matching rules over the component
matching rules makes the server implementation more complex than I would
like, but
makes things easier for the users.

I'll have a think about a formal framework for describing short cut matching
rules on top of component matching rules.

[snip]

> Such simplifications aren't so important if most users are
> just filling
> in the blanks in a template, although it might make it possible to
> reduce the number of templates. For example, one template
> might suffice
> for all subjectAltName cases.
>
> (userCertificate:componentFilterMatch:=item:{
> component "toBeSigned.extensions.*",
> rule componentFilterMatch,
> value and:{
> item:{ component "extnId", value 2.5.29.17 },
> item:{ component "extnValue.content.*.ALT-NAME-TYPE",
> value ALT-NAME-VALUE } } } )
>
> [Tom Gindin] That won't be very helpful for the compound
> types, nor for
> OTHER-NAME. However, it would give you a match for 5 of the
> 8 base types
> in GeneralName.

The default matching rule for compound types could be
directoryComponentsMatch,
which is basically a component-wise equality match. The ALT-NAME-VALUE would
be an LDAP string encoding of a value of the compound type. OTHER-NAME would
be treated as the equivalent SEQUENCE type (i.e. a compound type).

Regards,
Steven

Received: from mailhub.ways.com ([203.129.237.10]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id UAA21620 for ; Tue, 23 Jan 2001 20:04:14 -0800 (PST)
From: [email-masked]
Received: from kmtops ([203.197.250.20]) by mailhub.ways.com (8.9.3/8.8.7) with SMTP id JAA20745 for ; Wed, 24 Jan 2001 09:32:42 +0500
Reply-To:
To:
Subject: unsubscribe
Date: Wed, 24 Jan 2001 09:35:07 +0530
Message-ID:
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

krishnan mani
+91-22-9821339816
Ways India Limited

Received: from mailweb15.rediffmail.com (IDENT:qmailr@[203.199.83.23]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id TAA20369 for ; Tue, 23 Jan 2001 19:13:21 -0800 (PST)
Received: (qmail 20647 invoked by uid 510); 24 Jan 2001 03:12:17 -0000
Date: 24 Jan 2001 03:12:17 -0000
Message-ID: <[email-masked]>
Received: from unknown (164.164.6.31) by rediffmail.com via HTTP; 24 Jan 2001 03:12:17 -0000
MIME-Version: 1.0
To: "[email-masked]"
From: "rb krishna"
Content-ID:
Content-type: text/plain
Content-Description: Body
Content-Transfer-Encoding: 7bit

unsubscribe

_____________________________________________________
Chat with your friends as soon as they come online. Get Rediff Bol at
http://bol.rediff.com

Received: from prv-mail20.provo.novell.com (prv-mail20.provo.novell.com [137.65.81.122]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id SAA19654 for ; Tue, 23 Jan 2001 18:51:38 -0800 (PST)
Received: from INET-PRV-Message_Server by prv-mail20.provo.novell.com with Novell_GroupWise; Tue, 23 Jan 2001 14:09:47 -0700
Message-Id:
X-Mailer: Novell GroupWise Internet Agent 5.5.5.1
Date: Tue, 23 Jan 2001 14:09:41 -0700
From: "Bob Jueneman"
To:
Cc:
Subject: RE: DVD & DVP requirements
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id SAA19655

Steve, I didn't intend to "advertise," nor was I in any shape or form
advocating that the WG endorse or even consider the proprietary
attributes I was discussing. They were only provided as a reference.

You asked for an example of parameters a client could change
between invocations of a DPD server, where multiple invocations
would provide distinct, useful answers.

I think that the examples I provided do exactly that. You may or may
not like those examples, you may prefer to use other mechanisms
such as Policy OIDs, name subordination, or other techniques
(although I believe we might differ as to their utility in a general context),
and that's all fine and good.

All I was attempting to provide were EXAMPLES, per your request,
not necessarily a proposed change to the standard, etc.

Bob

Robert R. Jueneman
Security Architect

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

>>> Stephen Kent 01/23/01 10:33AM >>>
Bob,

>Steve, you said in part:
>>
>>I'd like to better understand what parameters the client will change
>>between invocations of a DPD server, in a controlled fashion, to make
>>multiple invocations for the same target certificate provide
>>distinct, useful, answers. Do you have some examples that could
>>clarify this scenario?
>>
>>Steve
>
>Let me give you a possible "existence proof " of such a scenario.
>
>There's an old joke about a Vermonter, who when asked, "How's
>your wife?" replied "Compared to what?"
>
>When we have said in this context, "Is this certificate chain valid?",
>we should really be asking "Can I trust this certificate chain?"
>and the only reasonable answer to that question is to say
>"compared to what?" or more precisely, "Trust it for what purpose?"

A DPV client specifies a set of parameters for controlling an
objective, deterministic process that we call certificate validation.
I think the word "trust" has no place in this process. At best,
since the client selects the parameters relative to an intended use
for the key in the cert, you might choose to say that the client
chooses these parameters based on its perception of what it needs to
trust the key for, but those would be your words, not mine.

>In other words, trust, like integrity, is not some binary value that is
>independent of any predicate. Instead, something, either a process
>or the data that was produced as a result of some process, is "trusted"
>if and only if the process conforms to a specified set of rules or
>expectations. It is clearly not possible for a process to be tested
>against all possible rules in the universe, so without qualifying the
>trust to a particular set of rules, the question is meaningless.

Validation is trinary here: yes, no, don't know.

>Now, the reason why a client or relying party might ask the server t
>hat question is obviously a function of the client's current context, i.e.,
>the type of transaction or whatever that is being evaluated.

Which is why it makes sense to keep this aspect of the decision to
use a cert for a given application a local matter, outside the scope
of this standard.

>And clearly, that context may vary, depending on the perceived value
>of the transaction, the history of that transaction and previous
>transactions with that signer, etc.

see comment immediately above.

>If the client is trying to decide whether to honor a purchase order
>for a single quart of 10-40 motor oil, the risk analysis for such a
>transaction would probably suggest that the probability of default
>is low, and that continued customer good will is worth more than
>that risk. In that case, maybe it isn't even worth the bother of
>consulting the server, except perhaps for auditing or logging
>purposes.
>
>On the other hand, if that very same client is evaluating a purchase
>order for one hundred million barrels of crude oil, to be delivered
>via multiple oil tankers FOB Saudi Arabia, then the risk analysis
>would suggest that the buyer's credentials had better be
>gilt-edged indeed.
>
>As to how the parameters would be conveyed, a very simple,
>existence-proof mechanism would be to simply encode the value
>of the transaction in dollars, and let the server try do its thing.
>maybe it has some artificial intelligence program that parses the
>Certificate Practice Statement and does a risk assessment.
>Or maybe it simply looks up the net worth of the buyer and the
>CA in Dun and Bradstreet and decides accordingly.

Since not all transactions are best characterized by monetary value,
this is not my idea of a good example. It also shifts the burden to
the server in a fashion that makes it impossible to test if a server
is operating properly. So, no, this is not a good idea.

>Of course, since I have a hammer and this looks like a nail,
>I would suggest that a better mechanism would be to use
>the Novell Security Attributes (cf.
>http://developer/novell.com/repository/attributes/certattrs_v10.htm),
>and to have the client either encode a minimum set of those
>attributes for this particular transaction. Or more likely,
>the client would be preconfigured with a set of attributes
>labeled platinum, gold, silver, bronze, green and brown,
>and would select one of those for certain kinds of transactions,

Bob, we frown on advertisements on this list. You know better.

>
>
>In either case, the client can ask the question, "Is this certificate
>chain trustworthy with respect to my "Platinum" criteria?" and get one
>answer, and later ask the same question with respect to exactly the
>same certificate chain, but specifying the "Green" criteria, and perhaps
>get a different answer.

We support this via reference to different policies configured on the
server, but only to the extent that the policies make use of standard
cert attribute validation parameters. To do what you propose would
require adding support for private extensions at the server and
perhaps in client requests. This could be done if the WG wants, but
it would be a supplement to the mandatory, 2459bis validation
criteria.

Steve

Received: from ext-mail.valicert.com (ns1.valicert.com [63.65.221.10]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id RAA18061 for ; Tue, 23 Jan 2001 17:42:46 -0800 (PST)
Received: from CONVERSION-DAEMON by ext-mail.valicert.com (PMDF V5.2-33 #46613) id <[email-masked]> for [email-masked]; Tue, 23 Jan 2001 17:48:40 -0800 (PST)
Received: from polaris.valicert.com ([192.168.2.34]) by ext-mail.valicert.com (PMDF V5.2-33 #46613) with ESMTP id <[email-masked]>; Tue, 23 Jan 2001 17:48:39 -0800 (PST)
Received: by exchange.valicert.com with Internet Mail Service (5.5.2650.21) id ; Tue, 23 Jan 2001 17:44:10 -0800
Content-return: allowed
Date: Tue, 23 Jan 2001 17:44:09 -0800
From: Peter Williams
Subject: RE: DPD & DPV requirements - to nonce or not to nonce?
To: "'Stephen Kent'"
Cc: [email-masked]
Message-id: <[email-masked]>
MIME-version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-type: text/plain; charset="iso-8859-1"

Steve,

Thanks for your comments on the usual viewpoint about nonces. Let me restate
what the standard that we profile asserts about "signed request/signed
response"
authentication procedures. I separate each point, below, so that my comments
on
your requirements formulation are clear.

X.509 advises that the rA (non-repeating number) generated by a UA, used to
detect
replay attacks and prevent forgery, be used in the context of a tA, an
expiry date.

(tA, from X.511/518 is, semantically, the "expiry time for the validity of
the signature")

X.509 recommends that, it is reasonable for a party B (a server) to "store
the
sequential part (rA) together with a timestamp tA in the clear and together
with
the hashed part of the token, during time range tA."

The X.509 one-way AND two-way authentication procedures are a general case
of strong
authentication: there is nothing specific to use by the Directory. X.511/518
signed request/response PDUs are consistent with the X.509 recommendation,
and require servers supporting origin authentication of requests, to detect
client replay attacks to PREVENT forgery.

X.500 does not say what one should do, upon detection.... (I chose to return
the
official security error code of "Signature invalid" in civilian deployments,
and
official security error code "no-information" in the military
configuration.)

Should we not follow the recommendation of X.509, when formulating
the nonce/time elements of the strong authentication requirements,
for our request/response/chained-response chain-validation protocol?

Are the user's authentication requirements different to X.509? Do we wish to
accomplish more, or less, than "detect replay attacks and prevent forgery?"
by
exploiting strong authentication, for example?

If we wish to achieve the same objectives as specified for the strong
authentication
service in X.509, then surely we would have servers detect client nonce
replay within
the validity window of the signature of the request token. We would
similarly act
at the UA, for server nonce and response token.

To do all this, one would need some kind of data store (e.g. hash tree) at
the
server in order to to be in compliance with the standard strong
authentication
procedures, and thereby act "reasonably", as defined by X.509.

I hope you recognise my reasoning is nothing other than a restatement of or
or description of an implementation of, what X.509 drafts have recommended
to
us since about 1986.

Finally,

Does IETF have actual notice of timestamping patents that claim
rights on a strong authentication-using server maintaining a store of
anti-replay information? (The ITU disclosure database
(http://www.itu.int/ITU-T/patent/files/13122000.pdf)
contains no notices, after 15 years, for X.509 other
than the Entrust '431 disclosure.)

Peter.

-----Original Message-----
From: Stephen Kent [mailto:[email-masked]]
Sent: Tuesday, January 23, 2001 3:29 PM
To: Peter Williams
Cc: [email-masked]
Subject: RE: DPD & DPV requirements - to nonce or not to nonce?

At 11:52 AM -0800 1/22/01, Peter Williams wrote:
Steve,
Thank you for your memo.
Let me summarize a requirement of your protocol design that seems to derive
from
your comments:
IETF-standardized validation servers MUST respond normally, when in
conforming mode, to a request that
repeats an anti-replay, nonce value.

Nonces are usually viewed as mechanisms employed by a client to detect
replays of responses. What you cite is a mechanism for a server to detect
and reject replays from a client, which is obviously quite different. (Maybe
it's just me, but I could not figure out what you were referring to in your
previous, cryptic message that you cite below.) It is contrary to many
server design notions, in that it requires maintaining state for each
client, to detect and reject reused nonces. Also, the client and server
might employ a lower layer protocol that would deal with this problem,
securely, obviating the need for such measures. But you do raise an
interesting point.

So, in response to the question above, no, a server would not be required to
respond to a replayed request, nor would it be required to detect and reject
such a response. Unless we impose constraints on clients in their generation
of nonces, something that many protocols do not do, then a sender might
repeat a nonce due to inadequate, local PRNG capability. This would subject
the client to a replay attack, which we would like to prevent. However, do
we want to reject the request and deny the client service? Maybe that's a
good way to bring the error the the attention of the client.

Steve

Peter.
-----Original Message-----
From: Stephen Kent [mailto:[email-masked]]
Sent: Monday, January 15, 2001 7:41 PM
To: Peter Williams
Cc: [email-masked]
Subject: RE: DPD & DPV requirements - to nonce or not to nonce?

Peter,

[Peter Williams]

Not sure I see the need for the nonce hash tree you described, though it is
a clever approach, but it also might run afoul of the time stamp patents of
some folks.

[Peter Williams]

Steve

Received: from po1.bbn.com (PO1.BBN.COM [192.1.50.38]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA15277 for ; Tue, 23 Jan 2001 15:31:57 -0800 (PST)
Received: from [128.33.238.54] (TC055.BBN.COM [128.33.238.55]) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id SAA27815; Tue, 23 Jan 2001 18:37:09 -0500 (EST)
Mime-Version: 1.0
X-Sender: [email-masked]
Message-Id:
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Date: Tue, 23 Jan 2001 18:32:38 -0500
To: Denis Pinkas
From: Stephen Kent
Subject: Re: DPD & DPV requirements
Cc: PKIX-List
Content-Type: text/plain; charset="us-ascii" ; format="flowed"

At 10:16 AM +0100 1/23/01, Denis Pinkas wrote:

>
> >
> > No. I want the path to be valid, and if the server can't provide the
> > revocation status info, then it does not know if the path is valid.
>
>We have a slight disagreement here. You accepted the goal which is: "Obtain
>one or more certification paths and optionally its associated revocation
>information for a leaf certificate according either to a validation policy
>or a trust anchor.". In that sentence, the word "valid" does not exist. In
>other words, DPD only *helps* a PKI-aware client to know whether a
>certificate is valid. It is better to return what can be returned as far a
>revocation information is concerned rather than nothing. You also noticed
>that a client may only request the certification path, without the
>revocation information.

My oversight. I still want DPD paths to be valid.

Steve

Received: from po1.bbn.com (PO1.BBN.COM [192.1.50.38]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA14934 for ; Tue, 23 Jan 2001 15:22:06 -0800 (PST)
Received: from [128.33.238.54] (TC055.BBN.COM [128.33.238.55]) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id SAA27146; Tue, 23 Jan 2001 18:28:08 -0500 (EST)
Mime-Version: 1.0
X-Sender: [email-masked] (Unverified)
Message-Id:
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Date: Tue, 23 Jan 2001 18:28:58 -0500
To: Peter Williams
From: Stephen Kent
Subject: RE: DPD & DPV requirements - to nonce or not to nonce?
Cc: [email-masked]
Content-Type: multipart/alternative; boundary="============_-1231829947==_ma============"

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

At 11:52 AM -0800 1/22/01, Peter Williams wrote:
>Steve,
>
>Thank you for your memo.
>
>Let me summarize a requirement of your protocol design that seems to
>derive from
>your comments:
>
>IETF-standardized validation servers MUST respond normally, when in
>conforming mode, to a request that
>repeats an anti-replay, nonce value.
>

Nonces are usually viewed as mechanisms employed by a client to
detect replays of responses. What you cite is a mechanism for a
server to detect and reject replays from a client, which is obviously
quite different. (Maybe it's just me, but I could not figure out what
you were referring to in your previous, cryptic message that you cite
below.) It is contrary to many server design notions, in that it
requires maintaining state for each client, to detect and reject
reused nonces. Also, the client and server might employ a lower
layer protocol that would deal with this problem, securely, obviating
the need for such measures. But you do raise an interesting point.

So, in response to the question above, no, a server would not be
required to respond to a replayed request, nor would it be required
to detect and reject such a response. Unless we impose constraints
on clients in their generation of nonces, something that many
protocols do not do, then a sender might repeat a nonce due to
inadequate, local PRNG capability. This would subject the client to a
replay attack, which we would like to prevent. However, do we want to
reject the request and deny the client service? Maybe that's a good
way to bring the error the the attention of the client.

Steve

>Peter.
>
>-----Original Message-----
>From: Stephen Kent [mailto:[email-masked]]
>Sent: Monday, January 15, 2001 7:41 PM
>To: Peter Williams
>Cc: [email-masked]
>Subject: RE: DPD & DPV requirements - to nonce or not to nonce?
>
>Peter,
>
>[Peter Williams]
>
>Not sure I see the need for the nonce hash tree you described,
>though it is a clever approach, but it also might run afoul of the
>time stamp patents of some folks.
>
>[Peter Williams]
>
>Steve

--============_-1231829947==_ma============
Content-Type: text/enriched; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

At 11:52 AM -0800 1/22/01, Peter Williams wrote:

Arial0000,0000,FFFFSteve,

=20

Thank you for your memo.

=20

Let me summarize a requirement of your protocol design that seems to
derive from

your comments:

=20

IETF-standardized validation servers MUST respond normally, when in
conforming mode, to a request that

repeats an anti-replay, nonce value.=20

=20

Arial0000,0000,FFFF

Nonces are usually viewed as mechanisms employed
by a client to detect replays of responses. What you cite is a
mechanism for a server to detect and reject replays from a client,
which is obviously quite different. (Maybe it's just me, but I could
not figure out what you were referring to in your previous, cryptic
message that you cite below.) It is contrary to many server design
notions, in that it requires maintaining state for each client, to
detect and reject reused nonces. Also, the client and server might
employ a lower layer protocol that would deal with this problem,
securely, obviating the need for such measures. But you do raise an
interesting point.

So, in response to the question above, no, a
server would not be required to respond to a replayed request,
nor would it be required to detect and reject
such a response. Unless we impose constraints on clients in their
generation of nonces, something that many protocols do not do, then a
sender might repeat a nonce due to inadequate, local PRNG capability.
This would subject the client to a replay attack, which we would like
to prevent. However, do we want to reject the request and deny the
client service? Maybe that's a good way to bring the error the the
attention of the client.

Steve

Arial0000,0000,FFFFPeter.

=20

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

From: Stephen Kent [mailto:[email-masked]]

Sent: Monday, January 15, 2001 7:41 PM

To: Peter Williams

Cc: [email-masked]

Subject: RE: DPD & DPV requirements - to nonce or not to
nonce?

right,leftPeter,

Arial0000,0000,FFFF[Peter
Williams] =20

Not sure I see the need for the nonce hash tree
you described, though it is a clever approach, but it also might run
afoul of the time stamp patents of some folks.

Arial0000,0000,FFFF[Peter
Williams] =20

Steve

--============_-1231829947==_ma============--

Received: from tpamail2.bdi.gte.com (tpamail2.bdi.gte.com [192.76.82.136]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA10344 for ; Tue, 23 Jan 2001 12:17:01 -0800 (PST)
From: [email-masked]
Received: from smtptpa.interwan.gte.com ([138.83.66.45]) by tpamail2.bdi.gte.com (8.9.3/8.9.3) with ESMTP id PAA01715 for ; Tue, 23 Jan 2001 15:22:21 -0500 (EST)
Received: from smtptpa.interwan.gte.com (localhost [127.0.0.1]) by smtptpa.interwan.gte.com (8.9.3/8.9.3) with ESMTP id PAA11521 for ; Tue, 23 Jan 2001 15:22:17 -0500 (EST)
Received: from imr01.bellatlantic.com (bagate.verizon.com [141.152.156.12]) by smtptpa.interwan.gte.com (8.9.3/8.9.3) with ESMTP id PAA11422 for ; Tue, 23 Jan 2001 15:22:12 -0500 (EST)
Received: from fhsmtp03.bell-atl.com (is051952.bellatlantic.com [151.203.130.8]) by imr01.bellatlantic.com (8.8.8/8.8.5) with ESMTP id PAA14527 for ; Tue, 23 Jan 2001 15:22:08 -0500 (EST)
Subject: unsuscribe
To: [email-masked]
Date: Tue, 23 Jan 2001 15:22:02 -0500
Message-ID:
X-MIMETrack: Serialize by Router on FHSMTP03/SMTP/Bell-Atl(Release 5.0.5 |September 22, 2000) at 01/23/2001 03:22:08 PM
MIME-Version: 1.0

Received: from mail.spyrus.com (mail.spyrus.com [207.212.34.20]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA09331 for ; Tue, 23 Jan 2001 11:48:46 -0800 (PST)
Received: from RHOUSLEY-PC.spyrus.com ([209.172.119.210]) by mail.spyrus.com (8.9.3/8.9.3) with ESMTP id LAA12263; Tue, 23 Jan 2001 11:53:50 -0800 (PST)
Message-Id: <[email-masked]>
X-Sender: [email-masked]
X-Mailer: QUALCOMM Windows Eudora Version 5.0.2
Date: Tue, 23 Jan 2001 13:57:58 -0500
To: Denis Pinkas
From: Russ Housley
Subject: Re: Post-facto queries [Was: RE: DPD & DPV requirements]
Cc: PKIX-List
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed

Denis:

Let me try again.

What evidence are you referring to? I assume that the relying party
validated the path (using current-time DPV, OCSP, or CRLs). Then, later, a
dispute arises. A third party (arbitrator, judge, lawyer doing discover,
etc) uses retrospective DPV to confirm that the replying party did the
processing correctly. Here, I a trusting the DPV server to be able to
reconstruct the response that would have been given at the date and time
specified in the query.

What does time stamping have to do with it? (That could become a catchy
song title. :-) )

Russ

At 04:48 PM 1/23/2001 +0100, Denis Pinkas wrote:
>[Denis]
>
>The additional problem to be considered is that the structure of the answer
>in case (a) would be different from the answer in the case of a current-time
>checking, since one structure would include individual time stamps while the
>other would not.
>
>[Russ]
>
>Why does the DPV need a 3rd party time stamp on the CRLs? It can keep
>track using its own clock as long as it has a trusted time source. The
>STIME working group is going to provide a straightforward mechanism for
>that...
>
>[Denis * new answer]
>
>If you use the evidence, it is because you do not trust the "valid" answer
>form the server (otherwise, you would not need the evidence). Hence you
>would not trust either the clock from the server.

Received: from edelweb.fr (edelweb.fr [212.234.46.16]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA07162 for ; Tue, 23 Jan 2001 11:13:54 -0800 (PST)
Received: from champagne.edelweb.fr (localhost.edelweb.fr [127.0.0.1]) by edelweb.fr with ESMTP id UAA14479; Tue, 23 Jan 2001 20:19:59 +0100 (MET)
Received: from champagne.edelweb.fr (champagne.edelweb.fr [193.51.14.161]) by edelweb.fr (nospam/1.3); Tue, 23 Jan 2001 20:19:59 +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 UAA17709; Tue, 23 Jan 2001 20:19:57 +0100 (MET)
From: Peter Sylvester
Received: (sylvest@localhost) by emeriau.edelweb.fr (8.7.6/8.6.6) id UAA22495; Tue, 23 Jan 2001 20:19:57 +0100 (MET)
Date: Tue, 23 Jan 2001 20:19:57 +0100 (MET)
Message-Id: <[email-masked]>
To: [email-masked], [email-masked]
Subject: Re: Post-facto queries [Was: RE: DPD & DPV requirements]
Cc: [email-masked]

> > I suppose the client might believe that the DPV server was honest,
> > but not a very good timekeeper. Seems a stretch though....
>
> Not exactly. See above.

If all relying parties agree that the time that is used by the
DPV servers is a good one, then this a good one. It seems part
of a policy to decide whether a DPV response can just use some
'local time' or an external time stamp.

This is an organisational issue.

A DPV server should not be restricted to use an external time
stamp. Well, the asn1 format can still be the same, the
time stamp is just signed with a different key/cert, but
having TWO signatures seems some overhead to me.

Received: from e2.ny.us.ibm.com (e2.ny.us.ibm.com [32.97.182.102]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA07113 for ; Tue, 23 Jan 2001 11:12:51 -0800 (PST)
Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.117.200.22]) by e2.ny.us.ibm.com (8.9.3/8.9.3) with ESMTP id OAA126918; Tue, 23 Jan 2001 14:17:33 -0500
Received: from d02ml237.somers.hqregion.ibm.com (d02ml237.sby.ibm.com [9.45.4.171]) by northrelay02.pok.ibm.com (8.8.8m3/NCO v4.95) with ESMTP id OAA89392; Tue, 23 Jan 2001 14:15:25 -0500
Importance: Normal
Subject: RE: Post-facto queries [Was: RE: DPD & DPV requirements]
To: "Covey, Carlin"
Cc:
X-Mailer: Lotus Notes Release 5.0.3 (Intl) 21 March 2000
Message-ID:
From: "Tom Gindin"
Date: Tue, 23 Jan 2001 14:18:12 -0500
X-MIMETrack: Serialize by Router on D02ML237/02/M/IBM(Release 5.0.6 |December 14, 2000) at 01/23/2001 02:18:28 PM
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii

The example I was giving works in two cases: first if the CA has
separate CRL and certificate signing keys, second if the original signature
package (including the certificate) is time-stamped at time of origination
and pyramided in the same way as the CRL I described.

Tom Gindin

"Covey, Carlin" on 01/23/2001 01:27:16 PM

To: Tom Gindin/Watson/IBM@IBMUS
cc:
Subject: RE: Post-facto queries [Was: RE: DPD & DPV requirements]

Thanks Tom, that helped a lot.

If the CA's signing key is compromised, then its signature over
CRL's is certainly suspect, modulo the timestamping you described
(or some other countersignature mechanism).

But if the CA's signing key is compromised then its signature over
certificates is also suspect. The bad guy in possession of the CA's
signing key could issue himself a back-dated certificate and sign any
back-dated document he wished. The fact that the CRL is timestamped,
and the CRL-plus-timestamp is again timestamped won't prevent this.
It seems to me that the document in question needs to be timestamped
at the time that it is signed by the originator. Timestamping the
CRL's helps some, but not enough.

Regards,

Carlin

-------------------------------------
- Carlin Covey
Cylink Corp.

-----Original Message-----
From: Tom Gindin [mailto:[email-masked]]
Sent: Tuesday, January 23, 2001 11:04 AM
To: Covey, Carlin
Cc: [email-masked]
Subject: RE: Post-facto queries [Was: RE: DPD & DPV requirements]

A back-dated time stamp is indeed worthless. If I remember Denis'
presentation at IETF 46 correctly, the main point of pyramiding time stamps
is to demonstrate that the message had the proper form at the proper time.
For example, suppose the following sequence of events, with the left column
indicating the relative month:

0: CRL issued with key CA1.
18: CRL time-stamped with key T0.
30: CA1 compromised.
36: Object from month 18 time-stamped with key T1.
45: T0 compromised.
48: Arbitrator asked to determine validity of CRL.

As long as the times of the compromises are clearly known to be after
the time-stamp by the next TSA in the pyramid, the CRL inside the object
from month 36 is still verifiable at month 48, even though its own key and
the first time-stamp's key are compromised.

Tom Gindin

"Covey, Carlin" on 01/23/2001 12:22:57 PM

To: PKIX-List
cc:
Subject: RE: Post-facto queries [Was: RE: DPD & DPV requirements]

Russ, I think Denis is saying that if the client trusts the DPV
server's good/bad response, why wouldn't it also trust the timestamp
that the DPV server put on the response (obviating the need for a
third-party timestamp). Denis, did I get that right?

I suppose the client might believe that the DPV server was honest,
but not a very good timekeeper. Seems a stretch though....

I have a question on an earlier email in this thread. Perhaps I
misinterpreted something. I'm puzzled why we would want timestamps
on individual CRLs in the case of post-facto validation of a certificate.
The CRL contains information that indicates its validity period.
Presumably if a timestamp were placed over the CRL later, the timestamp
would indicate the current time, not the validity time of the CRL.
(A timestamping server that back-dates timestamps doesn't seem very
trustworthy.) Why would I care whether the CRL for a certain week three
months ago now had today's timestamp on it? (I'm sure I must have missed
something in the discussion.)

Regards,

Carlin

-------------------------------------
- Carlin Covey
Cylink Corp.

-----Original Message-----
From: Denis Pinkas [mailto:[email-masked]]
Sent: Tuesday, January 23, 2001 10:04 AM
To: Russ Housley
Cc: PKIX-List
Subject: Re: Post-facto queries [Was: RE: DPD & DPV requirements]

Russ,

Your statement is too short so that I can understand what you do not
understand. :-)

Could you elaborate a little bit more, or maybe some one else could explain
better than I can.

Denis

> Denis:
>
> I do not understand your point.
>
> Russ
>
> At 04:48 PM 1/23/2001 +0100, Denis Pinkas wrote:
> >[Denis]
> >
> >The additional problem to be considered is that the structure of the
answer
> >in case (a) would be different from the answer in the case of a
current-time
> >checking, since one structure would include individual time stamps while
the
> >other would not.
> >
> >[Russ]
> >
> >Why does the DPV need a 3rd party time stamp on the CRLs? It can keep
> >track using its own clock as long as it has a trusted time source. The
> >STIME working group is going to provide a straightforward mechanism for
> >that...
> >
> >[Denis * new answer]
> >
> >If you use the evidence, it is because you do not trust the "valid"
answer
> >from the server (otherwise, you would not need the evidence). Hence you
> >would not trust either the clock from the server.

Received: from edelweb.fr (edelweb.fr [212.234.46.16]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA06399 for ; Tue, 23 Jan 2001 10:53:13 -0800 (PST)
Received: from champagne.edelweb.fr (localhost.edelweb.fr [127.0.0.1]) by edelweb.fr with ESMTP id TAA14338; Tue, 23 Jan 2001 19:59:12 +0100 (MET)
Received: from champagne.edelweb.fr (champagne.edelweb.fr [193.51.14.161]) by edelweb.fr (nospam/1.3); Tue, 23 Jan 2001 19:59:12 +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 TAA17581; Tue, 23 Jan 2001 19:59:11 +0100 (MET)
From: Peter Sylvester
Received: (sylvest@localhost) by emeriau.edelweb.fr (8.7.6/8.6.6) id TAA22486; Tue, 23 Jan 2001 19:59:10 +0100 (MET)
Date: Tue, 23 Jan 2001 19:59:10 +0100 (MET)
Message-Id: <[email-masked]>
To: [email-masked], [email-masked]
Subject: Re: DPD & DPV requirements
Cc: [email-masked]

>
> I do not think that we want client applications to issue cross-certificates
> as a means of building their certificate trust list. I guess that an
> implementor could do it that way, but it certainly should not be required.

It is not the DPV client, the relying party is delegated to the
DPV server.

>
> And, how would the subscriber get a certificate with the basic constraints
> of CA=TRUE?

I just make one, I am *THE* root:

What subscriber? The DPV server can just be its 'own' CA, i.e., there the
configuration management for a DPV server can consist of not giving a
list of trusted roots, but install one fixed DPV-TRUST-CA cert, and the
operator of that CA issues cross certs.

The path validation algorithm in X.509 starts with an empty naming constraint list.
Why should one add more?

Regards
Peter

Received: from exchange.cylink.com (exchange.cylink.com [192.43.161.25]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA05345 for ; Tue, 23 Jan 2001 10:32:37 -0800 (PST)
Received: by exchange.cylink.com with Internet Mail Service (5.5.2650.21) id ; Tue, 23 Jan 2001 10:38:15 -0800
Message-ID: <[email-masked]>
From: "Covey, Carlin"
To: PKIX-List
Subject: RE: Post-facto queries [Was: RE: DPD & DPV requirements]
Date: Tue, 23 Jan 2001 10:38:12 -0800
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"

Thanks Tom, that helped a lot.

If the CA's signing key is compromised, then its signature over
CRL's is certainly suspect, modulo the timestamping you described
(or some other countersignature mechanism).

But if the CA's signing key is compromised then its signature over
certificates is also suspect. The bad guy in possession of the CA's
signing key could issue himself a back-dated certificate and sign any
back-dated document he wished. The fact that the CRL is timestamped,
and the CRL-plus-timestamp is again timestamped won't prevent this.
It seems to me that the document in question needs to be timestamped
at the time that it is signed by the originator. Timestamping the
CRL's helps some, but not enough.

Regards,

Carlin

-------------------------------------
- Carlin Covey
Cylink Corp.

-----Original Message-----
From: Tom Gindin [mailto:[email-masked]]
Sent: Tuesday, January 23, 2001 10:56 AM
To: Denis Pinkas
Cc: Russ Housley; PKIX-List
Subject: Re: Post-facto queries [Was: RE: DPD & DPV requirements]

Denis:

Is your primary objection to post-facto queries that they pose a
temptation to NR relying parties to avoid archiving contemporary
verification information? If we look at the actual verifications performed
in NR, I think that you and I are in agreement that to have the RP keep the
(signed) revocation data supporting his initial determination is more
robust than to have the RP rely on the subsequent verifier acquiring the
revocation data through a post-facto query. IMO this is not a reason why
post-facto queries would be useless in all cases, however - an auditor
attempting to find whether a strong login had occurred before a revocation
or after it (in a case where CRL publication is typically delayed) would
find them useful.
These queries have their place when there is no better alternative,
but I think NR RP's are better off not relying on them. If such an RP (or
the escrow holder for 2-way NR in my draft) maintains contemporary
revocation information, it cannot be affected by the CA ceasing operations
or failing to maintain archives.

Tom Gindin

Denis Pinkas on 01/23/2001 12:04:14 PM

To: Russ Housley
cc: PKIX-List
Subject: Re: Post-facto queries [Was: RE: DPD & DPV requirements]

Russ,

Your statement is too short so that I can understand what you do not
understand. :-)

Could you elaborate a little bit more, or maybe some one else could explain
better than I can.

Denis

> Denis:
>
> I do not understand your point.
>
> Russ
>
> At 04:48 PM 1/23/2001 +0100, Denis Pinkas wrote:
> >[Denis]
> >
> >The additional problem to be considered is that the structure of the
answer
> >in case (a) would be different from the answer in the case of a
current-time
> >checking, since one structure would include individual time stamps while
the
> >other would not.
> >
> >[Russ]
> >
> >Why does the DPV need a 3rd party time stamp on the CRLs? It can keep
> >track using its own clock as long as it has a trusted time source. The
> >STIME working group is going to provide a straightforward mechanism for
> >that...
> >
> >[Denis * new answer]
> >
> >If you use the evidence, it is because you do not trust the "valid"
answer
> >from the server (otherwise, you would not need the evidence). Hence you
> >would not trust either the clock from the server.

Received: from e2.ny.us.ibm.com (e2.ny.us.ibm.com [32.97.182.102]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA03101 for ; Tue, 23 Jan 2001 09:50:19 -0800 (PST)
Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.117.200.22]) by e2.ny.us.ibm.com (8.9.3/8.9.3) with ESMTP id MAA317604; Tue, 23 Jan 2001 12:54:57 -0500
Received: from d02ml237.somers.hqregion.ibm.com (d02ml237.sby.ibm.com [9.45.4.171]) by northrelay02.pok.ibm.com (8.8.8m3/NCO v4.95) with ESMTP id MAA125906; Tue, 23 Jan 2001 12:52:49 -0500
Importance: Normal
Subject: Re: Post-facto queries [Was: RE: DPD & DPV requirements]
To: Denis Pinkas
Cc: Russ Housley , PKIX-List
X-Mailer: Lotus Notes Release 5.0.3 (Intl) 21 March 2000
Message-ID:
From: "Tom Gindin"
Date: Tue, 23 Jan 2001 12:55:37 -0500
X-MIMETrack: Serialize by Router on D02ML237/02/M/IBM(Release 5.0.6 |December 14, 2000) at 01/23/2001 12:55:52 PM
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii

Denis:

Is your primary objection to post-facto queries that they pose a
temptation to NR relying parties to avoid archiving contemporary
verification information? If we look at the actual verifications performed
in NR, I think that you and I are in agreement that to have the RP keep the
(signed) revocation data supporting his initial determination is more
robust than to have the RP rely on the subsequent verifier acquiring the
revocation data through a post-facto query. IMO this is not a reason why
post-facto queries would be useless in all cases, however - an auditor
attempting to find whether a strong login had occurred before a revocation
or after it (in a case where CRL publication is typically delayed) would
find them useful.
These queries have their place when there is no better alternative,
but I think NR RP's are better off not relying on them. If such an RP (or
the escrow holder for 2-way NR in my draft) maintains contemporary
revocation information, it cannot be affected by the CA ceasing operations
or failing to maintain archives.

Tom Gindin

Denis Pinkas on 01/23/2001 12:04:14 PM

To: Russ Housley
cc: PKIX-List
Subject: Re: Post-facto queries [Was: RE: DPD & DPV requirements]

Russ,

Your statement is too short so that I can understand what you do not
understand. :-)

Could you elaborate a little bit more, or maybe some one else could explain
better than I can.

Denis

> Denis:
>
> I do not understand your point.
>
> Russ
>
> At 04:48 PM 1/23/2001 +0100, Denis Pinkas wrote:
> >[Denis]
> >
> >The additional problem to be considered is that the structure of the
answer
> >in case (a) would be different from the answer in the case of a
current-time
> >checking, since one structure would include individual time stamps while
the
> >other would not.
> >
> >[Russ]
> >
> >Why does the DPV need a 3rd party time stamp on the CRLs? It can keep
> >track using its own clock as long as it has a trusted time source. The
> >STIME working group is going to provide a straightforward mechanism for
> >that...
> >
> >[Denis * new answer]
> >
> >If you use the evidence, it is because you do not trust the "valid"
answer
> >from the server (otherwise, you would not need the evidence). Hence you
> >would not trust either the clock from the server.

Received: from po1.bbn.com (PO1.BBN.COM [192.1.50.38]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA02623 for ; Tue, 23 Jan 2001 09:48:02 -0800 (PST)
Received: from [128.33.238.41] (TC047.BBN.COM [128.33.238.47]) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id MAA14761; Tue, 23 Jan 2001 12:53:54 -0500 (EST)
Mime-Version: 1.0
X-Sender: [email-masked] (Unverified)
Message-Id:
In-Reply-To:
References:
Date: Tue, 23 Jan 2001 12:44:48 -0500
To: "Bob Jueneman"
From: Stephen Kent
Subject: Re: DPD & DPV requirements
Cc: ,
Content-Type: text/plain; charset="us-ascii" ; format="flowed"

bob,

>Quite so. The problem with the existing cross-certificate structure, and with
> top-down name constraints, is that they are imposed on subordinate
>entities, rather willy-nilly, by the CAs, without providing a mechanism
>for the relying parties to specify the extent to which they wish to trust the
>CAs themselves, other than by switching roots. In particular, there is no
>ability to control "delegation" (trust, really) in the upwards direction.

As I said in my response to your recent message, the word "trust" is
vastly misused in these discussion, and your comments above are a
prime example.

>And I remain convinced that name subordination is a badly broken
>mechanism. It really doesn't work in a multi-lingual environment,
>and except perhaps in certain closed user group organizational constructs
>it simply doesn't work at all.

Sorry you still don't like the notion of name subordination, but it
is a fact of life in many, if not most, contexts. Why don't you
change your e-mail address one that terminates with bbn.com and try
to get the e-mail routed to you at Novell. I'll do what I can at
this end to make sure it never happens!

>What am I supposed to do with respect to a residentialPerson --
>reject anyone whose certificate indicates that they reside in the State of
>California? (Not such a bad idea, actually, considering how they have
>managed to screw up their power infrastructure and are now relying
>on their neighboring states to help them out.)

The lack of context for the comments makes it hard to respond to, but
my guess is that you were trying to say that absent someone from the
state of CA taking responsibility for issuing certs in that state,
you prefer to rely on TTPs to assert identifies of this sort.

>The Novell Security Attributes construct was invented to solve precisely
>the kinds of problems you have pointed out.

One more reference to your favorite corporate product and I'll ask
Paul to filter your messages from this list, if only to save virtual
trees :-)

Steve

Received: from po1.bbn.com (PO1.BBN.COM [192.1.50.38]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA02475 for ; Tue, 23 Jan 2001 09:47:46 -0800 (PST)
Received: from [128.33.238.41] (TC047.BBN.COM [128.33.238.47]) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id MAA14744; Tue, 23 Jan 2001 12:53:51 -0500 (EST)
Mime-Version: 1.0
X-Sender: [email-masked] (Unverified)
Message-Id:
In-Reply-To:
References:
Date: Tue, 23 Jan 2001 12:33:52 -0500
To: "Bob Jueneman"
From: Stephen Kent
Subject: RE: DVD & DVP requirements
Cc:
Content-Type: text/plain; charset="us-ascii" ; format="flowed"

Bob,

>Steve, you said in part:
> >
> >I'd like to better understand what parameters the client will change
> >between invocations of a DPD server, in a controlled fashion, to make
> >multiple invocations for the same target certificate provide
> >distinct, useful, answers. Do you have some examples that could
> >clarify this scenario?
> >
> >Steve
>
>Let me give you a possible "existence proof " of such a scenario.
>
>There's an old joke about a Vermonter, who when asked, "How's
>your wife?" replied "Compared to what?"
>
>When we have said in this context, "Is this certificate chain valid?",
>we should really be asking "Can I trust this certificate chain?"
>and the only reasonable answer to that question is to say
>"compared to what?" or more precisely, "Trust it for what purpose?"

A DPV client specifies a set of parameters for controlling an
objective, deterministic process that we call certificate validation.
I think the word "trust" has no place in this process. At best,
since the client selects the parameters relative to an intended use
for the key in the cert, you might choose to say that the client
chooses these parameters based on its perception of what it needs to
trust the key for, but those would be your words, not mine.

>In other words, trust, like integrity, is not some binary value that is
>independent of any predicate. Instead, something, either a process
>or the data that was produced as a result of some process, is "trusted"
>if and only if the process conforms to a specified set of rules or
>expectations. It is clearly not possible for a process to be tested
>against all possible rules in the universe, so without qualifying the
>trust to a particular set of rules, the question is meaningless.

Validation is trinary here: yes, no, don't know.

>Now, the reason why a client or relying party might ask the server t
>hat question is obviously a function of the client's current context, i.e.,
>the type of transaction or whatever that is being evaluated.

Which is why it makes sense to keep this aspect of the decision to
use a cert for a given application a local matter, outside the scope
of this standard.

>And clearly, that context may vary, depending on the perceived value
>of the transaction, the history of that transaction and previous
>transactions with that signer, etc.

see comment immediately above.

>If the client is trying to decide whether to honor a purchase order
>for a single quart of 10-40 motor oil, the risk analysis for such a
>transaction would probably suggest that the probability of default
>is low, and that continued customer good will is worth more than
>that risk. In that case, maybe it isn't even worth the bother of
>consulting the server, except perhaps for auditing or logging
>purposes.
>
>On the other hand, if that very same client is evaluating a purchase
>order for one hundred million barrels of crude oil, to be delivered
>via multiple oil tankers FOB Saudi Arabia, then the risk analysis
>would suggest that the buyer's credentials had better be
>gilt-edged indeed.
>
>As to how the parameters would be conveyed, a very simple,
>existence-proof mechanism would be to simply encode the value
>of the transaction in dollars, and let the server try do its thing.
>maybe it has some artificial intelligence program that parses the
>Certificate Practice Statement and does a risk assessment.
>Or maybe it simply looks up the net worth of the buyer and the
>CA in Dun and Bradstreet and decides accordingly.

Since not all transactions are best characterized by monetary value,
this is not my idea of a good example. It also shifts the burden to
the server in a fashion that makes it impossible to test if a server
is operating properly. So, no, this is not a good idea.

>Of course, since I have a hammer and this looks like a nail,
>I would suggest that a better mechanism would be to use
>the Novell Security Attributes (cf.
>http://developer/novell.com/repository/attributes/certattrs_v10.htm),
>and to have the client either encode a minimum set of those
>attributes for this particular transaction. Or more likely,
>the client would be preconfigured with a set of attributes
>labeled platinum, gold, silver, bronze, green and brown,
>and would select one of those for certain kinds of transactions,

Bob, we frown on advertisements on this list. You know better.

>
>
>In either case, the client can ask the question, "Is this certificate
>chain trustworthy with respect to my "Platinum" criteria?" and get one
>answer, and later ask the same question with respect to exactly the
>same certificate chain, but specifying the "Green" criteria, and perhaps
>get a different answer.

We support this via reference to different policies configured on the
server, but only to the extent that the policies make use of standard
cert attribute validation parameters. To do what you propose would
require adding support for private extensions at the server and
perhaps in client requests. This could be done if the WG wants, but
it would be a supplement to the mandatory, 2459bis validation
criteria.

Steve

Received: from po1.bbn.com (PO1.BBN.COM [192.1.50.38]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA02476 for ; Tue, 23 Jan 2001 09:47:46 -0800 (PST)
Received: from [128.33.238.41] (TC047.BBN.COM [128.33.238.47]) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id MAA14741; Tue, 23 Jan 2001 12:53:48 -0500 (EST)
Mime-Version: 1.0
X-Sender: [email-masked] (Unverified)
Message-Id:
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Date: Tue, 23 Jan 2001 12:14:55 -0500
To: Denis Pinkas
From: Stephen Kent
Subject: Re: DPD & DPV requirements
Cc: PKIX-List
Content-Type: text/plain; charset="us-ascii" ; format="flowed"

Denis,

>Russ,
>
> > I agree. If were were to add any capability, I would consider an input to
> > the path validation algorithm that allowed a user to provide name
> > constraints. There is already an input parameter for acceptable policies.
>
>This is fine for DPD.
>
>The next question is : is this also fine for DPV ?
>
>Not sure, some validation policies may request some (even private)
>extensions in the leaf certificate to be present for a certificate to be
>"valid" according to a validation policy. Hence a response "valid", should
>be interpreted as a minimum condition to be valid, but not always as a
>sufficient condition. We would have to be very careful when explaining what
>a "valid" status means.

Good point. The issue you're getting at here is how far beyond 2459
do we go in providing explicit controls on validation for DPV, since
it is not unreasonable for folks to impose such constraints in
various application contexts. I think we have some flexibility here,
but we need to pick a set of parameters and go forward.

Steve

Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA01473 for ; Tue, 23 Jan 2001 09:40:19 -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 SAA47982; Tue, 23 Jan 2001 18:53:36 +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 SAA19402; Tue, 23 Jan 2001 18:45:54 +0100
Message-ID: <[email-masked]>
Date: Tue, 23 Jan 2001 18:45:55 +0100
From: Denis Pinkas
Organization: Bull
X-Mailer: Mozilla 4.7 [fr] (Win98; I)
X-Accept-Language: fr
MIME-Version: 1.0
To: "Covey, Carlin"
CC: PKIX-List
Subject: Re: Post-facto queries [Was: RE: DPD & DPV requirements]
References: <[email-masked]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Carlin,

Thanks for trying to explain.

> Russ, I think Denis is saying that if the client trusts the DPV
> server's good/bad response, why wouldn't it also trust the timestamp
> that the DPV server put on the response (obviating the need for a
> third-party timestamp). Denis, did I get that right?

No. Unfortunately. If the relying party is willing to trust the signed
"valid" response obtained from the DPV server's by the client, then he does
not need any additional proof such as CRLs certification path or whatever.
If the relying does not trust the response then he will ask for the proof
(such as certification path and revocation information).

Also note that the time stamp is not issued by the DPV server, but requested
by the DPV server. The DPV server acts as a client from a TSA server.

> I suppose the client might believe that the DPV server was honest,
> but not a very good timekeeper. Seems a stretch though....

Not exactly. See above.

> I have a question on an earlier email in this thread. Perhaps I
> misinterpreted something. I'm puzzled why we would want timestamps
> on individual CRLs in the case of post-facto validation of a certificate.
> The CRL contains information that indicates its validity period.

If keys signing CRLs were never compromised nor revoked, time stamping would
not be necessary. Since CAs are not mandated to publish any information
about the revocation of a key after the end of the validity period, it is
necessary to prove that the signature was done during the period of the
validity of the certificate, unless it can be made sure that the key can
never be compromised or never be found from a brute force attack. Since we
can never be sure of these two conditions, time stamping guards against that
threat.

> Presumably if a timestamp were placed over the CRL later, the timestamp
> would indicate the current time, not the validity time of the CRL.

The time stamp needs to be placed either before the key is compromised (or
revoked) or before the end of validity of the certificate of the key that is
intended to be protected, which ever is the sooner. See the TSP document for
further details.

> (A timestamping server that back-dates timestamps doesn't seem very
> trustworthy.) Why would I care whether the CRL for a certain week three
> months ago now had today's timestamp on it? (I'm sure I must have missed
> something in the discussion.)

You did. :-) I hope that the explanations above give you the answer.

Regards,

Denis

> Regards,
>
> Carlin
>
> -------------------------------------
> - Carlin Covey
> Cylink Corp.
>
> -----Original Message-----
>
> From: Denis Pinkas [mailto:[email-masked]]
> Sent: Tuesday, January 23, 2001 10:04 AM
> To: Russ Housley
> Cc: PKIX-List
> Subject: Re: Post-facto queries [Was: RE: DPD & DPV requirements]
>
> Russ,
>
> Your statement is too short so that I can understand what you do not
> understand. :-)
>
> Could you elaborate a little bit more, or maybe some one else could explain
> better than I can.
>
> Denis
>
> > Denis:
> >
> > I do not understand your point.
> >
> > Russ
> >
> > At 04:48 PM 1/23/2001 +0100, Denis Pinkas wrote:
> > >[Denis]
> > >
> > >The additional problem to be considered is that the structure of the
> answer
> > >in case (a) would be different from the answer in the case of a
> current-time
> > >checking, since one structure would include individual time stamps while
> the
> > >other would not.
> > >
> > >[Russ]
> > >
> > >Why does the DPV need a 3rd party time stamp on the CRLs? It can keep
> > >track using its own clock as long as it has a trusted time source. The
> > >STIME working group is going to provide a straightforward mechanism for
> > >that...
> > >
> > >[Denis * new answer]
> > >
> > >If you use the evidence, it is because you do not trust the "valid"
> answer
> > >from the server (otherwise, you would not need the evidence). Hence you
> > >would not trust either the clock from the server.

Received: from exchange.cylink.com (exchange.cylink.com [192.43.161.25]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA29907 for ; Tue, 23 Jan 2001 09:17:20 -0800 (PST)
Received: by exchange.cylink.com with Internet Mail Service (5.5.2650.21) id ; Tue, 23 Jan 2001 09:22:58 -0800
Message-ID: <[email-masked]>
From: "Covey, Carlin"
To: PKIX-List
Subject: RE: Post-facto queries [Was: RE: DPD & DPV requirements]
Date: Tue, 23 Jan 2001 09:22:57 -0800
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"

Russ, I think Denis is saying that if the client trusts the DPV
server's good/bad response, why wouldn't it also trust the timestamp
that the DPV server put on the response (obviating the need for a
third-party timestamp). Denis, did I get that right?

I suppose the client might believe that the DPV server was honest,
but not a very good timekeeper. Seems a stretch though....

I have a question on an earlier email in this thread. Perhaps I
misinterpreted something. I'm puzzled why we would want timestamps
on individual CRLs in the case of post-facto validation of a certificate.
The CRL contains information that indicates its validity period.
Presumably if a timestamp were placed over the CRL later, the timestamp
would indicate the current time, not the validity time of the CRL.
(A timestamping server that back-dates timestamps doesn't seem very
trustworthy.) Why would I care whether the CRL for a certain week three
months ago now had today's timestamp on it? (I'm sure I must have missed
something in the discussion.)

Regards,

Carlin

-------------------------------------
- Carlin Covey
Cylink Corp.

-----Original Message-----
From: Denis Pinkas [mailto:[email-masked]]
Sent: Tuesday, January 23, 2001 10:04 AM
To: Russ Housley
Cc: PKIX-List
Subject: Re: Post-facto queries [Was: RE: DPD & DPV requirements]

Russ,

Your statement is too short so that I can understand what you do not
understand. :-)

Could you elaborate a little bit more, or maybe some one else could explain
better than I can.

Denis

> Denis:
>
> I do not understand your point.
>
> Russ
>
> At 04:48 PM 1/23/2001 +0100, Denis Pinkas wrote:
> >[Denis]
> >
> >The additional problem to be considered is that the structure of the
answer
> >in case (a) would be different from the answer in the case of a
current-time
> >checking, since one structure would include individual time stamps while
the
> >other would not.
> >
> >[Russ]
> >
> >Why does the DPV need a 3rd party time stamp on the CRLs? It can keep
> >track using its own clock as long as it has a trusted time source. The
> >STIME working group is going to provide a straightforward mechanism for
> >that...
> >
> >[Denis * new answer]
> >
> >If you use the evidence, it is because you do not trust the "valid"
answer
> >from the server (otherwise, you would not need the evidence). Hence you
> >would not trust either the clock from the server.

Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA28938 for ; Tue, 23 Jan 2001 08:58:38 -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 SAA10718; Tue, 23 Jan 2001 18:11:55 +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 SAA17936; Tue, 23 Jan 2001 18:04:13 +0100
Message-ID: <[email-masked]>
Date: Tue, 23 Jan 2001 18:04:14 +0100
From: Denis Pinkas
Organization: Bull
X-Mailer: Mozilla 4.7 [fr] (Win98; I)
X-Accept-Language: fr
MIME-Version: 1.0
To: Russ Housley
CC: PKIX-List
Subject: Re: Post-facto queries [Was: RE: DPD & DPV requirements]
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Russ,

Your statement is too short so that I can understand what you do not
understand. :-)

Could you elaborate a little bit more, or maybe some one else could explain
better than I can.

Denis

> Denis:
>
> I do not understand your point.
>
> Russ
>
> At 04:48 PM 1/23/2001 +0100, Denis Pinkas wrote:
> >[Denis]
> >
> >The additional problem to be considered is that the structure of the answer
> >in case (a) would be different from the answer in the case of a current-time
> >checking, since one structure would include individual time stamps while the
> >other would not.
> >
> >[Russ]
> >
> >Why does the DPV need a 3rd party time stamp on the CRLs? It can keep
> >track using its own clock as long as it has a trusted time source. The
> >STIME working group is going to provide a straightforward mechanism for
> >that...
> >
> >[Denis * new answer]
> >
> >If you use the evidence, it is because you do not trust the "valid" answer
> >from the server (otherwise, you would not need the evidence). Hence you
> >would not trust either the clock from the server.

Received: from mail.spyrus.com (mail.spyrus.com [207.212.34.20]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA28298 for ; Tue, 23 Jan 2001 08:52:56 -0800 (PST)
Received: from RHOUSLEY-PC.spyrus.com ([209.172.119.210]) by mail.spyrus.com (8.9.3/8.9.3) with ESMTP id IAA08460; Tue, 23 Jan 2001 08:57:58 -0800 (PST)
Message-Id: <[email-masked]>
X-Sender: [email-masked]
X-Mailer: QUALCOMM Windows Eudora Version 5.0.2
Date: Tue, 23 Jan 2001 11:55:22 -0500
To: Denis Pinkas
From: Russ Housley
Subject: Re: Post-facto queries [Was: RE: DPD & DPV requirements]
Cc: PKIX-List
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed

Denis:

I do not understand your point.

Russ

At 04:48 PM 1/23/2001 +0100, Denis Pinkas wrote:
>[Denis]
>
>The additional problem to be considered is that the structure of the answer
>in case (a) would be different from the answer in the case of a current-time
>checking, since one structure would include individual time stamps while the
>other would not.
>
>[Russ]
>
>Why does the DPV need a 3rd party time stamp on the CRLs? It can keep
>track using its own clock as long as it has a trusted time source. The
>STIME working group is going to provide a straightforward mechanism for
>that...
>
>[Denis * new answer]
>
>If you use the evidence, it is because you do not trust the "valid" answer
>form the server (otherwise, you would not need the evidence). Hence you
>would not trust either the clock from the server.

Received: from mail.spyrus.com (mail.spyrus.com [207.212.34.20]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA28299 for ; Tue, 23 Jan 2001 08:52:56 -0800 (PST)
Received: from RHOUSLEY-PC.spyrus.com ([209.172.119.210]) by mail.spyrus.com (8.9.3/8.9.3) with ESMTP id IAA08457; Tue, 23 Jan 2001 08:57:57 -0800 (PST)
Message-Id: <[email-masked]>
X-Sender: [email-masked]
X-Mailer: QUALCOMM Windows Eudora Version 5.0.2
Date: Tue, 23 Jan 2001 11:54:12 -0500
To: Denis Pinkas
From: Russ Housley
Subject: Re: Post-facto queries [Was: RE: DPD & DPV requirements]
Cc: PKIX-List
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed

Denis:

I thought that you might have some novel use of time stamp policy. I am
glad to see that you do not.

Russ

At 04:48 PM 1/23/2001 +0100, Denis Pinkas wrote:
>[Russ]
>
>Retrospective checking has always been viewed as a concern, especially in a
>dispute. This allows us to allocate the data archive necessary to perform
>such checking to a server rather than every client.
>
>[Denis]
>
>Let me rephrase the issue in a different way. We have two options:
>
> a) either support time stamping of every individual CRL in the server (I
> wanted to avoid this), or
> b) support no time stamping in the server.
>
>In case (a), the service would work in any case, provided that the chosen
>TSA is "acceptable" to the relying party.
>
>In case (b), the service would not work any more in case of a CA key
>compromise.
>
>[Russ]
>
>Doesn't this require the TSA to validate the subscriber signature before
>providing a time stamp? While this policy could be implemented, I do not
>believe that all TSAs will want to implement such a policy. If fact, I can
>think of cases where I would want time stamps for unsigned documents.
>
>[Denis * new answer]
>
>No. You certainly read the TSP document since you provide numerous comments
>during the last call period. :-) However, you missed the point that there is
>no such notion of "subscriber signature". Time stamp requests do not need
>to be authenticated. In addition, since the only thing a TSA "sees" is an
>imprint, it cannot know whether what is a signed or unsigned document. In
>other words a TSA blindly signs everything.

Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA23766 for ; Tue, 23 Jan 2001 07:42:56 -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 QAA43928; Tue, 23 Jan 2001 16:56:12 +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 QAA18014; Tue, 23 Jan 2001 16:48:30 +0100
Message-ID: <[email-masked]>
Date: Tue, 23 Jan 2001 16:48:32 +0100
From: Denis Pinkas
Organization: Bull
X-Mailer: Mozilla 4.7 [fr] (Win98; I)
X-Accept-Language: fr
MIME-Version: 1.0
To: Russ Housley
CC: PKIX-List
Subject: Re: Post-facto queries [Was: RE: DPD & DPV requirements]
References: <[email-masked]> <[email-masked]> <[email-masked]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Russ,

[Russ]

Just because a retrospective check is available does not mean that
current-time checking will stop.

[Denis]

Fine. But if current-time checking is done, there is no need any more for a
retrospective check. So what would be the additional value of a
retrospective check if current-time checking is done ?

[Russ]

This is where we disagree. When there is a dispute, a retrospective check
is needed to determine whether the relying party did their processing
correctly.

[Denis * new answer]

We certainly disagree here, since when there is a dispute, a retrospective
check is NOT needed. A proof obtained at current-time checking that has been
time-stamped at that time is sufficient.

Next topic:

[Russ]

Retrospective checking has always been viewed as a concern, especially in a
dispute. This allows us to allocate the data archive necessary to perform
such checking to a server rather than every client.

[Denis]

Let me rephrase the issue in a different way. We have two options:

a) either support time stamping of every individual CRL in the server (I
wanted to avoid this), or
b) support no time stamping in the server.

In case (a), the service would work in any case, provided that the chosen
TSA is "acceptable" to the relying party.

In case (b), the service would not work any more in case of a CA key
compromise.

[Russ]

Doesn't this require the TSA to validate the subscriber signature before
providing a time stamp? While this policy could be implemented, I do not
believe that all TSAs will want to implement such a policy. If fact, I can
think of cases where I would want time stamps for unsigned documents.

[Denis * new answer]

No. You certainly read the TSP document since you provide numerous comments
during the last call period. :-) However, you missed the point that there is
no such notion of "subscriber signature". Time stamp requests do not need
to be authenticated. In addition, since the only thing a TSA "sees" is an
imprint, it cannot know whether what is a signed or unsigned document. In
other words a TSA blindly signs everything.

Next topic:

[Denis]

The additional problem to be considered is that the structure of the answer
in case (a) would be different from the answer in the case of a current-time
checking, since one structure would include individual time stamps while the
other would not.

[Russ]

Why does the DPV need a 3rd party time stamp on the CRLs? It can keep
track using its own clock as long as it has a trusted time source. The
STIME working group is going to provide a straightforward mechanism for
that...

[Denis * new answer]

If you use the evidence, it is because you do not trust the "valid" answer
form the server (otherwise, you would not need the evidence). Hence you
would not trust either the clock from the server.

Denis

> Russ

Received: from mail.spyrus.com (mail.spyrus.com [207.212.34.20]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA18749 for ; Tue, 23 Jan 2001 07:03:33 -0800 (PST)
Received: from RHOUSLEY-PC.spyrus.com ([209.172.119.210]) by mail.spyrus.com (8.9.3/8.9.3) with ESMTP id HAA06504; Tue, 23 Jan 2001 07:08:36 -0800 (PST)
Message-Id: <[email-masked]>
X-Sender: [email-masked]
X-Mailer: QUALCOMM Windows Eudora Version 5.0.2
Date: Tue, 23 Jan 2001 10:08:39 -0500
To: Denis Pinkas
From: Russ Housley
Subject: Re: Post-facto queries [Was: RE: DPD & DPV requirements]
Cc: PKIX-List
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed

At 09:37 AM 1/23/2001 +0100, Denis Pinkas wrote:
>I said: " I believe that we should think more about the consequences before
>supporting this service." I still think it !
>
> > Just because a retrospective check is available does not mean that
> > current-time checking will stop.
>
>Fine. But if current-time checking is done, there is no need any more for a
>retrospective check. So what would be the additional value of a
>retrospective check if current-time checking is done ?

This is where we disagree. When there is a dispute, a retrospective check
is needed to determine whether the relying party did their processing
correctly.

> > Retrospective checking has always been
> > viewed as a concern, especially in a dispute. This allows us to allocate
> > the data archive necessary to perform such checking to a server rather than
> > every client.
>
>Let me rephrase the issue in a different way. We have two options:
>
>a) either support time stamping of every individual CRL in the server (I
>wanted to avoid this), or
>b) support no time stamping in the server.
>
>In case (a), the service would work in any case, provided that the chosen
>TSA is "acceptable" to the relying party.
>In case (b), the service would not work any more in case of a CA key
>compromise.

Doesn't this require the TSA to validate the subscriber signature before
providing a time stamp? While this policy could be implemented, I do not
believe that all TSAs will want to implement such a policy. If fact, I can
think of cases where I would want time stamps for unsigned documents.

>The additional problem to be considered is that the structure of the answer
>in case (a) would be different from the answer in the case of a current-time
>checking, since one structure would include individual time stamps while the
>other would not.

Why does the DPV need a 3rd party time stamp on the CRLs? It can keep
track using its own clock as long as it has a trusted time source. The
STIME working group is going to provide a straightforward mechanism for that...

Russ

Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id EAA10539 for ; Tue, 23 Jan 2001 04:50: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 OAA35980 for ; Tue, 23 Jan 2001 14:03:25 +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 NAA19342 for ; Tue, 23 Jan 2001 13:55:43 +0100
Message-ID: <[email-masked]>
Date: Tue, 23 Jan 2001 13:55:45 +0100
From: Denis Pinkas
Organization: Bull
X-Mailer: Mozilla 4.7 [fr] (Win98; I)
X-Accept-Language: fr
MIME-Version: 1.0
To: IETF-PXIX
Subject: Changes to the TSP protocol
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Summary of the changes to TSP to produce

The following changes have been provided in order to respond to several
comments raised by Jeff Schiller, our Security Area Director, who has
reviewed the document before its presentation to the IESG. Jeff has
indicated that these changes were correctly addressing his concerns.

1. What does it mean to be a "known" algorithm ?

The current text states the following, which was not precise enough:

" The hash algorithm indicated in the hashAlgorithm field MUST be a known
hash algorithm (one-way and collision resistant)."

The new text is the following (changing a MUST into a SHOULD):

The hash algorithm indicated in the hashAlgorithm field SHOULD be
a strong hash algorithm. That means that it SHOULD be one-way and
collision resistant. The Time Stamp Authority SHOULD check whether
or not the given hash algorithm is known to be "sufficient" (based
on the current state of knowledge in cryptanalysis and the current
state of the art in computational resources, for example). If the
TSA does not recognize the hash algorithm or knows that the hash
algorithm is weak (a decision left to the discretion of each
individual TSA), then the TSA SHOULD refuse to provide the
Time Stamp Token.

2. PKIStatus values

The current text states the following:

" Compliant servers MUST NOT produce any other values. Compliant clients
MAY ignore any other values."

This would create a problem if other values were added. The new text is the
following (changing a MUST into a SHOULD):

" Compliant servers SHOULD NOT produce any other values.
Compliant clients MUST generate an error if values it does not understand
are present."

3. PKIFailureInfo

The current text states the following:

" These are the only values of PKIFailureInfo that are supported.
Compliant servers MUST NOT produce any other values. Compliant clients MAY
ignore any other values."

As above, this would create a problem if other values were added. The new
text is the following (changing a MUST into a SHOULD):

" These are the only values of PKIFailureInfo that SHALL be supported.
Compliant servers SHOULD NOT produce any other values.
Compliant clients MUST generate an error if values it does not understand
are present."

Note: In order to align the document with RFC1510bis (CMP) an additional
error has been added (initial request from Francois Rousseau):

systemFailure (25)
-- the request cannot be handled due to system failure

4. Big Typo left.

The following temporary explanatory text was left and has been deleted.

" should read: 'Such syntax, .... to represent time *within* one
second, may be used here' (omit 'to')."

5. Removal of Annex C.

This annex C which contains the MIME Registrations forms to IANA for
timestamp-query and timestamp-reply will be removed as soon as an RFC number
is obtained and will be sent to IANA.

6. Unsigned integer

The text states:

The "time-to-check-back" parameter is a 32-bit integer, defined to be
the number of seconds that have elapsed since midnight, January 1,
1970, coordinated universal time.

The word "unsigned" has been added before integer.

7. Security consideration section cases 1 and 2.

In the security consideration section the difference between case 1 and case
2 was not clear enough, in particular because the first sentence was
misleading, stating :" the TSA can no longer be trusted".

In order to distinguish better between the two cases, the text replacement
is:

1. When a TSA shall not be used anymore, but the TSA private key
has not been compromised, the authority's certificate SHALL
be revoked. When the reasonCode extension relative to the
revoked certificate from the TSA is present in the CRL entry
extensions, it SHALL be set either to unspecified (0),
affiliationChanged (3), superseded (4) or cessationOfOperation
(5). In that case, at any future time, the tokens signed with
the corresponding key will be considered as invalid, but
tokens generated before the revocation time will remain valid.
When the reasonCode extension relative to the revoked
certificate from the TSA is not present in the CRL entry
extensions, then all the tokens that have been signed with
the corresponding key SHALL be considered as invalid. For
that reason, it is recommended to use the reasonCode
extension.

2. When the TSA private key has been compromised, then the
corresponding certificate SHALL be revoked. In that case,
the reasonCode extension relative to the revoked certificate
from the TSA may or may not be present in the CRL entry
extensions. When it is present then it SHALL be set to
keyCompromise (1). Any token signed by the TSA using that
private key cannot be trusted anymore. For this reason, it
is imperative that the TSA's private key be guarded with
proper security and controls in order to minimize the
possibility of compromise. In case the private key does
become compromised, an audit trail of all tokens generated
by the TSA MAY provide a means to discriminate between genuine
and false backdated tokens. A double time stamping from two
different TSAs is another way to address this issue.

8. Security consideration section case 4.

In the security consideration section, case 4, it was not clear enough in
which case the attack was applicable. The new text explains that the case
applies in case a nonce and no local clock is being used.

The original first sentence was:

4. An application using the TSA service SHOULD be concerned
about the amount of time it is willing to wait for a response.

The new sentence is:

4. A client application using only a nonce and no local clock
SHOULD be concerned about the amount of time it is willing
to wait for a response.

Denis

Received: from ietf.org (odin.ietf.org [132.151.1.176]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id EAA09817 for ; Tue, 23 Jan 2001 04:28:25 -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 HAA09468; Tue, 23 Jan 2001 07:34:33 -0500 (EST)
Message-Id: <[email-masked]>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-pkix-time-stamp-13.txt
Date: Tue, 23 Jan 2001 07:34:33 -0500
Sender: [email-masked]

--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 Time Stamp
Protocols (TSP)
Author(s) : C. Adams, P. Cain, D. Pinkas, R. Zuccherato
Filename : draft-ietf-pkix-time-stamp-13.txt
Pages : 26
Date : 22-Jan-01

A time stamping service supports assertions of proof that a datum
existed before a particular time. This document describes the format
of a request sent to a Time Stamping Authority (TSA) and of the
response that is returned. It also establishes several security-
relevant requirements for TSA operation, with regards to processing
requests to generate responses. A TSA may be operated as a Trusted
Third Party (TTP) service, though other operational models may be
appropriate, e.g. an organization might require a TSA for internal
time stamping purposes.

Non-repudiation services [ISONR] require the ability to establish the
existence of data before specified times. This protocol may be used as
a building block to support such services. An example of how to prove
that a digital signature was generated during the validity period of
a public key certificate is given in an annex.

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

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-ietf-pkix-time-stamp-13.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:
[email-masked].
In the body type:
"FILE /internet-drafts/draft-ietf-pkix-time-stamp-13.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="[email-masked]"

Content-Type: text/plain
Content-ID: <[email-masked]>

ENCODING mime
FILE /internet-drafts/draft-ietf-pkix-time-stamp-13.txt

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

Content-Type: text/plain
Content-ID: <[email-masked]>

--OtherAccess--

--NextPart--

Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id BAA24770 for ; Tue, 23 Jan 2001 01:39:21 -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 KAA54228 for ; Tue, 23 Jan 2001 10:52: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 KAA16904 for ; Tue, 23 Jan 2001 10:44:53 +0100
Message-ID: <[email-masked]>
Date: Tue, 23 Jan 2001 10:44:55 +0100
From: Denis Pinkas
Organization: Bull
X-Mailer: Mozilla 4.7 [fr] (Win98; I)
X-Accept-Language: fr
MIME-Version: 1.0
To: IETF-PXIX
Subject: Strawman proposals for DPV and DPD
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Since we now basically agree on many/most issues, it is time to draft
strawman
proposals if we want to reach an agreement at the end of this month. You
will find hereunder a description for DPV and DPD. The input /output
parameters for each protocol are identified.

STRAWMAN PROPOSAL FOR DPV:

Goals : Validate a leaf certificate according to a validation policy or one
trust anchor (public key value and CA name associated with CP and naming
constraints).

Obtain a signed "valid", "invalid" or "incomplete" answer to the question.

Optionally obtain the evidence to support the "valid" answer

Mandatory input :

Unambiguous reference of the certificate to be validated : either the
certificate itself or the ESSCertID (with issuerSerial present).

ESSCertID ::= SEQUENCE {
certHash Hash,
issuerSerial IssuerSerial OPTIONAL
}

Hash ::= OCTET STRING -- SHA1 hash of entire certificate

IssuerSerial ::= SEQUENCE {
issuer GeneralNames,
serialNumber CertificateSerialNumber
}

Mandatory input :

A flag indicating whether or not the evidence of the assertion shall be
returned : the certification path and its associated revocation information.

Optional input :

either one trust anchor, or
an unambiguous reference of the validation policy to be used: either the
description of the validation policy, or a reference to the validation
policy and its hash :

ValidationPolicyRef ::= SEQUENCE {
valPolicyId ValPolicyId,
valPolicyIDHash ValPolicyHash,
valPolicyQualifiers SEQUENCE SIZE (1..MAX) OF
ValPolicyQualifierInfo OPTIONAL}
}

ValPolicyId ::= OBJECT IDENTIFIER

ValPolicyHash ::= OCTET STRING -- SHA1 hash of entire certificate

ValPolicyQualifierInfo :== SEQUENCE {
valPolicyQualifierId ValPolicyQualifierId,
valQualifier ANY DEFINED BY valPolicyQualifierId }
}

ValPolicyQualifierId ::= OBJECT IDENTIFIER

Note 1 : if the ValidationPolicyRef or the trust anchor parameter is missing
in the request, then the server will return back either the
ValidationPolicyRef that has been used or alternatively a description of the
validation policy or one trust anchor.

Optional input :

Useful certificates, in the form they are in the current protocols : S/MIME,
IPSEC, TLS and ES formats, so that " blobs " can be used.

Optional input :

Useful revocation information, in the various forms in the current protocols
: S/MIME, IPSEC, TLS and ES formats, so that " blobs " can be used.

Optional input : A nonce, if no time is present on the client.

Mandatory output : A digital signature over the following items :

- a status : valid, invalid, incomplete.
- the reference of the certificate being validated or the certificate
itself.
- the date of validation,
- the reference of the validation policy that has been used during the
validation process or its description,
- optionally, the hash of the evidence.

Note 2 : a separate digital signature over the evidence (full path and
associated revocation information) should be avoided in order to avoid the
cost of two signatures. In order to be able to store the yes /no answer in
one place without the need to store the evidence (that may be quite big) in
the same place, it is proposed to include the hash of the evidence in the
signed answer. This does not augment too much the size of the answer while
providing integrity protection without the need of a second digital
signature.

Optional output :

If requested, the evidence of the assertion as a " blob " : a single
certification path and its associated revocation information.

Note 3 : The document provides elements for
such a structure inside the blob.

Optional output : The sent nonce if it was present (to detect replays).

STRAWMAN PROPOSAL FOR DPD :

Goals : Obtain one or more certification paths and optionally its associated
revocation information for a leaf certificate according either to a
validation policy, a trust anchor or a root key (public key value with CA
name).

Obtain a "success" or "failure" indication for the operation that has been
requested.

Note 1 : Either a full path is returned or nothing (no path nor revocation
information).

Note 2 : A full path may be found, but not necessarily all the associated
revocation information. The revocation information that has been found is
returned.

Note 3 : For each element of the path, both a CRL (or base CRL and delta)
and an OCSP response may be returned (if both exist) as associated
revocation information.

Mandatory input : Unambiguous reference of the certificate to be validated :
either the certificate itself or the ESSCertID (with issuerSerial present).

Mandatory input : When ESSCertID is being used, a flag indicating whether
the certificate itself should be returned.

Mandatory input : Flag indicating whether revocation information for the
path should be returned.

Mandatory input : A nonce (to detect replays).

Conditional input : If, revocation information for the path should be
returned, then a four states flag indicating whether CRLs and /or OCSP
responses should be returned for the leaf certificate (CRL only, OCSP only,
both if they exist, either don't care).

Conditional input : If, revocation information for the path should be
returned, then a four states flag indicating whether CRLs and /or OCSP
responses should be returned for each CA certificate from the path (CRL
only, OCSP only, both if they exist, either don't care).

Optional input : One of the following :

a) reference of the validation policy to be used (ValidationPolicyRef),
b) the description of the validation policy,
c) a self-signed certificate designating a root-key,
d) a trust anchor ( a root key with CP and naming constraints),
e) a root key (a public key value and an associated DN name of a CA),

Note 4 : if this parameter is missing, then the server must designate in the
response either the validation policy, the default root key or the
self-signed certificate that has been used.

Optional input : A sequence of useful CA certificates and a sequence of
useful revocation information (CRLs and/or OCSP responses).

Mandatory output : A primary status indicating: "success" if the operation
that has been requested has been accomplished, or "failure" in the other
case.

Mandatory output : A secondary status indicating : full path found / not
found.

Mandatory output : A secondary status indicating : full revocation
information found / not found.

Mandatory output : A secondary status indicating : leaf certificate found /
not found.

Mandatory output : The sent nonce (to detect replays).

Mandatory output : The reference of the certificate being validated or the
certificate itself.

Conditional output : one or more certification paths and optionally
associated revocation information.

Note 5: each path starts with the leaf certificate (or its reference) and
ends up either with a self-signed certificate or a root key associated with
a CA name.

Note 6 : When only the reference of the certificate is provided in the
request (i.e. ESSCertID) and when requested, the server may include the leaf
certificate in the returned paths.

Mandatory output : A digital signature over all the outputs (including the
input parameters as well) in order to
provide authentication with integrity.

Note 7: in case full revocation information is not found, the client should
sent back (using the sequence of useful certificates and a sequence of
useful revocation information) one of the certification path and the
associated revocation information that he got, he may then get more
revocation information. This avoids to have a stateful server.

Similar structures or easy to convert structures for on one side the input
parameters : " useful " certificates and " useful " revocation information ;
and on the other side the output parameter : certification path and
associated revocation information ; should thus be considered.

Regards,

Denis

Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id BAA20859 for ; Tue, 23 Jan 2001 01:10:48 -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 KAA09312; Tue, 23 Jan 2001 10:24:03 +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 KAA17652; Tue, 23 Jan 2001 10:16:21 +0100
Message-ID: <[email-masked]>
Date: Tue, 23 Jan 2001 10:16:23 +0100
From: Denis Pinkas
Organization: Bull
X-Mailer: Mozilla 4.7 [fr] (Win98; I)
X-Accept-Language: fr
MIME-Version: 1.0
To: Stephen Kent
CC: PKIX-List
Subject: Re: DPD & DPV requirements
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Steve,

Thanks for your detailed answer. We now mostly agree. See a few comments
below.

> Denis,
>
> >DPV goals:
> >
> >Validate a leaf certificate according either to a validation policy or one
> >(or more ?) trust anchor (public key value, CA name and optionally a
> >validity period) including CP and naming constraints.
>
> yes
>
> >
> >Obtain a signed " yes, no or incomplete " answer to the question together
> >with the date of validation.
>
> yes
>
> >Optionally provide a replay protection if no time is available on the
> >client.
>
> I would say that replay protection is necessary, period. The question
> is whether the protocol will meet this requirement via nonces or some
> other mechanism.

O.K.

> >Optionally obtain the evidence to support the yes answer
>
> I think it is a client option to request evidence, but a server MUST
> be able to provide the evidence.

O.K.

> >Note 1: A complete certification path is one that satisfies all of the
> >validation criteria specified in RFC 2459bis and that terminates at a trust
> >anchor (public key value, CA name and optionally a validity period) that may
> >include Certification Policy constraints as well as naming constraints.
>
> yes, plus any other validation parameters defined by 2459bis.
>
> >Note 2 : if a "ValidationPolicyRef" parameter or the trust anchor is missing
> >in the request, then the server will return back either the
> >ValidationPolicyRef that has been used or alternatively a description of the
> >validation policy or of the root key that has been used.
>
> yes, from the configured, default policy
>
> >Note 3 : In order to be able to store the yes /no answer in one place
> >without the need to store the evidence (that may be quite big) in the same
> >place, it is proposed to include the hash of the evidence in the signed
> >answer. This does not augment too much the size of the answer while
> >providing integrity protection without the need of a second digital
> >signature.
>
> this is getting a bit detailed to be a goal, but I agree with the motivation.
>
> > DPD goals:
> >
> >Obtain one or more certification paths and optionally its associated
> >revocation information for a leaf certificate according either to a
> >validation policy or a trust anchor.
>
> As above, this may be a client option to request, but a server must
> be prepared to provide the revocation status info.

O.K.

> >Optionally specify naming and CP constraints.
>
> I assume the same set of constraints as for DPV, right?

Right, while I would expect a DPV client either to reference a validation
policy or look if the used policy is acceptable, rather than specifying in
detail that validation policy.

> >Provide a replay protection (no date is necessary).
>
> Necessary.
>
> >Note 1 : Either a full certification path is returned or nothing (no
> >certification path nor revocation information).
>
> OK.
>
> >Note 2 : When a full path is found, all the associated revocation
> >information is not necessarily found. However, the revocation information
> >that has been found is returned.
>
> No. I want the path to be valid, and if the server can't provide the
> revocation status info, then it does not know if the path is valid.

We have a slight disagreement here. You accepted the goal which is: "Obtain
one or more certification paths and optionally its associated revocation
information for a leaf certificate according either to a validation policy
or a trust anchor.". In that sentence, the word "valid" does not exist. In
other words, DPD only *helps* a PKI-aware client to know whether a
certificate is valid. It is better to return what can be returned as far a
revocation information is concerned rather than nothing. You also noticed
that a client may only request the certification path, without the
revocation information.

> >Note 3 : For one element of the path, both a CRL (or base CRL and delta) and
> >an OCSP response may be returned (if both exist) as associated revocation
> >information.
>
> For EACH (not one) element ...

Correct.

> >Note 4 : if the validation policy or a root key (public key value and CA
> >name) is missing, then the server will designate in the response the default
> >validation policy or root key or the self-signed certificate that has been
> >used.
>
> right, see note above re point Note 2 under DPV.
>
> >Note 5: each path starts with the leaf certificate (or its reference) and
> >ends up either with a self-signed certificate or a root key associated with
> >a CA name.
>
> each path ends with a trust anchor

Yes.

> >Note 6 : When only the reference of the certificate is provided in the
> >request (i.e. ESSCertID) and when requested, the server may include the leaf
> >certificate in the returned paths.
>
> OK.
>
> >Note 7: in case full revocation information is not found, the client may
> >send back (using the sequence of useful certificates and a sequence of
> >useful revocation information) one of the certification path and the
> >associated revocation information that he got, in order to try to obtain
> >more revocation information. This avoids to have a stateful server.
>
> The strawman spec already allows the client to submit a set of certs
> and revocation status data so this is an unduly narrow
> characterization.
>
> >
> >If we can agree on these goals, then I am ready to send a detailed proposal
> >for the input and output parameters for each protocol.
>
> we're getting closer, but I see most of these "goals" as a subset of
> or refinement of the strawman spec. I don't want to reduce the scope
> of that spec to the subset required above. also, I've seen some
> comments suggesting that optional support for post-facto validation
> for DPV is desirable.

This topic is being discussed on another thread and is still open.

Denis

Note: No more comments below.

> >Let me now answer to one of your questions and then comment on another one.
> >
> >1. [Steve]
> >
> > >You say "that providing anything other than the target cert per se has
> > >potential problems and adds complexity to the server". However, you do not
> > >provide arguments to support this statement.
> >
> >Any means of referring to a cert, other than providing the cert, is
> >problematic. For example, issuer name and serial number is ambiguous
> >because we can't guarantee uniqueness of issuer names. A hash of a
> >cert fails to help me locate the cert if I can't find it in a local
> >cache. A subject key identifier has a similar problem. We had
> >similar discussions re certificate references in the attribute
> >certificate realm.
> >
> >Your example does not seem to address this concern, or maybe we're
> >just miscommunicating on another level.
> >
> >[Denis]
> >
> >When you use ESSCertID (defined in RFC 2634), it does address your concern,
> >since ESSCertID may carry both the properties you mentioned: issuer name and
> >serial number (to locate the certificate) but also a hash of a cert (to make
> >it unambiguous).
>
> Good point. IF we adopt that structure, it would avoid the problems I
> noted above.
>
> >2. [Denis]
> >
> > >I agree with you that "we already have application protocols where a client
> > >that is not PKI-aware might acquire cert paths and/or revocation data that
> > >he could pass on to a DPV server." The S/MIME example I provided is one
> > >such example. However, this would mean that each blob able to contain
> > > such cert paths and/or revocation data would have to be passed
> > >"as it is", i.e. without being opened by the application. I made the list
> > > of such data structures for three documents from the S/MIME working
> > > group. If we proceed in that direction, then we should ask the other
> > > working groups (e.g. IPSEC, TLS) to provide us with a list of the data
> > > structures that are relevant. If this list is not too large, then it could
> > > make sense to support all of them, otherwise, we would have to
> > > consider that this is not practical.
> > >
> > >If you agree with this idea, it could be interesting that we raise the
> > >question to the other working groups.
> >
> >[Steve]
> >
> >Good points. I have glibly discussed having these apps pass in certs
> >and CRLs, but without taking into account the implications of this
> >model. If we agree to support data structures from these protocols,
> >then we make life easier for these clients, but servers have to be
> >aware of each distinct data structure. We might standardize on a
> >few, common formats now in use, and encourage future apps to make use
> >of these structures, while still providing tags to identify them and
> >thus accommodate new structures if needed.
> >
> >[Denis]
> >
> >We both agree. So would you be sending such a request on the IPSEC and TLS
> >mailing lists ?
>
> Yes.
>
> Steve

Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id AAA17959 for ; Tue, 23 Jan 2001 00:46:19 -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 JAA47326; Tue, 23 Jan 2001 09:59:30 +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 JAA18146; Tue, 23 Jan 2001 09:51:48 +0100
Message-ID: <[email-masked]>
Date: Tue, 23 Jan 2001 09:51:49 +0100
From: Denis Pinkas
Organization: Bull
X-Mailer: Mozilla 4.7 [fr] (Win98; I)
X-Accept-Language: fr
MIME-Version: 1.0
To: Steve Hanna
CC: Stephen Kent , PKIX List
Subject: Re: Need to support non-ASN.1 DPV clients?
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Steve (Hanna),

( ...)

> > For the time being I would suggest that the consensus is: "We do not need to
> > support non-ASN.1-capable DPV clients."
>
> Since Steve Kent's requirements did not propose to support
> non-ASN.1-capable, PKI-aware DPV clients, you are right that the
> decision reached last week (not to support non-PKI aware,
> non-ASN.1-capable DPV clients) implies that "We do not need to support
> non-ASN.1-capable DPV clients."

I do not "buy" your phrasing. It is not an implication, it is the basis of
the agreement. DPV has to be usable by a non-PKI aware client, or, let us
say, by a client with very limited PKI knowledge.

> > I have advocated the use of "blobs" for both the request parameters and the
> > optional result for a DPV client. This allows to have non-PKI aware clients.
> > Maybe there are some variations under that wording, but certainly a DPV
> > client is not DPD capable. Hence a good reason for the separation of the two
> > functionality.

> The set of inputs for the DPV and DPD protocols are remarkably similar.

The inputs, the goal of request and the responses are quite different.

> As long as we design the protocol properly, I don't see why there should
> be any problem using one protocol for both.

Let us look at the details below.

> A non-PKI-aware client can
> pass blobs in and out (binary objects whose contents it does not
> understand). A PKI-aware client will understand the contents of those
> objects. A non-PKI-aware client will trust the server (although it may
> archive the blob for someone else to analyze later). A PKI-aware client
> may or may not trust the server.

I agree with you on the above statements. It is now time to go for a
proposal where you will see the differences. I made no attempt to look for
the similarities, but I am confident you will do that exercise. :-)

I will be posting the proposal in a different message, so that it can be
discussed more easily.

Denis

> -Steve

Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id AAA16039 for ; Tue, 23 Jan 2001 00:32: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 JAA47938; Tue, 23 Jan 2001 09:45: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 JAA17060; Tue, 23 Jan 2001 09:37:56 +0100
Message-ID: <[email-masked]>
Date: Tue, 23 Jan 2001 09:37:58 +0100
From: Denis Pinkas
Organization: Bull
X-Mailer: Mozilla 4.7 [fr] (Win98; I)
X-Accept-Language: fr
MIME-Version: 1.0
To: Russ Housley
CC: PKIX-List
Subject: Re: Post-facto queries [Was: RE: DPD & DPV requirements]
References: <[email-masked]> <[email-masked]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Russ,

> Denis:
>
> I agree with 1, 2a, and 2b.

Fine.

> I cannot accept 2c.

I said: " I believe that we should think more about the consequences before
supporting this service." I still think it !

> Just because a retrospective check is available does not mean that
> current-time checking will stop.

Fine. But if current-time checking is done, there is no need any more for a
retrospective check. So what would be the additional value of a
retrospective check if current-time checking is done ?

> Retrospective checking has always been
> viewed as a concern, especially in a dispute. This allows us to allocate
> the data archive necessary to perform such checking to a server rather than
> every client.

Let me rephrase the issue in a different way. We have two options:

a) either support time stamping of every individual CRL in the server (I
wanted to avoid this), or
b) support no time stamping in the server.

In case (a), the service would work in any case, provided that the chosen
TSA is "acceptable" to the relying party.
In case (b), the service would not work any more in case of a CA key
compromise.

The additional problem to be considered is that the structure of the answer
in case (a) would be different from the answer in the case of a current-time
checking, since one structure would include individual time stamps while the
other would not.

Which case do we want to support ?

Once again, I believe that we should think more about the consequences
before rushing to support this service.

Denis

> Russ
>
> At 05:37 PM 1/22/2001 +0100, Denis Pinkas wrote:
> >Russ,
> >
> > > I think this is a very good idea. I strongly encourage us to do it.
> >
> >Wait a second. :-)
> >
> >It would be nice to get such a service ... but we have to think about the
> >consequences.
> >
> >1) If such service would exist, then it should be clear that it should only
> >be optional.
> >2) The functions of a CA should not be changed because of the existence of
> >this functionality.
> >
> >What are the implications ?
> >
> >a) Such a service would not work as soon as revocation status would be
> >obtained through OCSP responses. There is a move to get the revocation
> >status of the leaf certificate using OCSP. Such service would thus be
> >unusable in that case.
> >
> >b) Such a service would work if CRLs and delta CRls were all captured by a
> >TTP *different* from the CA. The size of the storage might become quite
> >important.
> >
> >c) Such a service would degrade the security. Let me explain. If people can
> >say: "We will check later, since we have a server always giving us the right
> >answer", then will rely on it and will not ask for the certificatio path and
> >revocation information at the time of initial verification. What can happen
> >between initial verification and a later verification ? The answer is: a key
> >compromise of a CA issuing key.
> >
> >Today by time-stamping the whole certification path and revocation
> >information (i.e. the evidence) you can protect against that threat.
> >
> >If you would like to get the same protection the server would need to obtain
> >a time-stamp on every individual CRL and delta CRL and we would be
> >encouraging structures like individual time-stamped CRLs and individual
> >time-stamped delta-CRLs.
> >
> >In other words, supporting this service would imply supporting time-stamping
> >by the server. We wanted to avoid the support of time stamping by a DPV
> >server and leave it to the discretion of the client.
> >
> >I believe that we should think more about the consequences before supporting
> >this service.
> >
> >Regards,
> >
> >Denis
> >
> >
> > > Russ
> > >
> > > At 04:59 AM 1/20/2001 -0500, Linn, John wrote:
> > > >Considering one point arising within this thread:
> > > >
> > > > >
> > > > >
> > > > >[Steve]
> > > > >
> > > > >There was some sentiment for having the "was it valid then" function as
> > > > >provided in SCVP, but if there is not continued support we could
> > delete it.
> > > > >I want to get more feedback on this issue.
> > > > >
> > > > >[Denis]
> > > > >
> > > > >So, let us wait and see ...
> > > > >
> > > > >I'm not seeing any support for retrospective queries, so I think
> > we'll drop
> > > >it.
> > > >
> > > >I think it'd be useful to be able to support post-facto queries in the DPV
> > > >framework. If a query specified a non-current time, a server could (if it
> > > >had the requisite info to determine then-current status) return the
> > > >appropriate status indication or else, without prejudice, indicate "unable
> > > >to determine status for requested time". I can see value for DPV, and
> > valid
> > > >requirements to make post-facto status determinations, and would rather
> > > >include such a hook than incur a need to define another generation of
> > > >certificate validation protocol in order to represent their conjunction.
> > > >
> > > >--jl

Received: from janus.hosting4u.net (janus.hosting4u.net [209.15.2.37]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id XAA05458 for ; Mon, 22 Jan 2001 23:28:58 -0800 (PST)
Received: (qmail 13968 invoked from network); 23 Jan 2001 07:34:53 -0000
Received: from taurus.hosting4u.net (209.15.2.33) by mail-gate.hosting4u.net with SMTP; 23 Jan 2001 07:34:53 -0000
Received: from nma.com ([63.204.17.82]) by taurus.hosting4u.net ; Tue, 23 Jan 2001 01:34:52 -0600
Message-ID: <[email-masked]>
Date: Mon, 22 Jan 2001 23:35:03 -0800
From: Ed Gerck
X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; I)
X-Accept-Language: en
MIME-Version: 1.0
To: Bob Jueneman
CC: [email-masked], [email-masked]
Subject: Re: (DVD to DVP ga fajii shisutemu desu ka?)
References:
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Bob Jueneman wrote:

> And I quite agree that although "trust" without a predicate
> "with respect to rule X" is meaningless, "reliance" can be
> binary if the rules are satisfied to an acceptable level of
> confidence. And if the reliance part of the equation is
> satisfied, then dependence is presumably a rational decision.

In deed, Trust can be defined as "that which I rely upon for my decisions".
But this is only the subjective stance (eg, for one host, for mysef, etc.).
It does not work intersubjectively, for example between Internet hosts.

In such cases, rather than saying "A trusts B", one should say (and define)
"A trusts B on matters of X at epoch T" because trust depends on time
and locality (epoch) as well as "matters of X" (the predicate).

More on this approach and the information-theoretic definition of trust
in http://www.mcg.org.br/trustdef.htm

Cheers,

Ed Gerck

Received: from po1.bbn.com (PO1.BBN.COM [192.1.50.38]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id UAA24501 for ; Mon, 22 Jan 2001 20:09:31 -0800 (PST)
Received: from [128.33.238.51] (TC051.BBN.COM [128.33.238.51]) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id XAA12699; Mon, 22 Jan 2001 23:15:25 -0500 (EST)
Mime-Version: 1.0
X-Sender: [email-masked] (Unverified)
Message-Id:
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Date: Mon, 22 Jan 2001 18:31:18 -0500
To: Denis Pinkas
From: Stephen Kent
Subject: Re: DPD & DPV requirements
Cc: PKIX-List
Content-Type: text/plain; charset="us-ascii" ; format="flowed"

Denis,

>DPV goals:
>
>Validate a leaf certificate according either to a validation policy or one
>(or more ?) trust anchor (public key value, CA name and optionally a
>validity period) including CP and naming constraints.

yes

>
>Obtain a signed " yes, no or incomplete " answer to the question together
>with the date of validation.

yes

>Optionally provide a replay protection if no time is available on the
>client.

I would say that replay protection is necessary, period. The question
is whether the protocol will meet this requirement via nonces or some
other mechanism.

>Optionally obtain the evidence to support the yes answer

I think it is a client option to request evidence, but a server MUST
be able to provide the evidence.

>Note 1: A complete certification path is one that satisfies all of the
>validation criteria specified in RFC 2459bis and that terminates at a trust
>anchor (public key value, CA name and optionally a validity period) that may
>include Certification Policy constraints as well as naming constraints.

yes, plus any other validation parameters defined by 2459bis.

>Note 2 : if a "ValidationPolicyRef" parameter or the trust anchor is missing
>in the request, then the server will return back either the
>ValidationPolicyRef that has been used or alternatively a description of the
>validation policy or of the root key that has been used.

yes, from the configured, default policy

>Note 3 : In order to be able to store the yes /no answer in one place
>without the need to store the evidence (that may be quite big) in the same
>place, it is proposed to include the hash of the evidence in the signed
>answer. This does not augment too much the size of the answer while
>providing integrity protection without the need of a second digital
>signature.

this is getting a bit detailed to be a goal, but I agree with the motivation.

> DPD goals:
>
>Obtain one or more certification paths and optionally its associated
>revocation information for a leaf certificate according either to a
>validation policy or a trust anchor.

As above, this may be a client option to request, but a server must
be prepared to provide the revocation status info.

>Optionally specify naming and CP constraints.

I assume the same set of constraints as for DPV, right?

>Provide a replay protection (no date is necessary).

Necessary.

>Note 1 : Either a full certification path is returned or nothing (no
>certification path nor revocation information).

OK.

>Note 2 : When a full path is found, all the associated revocation
>information is not necessarily found. However, the revocation information
>that has been found is returned.

No. I want the path to be valid, and if the server can't provide the
revocation status info, then it does not know if the path is valid.

>Note 3 : For one element of the path, both a CRL (or base CRL and delta) and
>an OCSP response may be returned (if both exist) as associated revocation
>information.

For EACH (not one) element ...

>Note 4 : if the validation policy or a root key (public key value and CA
>name) is missing, then the server will designate in the response the default
>validation policy or root key or the self-signed certificate that has been
>used.

right, see note above re point Note 2 under DPV.

>Note 5: each path starts with the leaf certificate (or its reference) and
>ends up either with a self-signed certificate or a root key associated with
>a CA name.

each path ends with a trust anchor

>Note 6 : When only the reference of the certificate is provided in the
>request (i.e. ESSCertID) and when requested, the server may include the leaf
>certificate in the returned paths.

OK.

>Note 7: in case full revocation information is not found, the client may
>send back (using the sequence of useful certificates and a sequence of
>useful revocation information) one of the certification path and the
>associated revocation information that he got, in order to try to obtain
>more revocation information. This avoids to have a stateful server.

The strawman spec already allows the client to submit a set of certs
and revocation status data so this is an unduly narrow
characterization.

>
>If we can agree on these goals, then I am ready to send a detailed proposal
>for the input and output parameters for each protocol.

we're getting closer, but I see most of these "goals" as a subset of
or refinement of the strawman spec. I don't want to reduce the scope
of that spec to the subset required above. also, I've seen some
comments suggesting that optional support for post-facto validation
for DPV is desirable.

>Let me now answer to one of your questions and then comment on another one.
>
>1. [Steve]
>
> >You say "that providing anything other than the target cert per se has
> >potential problems and adds complexity to the server". However, you do not
> >provide arguments to support this statement.
>
>Any means of referring to a cert, other than providing the cert, is
>problematic. For example, issuer name and serial number is ambiguous
>because we can't guarantee uniqueness of issuer names. A hash of a
>cert fails to help me locate the cert if I can't find it in a local
>cache. A subject key identifier has a similar problem. We had
>similar discussions re certificate references in the attribute
>certificate realm.
>
>Your example does not seem to address this concern, or maybe we're
>just miscommunicating on another level.
>
>[Denis]
>
>When you use ESSCertID (defined in RFC 2634), it does address your concern,
>since ESSCertID may carry both the properties you mentioned: issuer name and
>serial number (to locate the certificate) but also a hash of a cert (to make
>it unambiguous).

Good point. IF we adopt that structure, it would avoid the problems I
noted above.

>2. [Denis]
>
> >I agree with you that "we already have application protocols where a client
> >that is not PKI-aware might acquire cert paths and/or revocation data that
> >he could pass on to a DPV server." The S/MIME example I provided is one
> >such example. However, this would mean that each blob able to contain
> > such cert paths and/or revocation data would have to be passed
> >"as it is", i.e. without being opened by the application. I made the list
> > of such data structures for three documents from the S/MIME working
> > group. If we proceed in that direction, then we should ask the other
> > working groups (e.g. IPSEC, TLS) to provide us with a list of the data
> > structures that are relevant. If this list is not too large, then it could
> > make sense to support all of them, otherwise, we would have to
> > consider that this is not practical.
> >
> >If you agree with this idea, it could be interesting that we raise the
> >question to the other working groups.
>
>[Steve]
>
>Good points. I have glibly discussed having these apps pass in certs
>and CRLs, but without taking into account the implications of this
>model. If we agree to support data structures from these protocols,
>then we make life easier for these clients, but servers have to be
>aware of each distinct data structure. We might standardize on a
>few, common formats now in use, and encourage future apps to make use
>of these structures, while still providing tags to identify them and
>thus accommodate new structures if needed.
>
>[Denis]
>
>We both agree. So would you be sending such a request on the IPSEC and TLS
>mailing lists ?

Yes.

Steve

Received: from po1.bbn.com (PO1.BBN.COM [192.1.50.38]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id UAA24385 for ; Mon, 22 Jan 2001 20:08:45 -0800 (PST)
Received: from [128.33.238.51] (TC051.BBN.COM [128.33.238.51]) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id XAA12533; Mon, 22 Jan 2001 23:14:44 -0500 (EST)
Mime-Version: 1.0
X-Sender: [email-masked] (Unverified)
Message-Id:
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Date: Mon, 22 Jan 2001 14:48:22 -0500
To: Frank Balluffi
From: Stephen Kent
Subject: RE: DID & DIP requirements
Cc: [email-masked]
Content-Type: text/plain; charset="us-ascii" ; format="flowed"

Frank,

>Steve Kent said:
>
> > How about the following definition:
> >
> > A complete certification path is one that satisfies all of the
> > validation criteria specified in RFC 2459bis and that terminates at a
> > certificate configured as a trust anchor in the server and specified
> > by reference to the policy containing that path, or a path that
> > terminates at a trust anchor certificate supplied by the client in a
> > request.
>
>Good. I find "and specified by reference to the policy containing that path"
>a bit awkward. I assume you mean the path satisfies the validation criteria
>specified by the policy.

Yes, including trust anchors specified by the policy.

Steve

Received: from prv-mail20.provo.novell.com (prv-mail20.provo.novell.com [137.65.81.122]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id QAA21286 for ; Mon, 22 Jan 2001 16:36:02 -0800 (PST)
Received: from INET-PRV-Message_Server by prv-mail20.provo.novell.com with Novell_GroupWise; Mon, 22 Jan 2001 17:41:32 -0700
Message-Id:
X-Mailer: Novell GroupWise Internet Agent 5.5.5.1
Date: Mon, 22 Jan 2001 17:41:26 -0700
From: "Bob Jueneman"
To:
Cc: ,
Subject: Re: (DVD to DVP ga fajii shisutemu desu ka?)
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=_C19A9A2C.D1B0E003"

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

--=_C19A9A2C.D1B0E003
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

Back in 1989, I wrote a paper entitled "Integrity Controls for=20
Military and Commercial Applications". as a contribution to an=20
Invitational Workshop on Data Integrity held at NIST. (

Unfortunately, due to technology obsolescence I don't have=20
soft-copy, but as I recall it was reprinted in a compendium of=20
integrity papers edited by Marshall Abrams. And I'd be happy=20
to send you a hard copy if you are interested.)

In that paper, I tried to address the concerns raised by Clark=20
and Wilson regarding integrity, and laid out an approach to=20
integrating integrity considerations with confidentiality=20
considerations using the classical Biba/Bell-Lapadua=20
mandatory access control model of a Trusted Computer Base.

Unlike conventional military systems, where the security=20
classification level is normally the primary concern, and=20
compartments or categories are the exception, in the Biba=20
model and my extension, the compartments become=20
capabilities or rules, and the integrity levels are perhaps=20
less important. In particular, each labeled compartment becomes=20
a name of or citation to a particular "integrity process rule" which =
the=20
process which created the data is alleged to have satisfied.

But interestingly enough vis a vis your suggestion, I did suggest=20
that a probabilistic or heuristic "confidence level" could perhaps=20
be used as an integrity level, as part of the mandatory access=20
control decision.

And I quite agree that although "trust" without a predicate=20
"with respect to rule X" is meaningless, "reliance" can be=20
binary if the rules are satisfied to an acceptable level of=20
confidence. And if the reliance part of the equation is=20
satisfied, then dependence is presumably a rational decision. =20
If the reliance value is not a binary "TRUE", then dependence=20
may still be in order, but based upon other heuristics and/or=20
perception of risks, even down to the gut-level hunch, so=20
long as it is the relying party's money that he is betting.

Regards,

Bob

Robert R. Jueneman
Security Architect

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

>>> Michael Sierchio 01/22/01 05:08PM >>>
Bob Jueneman wrote:

> In other words, trust, like integrity, is not some binary value that is
> independent of any predicate. Instead, something, either a process
> or the data that was produced as a result of some process, is "trusted"
> if and only if the process conforms to a specified set of rules or
> expectations. It is clearly not possible for a process to be tested
> against all possible rules in the universe, so without qualifying the
> trust to a particular set of rules, the question is meaningless.

Trust may be fuzzy -- it depends on subjective evaluation, etc. But
reliance follows an act of defuzzification (a technical term, believe
it or not) in which the fuzzy output set is converted to a crisp
(yes, binary) number (we open the box and the cat is either dead or=20
alive).

Open to the chapter with the heading:

Trust -> Confidence -> Reliance -> Dependence

Audun J=F8sang(*) suggests an interesting approach to modelling trust.=20
Belief trust requires an assessment of external data (or capta), the
accuracy, completeness, truthfulness and reliability of which may
not be known perfectly by a relying party.

Even with a fixed ruleset it seems to me that the problem is one
of constraint based reasoning under conditions of uncertainty.
Do you propose that a validation responder, for example, reply with a=20
membership grade (percent probability of being valid)? That actually
seems reasonable and promising. This is a nascent research area.

*)
http://www.item.ntnu.no/~ajos/PhD.html

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

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

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

--=_C19A9A2C.D1B0E003--

Received: from inspiron.tenebras.com (adsl-64-163-143-195.dsl.snfc21.pacbell.net [64.163.143.195]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id QAA20321 for ; Mon, 22 Jan 2001 16:26:46 -0800 (PST)
Received: from dnai.com (localhost [127.0.0.1]) by inspiron.tenebras.com (8.11.1/8.9.3) with ESMTP id f0N08xl18651; Mon, 22 Jan 2001 16:09:30 -0800 (PST) (envelope-from [email-masked])
Sender: [email-masked]
Message-ID: <[email-masked]>
Date: Mon, 22 Jan 2001 16:08:58 -0800
From: Michael Sierchio
X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.12 i386)
X-Accept-Language: en
MIME-Version: 1.0
To: Bob Jueneman
CC: [email-masked], [email-masked]
Subject: (DVD to DVP ga fajii shisutemu desu ka?)
References:
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit

Bob Jueneman wrote:

> In other words, trust, like integrity, is not some binary value that is
> independent of any predicate. Instead, something, either a process
> or the data that was produced as a result of some process, is "trusted"
> if and only if the process conforms to a specified set of rules or
> expectations. It is clearly not possible for a process to be tested
> against all possible rules in the universe, so without qualifying the
> trust to a particular set of rules, the question is meaningless.

Trust may be fuzzy -- it depends on subjective evaluation, etc. But
reliance follows an act of defuzzification (a technical term, believe
it or not) in which the fuzzy output set is converted to a crisp
(yes, binary) number (we open the box and the cat is either dead or
alive).

Open to the chapter with the heading:

Trust -> Confidence -> Reliance -> Dependence

Audun Jøsang(*) suggests an interesting approach to modelling trust.
Belief trust requires an assessment of external data (or capta), the
accuracy, completeness, truthfulness and reliability of which may
not be known perfectly by a relying party.

Even with a fixed ruleset it seems to me that the problem is one
of constraint based reasoning under conditions of uncertainty.
Do you propose that a validation responder, for example, reply with a
membership grade (percent probability of being valid)? That actually
seems reasonable and promising. This is a nascent research area.

*)
http://www.item.ntnu.no/~ajos/PhD.html

Received: from e3.ny.us.ibm.com (e3.ny.us.ibm.com [32.97.182.103]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA18980 for ; Mon, 22 Jan 2001 15:29:53 -0800 (PST)
Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.117.200.22]) by e3.ny.us.ibm.com (8.9.3/8.9.3) with ESMTP id SAA144852; Mon, 22 Jan 2001 18:35:01 -0500
Received: from d02ml237.somers.hqregion.ibm.com (d02ml237.sby.ibm.com [9.45.4.171]) by northrelay02.pok.ibm.com (8.8.8m3/NCO v4.95) with ESMTP id SAA58028; Mon, 22 Jan 2001 18:32:54 -0500
Importance: Normal
Subject: Re: Post-facto queries [Was: RE: DPD & DPV requirements]
To: Russ Housley
Cc: Denis Pinkas , PKIX-List
X-Mailer: Lotus Notes Release 5.0.3 (Intl) 21 March 2000
Message-ID:
From: "Tom Gindin"
Date: Mon, 22 Jan 2001 18:35:54 -0500
X-MIMETrack: Serialize by Router on D02ML237/02/M/IBM(Release 5.0.6 |December 14, 2000) at 01/22/2001 06:35:56 PM
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii

As long as it is understood that a non-repudiation service (whether
technical or a stronger variant) should not rely primarily on post-facto
validation queries, supporting them is IMO not harmful. Denis is quite
right to worry about the effects of excessive reliance on them.

Tom Gindin

Russ Housley on 01/22/2001 01:36:25 PM

To: Denis Pinkas
cc: PKIX-List
Subject: Re: Post-facto queries [Was: RE: DPD & DPV requirements]

Denis:

I agree with 1, 2a, and 2b. I cannot accept 2c.

Just because a retrospective check is available does not mean that
current-time checking will stop. Retrospective checking has always been
viewed as a concern, especially in a dispute. This allows us to allocate
the data archive necessary to perform such checking to a server rather than
every client.

Russ

At 05:37 PM 1/22/2001 +0100, Denis Pinkas wrote:
>Russ,
>
> > I think this is a very good idea. I strongly encourage us to do it.
>
>Wait a second. :-)
>
>It would be nice to get such a service ... but we have to think about the
>consequences.
>
>1) If such service would exist, then it should be clear that it should
only
>be optional.
>2) The functions of a CA should not be changed because of the existence of
>this functionality.
>
>What are the implications ?
>
>a) Such a service would not work as soon as revocation status would be
>obtained through OCSP responses. There is a move to get the revocation
>status of the leaf certificate using OCSP. Such service would thus be
>unusable in that case.
>
>b) Such a service would work if CRLs and delta CRls were all captured by a
>TTP *different* from the CA. The size of the storage might become quite
>important.
>
>c) Such a service would degrade the security. Let me explain. If people
can
>say: "We will check later, since we have a server always giving us the
right
>answer", then will rely on it and will not ask for the certificatio path
and
>revocation information at the time of initial verification. What can
happen
>between initial verification and a later verification ? The answer is: a
key
>compromise of a CA issuing key.
>
>Today by time-stamping the whole certification path and revocation
>information (i.e. the evidence) you can protect against that threat.
>
>If you would like to get the same protection the server would need to
obtain
>a time-stamp on every individual CRL and delta CRL and we would be
>encouraging structures like individual time-stamped CRLs and individual
>time-stamped delta-CRLs.
>
>In other words, supporting this service would imply supporting
time-stamping
>by the server. We wanted to avoid the support of time stamping by a DPV
>server and leave it to the discretion of the client.
>
>I believe that we should think more about the consequences before
supporting
>this service.
>
>Regards,
>
>Denis
>
>
> > Russ
> >
> > At 04:59 AM 1/20/2001 -0500, Linn, John wrote:
> > >Considering one point arising within this thread:
> > >
> > > >
> > > >
> > > >[Steve]
> > > >
> > > >There was some sentiment for having the "was it valid then" function
as
> > > >provided in SCVP, but if there is not continued support we could
> delete it.
> > > >I want to get more feedback on this issue.
> > > >
> > > >[Denis]
> > > >
> > > >So, let us wait and see ...
> > > >
> > > >I'm not seeing any support for retrospective queries, so I think
> we'll drop
> > >it.
> > >
> > >I think it'd be useful to be able to support post-facto queries in the
DPV
> > >framework. If a query specified a non-current time, a server could
(if it
> > >had the requisite info to determine then-current status) return the
> > >appropriate status indication or else, without prejudice, indicate
"unable
> > >to determine status for requested time". I can see value for DPV, and
> valid
> > >requirements to make post-facto status determinations, and would
rather
> > >include such a hook than incur a need to define another generation of
> > >certificate validation protocol in order to represent their
conjunction.
> > >--jl

Received: from prv-mail20.provo.novell.com (prv-mail20.provo.novell.com [137.65.81.122]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id PAA18507 for ; Mon, 22 Jan 2001 15:15:35 -0800 (PST)
Received: from INET-PRV-Message_Server by prv-mail20.provo.novell.com with Novell_GroupWise; Mon, 22 Jan 2001 16:21:06 -0700
Message-Id:
X-Mailer: Novell GroupWise Internet Agent 5.5.5.1
Date: Mon, 22 Jan 2001 16:20:59 -0700
From: "Bob Jueneman"
To:
Cc:
Subject: Re: DPD & DPV requirements
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id PAA18508

Quite so. The problem with the existing cross-certificate structure, and with
top-down name constraints, is that they are imposed on subordinate
entities, rather willy-nilly, by the CAs, without providing a mechanism
for the relying parties to specify the extent to which they wish to trust the
CAs themselves, other than by switching roots. In particular, there is no
ability to control "delegation" (trust, really) in the upwards direction.

And I remain convinced that name subordination is a badly broken
mechanism. It really doesn't work in a multi-lingual environment,
and except perhaps in certain closed user group organizational constructs
it simply doesn't work at all.

What am I supposed to do with respect to a residentialPerson --
reject anyone whose certificate indicates that they reside in the State of
California? (Not such a bad idea, actually, considering how they have
managed to screw up their power infrastructure and are now relying
on their neighboring states to help them out.)

The Novell Security Attributes construct was invented to solve precisely
the kinds of problems you have pointed out.

Bob

>>> Russ Housley 01/22/01 03:08PM >>>
Peter:

Your question regarding cross-certificates makes an assumption about trust
models that is not universal. Also, the mechanism that I proposed allows
the relying party, not a CA, is impose name constraints (in the same way
that the relying party can impose policy constraints).

Russ

At 06:30 PM 1/22/2001 +0100, Peter Sylvester wrote:
> >
> > I would like to second Russ Housley's comments above for associating name
> > constraints with trust anchors. Without naming constraints we would get
> > security threats that would imply global trust, which is not a real life
> > situation. If other words, I want to be able to detect when company X
> > certifies a name from a user (or entity) from company Y, and when this is
> > not allowed.
> >
> > Denis
> >
> >
>
>Can you give an example what do you want to do that you cannot
>do with an appropriate cross certificate.

Received: from prv-mail20.provo.novell.com (prv-mail20.provo.novell.com [137.65.81.122]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id PAA18151 for ; Mon, 22 Jan 2001 15:03:03 -0800 (PST)
Received: from INET-PRV-Message_Server by prv-mail20.provo.novell.com with Novell_GroupWise; Mon, 22 Jan 2001 16:08:34 -0700
Message-Id:
X-Mailer: Novell GroupWise Internet Agent 5.5.5.1
Date: Mon, 22 Jan 2001 16:08:29 -0700
From: "Bob Jueneman"
To:
Cc:
Subject: RE: DVD & DVP requirements
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id PAA18152

Steve, you said in part:
>
>I'd like to better understand what parameters the client will change
>between invocations of a DPD server, in a controlled fashion, to make
>multiple invocations for the same target certificate provide
>distinct, useful, answers. Do you have some examples that could
>clarify this scenario?
>
>Steve

Let me give you a possible "existence proof " of such a scenario.

There's an old joke about a Vermonter, who when asked, "How's
your wife?" replied "Compared to what?"

When we have said in this context, "Is this certificate chain valid?",
we should really be asking "Can I trust this certificate chain?"
and the only reasonable answer to that question is to say
"compared to what?" or more precisely, "Trust it for what purpose?"

In other words, trust, like integrity, is not some binary value that is
independent of any predicate. Instead, something, either a process
or the data that was produced as a result of some process, is "trusted"
if and only if the process conforms to a specified set of rules or
expectations. It is clearly not possible for a process to be tested
against all possible rules in the universe, so without qualifying the
trust to a particular set of rules, the question is meaningless.

Now, the reason why a client or relying party might ask the server t
hat question is obviously a function of the client's current context, i.e.,
the type of transaction or whatever that is being evaluated.

And clearly, that context may vary, depending on the perceived value
of the transaction, the history of that transaction and previous
transactions with that signer, etc.

If the client is trying to decide whether to honor a purchase order
for a single quart of 10-40 motor oil, the risk analysis for such a
transaction would probably suggest that the probability of default
is low, and that continued customer good will is worth more than
that risk. In that case, maybe it isn't even worth the bother of
consulting the server, except perhaps for auditing or logging
purposes.

On the other hand, if that very same client is evaluating a purchase
order for one hundred million barrels of crude oil, to be delivered
via multiple oil tankers FOB Saudi Arabia, then the risk analysis
would suggest that the buyer's credentials had better be
gilt-edged indeed.

As to how the parameters would be conveyed, a very simple,
existence-proof mechanism would be to simply encode the value
of the transaction in dollars, and let the server try do its thing.
maybe it has some artificial intelligence program that parses the
Certificate Practice Statement and does a risk assessment.
Or maybe it simply looks up the net worth of the buyer and the
CA in Dun and Bradstreet and decides accordingly.

Of course, since I have a hammer and this looks like a nail,
I would suggest that a better mechanism would be to use
the Novell Security Attributes (cf. http://developer/novell.com/repository/attributes/certattrs_v10.htm),
and to have the client either encode a minimum set of those
attributes for this particular transaction. Or more likely,
the client would be preconfigured with a set of attributes
labeled platinum, gold, silver, bronze, green and brown,
and would select one of those for certain kinds of transactions,

Whether the name of the attribute string was sent to the
server, or the content of the attribute wouldn't matter that much.
The important point is that the MAC label portion could be used
to encode what CAs (registries) that may have been certified
by a particular root are to be trusted in this context, as well as
what enterprises. And individuals and/or role within an enterprise
can be encoded to indicate whether o not that person is required
to have Purchasing Agent authority, or perhaps Owner or
Managing Director authority.

And regardless of the claimed authority, the certificate quality
portion of the Novell Security Attributes label would convey useful
information as to how and where the key as generated (the
assurance level of the platform), the assurance level of the
platform where the key will actually be used, and how and where
the key was stored in the meantime. And finally, there would
be a minimum certificate class requirement that would deal with
the nature of the end-entity and the due diligence invested by
the CA in confirming both the nature of the end-entity and the
right of that end-entity to use those credentials.

Given a compact, machine-readable representation of
all of these parameters, I believe it should be obvious how the server
could validate the certificate chain. If all of the attributes were
encoded in the certificate chain itself, then other than perhaps
the difficulty of finding and downloading all of the certificates
the client could easily validate these parameters itself -- it's
just code, and I'm not assuming that this has to run on something
like a cellular phone.

But if all of the certificate do not contain pre-encoded Novell
Security Attributes, then perhaps the server knows something
about the issuer and their policies, perhaps as a result of some
human having read the CA's CPS and the end-entity's balance
sheet, and had prestored some judgements that can then be
presented.

In either case, the client can ask the question, "Is this certificate
chain trustworthy with respect to my "Platinum" criteria?" and get one
answer, and later ask the same question with respect to exactly the
same certificate chain, but specifying the "Green" criteria, and perhaps
get a different answer.

(BTW, a certificate chain that satisfies the Platinum criteria might
not satisfy the "Green" criteria. Bill Gates of Microsoft might satisfy
the platinum criteria, but if the item being bought was $35 worth of
a controlled substance, and the "Green" criteria required that either a
Doctor's or a Registered Pharmacist's DEA license number had
to be specified, then Bill's order wouldn't qualify.)

Regards,

Bob

Robert R. Jueneman
Security Architect

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

Received: from mail.spyrus.com (mail.spyrus.com [207.212.34.20]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA15663 for ; Mon, 22 Jan 2001 14:05:03 -0800 (PST)
Received: from RHOUSLEY-PC.spyrus.com ([209.172.119.210]) by mail.spyrus.com (8.9.3/8.9.3) with ESMTP id OAA24390; Mon, 22 Jan 2001 14:10:31 -0800 (PST)
Message-Id: <[email-masked]>
X-Sender: [email-masked]
X-Mailer: QUALCOMM Windows Eudora Version 5.0.2
Date: Mon, 22 Jan 2001 17:08:57 -0500
To: Peter Sylvester
From: Russ Housley
Subject: Re: DPD & DPV requirements
Cc: [email-masked]
In-Reply-To: <[email-masked]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed

Peter:

Your question regarding cross-certificates makes an assumption about trust
models that is not universal. Also, the mechanism that I proposed allows
the relying party, not a CA, is impose name constraints (in the same way
that the relying party can impose policy constraints).

Russ

At 06:30 PM 1/22/2001 +0100, Peter Sylvester wrote:
> >
> > I would like to second Russ Housley's comments above for associating name
> > constraints with trust anchors. Without naming constraints we would get
> > security threats that would imply global trust, which is not a real life
> > situation. If other words, I want to be able to detect when company X
> > certifies a name from a user (or entity) from company Y, and when this is
> > not allowed.
> >
> > Denis
> >
> >
>
>Can you give an example what do you want to do that you cannot
>do with an appropriate cross certificate.

Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA15003 for ; Mon, 22 Jan 2001 13:57:20 -0800 (PST)
Received: from eastmail2.East.Sun.COM ([129.148.1.241]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id OAA02779; Mon, 22 Jan 2001 14:03:13 -0800 (PST)
Received: from sunlabs.East.Sun.COM (sunlabs.East.Sun.COM [129.148.75.250]) by eastmail2.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id RAA01712; Mon, 22 Jan 2001 17:03:12 -0500 (EST)
Received: from sun.com (dhcp75-155 [129.148.75.155]) by sunlabs.East.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id RAA13133; Mon, 22 Jan 2001 17:03:10 -0500 (EST)
Message-ID: <[email-masked]>
Date: Mon, 22 Jan 2001 17:00:11 -0500
From: Steve Hanna
Organization: Sun Microsystems, Inc.
X-Mailer: Mozilla 4.75 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Denis Pinkas
CC: Stephen Kent , PKIX List
Subject: Re: Need to support non-ASN.1 DPV clients?
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Denis Pinkas wrote:
> > I have seen one response to my question:
> >
> > > Do we need to support non-PKI aware, non-ASN.1-capable DPV clients?
> >
> > Of course, the WG chair is responsible for judging consensus. But given
> > that the only response was in the negative (indicating that this work
> > will be done elsewhere) and that nobody has come forward to say we must
> > support non-ASN.1-capable DPV clients,
> > I will suggest that the consensus
> > answer is "No, we do not need to support non-PKI aware,
> > non-ASN.1-capable DPV clients."
>
> Your last sentence is not the same as the sentence above: "non-PKI aware"
> and "non ASN.1 capable" are not equivalent.
>
> For the time being I would suggest that the consensus is: "We do not need to
> support non-ASN.1-capable DPV clients."

Since Steve Kent's requirements did not propose to support
non-ASN.1-capable, PKI-aware DPV clients, you are right that the
decision reached last week (not to support non-PKI aware,
non-ASN.1-capable DPV clients) implies that "We do not need to support
non-ASN.1-capable DPV clients."

> I have advocated the use of "blobs" for both the request parameters and the
> optional result for a DPV client. This allows to have non-PKI aware clients.
> Maybe there are some variations under that wording, but certainly a DPV
> client is not DPD capable. Hence a good reason for the separation of the two
> functionality.

The set of inputs for the DPV and DPD protocols are remarkably similar.
As long as we design the protocol properly, I don't see why there should
be any problem using one protocol for both. A non-PKI-aware client can
pass blobs in and out (binary objects whose contents it does not
understand). A PKI-aware client will understand the contents of those
objects. A non-PKI-aware client will trust the server (although it may
archive the blob for someone else to analyze later). A PKI-aware client
may or may not trust the server.

-Steve

Received: from ext-mail.valicert.com (ns1.valicert.com [63.65.221.10]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA09888 for ; Mon, 22 Jan 2001 11:51:19 -0800 (PST)
Received: from CONVERSION-DAEMON by ext-mail.valicert.com (PMDF V5.2-33 #46613) id <[email-masked]> for [email-masked]; Mon, 22 Jan 2001 11:57:23 -0800 (PST)
Received: from polaris.valicert.com ([192.168.2.34]) by ext-mail.valicert.com (PMDF V5.2-33 #46613) with ESMTP id <[email-masked]>; Mon, 22 Jan 2001 11:57:22 -0800 (PST)
Received: by exchange.valicert.com with Internet Mail Service (5.5.2650.21) id ; Mon, 22 Jan 2001 11:52:55 -0800
Content-return: allowed
Date: Mon, 22 Jan 2001 11:52:55 -0800
From: Peter Williams
Subject: RE: DPD & DPV requirements - to nonce or not to nonce?
To: "'Stephen Kent'"
Cc: [email-masked]
Message-id: <[email-masked]>
MIME-version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-type: multipart/alternative; boundary="Boundary_(ID_ITMuFsyzRgfZ8ctDqFj22w)"

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

--Boundary_(ID_ITMuFsyzRgfZ8ctDqFj22w)
Content-type: text/plain; charset="iso-8859-1"

Steve,

Thank you for your memo.

Let me summarize a requirement of your protocol design that seems to derive
from
your comments:

IETF-standardized validation servers MUST respond normally, when in
conforming mode, to a request that
repeats an anti-replay, nonce value.

Peter.

-----Original Message-----
From: Stephen Kent [mailto:[email-masked]]
Sent: Monday, January 15, 2001 7:41 PM
To: Peter Williams
Cc: [email-masked]
Subject: RE: DPD & DPV requirements - to nonce or not to nonce?

Peter,

[Peter Williams]

Not sure I see the need for the nonce hash tree you described, though it is
a clever approach, but it also might run afoul of the time stamp patents of
some folks.

[Peter Williams]

Steve

--Boundary_(ID_ITMuFsyzRgfZ8ctDqFj22w)
Content-type: text/html; charset="iso-8859-1"

Steve,

Thank
you for your memo.

Let me
summarize a requirement of your protocol design that seems to derive
from

your
comments:

IETF-standardized validation servers MUST respond
normally, when in conforming mode, to a request
that

repeats an anti-replay, nonce
value.

Peter.

-----Original Message-----
From: Stephen
Kent [mailto:[email-masked]]
Sent: Monday, January 15, 2001 7:41
PM
To: Peter Williams
Cc:
[email-masked]
Subject: RE: DPD & DPV requirements - to nonce
or not to nonce?

Peter,
[Peter Williams]

Not sure I see the need for the nonce hash tree you described, though it is
a clever approach, but it also might run afoul of the time stamp patents of
some folks.
[Peter Williams]

Steve

--Boundary_(ID_ITMuFsyzRgfZ8ctDqFj22w)--

Received: from mail.spyrus.com (mail.spyrus.com [207.212.34.20]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA06149 for ; Mon, 22 Jan 2001 10:33:54 -0800 (PST)
Received: from RHOUSLEY-PC.spyrus.com ([209.172.119.210]) by mail.spyrus.com (8.9.3/8.9.3) with ESMTP id KAA19273; Mon, 22 Jan 2001 10:38:36 -0800 (PST)
Message-Id: <[email-masked]>
X-Sender: [email-masked]
X-Mailer: QUALCOMM Windows Eudora Version 5.0.2
Date: Mon, 22 Jan 2001 13:36:25 -0500
To: Denis Pinkas
From: Russ Housley
Subject: Re: Post-facto queries [Was: RE: DPD & DPV requirements]
Cc: PKIX-List
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed

Denis:

I agree with 1, 2a, and 2b. I cannot accept 2c.

Just because a retrospective check is available does not mean that
current-time checking will stop. Retrospective checking has always been
viewed as a concern, especially in a dispute. This allows us to allocate
the data archive necessary to perform such checking to a server rather than
every client.

Russ

At 05:37 PM 1/22/2001 +0100, Denis Pinkas wrote:
>Russ,
>
> > I think this is a very good idea. I strongly encourage us to do it.
>
>Wait a second. :-)
>
>It would be nice to get such a service ... but we have to think about the
>consequences.
>
>1) If such service would exist, then it should be clear that it should only
>be optional.
>2) The functions of a CA should not be changed because of the existence of
>this functionality.
>
>What are the implications ?
>
>a) Such a service would not work as soon as revocation status would be
>obtained through OCSP responses. There is a move to get the revocation
>status of the leaf certificate using OCSP. Such service would thus be
>unusable in that case.
>
>b) Such a service would work if CRLs and delta CRls were all captured by a
>TTP *different* from the CA. The size of the storage might become quite
>important.
>
>c) Such a service would degrade the security. Let me explain. If people can
>say: "We will check later, since we have a server always giving us the right
>answer", then will rely on it and will not ask for the certificatio path and
>revocation information at the time of initial verification. What can happen
>between initial verification and a later verification ? The answer is: a key
>compromise of a CA issuing key.
>
>Today by time-stamping the whole certification path and revocation
>information (i.e. the evidence) you can protect against that threat.
>
>If you would like to get the same protection the server would need to obtain
>a time-stamp on every individual CRL and delta CRL and we would be
>encouraging structures like individual time-stamped CRLs and individual
>time-stamped delta-CRLs.
>
>In other words, supporting this service would imply supporting time-stamping
>by the server. We wanted to avoid the support of time stamping by a DPV
>server and leave it to the discretion of the client.
>
>I believe that we should think more about the consequences before supporting
>this service.
>
>Regards,
>
>Denis
>
>
> > Russ
> >
> > At 04:59 AM 1/20/2001 -0500, Linn, John wrote:
> > >Considering one point arising within this thread:
> > >
> > > >
> > > >
> > > >[Steve]
> > > >
> > > >There was some sentiment for having the "was it valid then" function as
> > > >provided in SCVP, but if there is not continued support we could
> delete it.
> > > >I want to get more feedback on this issue.
> > > >
> > > >[Denis]
> > > >
> > > >So, let us wait and see ...
> > > >
> > > >I'm not seeing any support for retrospective queries, so I think
> we'll drop
> > >it.
> > >
> > >I think it'd be useful to be able to support post-facto queries in the DPV
> > >framework. If a query specified a non-current time, a server could (if it
> > >had the requisite info to determine then-current status) return the
> > >appropriate status indication or else, without prejudice, indicate "unable
> > >to determine status for requested time". I can see value for DPV, and
> valid
> > >requirements to make post-facto status determinations, and would rather
> > >include such a hook than incur a need to define another generation of
> > >certificate validation protocol in order to represent their conjunction.
> > >
> > >--jl

Received: from mail.phaos.com ([206.30.74.234]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA05192 for ; Mon, 22 Jan 2001 10:17:16 -0800 (PST)
Received: from phaos_arik.phaos.com (ruskie.spacerat.com [207.51.38.135]) by mail.phaos.com (8.9.2/8.9.2) with ESMTP id RAA98958; Mon, 22 Jan 2001 17:29:27 -0500 (EST) (envelope-from [email-masked])
Message-Id: <[email-masked]>
X-Sender: [email-masked]
X-Mailer: QUALCOMM Windows Eudora Version 5.0.2
Date: Mon, 22 Jan 2001 13:35:58 -0500
To: Carlisle Adams
From: Ari Kermaier
Subject: RE: questions about rfc2510bis and rfc2511bis
Cc: "[email-masked]'" , "[email-masked]'"
In-Reply-To:
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed

Carlisle,

Thank you for your answers, they're very helpful. However, I have a
follow-up to the AttributeTypeAndValue SEQUENCES comments:
>AttributeTypeAndValue Sequences: --------------------------------
>
>There are several places in CMP/CRMF where a definition such as
>the following appears:
>
>CertReqMsg ::= SEQUENCE { (...) regInfo SEQUENCE
>SIZE(1..MAX) of AttributeTypeAndValue OPTIONAL }
>
>5) In such a field, is it permissible for more than
>one AttributeTypeAndValue having the same type OID to be present?
>
>I don't think anything prohibits this, but this is an ASN.1 question, not
>a CMP/CRMF question.
>6) If yes, how should the multiple entries be processed? If no,
>shouldn't there be a comment to that effect, or perhaps a new production
>defined (such as AttrTypeAndValueSequence ::= SEQUENCE SIZE(1..MAX)
>of AttributeTypeAndValue)) with a comment included?
>
>No, I don't think a comment is warranted here. (As I said, this is an
>ASN.1 question, and there's no reason to do anything here that violates
>how ASN.1 is supposed to work...)

I wasn't thinking about a comment that violates ASN.1 per se, but rather
something along the lines of the treatment of extensions in rfc2459:

4.1 Basic Certificate Fields

(...)
extensions [3] EXPLICIT Extensions OPTIONAL
-- If present, version shall be v3
(...)

Extensions ::= SEQUENCE SIZE (1..MAX) OF Extension

Extension ::= SEQUENCE {
extnID OBJECT IDENTIFIER,
critical BOOLEAN DEFAULT FALSE,
extnValue OCTET STRING }

(...)

4.2 Standard Certificate Extensions

(...)
Each extension includes an OID and an ASN.1 structure (...) Only
one instance of a particular extension may appear in a particular
certificate. For example, a certificate may contain only one authority
key identifier extension (...)

I was thinking that a similar restriction might make sense for most (maybe
all?) of the registration info and controls.

::Ari

Received: from edelweb.fr (edelweb.fr [212.234.46.16]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA03665 for ; Mon, 22 Jan 2001 09:49:50 -0800 (PST)
Received: from champagne.edelweb.fr (localhost.edelweb.fr [127.0.0.1]) by edelweb.fr with ESMTP id SAA05948; Mon, 22 Jan 2001 18:55:47 +0100 (MET)
Received: from champagne.edelweb.fr (champagne.edelweb.fr [193.51.14.161]) by edelweb.fr (nospam/1.3); Mon, 22 Jan 2001 18:55:47 +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 SAA11872; Mon, 22 Jan 2001 18:55:46 +0100 (MET)
From: Peter Sylvester
Received: (sylvest@localhost) by emeriau.edelweb.fr (8.7.6/8.6.6) id SAA22058; Mon, 22 Jan 2001 18:55:45 +0100 (MET)
Date: Mon, 22 Jan 2001 18:55:45 +0100 (MET)
Message-Id: <[email-masked]>
To: [email-masked], [email-masked]
Subject: RE: DID & DIP requirements
Cc: [email-masked]

>
> While it is true that the client puts its faith in a DPV server, that
> does not mean that the client has no input to the validation process,
> not is that process "unknowlable" by an external agent armed with
> knowledge of the validation parameters. It should be possible to
> predict the results of DPV operation armed with knowledge of the
> client request, locally configured policies, and knowledge of the
> other servers to which the DPC server has access.

I accept a locally configured policy harded coded as a representation
of the 'application'.

For others I would be very careful.

> > In DPD this may be completely the other way around.
> >
> > >
> > > The client and server algorithmic descriptions should help resolve this.
> >
> >For DPV you have no algorithmic description in the same way as
> >you don't know how a OCSP responder came to his conclusion.
>
> I don't think we agree here. The DPV server must operate on an
> algorithmic basis and thus have a predictable output. We don't want
> non-deterministic operation

Hm, even X509 does not operate on an algorithmic basis. It only specified
what criteria a valid path must follow, but not how to get to a valid path.

The OCSP is also non-deterministic, also the possibilities are smaller,
you don't know whether the server has access to a CRL, or directly
to a CA base.

>
> > >
> > > I would argue that having the protocol define a functional equivalent path
> > > discovery algorithm, like RFC 2459 does for path validation, will help
> > > implementers.
> >
> >For a DPV you don't need that. The DPV server verifies against against
> >his local trust base.
>
> Not entirely true, since the client may provide inputs to the
> validation process which will specify how the process works, mod any
> overrides configured into the server.

Well, we are back to case 1: What are the possible controls for
a DPV client? ;-)

>
> > for DPD I am not sure at all, it rather sems to me like a search in
> >a directory
> >anyway, and you may need to ask the DPD server several times.
>
> I'd like to better understand what parameters the client will change
> between invocations of a DPD server, in a controlled fashion, to make
> multiple invocations for the same target certificate provide
> distinct, useful, answers. Do you have some examples that could
> clarify this scenario?

Well, as a minimum client could just return a 'session id' as we
had discussed in the OCSP based DPD. This id contains in
a opaque way (for the client) enough info for the server to resume
to 'get the next'.

If you allow a client to react on the first response to say something
like: 'oh well, you first answer is really not the right direction,
instead of using a bottom up algoritm, you'd better do yoyo', then
this gets rather complicated IMHO.

Received: from po1.bbn.com (PO1.BBN.COM [192.1.50.38]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA02444 for ; Mon, 22 Jan 2001 09:30:12 -0800 (PST)
Received: from [171.78.30.112] (dhcp030-112.genuity.com [171.78.30.112]) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id MAA10714; Mon, 22 Jan 2001 12:36:05 -0500 (EST)
Mime-Version: 1.0
X-Sender: [email-masked]
Message-Id:
Date: Mon, 22 Jan 2001 12:36:43 -0500
To: Peter Sylvester
From: Stephen Kent
Subject: RE: DID & DIP requirements
Cc: [email-masked]
Content-Type: text/plain; charset="us-ascii" ; format="flowed"

Peter,

>Frank wrote:
>
> > Peter Sylvester wrote:
> >
> > > - A client may indicate one or more certificates to be validated.
> > >
> > > - 1 - Each certificate may be accompagnied by a 'lump' of certificates
> > > that may assist the server to find a valid path for that
> > > particular certificate.
> > >
> > > 2 - There may be an additional bunch of certificates that may be
> > > used by the server to determine valid paths.
> > >
> > > I tended to have 1, because for different certs the paths may be
> > > different, but I may be wrong since even if one throws all the
> > > different hints in 1 into one bag, the server could probably
> > > find out the good stuff anyway.
> >
> > 2 seems more efficient to me. I can't see any downside to 2.
>
>Sounds reasonable.
>
> >
> > How does the server know when it has completed the process of discovering a
> > path? It finds a self-signed certificate [this would break RFC 2459 path
> > validation]? The server maintains a collection of trusted certificates? The
> > client sends a collection of trusted certificates?
>
>Which server, DPV or DPD?
>The DPV client is assumed not to have trust in anything
>else than the server. The server maintains a trust base. It
>comes to a solution by what local or external means.

While it is true that the client puts its faith in a DPV server, that
does not mean that the client has no input to the validation process,
not is that process "unknowlable" by an external agent armed with
knowledge of the validation parameters. It should be possible to
predict the results of DPV operation armed with knowledge of the
client request, locally configured policies, and knowledge of the
other servers to which the DPC server has access.

> In DPD this may be completely the other way around.
>
> >
> > The client and server algorithmic descriptions should help resolve this.
>
>For DPV you have no algorithmic description in the same way as
>you don't know how a OCSP responder came to his conclusion.

I don't think we agree here. The DPV server must operate on an
algorithmic basis and thus have a predictable output. We don't want
non-deterministic operation

> >
> > I would argue that having the protocol define a functional equivalent path
> > discovery algorithm, like RFC 2459 does for path validation, will help
> > implementers.
>
>For a DPV you don't need that. The DPV server verifies against against
>his local trust base.

Not entirely true, since the client may provide inputs to the
validation process which will specify how the process works, mod any
overrides configured into the server.

> for DPD I am not sure at all, it rather sems to me like a search in
>a directory
>anyway, and you may need to ask the DPD server several times.

I'd like to better understand what parameters the client will change
between invocations of a DPD server, in a controlled fashion, to make
multiple invocations for the same target certificate provide
distinct, useful, answers. Do you have some examples that could
clarify this scenario?

Steve

Received: from edelweb.fr (edelweb.fr [212.234.46.16]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA01945 for ; Mon, 22 Jan 2001 09:25:31 -0800 (PST)
Received: from champagne.edelweb.fr (localhost.edelweb.fr [127.0.0.1]) by edelweb.fr with ESMTP id SAA05778; Mon, 22 Jan 2001 18:31:06 +0100 (MET)
Received: from champagne.edelweb.fr (champagne.edelweb.fr [193.51.14.161]) by edelweb.fr (nospam/1.3); Mon, 22 Jan 2001 18:31:07 +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 SAA11778; Mon, 22 Jan 2001 18:30:40 +0100 (MET)
From: Peter Sylvester
Received: (sylvest@localhost) by emeriau.edelweb.fr (8.7.6/8.6.6) id SAA22050; Mon, 22 Jan 2001 18:30:40 +0100 (MET)
Date: Mon, 22 Jan 2001 18:30:40 +0100 (MET)
Message-Id: <[email-masked]>
To: [email-masked], [email-masked]
Subject: Re: DPD & DPV requirements
Cc: [email-masked], [email-masked], [email-masked]

>
> I would like to second Russ Housley's comments above for associating name
> constraints with trust anchors. Without naming constraints we would get
> security threats that would imply global trust, which is not a real life
> situation. If other words, I want to be able to detect when company X
> certifies a name from a user (or entity) from company Y, and when this is
> not allowed.
>
> Denis
>
>

Can you give an example what do you want to do that you cannot
do with an appropriate cross certificate.

Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA01001 for ; Mon, 22 Jan 2001 09:18:00 -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 SAA34368; Mon, 22 Jan 2001 18:31: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 SAA17108; Mon, 22 Jan 2001 18:23:29 +0100
Message-ID: <[email-masked]>
Date: Mon, 22 Jan 2001 18:23:30 +0100
From: Denis Pinkas
Organization: Bull
X-Mailer: Mozilla 4.7 [fr] (Win98; I)
X-Accept-Language: fr
MIME-Version: 1.0
To: Steve Hanna
CC: Stephen Kent , PKIX List
Subject: Re: Need to support non-ASN.1 DPV clients?
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Steve (Hanna),

Since no answer would mean "yes", you force me to answer.

> I have seen one response to my question:
>
> > Do we need to support non-PKI aware, non-ASN.1-capable DPV clients?
>
> Of course, the WG chair is responsible for judging consensus. But given
> that the only response was in the negative (indicating that this work
> will be done elsewhere) and that nobody has come forward to say we must
> support non-ASN.1-capable DPV clients,

Since Paul does not insist anymore, I can support this statement.

> I will suggest that the consensus
> answer is "No, we do not need to support non-PKI aware,
> non-ASN.1-capable DPV clients."

Your last sentence is not the same as the sentence above: "non-PKI aware"
and "non ASN.1 capable" are not equivalent.

For the time being I would suggest that the consensus is: "We do not need to
support non-ASN.1-capable DPV clients."

I have advocated the use of "blobs" for both the request parameters and the
optional result for a DPV client. This allows to have non-PKI aware clients.
Maybe there are some variations under that wording, but certainly a DPV
client is not DPD capable. Hence a good reason for the separation of the two
functionality.

Denis

> That simplifies things a bit.
>
> -Steve

Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA29954 for ; Mon, 22 Jan 2001 09:10: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 SAA46572; Mon, 22 Jan 2001 18:24: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 SAA16680; Mon, 22 Jan 2001 18:16:19 +0100
Message-ID: <[email-masked]>
Date: Mon, 22 Jan 2001 18:16:20 +0100
From: Denis Pinkas
Organization: Bull
X-Mailer: Mozilla 4.7 [fr] (Win98; I)
X-Accept-Language: fr
MIME-Version: 1.0
To: Russ Housley
CC: Steve Hanna , Stephen Kent , PKIX-List
Subject: Re: DPD & DPV requirements
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

> I agree. If were were to add any capability, I would consider an input to
> the path validation algorithm that allowed a user to provide name
> constraints. There is already an input parameter for acceptable policies.
>
> Russ

I would like to second Russ Housley's comments above for associating name
constraints with trust anchors. Without naming constraints we would get
security threats that would imply global trust, which is not a real life
situation. If other words, I want to be able to detect when company X
certifies a name from a user (or entity) from company Y, and when this is
not allowed.

Denis

> At 04:18 PM 1/19/2001 -0500, Steve Hanna wrote:
> >I would like to second Steve Kent's comments against associating name
> >constraints with trust anchors. We need to balance flexibility and
> >complexity here, I believe.
> >
> >Most users never tweak their trust anchors. They don't even know what a
> >trust anchor is. In most cases where trust anchors are modified from the
> >default, the set of trust anchors is configured by an administrator. For
> >the administrator who wants to configure a partially trusted CA (with
> >name constraints), the simplest and best solution is for the
> >administrator to establish his own CA, issue a cross-certificate to the
> >partially trusted CA (with name constraints), and configure the
> >administrator's CA as the trust anchor. This allows the administrator to
> >modify the set of trusted CAs and the limits placed on that trust ad
> >infinitum without requiring the application's trust anchors to be
> >reconfigured (which is often painful).
> >
> >Associating name constraints with trust anchors adds needless complexity
> >to application code and user interface. Added complexity increases the
> >likelihood of bugs and security holes. And this is a slippery slope.
> >Today, we want name constraints with each trust anchor. Tomorrow, policy
> >constraints. Then policy mapping. Imagine the user interface for that.
> >We already have a format for expressing these constraints. It's called a
> >cross-certificate. Let's not reinvent the wheel.
> >
> >-Steve
> >
> >Stephen Kent wrote:
> > > >[Steve]
> > > >
> > > >Self-signed certs are not the only way to deal with multiple roots, and it
> > > >often seems to me that they are a poor way, when we want to make use of
> > > >features like naming constraints. Why not just have cross certs issued to
> > > >other "roots" by a local CA and embed the naming (and policy?) constraints
> > > >into those cross certs?
> > > >
> > > >
> > > >[Denis]
> > > >
> > > >This would be quite an artificial way to do this, and more complex than
> > > >simply adding the elements to define the policy and naming
> > constraints. The
> > > >proposal is simply to define the policy constraints and the name
> > > >constraints. Take a look at the document being progressed in the S/MIME WG
> > > >which defines a validation policy format for non repudiation: Electronic
> > > >Signature Policies
> > >
> > > I don't think of it as artificial at all. Cross certification is a
> > > standard way to create links between PKIs, and to express constraints
> > > on these links. It has the advantage that path validation can be
> > > applied uniformly rather than having to treat each trust point
> > > specially, associating name and policy constraints etc. via special
> > > means. But, I'm not hard over on this.

Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA28493 for ; Mon, 22 Jan 2001 08:47:09 -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 SAA21066; Mon, 22 Jan 2001 18:00:18 +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 RAA20114; Mon, 22 Jan 2001 17:52:38 +0100
Message-ID: <[email-masked]>
Date: Mon, 22 Jan 2001 17:52:39 +0100
From: Denis Pinkas
Organization: Bull
X-Mailer: Mozilla 4.7 [fr] (Win98; I)
X-Accept-Language: fr
MIME-Version: 1.0
To: Russ Housley
CC: PKIX-List
Subject: Re: DPD & DPV requirements
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Russ,

> I agree. If were were to add any capability, I would consider an input to
> the path validation algorithm that allowed a user to provide name
> constraints. There is already an input parameter for acceptable policies.

This is fine for DPD.

The next question is : is this also fine for DPV ?

Not sure, some validation policies may request some (even private)
extensions in the leaf certificate to be present for a certificate to be
"valid" according to a validation policy. Hence a response "valid", should
be interpreted as a minimum condition to be valid, but not always as a
sufficient condition. We would have to be very careful when explaining what
a "valid" status means.

Denis

> Russ

Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA27637 for ; Mon, 22 Jan 2001 08:32:09 -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 RAA39376; Mon, 22 Jan 2001 17:45: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 RAA21032; Mon, 22 Jan 2001 17:37:38 +0100
Message-ID: <[email-masked]>
Date: Mon, 22 Jan 2001 17:37:39 +0100
From: Denis Pinkas
Organization: Bull
X-Mailer: Mozilla 4.7 [fr] (Win98; I)
X-Accept-Language: fr
MIME-Version: 1.0
To: Russ Housley
CC: PKIX-List
Subject: Re: Post-facto queries [Was: RE: DPD & DPV requirements]
References: <[email-masked]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Russ,

> I think this is a very good idea. I strongly encourage us to do it.

Wait a second. :-)

It would be nice to get such a service ... but we have to think about the
consequences.

1) If such service would exist, then it should be clear that it should only
be optional.
2) The functions of a CA should not be changed because of the existence of
this functionality.

What are the implications ?

a) Such a service would not work as soon as revocation status would be
obtained through OCSP responses. There is a move to get the revocation
status of the leaf certificate using OCSP. Such service would thus be
unusable in that case.

b) Such a service would work if CRLs and delta CRls were all captured by a
TTP *different* from the CA. The size of the storage might become quite
important.

c) Such a service would degrade the security. Let me explain. If people can
say: "We will check later, since we have a server always giving us the right
answer", then will rely on it and will not ask for the certificatio path and
revocation information at the time of initial verification. What can happen
between initial verification and a later verification ? The answer is: a key
compromise of a CA issuing key.

Today by time-stamping the whole certification path and revocation
information (i.e. the evidence) you can protect against that threat.

If you would like to get the same protection the server would need to obtain
a time-stamp on every individual CRL and delta CRL and we would be
encouraging structures like individual time-stamped CRLs and individual
time-stamped delta-CRLs.

In other words, supporting this service would imply supporting time-stamping
by the server. We wanted to avoid the support of time stamping by a DPV
server and leave it to the discretion of the client.

I believe that we should think more about the consequences before supporting
this service.

Regards,

Denis

> Russ
>
> At 04:59 AM 1/20/2001 -0500, Linn, John wrote:
> >Considering one point arising within this thread:
> >
> > >
> > >
> > >[Steve]
> > >
> > >There was some sentiment for having the "was it valid then" function as
> > >provided in SCVP, but if there is not continued support we could delete it.
> > >I want to get more feedback on this issue.
> > >
> > >[Denis]
> > >
> > >So, let us wait and see ...
> > >
> > >I'm not seeing any support for retrospective queries, so I think we'll drop
> >it.
> >
> >I think it'd be useful to be able to support post-facto queries in the DPV
> >framework. If a query specified a non-current time, a server could (if it
> >had the requisite info to determine then-current status) return the
> >appropriate status indication or else, without prejudice, indicate "unable
> >to determine status for requested time". I can see value for DPV, and valid
> >requirements to make post-facto status determinations, and would rather
> >include such a hook than incur a need to define another generation of
> >certificate validation protocol in order to represent their conjunction.
> >
> >--jl

Received: from mail.spyrus.com (mail.spyrus.com [207.212.34.20]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA23511 for ; Mon, 22 Jan 2001 07:39:20 -0800 (PST)
Received: from RHOUSLEY-PC.spyrus.com ([209.172.119.210]) by mail.spyrus.com (8.9.3/8.9.3) with ESMTP id HAA15064 for ; Mon, 22 Jan 2001 07:44:51 -0800 (PST)
Message-Id: <[email-masked]>
X-Sender: [email-masked]
X-Mailer: QUALCOMM Windows Eudora Version 5.0.2
Date: Mon, 22 Jan 2001 10:44:54 -0500
To: PKIX-List
From: Russ Housley
Subject: Re: Post-facto queries [Was: RE: DPD & DPV requirements]
In-Reply-To:
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed

I think this is a very good idea. I strongly encourage us to do it.

Russ

At 04:59 AM 1/20/2001 -0500, Linn, John wrote:
>Considering one point arising within this thread:
>
> >
> >
> >[Steve]
> >
> >There was some sentiment for having the "was it valid then" function as
> >provided in SCVP, but if there is not continued support we could delete it.
> >I want to get more feedback on this issue.
> >
> >[Denis]
> >
> >So, let us wait and see ...
> >
> >I'm not seeing any support for retrospective queries, so I think we'll drop
>it.
>
>I think it'd be useful to be able to support post-facto queries in the DPV
>framework. If a query specified a non-current time, a server could (if it
>had the requisite info to determine then-current status) return the
>appropriate status indication or else, without prejudice, indicate "unable
>to determine status for requested time". I can see value for DPV, and valid
>requirements to make post-facto status determinations, and would rather
>include such a hook than incur a need to define another generation of
>certificate validation protocol in order to represent their conjunction.
>
>--jl

Received: from ext-mail.valicert.com (ns1.valicert.com [63.65.221.10]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA20013 for ; Mon, 22 Jan 2001 07:20:26 -0800 (PST)
Received: from CONVERSION-DAEMON by ext-mail.valicert.com (PMDF V5.2-33 #46613) id <[email-masked]> for [email-masked]; Mon, 22 Jan 2001 07:26:28 -0800 (PST)
Received: from polaris.valicert.com ([192.168.2.34]) by ext-mail.valicert.com (PMDF V5.2-33 #46613) with ESMTP id <[email-masked]>; Mon, 22 Jan 2001 07:26:27 -0800 (PST)
Received: by exchange.valicert.com with Internet Mail Service (5.5.2650.21) id ; Mon, 22 Jan 2001 07:22:01 -0800
Content-return: allowed
Date: Mon, 22 Jan 2001 07:21:52 -0800
From: Frank Balluffi
Subject: RE: DID & DIP requirements
To: "'Stephen Kent'"
Cc: [email-masked]
Message-id: <[email-masked]>
MIME-version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-type: text/plain; charset="iso-8859-1"

Steve Kent said:

> How about the following definition:
>
> A complete certification path is one that satisfies all of the
> validation criteria specified in RFC 2459bis and that terminates at a
> certificate configured as a trust anchor in the server and specified
> by reference to the policy containing that path, or a path that
> terminates at a trust anchor certificate supplied by the client in a
> request.

Good. I find "and specified by reference to the policy containing that path"
a bit awkward. I assume you mean the path satisfies the validation criteria
specified by the policy.

Frank

> -----Original Message-----
> From: Stephen Kent [mailto:[email-masked]]
> Sent: Friday, January 19, 2001 10:37 AM
> To: Frank Balluffi
> Cc: [email-masked]
> Subject: RE: DID & DIP requirements
>
>
> Frank,
>
> >Peter Sylvester said:
> >
> > > Which server, DPV or DPD?
> > > The DPV client is assumed not to have trust in anything
> > > else than the server. The server maintains a trust base. It
> > > comes to a solution by what local or external means.
> >
> >Since I'm no longer clear about what the differences are
> between a DPV and a
> >DPD server, whoever is performing the task of discovering
> paths. Put simply,
> >it is not clear to me that such a server knows when it has
> discovered a
> >complete path. In other words, there seem to be two types of
> trust points:
> >points along the path and points at the end of the path.
>
> How about the following definition:
>
> A complete certification path is one that satisfies all of the
> validation criteria specified in RFC 2459bis and that terminates at a
> certificate configured as a trust anchor in the server and specified
> by reference to the policy containing that path, or a path that
> terminates at a trust anchor certificate supplied by the client in a
> request.
>

Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id DAA07937 for ; Mon, 22 Jan 2001 03:55:56 -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 NAA37246; Mon, 22 Jan 2001 13:09:06 +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 NAA10536; Mon, 22 Jan 2001 13:01:26 +0100
Message-ID: <[email-masked]>
Date: Mon, 22 Jan 2001 13:01:27 +0100
From: Denis Pinkas
Organization: Bull
X-Mailer: Mozilla 4.7 [fr] (Win98; I)
X-Accept-Language: fr
MIME-Version: 1.0
To: Stephen Kent
CC: PKIX-List
Subject: Re: DPD & DPV requirements
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Denis,

Your message is really too big, so I'll trim it in my response, with
the attendant possibility that I'll through away some context that
will later cause confusion, ...

[Denis]

I will do the same. :-)

Since we now understand much better each other, I will not reproduce all the
issues we agree on. I will answer to one of your questions and comment on
one issue on which we both agree.

In order to progress, I suggest that we try first to agree on the goals.
Here is a proposal.

DPV goals:

Validate a leaf certificate according either to a validation policy or one
(or more ?) trust anchor (public key value, CA name and optionally a
validity period) including CP and naming constraints.

Obtain a signed " yes, no or incomplete " answer to the question together
with the date of validation.

Optionally provide a replay protection if no time is available on the
client.

Optionally obtain the evidence to support the yes answer

Note 1: A complete certification path is one that satisfies all of the
validation criteria specified in RFC 2459bis and that terminates at a trust
anchor (public key value, CA name and optionally a validity period) that may
include Certification Policy constraints as well as naming constraints.

Note 2 : if a "ValidationPolicyRef" parameter or the trust anchor is missing
in the request, then the server will return back either the
ValidationPolicyRef that has been used or alternatively a description of the
validation policy or of the root key that has been used.

Note 3 : In order to be able to store the yes /no answer in one place
without the need to store the evidence (that may be quite big) in the same
place, it is proposed to include the hash of the evidence in the signed
answer. This does not augment too much the size of the answer while
providing integrity protection without the need of a second digital
signature.

DPD goals:

Obtain one or more certification paths and optionally its associated
revocation information for a leaf certificate according either to a
validation policy or a trust anchor.

Optionally specify naming and CP constraints.

Provide a replay protection (no date is necessary).

Note 1 : Either a full certification path is returned or nothing (no
certification path nor revocation information).

Note 2 : When a full path is found, all the associated revocation
information is not necessarily found. However, the revocation information
that has been found is returned.

Note 3 : For one element of the path, both a CRL (or base CRL and delta) and
an OCSP response may be returned (if both exist) as associated revocation
information.

Note 4 : if the validation policy or a root key (public key value and CA
name) is missing, then the server will designate in the response the default
validation policy or root key or the self-signed certificate that has been
used.

Note 5: each path starts with the leaf certificate (or its reference) and
ends up either with a self-signed certificate or a root key associated with
a CA name.

Note 6 : When only the reference of the certificate is provided in the
request (i.e. ESSCertID) and when requested, the server may include the leaf
certificate in the returned paths.

Note 7: in case full revocation information is not found, the client may
send back (using the sequence of useful certificates and a sequence of
useful revocation information) one of the certification path and the
associated revocation information that he got, in order to try to obtain
more revocation information. This avoids to have a stateful server.

If we can agree on these goals, then I am ready to send a detailed proposal
for the input and output parameters for each protocol.

Let me now answer to one of your questions and then comment on another one.

1. [Steve]

>You say "that providing anything other than the target cert per se has
>potential problems and adds complexity to the server". However, you do not
>provide arguments to support this statement.

Any means of referring to a cert, other than providing the cert, is
problematic. For example, issuer name and serial number is ambiguous
because we can't guarantee uniqueness of issuer names. A hash of a
cert fails to help me locate the cert if I can't find it in a local
cache. A subject key identifier has a similar problem. We had
similar discussions re certificate references in the attribute
certificate realm.

Your example does not seem to address this concern, or maybe we're
just miscommunicating on another level.

[Denis]

When you use ESSCertID (defined in RFC 2634), it does address your concern,
since ESSCertID may carry both the properties you mentioned: issuer name and
serial number (to locate the certificate) but also a hash of a cert (to make
it unambiguous).

2. [Denis]

>I agree with you that "we already have application protocols where a client
>that is not PKI-aware might acquire cert paths and/or revocation data that
>he could pass on to a DPV server." The S/MIME example I provided is one
>such example. However, this would mean that each blob able to contain
> such cert paths and/or revocation data would have to be passed
>"as it is", i.e. without being opened by the application. I made the list
> of such data structures for three documents from the S/MIME working
> group. If we proceed in that direction, then we should ask the other
> working groups (e.g. IPSEC, TLS) to provide us with a list of the data
> structures that are relevant. If this list is not too large, then it could
> make sense to support all of them, otherwise, we would have to
> consider that this is not practical.
>
>If you agree with this idea, it could be interesting that we raise the
>question to the other working groups.

[Steve]

Good points. I have glibly discussed having these apps pass in certs
and CRLs, but without taking into account the implications of this
model. If we agree to support data structures from these protocols,
then we make life easier for these clients, but servers have to be
aware of each distinct data structure. We might standardize on a
few, common formats now in use, and encourage future apps to make use
of these structures, while still providing tags to identify them and
thus accommodate new structures if needed.

[Denis]

We both agree. So would you be sending such a request on the IPSEC and TLS
mailing lists ?

Regards,

Denis

Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id DAA06510 for ; Mon, 22 Jan 2001 03:41:53 -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 MAA53752; Mon, 22 Jan 2001 12:54:30 +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 MAA21650; Mon, 22 Jan 2001 12:46:35 +0100
Message-ID: <[email-masked]>
Date: Mon, 22 Jan 2001 12:46:36 +0100
From: Denis Pinkas
Organization: Bull
X-Mailer: Mozilla 4.7 [fr] (Win98; I)
X-Accept-Language: fr
MIME-Version: 1.0
To: [email-masked]
CC: [email-masked], [email-masked]
Subject: Re: question to time stamp draft: case of error
References: <[email-masked]> <[email-masked]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Bernd,

> > [email-masked] wrote:
> >
> > Jean-Marc Desperrier ([email-masked]) asked a
> > similar question in December and Ari Kermaier ([email-masked]) wrote:
> >
> > > The PKIFailureInfo structure described in
> > draft-ietf-pkix-rfc2510bis-02
> > > includes systemFailure(25) which, while not very descriptive, might
> > fit the
> > > bill for hardware failure.
> >
> > Denis, will you be adding systemFailure(25) to the PKIFailureInfo in
> > the RFC version of the Time Stamping Protocol?

systemFailure(25) has been added.

> And additional badSenderNonce(18)?
> I think, if a time stamp query contains a wrong nonce, this is also a
> helpful value.

This has not been added. I do not want to raise at this time questions like:
what is a bad nonce ? or how does a server know it is a bad nonce ?

> BTW,
> if a signed ts query is received, it should be possible to send
> appropriate
> errors send back like badMessageCheck(1), signerNotTrusted(20) or
> notAuthorized(23).
> Is it generally planned that the new RFC provides a signed time stamp
> query?

There is no plan for a new RFC addressing a signed time stamp query. The
architecture is transport independent. Since the proposed additional error
cases would correspond to the transport protocol, they have not been added.
A revised version, including changes to address comments from Jeff Schiller
(our security area Director) is on its way.

> The last draft-ietf-pkix-time-stamp-12.txt say nothing about this fact.
>
> >
> > I agree with Jean-Marc and Ari that it would be very useful to add
> > this additional value to the PKIFailureInfo since the latest time
> > stamping draft currently indicates that:
> >
> > "These are the only values of PKIFailureInfo that are supported.
> > Compliant servers MUST NOT produce any other values. Compliant clients
> > MAY ignore any other values."

This text has been changed in the revised document. Wait for the summary of
all the changes that will be posted soon, to see the replacement which
addresses this concern.

Denis

> > By not adding during the final editing of the RFC
> > version, this useful value could not ever be used to indicate this
> > type of error.
> >
>
> with kind regards
> --
> Mors certa, hora incerta. In dubio pro mille.
> --------------------------------------------------------------------
> Bernd Matthes Celo Communications GmbH
> Senior Software Engineer Weissenfelser Strasse 46a
> Nachrichtentechniker D 06217 Merseburg
> Dipl.-Ing.(FH) http://www.celocom.com
> f. technische Informatik mailto:[email-masked]
> http://www.worldbug.de Tel.: +49 3461/3318-0
> mailto:[email-masked] Fax: +49 3461/415072
> --------------------------------------------------------------------
> "When in doubt, use brute force." (Ken Thompson)

Received: from tholian.securitydynamics.com (tholian.securid.com [204.167.112.129]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id BAA09779 for ; Sat, 20 Jan 2001 01:54:17 -0800 (PST)
Received: from [192.168.7.5] by tholian.securitydynamics.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 20 Jan 2001 09:59:03 UT
Received: from exna00.securitydynamics.com (ebola.securid.com [192.168.7.4]) by sdtihq24.securid.com (Pro-8.9.3/Pro-8.9.3) with ESMTP id FAA12005; Sat, 20 Jan 2001 05:00:04 -0500 (EST)
Received: by exna00.securitydynamics.com with Internet Mail Service (5.5.2650.21) id ; Sat, 20 Jan 2001 05:00:04 -0500
Message-ID:
From: "Linn, John"
To: Stephen Kent , Denis Pinkas
Cc: PKIX-List
Subject: Post-facto queries [Was: RE: DPD & DPV requirements]
Date: Sat, 20 Jan 2001 04:59:49 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"

Considering one point arising within this thread:

>
>
>[Steve]
>
>There was some sentiment for having the "was it valid then" function as
>provided in SCVP, but if there is not continued support we could delete it.
>I want to get more feedback on this issue.
>
>[Denis]
>
>So, let us wait and see ...
>
>I'm not seeing any support for retrospective queries, so I think we'll drop
it.

I think it'd be useful to be able to support post-facto queries in the DPV
framework. If a query specified a non-current time, a server could (if it
had the requisite info to determine then-current status) return the
appropriate status indication or else, without prejudice, indicate "unable
to determine status for requested time". I can see value for DPV, and valid
requirements to make post-facto status determinations, and would rather
include such a hook than incur a need to define another generation of
certificate validation protocol in order to represent their conjunction.

--jl

Received: from sottmxs02.entrust.com (gatekeeper.entrust.com [204.101.128.170]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA06425 for ; Fri, 19 Jan 2001 14:45:39 -0800 (PST)
Received: by sottmxs02.entrust.com with Internet Mail Service (5.5.2650.21) id ; Fri, 19 Jan 2001 17:49:27 -0500
Message-ID:
From: Carlisle Adams
To: "'Ari Kermaier'"
Cc: "[email-masked]'" , "[email-masked]'"
Subject: RE: questions about rfc2510bis and rfc2511bis
Date: Fri, 19 Jan 2001 17:47:27 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C08269.CC1DDCE0"

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_01C08269.CC1DDCE0
Content-Type: text/plain;
charset="iso-8859-1"

Hi Ari,

As I wrote in my response to Magnus, I apologize for such a long delay in
replying to your comments/questions. See embedded answers below.

> ----------
> From: Ari Kermaier[SMTP:[email-masked]]
> Sent: Tuesday, January 09, 2001 12:38 PM
> To: Carlisle Adams
> Subject: questions about rfc2510bis and rfc2511bis
>
> I posted the comments and questions listed below over the last few weeks,
> but they didn't seem to generate any interest. Since the documents in
> question have been submitted for last call, I thought I'd better send them
>
> to you directly. I apologize if that's inappropriate.
>
> Ari Kermaier
> Phaos Technology
>
> AltCertTemplate Control:
> ------------------------
>
> CMP (draft-ietf-pkix-rfc2510bis-02) Appendix D defines the following new
> control:
>
> id-regCtrl-altCertTemplate OBJECT IDENTIFIER ::= {id-regCtrl 7}
> AltCertTemplate ::= AttributeTypeAndValue
>
> 1) Is the complete (expanded) syntax of the control supposed to be
>
> SEQUENCE {id-regCtrl-altCertTemplate OBJECT IDENTIFIER,
> SEQUENCE {type OBJECT IDENTIFIER,
> value ANY DEFINED BY type} }

Yes.

> and if so what OIDs are envisioned for use here?

I did do an independent "cmp-altCert" draft 6 months ago that has just
expired. I will probably get around to updating and resubmitting it some
day soon... Anyway, the sorts of things I had in mind were templates for
X.509 attribute certificates and WAP WTLS certificates (id-acTemplate ::=
{id-regCtrl-altCertTemplate xx} and id-wtlsTemplate ::=
{id-regCtrl-altCertTemplate yy} were the place-holders in the draft).

> 2) If this control is present and contains both the subject and public
> key,
> is a POPOSigningKey signature supposed to be calculated on the DER
> encoding
> of the entire control, or just the AttributeTypeAndValue payload of the
> control?

Good point -- this was unclear. What I intended was the DER-encoded value
of the AttributeTypeAndValue payload. I will clarify this in the text.

> 3) The first paragraph of draft-ietf-pkix-rfc2510bis-02 Appendix D, where
> the AltCertTemplate control is defined, states:
>
> The following definitions are from rfc2511bis. They are included
> here
> in order to codify behavioral clarifications to that request
> message; otherwise, all syntax and semantics are identical to
> rfc2511bis.

[Note: by "definitions" above, all I meant was CertRequest, POPOSigningKey,
and POPOPrivKey.]

> As far as I can see, the AltCertTemplate control is not mentioned anywhere
>
> in rfc2511bis, nor is it included in the ASN.1 module for rfc2510bis. Is
> this a sin of omission (missing from 2511bis and 2510bis Appendix F) or of
>
> comission (maybe it shouldn't be in 2510bis Appendix D either)?

I don't think a sin (omission or commission) is occurring here. RFC 2511
says that the list of controls may expand over time. This expansion need
not occur in 2511; it could theoretically happen anywhere (as long as it's
controlled). All we're doing here is defining a new control and specifying
the behaviour around its processing. This doesn't have to be in 2511bis,
and doesn't really belong in 2510bis App G either (since App G is the syntax
for everything outside 2511). I think it is perfectly reasonable for this
control and behaviour specification to happen in appendix D of 2510bis since
this is the specification that also allows alternative certificate formats
through CMPCertificate, whereas this concept is irrelevant to 2511bis.

> CertResponse.rspInfo:
> ---------------------
>
> draft-ietf-pkix-rfc2510bis-02 section 3.3.4 has the following syntax for a
>
> certification response:
>
> CertResponse ::= SEQUENCE {
> certReqId INTEGER,
> -- to match this response with corresponding request (a value
> -- of -1 is to be used if certReqId is not specified in the
> -- corresponding request)
> status PKIStatusInfo,
> certifiedKeyPair CertifiedKeyPair OPTIONAL,
> rspInfo OCTET STRING OPTIONAL
> -- analogous to the id-regInfo-utf8Pairs OCTET STRING defined
> -- for regInfo in CertReqMsg [rfc2511bis]
> }
>
> 4) I don't understand the comment for the rspInfo field -- rfc2511bis has
> the UTF8Pairs registration info value defined as UTF8String, not OCTET
> STRING. Can anyone enlighten me as to how rspInfo is supposed to be
> encoded?

"OCTET STRING" was a poor choice of description in this comment. You're
right; this is confusing. I should have used "octet string", or preferably
"string", since I didn't mean the ASN.1 type; all I meant was "bunch of
octets". I will fix this.

> AttributeTypeAndValue Sequences:
> --------------------------------
>
> There are several places in CMP/CRMF where a definition such as the
> following appears:
>
> CertReqMsg ::= SEQUENCE {
> (...)
> regInfo SEQUENCE SIZE(1..MAX) of AttributeTypeAndValue OPTIONAL }
>
> 5) In such a field, is it permissible for more than one
> AttributeTypeAndValue having the same type OID to be present?

I don't think anything prohibits this, but this is an ASN.1 question, not a
CMP/CRMF question.

> 6) If yes, how should the multiple entries be processed? If no, shouldn't
> there be a comment to that effect, or perhaps a new production defined
> (such as AttrTypeAndValueSequence ::= SEQUENCE SIZE(1..MAX) of
> AttributeTypeAndValue)) with a comment included?

No, I don't think a comment is warranted here. (As I said, this is an ASN.1
question, and there's no reason to do anything here that violates how ASN.1
is supposed to work...)

> CertStatus.certReqId:
> ---------------------
>
> 7) An apparent inconsistency between the text and the ASN.1 module in
> rfc2510bis:
>
> 3.3.18 Certificate Confirmation content
>
> CertStatus ::= SEQUENCE {
> certHash OCTET STRING,
> -- the hash of the certificate, using the same hash algorithm
> -- as is used to create and verify the certificate signature
> certReqId INTEGER,
> -- to match this confirmation with the corresponding req/rep
> statusInfo PKIStatusInfo OPTIONAL
> }
>
> Appendix F: "Compilable" ASN.1 Module using 1988 Syntax
>
> CertStatus ::= SEQUENCE {
> certHash OCTET STRING,
> -- the hash of the certificate, using the same hash algorithm
> -- as is used to create and verify the certificate signature
> statusInfo PKIStatusInfo OPTIONAL
> }

Someone else pointed this out to me as well (to my great embarrassment,
after all the ca-talk discussion over this structure!). I can't believe I
missed this in the appendix! Section 3.3.18 is correct, and the appendix
will be fixed.

Thank you for your comments, and I hope the above explanations are helpful.

Carlisle.

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

Hi =
Ari,

As I wrote =
in my response to Magnus, I apologize for such a long delay in replying =
to your comments/questions.  See embedded answers =
below.

----------

From:   =
Ari =
Kermaier[SMTP:[email-masked]]

Sent:   =
Tuesday, January 09, 2001 12:38 =
PM

To: =
Carlisle =
Adams

Subject: =
questions about rfc2510bis and rfc2511bis

I posted the comments and questions =
listed below over the last few weeks,

but they didn't seem to generate any =
interest. Since the documents in

question have been submitted for last =
call, I thought I'd better send them

to you directly. I apologize if =
that's inappropriate.

Ari Kermaier

Phaos Technology

AltCertTemplate Control:

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

CMP (draft-ietf-pkix-rfc2510bis-02) =
Appendix D defines the following new

control:

id-regCtrl-altCertTemplate OBJECT IDENTIFIER ::=3D =
{id-regCtrl 7}

AltCertTemplate ::=3D AttributeTypeAndValue

1) Is the complete (expanded) syntax =
of the control supposed to be

SEQUENCE =
{id-regCtrl-altCertTemplate OBJECT IDENTIFIER,

=
SEQUENCE {type OBJECT IDENTIFIER,

&nb=
sp;       value ANY DEFINED BY type} =
}

Yes.

and if so what OIDs are envisioned for =
use here?

I did do =
an independent "cmp-altCert" draft 6 months ago that has just =
expired.  I will probably get around to updating and resubmitting =
it some day soon...  Anyway, the sorts of things I had in mind =
were templates for X.509 attribute certificates and WAP WTLS =
certificates (id-acTemplate ::=3D {id-regCtrl-altCertTemplate xx} and =
id-wtlsTemplate ::=3D {id-regCtrl-altCertTemplate yy} were the =
place-holders in the draft).

2) If this control is present and =
contains both the subject and public key,

is a POPOSigningKey signature =
supposed to be calculated on the DER encoding

of the entire control, or just the =
AttributeTypeAndValue payload of the

control?

Good =
point -- this was unclear.  What I intended was the DER-encoded =
value of the AttributeTypeAndValue payload.  I will clarify this =
in the text.

3) The first paragraph of =
draft-ietf-pkix-rfc2510bis-02 Appendix D, where

the AltCertTemplate control is =
defined, states:

The following definitions are from rfc2511bis.  =
They are included here

in order to codify behavioral clarifications to that =
request

message; otherwise, all syntax and semantics are =
identical to rfc2511bis.

[Note:  by "definitions" above, all I meant was =
CertRequest, POPOSigningKey, and POPOPrivKey.]

As far as I can see, the =
AltCertTemplate control is not mentioned anywhere

in rfc2511bis, nor is it included in =
the ASN.1 module for rfc2510bis. Is

this a sin of omission (missing from =
2511bis and 2510bis Appendix F) or of

comission (maybe it shouldn't be in =
2510bis Appendix D either)?

I don't =
think a sin (omission or commission) is occurring here.  RFC 2511 =
says that the list of controls may expand over time.  This =
expansion need not occur in 2511; it could theoretically happen =
anywhere (as long as it's controlled).  All we're doing here is =
defining a new control and specifying the behaviour around its =
processing.  This doesn't have to be in 2511bis, and doesn't =
really belong in 2510bis App G either (since App G is the syntax for =
everything outside 2511).  I think it is perfectly reasonable for =
this control and behaviour specification to happen in appendix D of =
2510bis since this is the specification that also allows alternative =
certificate formats through CMPCertificate, whereas this concept is =
irrelevant to 2511bis.

CertResponse.rspInfo:

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

draft-ietf-pkix-rfc2510bis-02 section =
3.3.4 has the following syntax for a

certification response:

CertResponse ::=3D =
SEQUENCE {

=
certReqId           =
INTEGER,

=
-- to match this response with corresponding request (a value

=
-- of -1 is to be used if certReqId is not specified in the

=
-- corresponding request)

=
status           =
PKIStatusInfo,

=
certifiedKeyPair    CertifiedKeyPair    =
OPTIONAL,

=
rspInfo           =
;  OCTET STRING        =
OPTIONAL

=
-- analogous to the id-regInfo-utf8Pairs OCTET STRING defined

=
-- for regInfo in CertReqMsg [rfc2511bis]

}

4) I don't understand the comment for =
the rspInfo field -- rfc2511bis has

the UTF8Pairs registration info value =
defined as UTF8String, not OCTET

STRING. Can anyone enlighten me as to =
how rspInfo is supposed to be encoded?

"OCTET STRING" was a poor choice of description in =
this comment.  You're right; this is confusing.  I should =
have used "octet string", or preferably "string", =
since I didn't mean the ASN.1 type; all I meant was "bunch of =
octets".  I will fix this.

AttributeTypeAndValue =
Sequences:

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

There are several places in CMP/CRMF =
where a definition such as the

following appears:

CertReqMsg ::=3D SEQUENCE {

(...)

=
regInfo   SEQUENCE SIZE(1..MAX) of AttributeTypeAndValue =
OPTIONAL }

5) In such a field, is it permissible =
for more than one

AttributeTypeAndValue having the same =
type OID to be present?

I don't =
think anything prohibits this, but this is an ASN.1 question, not a =
CMP/CRMF question.

6) If yes, how should the multiple =
entries be processed? If no, shouldn't

there be a comment to that effect, or =
perhaps a new production defined

(such as AttrTypeAndValueSequence =
::=3D SEQUENCE SIZE(1..MAX) of

AttributeTypeAndValue)) with a =
comment included?

No, I =
don't think a comment is warranted here.  (As I said, this is an =
ASN.1 question, and there's no reason to do anything here that violates =
how ASN.1 is supposed to work...)

CertStatus.certReqId:

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

7) An apparent inconsistency between =
the text and the ASN.1 module in

rfc2510bis:

3.3.18 Certificate Confirmation =
content

=
CertStatus ::=3D SEQUENCE {

=
certHash    OCTET STRING,

=
-- the hash of the certificate, using the same hash algorithm

=
-- as is used to create and verify the certificate signature

=
certReqId   INTEGER,

=
-- to match this confirmation with the corresponding req/rep

=
statusInfo  PKIStatusInfo OPTIONAL

=
}

Appendix F: "Compilable" =
ASN.1 Module using 1988 Syntax

CertStatus ::=3D SEQUENCE =
{

=
certHash    OCTET STRING,

-- the =
hash of the certificate, using the same hash algorithm

-- as =
is used to create and verify the certificate signature

=
statusInfo  PKIStatusInfo OPTIONAL

}

Someone =
else pointed this out to me as well (to my great embarrassment, after =
all the ca-talk discussion over this structure!).  I can't believe =
I missed this in the appendix!  Section 3.3.18 is correct, and the =
appendix will be fixed.

Thank you =
for your comments, and I hope the above explanations are =
helpful.

Carlisle.

------_=_NextPart_001_01C08269.CC1DDCE0--

Received: from sottmxs02.entrust.com (gatekeeper.entrust.com [204.101.128.170]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA05752 for ; Fri, 19 Jan 2001 14:13:30 -0800 (PST)
Received: by sottmxs02.entrust.com with Internet Mail Service (5.5.2650.21) id ; Fri, 19 Jan 2001 17:17:14 -0500
Message-ID:
From: Carlisle Adams
To: "'Magnus Nystrom'"
Cc: "Richards, Gareth" , [email-masked], "[email-masked]'"
Subject: RE: WG Last Call, RFC 2510bis
Date: Fri, 19 Jan 2001 17:15:14 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C08265.4BE26590"

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_01C08265.4BE26590
Content-Type: text/plain;
charset="iso-8859-1"

Hi Magnus,

Very sorry for the frustratingly long delay in responding, but a number of
things (including the Christmas break!) have kept my attention away from CMP
for the past month. Anyway, responses are embedded below.

> ----------
> From: Magnus Nystrom[SMTP:[email-masked]]
> Sent: Friday, December 22, 2000 9:01 AM
> To: [email-masked]
> Cc: Richards, Gareth
> Subject: Re: WG Last Call, RFC 2510bis
>
> Dear CMP and CRMF editors,
>
> In response to the last-call on rfc2510bis and rfc2511bis, we do have a
> couple of related questions. While answers to these may exist in the
> documents we have not been able to find them.
>
> a) What is a CMP client which receives a PKIMessage response with a
> PKIStatus of "waiting" supposed to do? A procedure for CMP using TCP
> as transport seems to be to use the pollRep/pollReq pair, but it
> seems as if polling should be part of CMP rather than dependent on
> its transport?

A long discussion/debate occurred some time ago on the ca-talk list
regarding whether or not polling belonged in CMP or in the transport layer.
There certainly was not consensus, but "rough consensus" (very rough!)
seemed to lean toward the transport layer. Therefore, the transport layer
needs to deal with this in some way (e.g., a polling mechanism for TCP;
perhaps nothing for e-mail -- the client simply waits for an e-mail that
contains more of the response). In any case, nailing this down for the
various transports is something that could/should be done in the transport
draft.

> b) In ir, cr and kur message types, the CertReqMessages SEQUENCE
> has the following restrictions (see Appendix B4 and rfc2510bis-02):
>
> 1. The SEQUENCE can contain one or two CertReqMsg structures.
> 2. The first request MUST contain a public key in the certTemplate.
> 3. The second request if present MUST NOT contain the public key
> bits in the certTemplate
>
> This therefore restricts server side key generation to situations where
> two certification requests are being made. This seems overly restrictive
> especially in the kur/kup situation where an end-entity would generally
> only update one key pair.
>
> It is not clear why the two CertReqMsg structures are restricted in
> this way. We therefore propose that restrictions 2 and 3 above are
> removed and that the two requests are treated equivalently.

Firstly, note that Appendix B is only a minimum profile for interoperability
purposes. In practice, conforming implementations can do much more than
this profile (and, as you point out, may wish to do slightly different
things for kur/kup support). That is, the restrictions given need not
govern day-to-day operation (this understanding is in accordance with normal
IETF rules of specification compliance).

Having said that, however, I will note that you are not the first person to
ask about this, and that this request seems perfectly reasonable.
Therefore, I will modify CertReq and KeyUpdateReq to remove restrictions 2
and 3 above (the restrictions will still apply to InitReq).

> c) Related to b), when a CMP client chooses not to include a public
> key in a certTemplate, how shall it inform the RA/CA of the
> particular algorithm it wishes the CA to generate a key for? And
> parameters - e.g. "Please generate a 1024 bit RSA key with F4 as
> public exponent".

In general, this could happen with a separate genMsg/genRep exchange (e.g.,
keyPairParamReq / keyPairParamRep, or perhaps a new pair as yet undefined).
Alternatively, a control could be defined to carry this information. But
there is no syntax available to do this within CertTemplate today. (Note
that RSA presents a bit of a difficulty because "parameters" have not been
defined for this AlgId, otherwise the keyPairParamReq/Rep could conceivably
be used for this algorithm.)

> Any clarifications or comments would be most welcome.
>
> Thanks,
> -- Magnus Nystrom & Gareth Richards,
> RSA Security

I hope this helps to clear some things up!

Carlisle.

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

RE: WG Last Call, RFC 2510bis

Hi =
Magnus,

Very sorry =
for the frustratingly long delay in responding, but a number of things =
(including the Christmas break!) have kept my attention away from CMP =
for the past month.  Anyway, responses are embedded =
below.

----------

From:   =
Magnus =
Nystrom[SMTP:[email-masked]]

Sent:   =
Friday, December 22, 2000 9:01 =
AM

To: =
[email-masked]

Cc: =
Richards, =
Gareth

Subject: =
Re: WG Last Call, RFC 2510bis

Dear CMP and CRMF editors,

In response to the last-call on =
rfc2510bis and rfc2511bis, we do have a

couple of related questions. While =
answers to these may exist in the

documents we have not been able to =
find them.

a) What is a CMP client which receives =
a PKIMessage response with a

PKIStatus of "waiting" =
supposed to do? A procedure for CMP using TCP

as transport seems to be to use the =
pollRep/pollReq pair, but it

seems as if polling should be part of =
CMP rather than dependent on

its transport?

A long =
discussion/debate occurred some time ago on the ca-talk list regarding =
whether or not polling belonged in CMP or in the transport layer.  =
There certainly was not consensus, but "rough consensus" =
(very rough!) seemed to lean toward the transport layer.  =
Therefore, the transport layer needs to deal with this in some way =
(e.g., a polling mechanism for TCP; perhaps nothing for e-mail -- the =
client simply waits for an e-mail that contains more of the =
response).  In any case, nailing this down for the various =
transports is something that could/should be done in the transport =
draft.

b) In ir, cr and kur message types, =
the CertReqMessages SEQUENCE

has the following restrictions (see =
Appendix B4 and rfc2510bis-02):

1. The SEQUENCE can contain one or two =
CertReqMsg structures.

2. The first request MUST contain a =
public key in the certTemplate.

3. The second request if present MUST =
NOT contain the public key

bits in the =
certTemplate

This therefore restricts server side =
key generation to situations where

two certification requests are being =
made.  This seems overly restrictive

especially in the kur/kup situation =
where an end-entity would generally

only update one key pair.

It is not clear why the two CertReqMsg =
structures are restricted in

this way. We therefore propose that =
restrictions 2 and 3 above are

removed and that the two requests are =
treated equivalently.

Firstly, =
note that Appendix B is only a minimum profile for interoperability =
purposes.  In practice, conforming implementations can do much =
more than this profile (and, as you point out, may wish to do slightly =
different things for kur/kup support).  That is, the restrictions =
given need not govern day-to-day operation (this understanding is in =
accordance with normal IETF rules of specification =
compliance).

Having =
said that, however, I will note that you are not the first person to =
ask about this, and that this request seems perfectly reasonable.  =
Therefore, I will modify CertReq and KeyUpdateReq to remove =
restrictions 2 and 3 above (the restrictions will still apply to =
InitReq).

c) Related to b), when a CMP client =
chooses not to include a public

key in a certTemplate, how shall it =
inform the RA/CA of the

particular algorithm it wishes the CA =
to generate a key for? And

parameters - e.g. "Please =
generate a 1024 bit RSA key with F4 as

public exponent".

In =
general, this could happen with a separate genMsg/genRep exchange =
(e.g., keyPairParamReq / keyPairParamRep, or perhaps a new pair as yet =
undefined).  Alternatively, a control could be defined to carry =
this information.  But there is no syntax available to do this =
within CertTemplate today.  (Note that RSA presents a bit of a =
difficulty because "parameters" have not been defined for =
this AlgId, otherwise the keyPairParamReq/Rep could conceivably be used =
for this algorithm.)

Any clarifications or comments would =
be most welcome.

Thanks,

-- Magnus Nystrom & Gareth =
Richards,

RSA Security

I hope =
this helps to clear some things up!

Carlisle.

------_=_NextPart_001_01C08265.4BE26590--

Received: from mail.spyrus.com (mail.spyrus.com [207.212.34.20]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA05318 for ; Fri, 19 Jan 2001 13:58:26 -0800 (PST)
Received: from RHOUSLEY-PC.spyrus.com ([209.172.119.210]) by mail.spyrus.com (8.9.3/8.9.3) with ESMTP id OAA19963; Fri, 19 Jan 2001 14:03:03 -0800 (PST)
Message-Id: <[email-masked]>
X-Sender: [email-masked]
X-Mailer: QUALCOMM Windows Eudora Version 5.0.2
Date: Fri, 19 Jan 2001 17:02:57 -0500
To: Steve Hanna
From: Russ Housley
Subject: Re: DPD & DPV requirements
Cc: Stephen Kent , Denis Pinkas , PKIX-List
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed

I agree. If were were to add any capability, I would consider an input to
the path validation algorithm that allowed a user to provide name
constraints. There is already an input parameter for acceptable policies.

Russ

At 04:18 PM 1/19/2001 -0500, Steve Hanna wrote:
>I would like to second Steve Kent's comments against associating name
>constraints with trust anchors. We need to balance flexibility and
>complexity here, I believe.
>
>Most users never tweak their trust anchors. They don't even know what a
>trust anchor is. In most cases where trust anchors are modified from the
>default, the set of trust anchors is configured by an administrator. For
>the administrator who wants to configure a partially trusted CA (with
>name constraints), the simplest and best solution is for the
>administrator to establish his own CA, issue a cross-certificate to the
>partially trusted CA (with name constraints), and configure the
>administrator's CA as the trust anchor. This allows the administrator to
>modify the set of trusted CAs and the limits placed on that trust ad
>infinitum without requiring the application's trust anchors to be
>reconfigured (which is often painful).
>
>Associating name constraints with trust anchors adds needless complexity
>to application code and user interface. Added complexity increases the
>likelihood of bugs and security holes. And this is a slippery slope.
>Today, we want name constraints with each trust anchor. Tomorrow, policy
>constraints. Then policy mapping. Imagine the user interface for that.
>We already have a format for expressing these constraints. It's called a
>cross-certificate. Let's not reinvent the wheel.
>
>-Steve
>
>Stephen Kent wrote:
> > >[Steve]
> > >
> > >Self-signed certs are not the only way to deal with multiple roots, and it
> > >often seems to me that they are a poor way, when we want to make use of
> > >features like naming constraints. Why not just have cross certs issued to
> > >other "roots" by a local CA and embed the naming (and policy?) constraints
> > >into those cross certs?
> > >
> > >
> > >[Denis]
> > >
> > >This would be quite an artificial way to do this, and more complex than
> > >simply adding the elements to define the policy and naming
> constraints. The
> > >proposal is simply to define the policy constraints and the name
> > >constraints. Take a look at the document being progressed in the S/MIME WG
> > >which defines a validation policy format for non repudiation: Electronic
> > >Signature Policies
> >
> > I don't think of it as artificial at all. Cross certification is a
> > standard way to create links between PKIs, and to express constraints
> > on these links. It has the advantage that path validation can be
> > applied uniformly rather than having to treat each trust point
> > specially, associating name and policy constraints etc. via special
> > means. But, I'm not hard over on this.

Received: from mail2.microsoft.com (mail2.microsoft.com [131.107.3.124]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id NAA04840 for ; Fri, 19 Jan 2001 13:40:03 -0800 (PST)
Received: from 157.54.9.104 by mail2.microsoft.com (InterScan E-Mail VirusWall NT); Fri, 19 Jan 2001 13:45:20 -0800 (Pacific Standard Time)
Received: by inet-imc-02.redmond.corp.microsoft.com with Internet Mail Service (5.5.2651.58) id ; Fri, 19 Jan 2001 13:45:18 -0800
Message-ID: <[email-masked]>
From: David Cross
To: Steve Hanna , Stephen Kent , PKIX List
Subject: RE: Need to support non-ASN.1 DPV clients?
Date: Fri, 19 Jan 2001 13:44:58 -0800
X-MS-TNEF-Correlator: <[email-masked]>
X-Mailer: Internet Mail Service (5.5.2651.58)

I have to concur - ASN.1 decoders can be relatively small. Steve's
suggestion simplifies this issue and makes it easier for us to move forward
on solutions.

David B. Cross

-----Original Message-----
From: Steve Hanna
Sent: Fri 1/19/2001 1:18 PM
To: Stephen Kent; PKIX List
Cc:
Subject: Re: Need to support non-ASN.1 DPV clients?

I have seen one response to my question:

> Do we need to support non-PKI aware, non-ASN.1-capable DPV clients?

Of course, the WG chair is responsible for judging consensus. But given
that the only response was in the negative (indicating that this work
will be done elsewhere) and that nobody has come forward to say we must
support non-ASN.1-capable DPV clients, I will suggest that the consensus
answer is "No, we do not need to support non-PKI aware,
non-ASN.1-capable DPV clients."

That simplifies things a bit.

-Steve

begin 600 winmail.dat
M>)\^(A,5`0:0"``$```````!``$``0>0!@`(````Y`0```````#H``$%@`,`
M#@```-$'`0`3``T`+``Z``4`9`$!"8`!`"$```!&.38W,D4U-#-$1C8Q,C1&
M.$,Y1D8S,44W,SE$1D5%0P!_!P$@@`,`#@```-$'`0`3``T`+0`2``4`/0$!
M#8`$``(````"``(``0.0!@!$$```.@```$``.0!:JLD188+``1\`,4`!````
M#@```#0`,0`X`#0`,P`X```````#`!I``````!\`,$`!````#@```#0`,0`X
M`#0`,P`X```````#`!E``````!\`20`!````5@```%(`90`Z`"``3@!E`&4`
M9``@`'0`;P`@`',`=0!P`'``;P!R`'0`(`!N`&\`;@`M`$$`4P!.`"X`,0`@
M`$0`4`!6`"``8P!L`&D`90!N`'0`0``````"`7$``0```!L````!
MP()=]D+'`W3,F)%"7Z,;T1XS&LF:``"W&9,`'P!T``$````P````4P!T`&4`
M<`!H`&4`;@`@`$L`90!N`'0`.P`@`%``2P!)`%@`(`!,`&D`,=Z#04\``\(41/0U194`!%($A434P@
M4`!50DQ)0R`B+2`O+U%%>!#Q;F=E/092=A,Q+T$`D`(@(#9@
M+C`N-#0E0"*0-2KV2_*V#/:==$2"!I-4!"+O\2T`-@!!!E3V9?9V]H?VF/
M_VJ?:Z]LOVW/;M]U[V+O8___90]R+W,_=$]U7W9O=W]X@\,A$"`P2U%53RWP
M/I8A-8!T>6QE+C%!4H!'24XM4DE'(*#Q-/`P<'@B\3\X"K$0`O]`14#C0*%!
M/X3O'QM.486_WWB_?L]ZWXO8/\!I'-(D?%HT)5%&+=%0\7J(4#)7D$L+XHO)
M+9?"3P409Z\+@`=`!=`'D',\H&67P[>4+2P0/C%2/QL+@&4*@:^+[WT&/D"0
M2V*+R48#8?8ZCPP?X2^=BH/93G0@D/\`<)A@53^-?WU"CMZ:3YM?_YQOG7^G
MN`9@`C"?;Z!_3?:D-CM2^V/TWWN]\?O.^]_[\/P!^JI75B:O\%D*L_PJ]-Z#3?->^Y7[IO
M_[MT-O;$7\5OQG_2?]./U)_U)-8UC^$OE5++OW\?@"__@3^"3]GOC%_0/XY_
MD@4?\/Y0B:^3*9*?DZ^4OY7/EMW_1_41,+@A`B!*8GVP5O%(0_IM2Q!Q"E!0
MH\I\V1^VWO_;_]T%Y`_?O]N$.('CT>`__^%/XE_C;^8/YQ_H+^D_\K_M?0=G
MN(`_*#[]#WS_?@_?_^\`_P(/-J!(<'%*,'L=LBCP9TJS(-\A[[ME*'^84#Z@2A!*P"`!
M+651T7?]4[!K(_\E#R8?)R\H/RE/YRI?*V_\O7=I2V!*0D``M^NA2I#L,'>X
M$$J`*5)3WS`?,2^[="UC"M!B2;#LH-_J\$GQGT!4>,VR8>R@!C'Z;5/@=#0_
M-4\V7S=O.'__.8\ZGSNO_+W-YC]O0'\*?[T+CW,(,.K0/:/-X&>8\/^Y(2UG
M(#=$GT6O1K].WT_O_[O/2'])CTJ?2Z],OUTB/R#&__R]40\+ZBXB9N]G
M__\.WP_O$/]L+Q,?%"\5/UHO_Q=?&&]LSVW?;N^TI2UR@'#T;7!KP&92@$+`
M,Z$@`,-"P**P8FET+G)/L][W_]\[WW_?P^`'X$O
MEV6B$X1O?X5_AH^'GXBOB;^*S]VN0@!,3T-+455/5+Y%EH^:OXQOH`^--S62
M$?'+D$]$68N-RV"ASXVA0C?+<4A434QK`'T!IH`````?`$<0`0```!X```!M
M`&4```@0`0```&4```!)2$%6151/0T].0U52+4%3
M3C%$14-/1$524T-!3D)%4D5,051)5D5,65--04Q,4U1%5D534U5'1T535$E/
M3E-)35!,249)15-42$E325-3545!3D1-04M%4TE414%324521D]2``````(!
M?P`!````3P```#PR-$$W,34R-S4V-C%#.#0R.$,P,#0S,D5&0T$U0T(W0S$P
M,48R14!R960M;7-G+3`R+G)E9&UO;F0N8V]R<"YM:6-R;W-O9G0N8V]M/@``
"5(L=
`
end

Received: from po1.bbn.com (PO1.BBN.COM [192.1.50.38]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA04311 for ; Fri, 19 Jan 2001 13:19:57 -0800 (PST)
Received: from [171.78.30.112] (dhcp030-112.genuity.com [171.78.30.112]) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id QAA27838; Fri, 19 Jan 2001 16:25:36 -0500 (EST)
Mime-Version: 1.0
X-Sender: [email-masked] (Unverified)
Message-Id:
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Date: Fri, 19 Jan 2001 10:37:21 -0500
To: Frank Balluffi
From: Stephen Kent
Subject: RE: DID & DIP requirements
Cc: [email-masked]
Content-Type: text/plain; charset="us-ascii" ; format="flowed"

Frank,

>Peter Sylvester said:
>
> > Which server, DPV or DPD?
> > The DPV client is assumed not to have trust in anything
> > else than the server. The server maintains a trust base. It
> > comes to a solution by what local or external means.
>
>Since I'm no longer clear about what the differences are between a DPV and a
>DPD server, whoever is performing the task of discovering paths. Put simply,
>it is not clear to me that such a server knows when it has discovered a
>complete path. In other words, there seem to be two types of trust points:
>points along the path and points at the end of the path.

How about the following definition:

A complete certification path is one that satisfies all of the
validation criteria specified in RFC 2459bis and that terminates at a
certificate configured as a trust anchor in the server and specified
by reference to the policy containing that path, or a path that
terminates at a trust anchor certificate supplied by the client in a
request.

Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA03901 for ; Fri, 19 Jan 2001 13:15:49 -0800 (PST)
Received: from eastmail1.East.Sun.COM ([129.148.1.240]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id NAA12504; Fri, 19 Jan 2001 13:21:34 -0800 (PST)
Received: from sunlabs.East.Sun.COM (sunlabs.East.Sun.COM [129.148.75.250]) by eastmail1.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id QAA27836; Fri, 19 Jan 2001 16:21:33 -0500 (EST)
Received: from sun.com (dhcp75-155 [129.148.75.155]) by sunlabs.East.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id QAA20085; Fri, 19 Jan 2001 16:21:31 -0500 (EST)
Message-ID: <[email-masked]>
Date: Fri, 19 Jan 2001 16:18:35 -0500
From: Steve Hanna
Organization: Sun Microsystems, Inc.
X-Mailer: Mozilla 4.75 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Stephen Kent
CC: Denis Pinkas , PKIX-List
Subject: Re: DPD & DPV requirements
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

I would like to second Steve Kent's comments against associating name
constraints with trust anchors. We need to balance flexibility and
complexity here, I believe.

Most users never tweak their trust anchors. They don't even know what a
trust anchor is. In most cases where trust anchors are modified from the
default, the set of trust anchors is configured by an administrator. For
the administrator who wants to configure a partially trusted CA (with
name constraints), the simplest and best solution is for the
administrator to establish his own CA, issue a cross-certificate to the
partially trusted CA (with name constraints), and configure the
administrator's CA as the trust anchor. This allows the administrator to
modify the set of trusted CAs and the limits placed on that trust ad
infinitum without requiring the application's trust anchors to be
reconfigured (which is often painful).

Associating name constraints with trust anchors adds needless complexity
to application code and user interface. Added complexity increases the
likelihood of bugs and security holes. And this is a slippery slope.
Today, we want name constraints with each trust anchor. Tomorrow, policy
constraints. Then policy mapping. Imagine the user interface for that.
We already have a format for expressing these constraints. It's called a
cross-certificate. Let's not reinvent the wheel.

-Steve

Stephen Kent wrote:
> >[Steve]
> >
> >Self-signed certs are not the only way to deal with multiple roots, and it
> >often seems to me that they are a poor way, when we want to make use of
> >features like naming constraints. Why not just have cross certs issued to
> >other "roots" by a local CA and embed the naming (and policy?) constraints
> >into those cross certs?
> >
> >
> >[Denis]
> >
> >This would be quite an artificial way to do this, and more complex than
> >simply adding the elements to define the policy and naming constraints. The
> >proposal is simply to define the policy constraints and the name
> >constraints. Take a look at the document being progressed in the S/MIME WG
> >which defines a validation policy format for non repudiation: Electronic
> >Signature Policies
>
> I don't think of it as artificial at all. Cross certification is a
> standard way to create links between PKIs, and to express constraints
> on these links. It has the advantage that path validation can be
> applied uniformly rather than having to treat each trust point
> specially, associating name and policy constraints etc. via special
> means. But, I'm not hard over on this.

Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA03841 for ; Fri, 19 Jan 2001 13:15:30 -0800 (PST)
Received: from eastmail1.East.Sun.COM ([129.148.1.240]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id NAA12408; Fri, 19 Jan 2001 13:21:15 -0800 (PST)
Received: from sunlabs.East.Sun.COM (sunlabs.East.Sun.COM [129.148.75.250]) by eastmail1.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id QAA27718; Fri, 19 Jan 2001 16:21:13 -0500 (EST)
Received: from sun.com (dhcp75-155 [129.148.75.155]) by sunlabs.East.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id QAA20034; Fri, 19 Jan 2001 16:21:11 -0500 (EST)
Message-ID: <[email-masked]>
Date: Fri, 19 Jan 2001 16:18:15 -0500
From: Steve Hanna
Organization: Sun Microsystems, Inc.
X-Mailer: Mozilla 4.75 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Stephen Kent , PKIX List
Subject: Re: Need to support non-ASN.1 DPV clients?
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

I have seen one response to my question:

> Do we need to support non-PKI aware, non-ASN.1-capable DPV clients?

Of course, the WG chair is responsible for judging consensus. But given
that the only response was in the negative (indicating that this work
will be done elsewhere) and that nobody has come forward to say we must
support non-ASN.1-capable DPV clients, I will suggest that the consensus
answer is "No, we do not need to support non-PKI aware,
non-ASN.1-capable DPV clients."

That simplifies things a bit.

-Steve

Received: from mail.spyrus.com (mail.spyrus.com [207.212.34.20]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA02407 for ; Fri, 19 Jan 2001 11:56:00 -0800 (PST)
Received: from RHOUSLEY-PC.spyrus.com ([209.172.119.210]) by mail.spyrus.com (8.9.3/8.9.3) with ESMTP id MAA17819; Fri, 19 Jan 2001 12:01:00 -0800 (PST)
Message-Id: <[email-masked]>
X-Sender: [email-masked]
X-Mailer: QUALCOMM Windows Eudora Version 5.0.2
Date: Fri, 19 Jan 2001 13:51:07 -0500
To: David Kemp
From: Russ Housley
Subject: Re: Two questions on delta-CRL
Cc: [email-masked]
In-Reply-To: <[email-masked]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed

Dave:

I understand your operational issue. This was never raised during
discussions prior to RFC 2459 being issued. Perhaps that is because we
each thought that the words meant something different. I would like to
make sure that son-of-RFC 2458 reflects the consensus (regardless of it
being a change to RFC 2459 or not).

Russ

At 02:08 PM 1/18/2001 -0500, David Kemp wrote:
>Russ,
>
>I'm not in favor of standards documents splitting hairs. So if
>"issued" equals "distributed", then new-part-1 MUST be modified
>so that it agrees with X.509, in order to enable delta-CRLs to
>serve any useful purpose.
>
>It makes sense to issue (and push to a global directory) full CRLs
>every 24 hours and deltas every 15 minutes. It makes NO sense to
>push full CRLs every 15 minutes, in addition to the deltas.
>
>Dave
>
>
>
>From: Russ Housley
> >
> >
> > I think we may be splitting hairs on the term "issue." I am not
> > sure that I would consider a CRL that was generated but not distributed
> > to be "issued."

Received: from ext-mail.valicert.com (ns1.valicert.com [63.65.221.10]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA21155 for ; Fri, 19 Jan 2001 07:21:04 -0800 (PST)
Received: from CONVERSION-DAEMON by ext-mail.valicert.com (PMDF V5.2-33 #46613) id <[email-masked]> for [email-masked]; Fri, 19 Jan 2001 07:26:52 -0800 (PST)
Received: from polaris.valicert.com ([192.168.2.34]) by ext-mail.valicert.com (PMDF V5.2-33 #46613) with ESMTP id <[email-masked]>; Fri, 19 Jan 2001 07:26:52 -0800 (PST)
Received: by exchange.valicert.com with Internet Mail Service (5.5.2650.21) id ; Fri, 19 Jan 2001 07:22:32 -0800
Content-return: allowed
Date: Fri, 19 Jan 2001 07:22:31 -0800
From: Frank Balluffi
Subject: RE: DID & DIP requirements
To: "'Peter Sylvester'"
Cc: [email-masked]
Message-id: <[email-masked]>
MIME-version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-type: text/plain; charset="iso-8859-1"

Peter is right. It first appeared in a message I sent. I assume that the
gremlin(s) meant DPD and DPV :-).

Frank

> -----Original Message-----
> From: Peter Sylvester [mailto:[email-masked]]
> Sent: Friday, January 19, 2001 10:24 AM
> To: [email-masked]; [email-masked]
> Cc: [email-masked]
> Subject: RE: DID & DIP requirements
>
>
> >
> > Mike,
> >
> > I assumed that DID and DIP were typos, and that Peter meant
> DPD and DPV.
> >
> > Frank
>
>
> Hm :-) It appeared first in
>
>
> > From: Frank Balluffi
> > Subject: RE: DID & DIP requirements
> > To: "'Peter Sylvester'"
> > Cc: [email-masked]
>
> > Peter Sylvester wrote:
> >
> > > - A client may indicate one or more certificates to be validated.
> > >
> ...
> >
> > Frank
> >
>
> An answer to my message
>
> > From: Peter Sylvester
> > Received: (sylvest@localhost) by emeriau.edelweb.fr
> (8.7.6/8.6.6) id OAA20034; Wed, 17 Jan 2001 14:15:06 +0100 (MET)
> > Date: Wed, 17 Jan 2001 14:15:06 +0100 (MET)
> > To: [email-masked], [email-masked]
> > Subject: RE: DPD & DPV requirements
> > Cc: [email-masked]
> >
> > Frank wrote:
> >
> > > I'm confused. Are people saying that the certificate
> whose path the client
> > > would like to discover or validate is in the unordered
> lump of certificates
> > > or that a separate lump of certificates may be sent to
> assist the server? I
> > > thought the latter.
> >
> > This is not quite clear to me either.
> >
> > Before going to specify a syntax we should state it differently,
> > here some ideas:
> >
> > - A client may indicate one or more certificates to be validated.
> >
> ...
>

Received: from edelweb.fr (edelweb.fr [212.234.46.16]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA20334 for ; Fri, 19 Jan 2001 07:17:56 -0800 (PST)
Received: from champagne.edelweb.fr (localhost.edelweb.fr [127.0.0.1]) by edelweb.fr with ESMTP id QAA22714; Fri, 19 Jan 2001 16:23:31 +0100 (MET)
Received: from champagne.edelweb.fr (champagne.edelweb.fr [193.51.14.161]) by edelweb.fr (nospam/1.3); Fri, 19 Jan 2001 16:23:31 +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 QAA04219; Fri, 19 Jan 2001 16:23:30 +0100 (MET)
From: Peter Sylvester
Received: (sylvest@localhost) by emeriau.edelweb.fr (8.7.6/8.6.6) id QAA20875; Fri, 19 Jan 2001 16:23:30 +0100 (MET)
Date: Fri, 19 Jan 2001 16:23:30 +0100 (MET)
Message-Id: <[email-masked]>
To: [email-masked], [email-masked]
Subject: RE: DID & DIP requirements
Cc: [email-masked]

>
> Mike,
>
> I assumed that DID and DIP were typos, and that Peter meant DPD and DPV.
>
> Frank

Hm :-) It appeared first in

> From: Frank Balluffi
> Subject: RE: DID & DIP requirements
> To: "'Peter Sylvester'"
> Cc: [email-masked]

> Peter Sylvester wrote:
>
> > - A client may indicate one or more certificates to be validated.
> >
...
> Frank

An answer to my message

> From: Peter Sylvester
> Received: (sylvest@localhost) by emeriau.edelweb.fr (8.7.6/8.6.6) id OAA20034; Wed, 17 Jan 2001 14:15:06 +0100 (MET)
> Date: Wed, 17 Jan 2001 14:15:06 +0100 (MET)
> To: [email-masked], [email-masked]
> Subject: RE: DPD & DPV requirements
> Cc: [email-masked]
>
> Frank wrote:
>
> > I'm confused. Are people saying that the certificate whose path the client
> > would like to discover or validate is in the unordered lump of certificates
> > or that a separate lump of certificates may be sent to assist the server? I
> > thought the latter.
>
> This is not quite clear to me either.
>
> Before going to specify a syntax we should state it differently,
> here some ideas:
>
> - A client may indicate one or more certificates to be validated.
>
...

Received: from ext-mail.valicert.com (ns1.valicert.com [63.65.221.10]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA17776 for ; Fri, 19 Jan 2001 06:29:37 -0800 (PST)
Received: from CONVERSION-DAEMON by ext-mail.valicert.com (PMDF V5.2-33 #46613) id <[email-masked]> for [email-masked]; Fri, 19 Jan 2001 06:35:24 -0800 (PST)
Received: from polaris.valicert.com ([192.168.2.34]) by ext-mail.valicert.com (PMDF V5.2-33 #46613) with ESMTP id <[email-masked]>; Fri, 19 Jan 2001 06:35:24 -0800 (PST)
Received: by exchange.valicert.com with Internet Mail Service (5.5.2650.21) id ; Fri, 19 Jan 2001 06:31:04 -0800
Content-return: allowed
Date: Fri, 19 Jan 2001 06:31:03 -0800
From: Frank Balluffi
Subject: RE: DID & DIP requirements
To: "'Michael Myers'"
Cc: [email-masked]
Message-id: <[email-masked]>
MIME-version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-type: text/plain; charset="iso-8859-1"

Mike,

I assumed that DID and DIP were typos, and that Peter meant DPD and DPV.

Frank

> -----Original Message-----
> From: Michael Myers [mailto:[email-masked]]
> Sent: Thursday, January 18, 2001 11:19 PM
> To: Frank Balluffi; 'Peter Sylvester'
> Cc: [email-masked]
> Subject: RE: DID & DIP requirements
>
>
> I've been accused of being the cause for more than a few
> acronyms within
> PKIX, most recently DPV and DPD. But I haven't a clue what
> DID and DIP are.
> Enlightenment or clarification requested.
>
> Mike
>
>
>
> > -----Original Message-----
> > From: Frank Balluffi [mailto:[email-masked]]
> > Sent: Thursday, January 18, 2001 1:03 PM
> > To: 'Peter Sylvester'
> > Cc: [email-masked]
> > Subject: RE: DID & DIP requirements
> >
> >
> > Peter Sylvester said:
> >
> > > Which server, DPV or DPD?
> > > The DPV client is assumed not to have trust in anything
> > > else than the server. The server maintains a trust base. It
> > > comes to a solution by what local or external means.
> >
> > Since I'm no longer clear about what the differences are between
> > a DPV and a
> > DPD server, whoever is performing the task of discovering paths.
> > Put simply,
> > it is not clear to me that such a server knows when it has
> discovered a
> > complete path. In other words, there seem to be two types
> of trust points:
> > points along the path and points at the end of the path.
> >
> > Frank
> >
> > > -----Original Message-----
> > > From: Peter Sylvester [mailto:[email-masked]]
> > > Sent: Thursday, January 18, 2001 2:25 PM
> > > To: [email-masked]; [email-masked]
> > > Cc: [email-masked]
> > > Subject: RE: DID & DIP requirements
> > >
> > >
> > > Frank wrote:
> > >
> > > > Peter Sylvester wrote:
> > > >
> > > > > - A client may indicate one or more certificates to
> be validated.
> > > > >
> > > > > - 1 - Each certificate may be accompagnied by a 'lump' of
> > > certificates
> > > > > that may assist the server to find a valid path for that
> > > > > particular certificate.
> > > > >
> > > > > 2 - There may be an additional bunch of
> certificates that may be
> > > > > used by the server to determine valid paths.
> > > > >
> > > > > I tended to have 1, because for different certs the
> paths may be
> > > > > different, but I may be wrong since even if one throws all the
> > > > > different hints in 1 into one bag, the server could probably
> > > > > find out the good stuff anyway.
> > > >
> > > > 2 seems more efficient to me. I can't see any downside to 2.
> > >
> > > Sounds reasonable.
> > >
> > > >
> > > > How does the server know when it has completed the process
> > > of discovering a
> > > > path? It finds a self-signed certificate [this would break
> > > RFC 2459 path
> > > > validation]? The server maintains a collection of trusted
> > > certificates? The
> > > > client sends a collection of trusted certificates?
> > >
> > > Which server, DPV or DPD?
> > > The DPV client is assumed not to have trust in anything
> > > else than the server. The server maintains a trust base. It
> > > comes to a solution by what local or external means.
> > >
> > >
> > > In DPD this may be completely the other way around.
> > >
> > > >
> > > > The client and server algorithmic descriptions should help
> > > resolve this.
> > >
> > > For DPV you have no algorithmic description in the same way as
> > > you don't know how a OCSP responder came to his conclusion.
> > >
> > > >
> > > > I would argue that having the protocol define a functional
> > > equivalent path
> > > > discovery algorithm, like RFC 2459 does for path
> > > validation, will help
> > > > implementers.
> > >
> > > For a DPV you don't need that. The DPV server verifies
> against against
> > > his local trust base.
> > >
> > > for DPD I am not sure at all, it rather sems to me like a
> > > search in a directory
> > > anyway, and you may need to ask the DPD server several times.
> > >
> > > Peter
> > >
> >
>

Received: from edelweb.fr (edelweb.fr [212.234.46.16]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id CAA26389 for ; Fri, 19 Jan 2001 02:01:11 -0800 (PST)
Received: from champagne.edelweb.fr (localhost.edelweb.fr [127.0.0.1]) by edelweb.fr with ESMTP id LAA20543; Fri, 19 Jan 2001 11:06:47 +0100 (MET)
Received: from champagne.edelweb.fr (champagne.edelweb.fr [193.51.14.161]) by edelweb.fr (nospam/1.3); Fri, 19 Jan 2001 11:06:47 +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 LAA02312; Fri, 19 Jan 2001 11:06:45 +0100 (MET)
From: Peter Sylvester
Received: (sylvest@localhost) by emeriau.edelweb.fr (8.7.6/8.6.6) id LAA20766; Fri, 19 Jan 2001 11:06:44 +0100 (MET)
Date: Fri, 19 Jan 2001 11:06:44 +0100 (MET)
Message-Id: <[email-masked]>
To: [email-masked], [email-masked], [email-masked]
Subject: RE: DPD & DPV requirements
Cc: [email-masked]

> >
> >Not necessarily: If the DPV server just has to say Yes/No, then
> >it may not be PKI aware.
>
> Huh? The DPV server says yes or no based on evaluation of the path
> relative to specified parameters, and based on available revocation
> status data. How does it do this if is is not PKI aware?
You are right.

> I too remain curious since it has been my assertion all along, as expressed
> in the DPV draft, that a DPV server is in fact a concentrator of PKI
> "awareness".\
>
You are right, too.

Im my view the 'DPV' server says yes or now about concerning the
validity and trustworthiness of a certificate. The client does not
necessarily care how he server came to that conclusion.

Received: from e4.ny.us.ibm.com (e4.ny.us.ibm.com [32.97.182.104]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id UAA22507 for ; Thu, 18 Jan 2001 20:10:48 -0800 (PST)
Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.117.200.22]) by e4.ny.us.ibm.com (8.9.3/8.9.3) with ESMTP id XAA252224; Thu, 18 Jan 2001 23:15:34 -0500
Received: from d02ml237.somers.hqregion.ibm.com (d02ml237.sby.ibm.com [9.45.4.171]) by northrelay02.pok.ibm.com (8.8.8m3/NCO v4.95) with ESMTP id XAA172936; Thu, 18 Jan 2001 23:13:33 -0500
Importance: Normal
Subject: Re: Certificate Matching was:RE: Basic Cert-2-Directory mapping question
To:
Cc:
X-Mailer: Lotus Notes Release 5.0.3 (Intl) 21 March 2000
Message-ID:
From: "Tom Gindin"
Date: Thu, 18 Jan 2001 23:16:16 -0500
X-MIMETrack: Serialize by Router on D02ML237/02/M/IBM(Release 5.0.6 |December 14, 2000) at 01/18/2001 11:16:28 PM
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii

Responses below. I'm not against having a general component filter
matching rule, but I do want some shortcuts for common cases. Users are
supposed to be able to formulate LDAP queries by hand, after all, and
something as simple as "find certificates with the following e-mail
address" shouldn't require a 6 line query.

Tom Gindin

"Steven Legg" on 01/18/2001 07:11:24 PM

Please respond to

To: Tom Gindin/Watson/IBM@IBMUS
cc:
Subject: Certificate Matching was:RE: Basic Cert-2-Directory mapping
question

Tom,

> -----Original Message-----
> From: Tom Gindin [mailto:[email-masked]]
> Sent: Tuesday, 16 January 2001 15:30
> To: [email-masked]
> Cc: 'Stephen Kent'; [email-masked]
> Subject: RE: Basic Cert-2-Directory mapping question
>
>
>
> The technique you documented has some effects equivalent to the
> alternative 1 I proposed,

But also what I think are important differences. For a start, the use
of surrogate attributes to search for certificates throws responsibility
for managing the relationship between the surrogates and the certificate
onto the directory clients. It isn't necessarily the case that the
authority responsible for managing values of the surrogate attribute
(e.g. email addresses) is the same as the authority that manages
certificates.
The different authorities could end up stepping on each other's toes, and
access control policies could get in the way of any one authority managing
the relationship.

It isn't always appropriate that the value of the surrogate attribute
matches the value of the corresponding field in the certificate.
Maybe the certificate is valid but uses a superseded value for the
surrogate attribute (maybe the user has changed ISPs and is waiting for
an updated certificate). Maybe the certificate is in a secondary
repository that doesn't/can't hold the surrogate attributes (a partial
replica perhaps). Maybe the certificate is being stored in an entry
other than the certificate owner's nominal entry. Not requiring there
to be a relationship between the fields of a certificate and the other
attributes in an entry gives us more flexibility in how and where to
store certificates in a directory.

[Tom Gindin] In theory, if one of the values of SubjectAltName has been
superseded, the certificate should be revoked. It might well be
appropriate to define a separate multi-valued attribute with a name like
"CertificateEMailAddresses" to hold these values, and in that case the
value goes in the same entry as the cert irrespective of certificate
ownership.

Using surrogate search attributes to support searching on certificates
also doesn't help to isolate one of a number of certificates stored in
the same entry. A matching rule that directly matches a component
in a certificate can be combined with the valuesReturnFilter control
so that the directory server only returns the certificate that matches.
With surrogate search attributes the client will get back all
certificates in the entry and have to filter them itself to find
which is the one it actually wants.

[Tom Gindin] You're right that it doesn't isolate a single cert. It does
cut down the search space from a whole directory to a single entry,
however.

> although with a syntax which requires
> considerable knowledge of ASN.1 to formulate an LDAP query

I recognize that the need to understand ASN.1 in order to formulate a
query is an obstacle to acceptance. To get around that I propose adding
component matching templates to the LDAP/PKI profile for the set of
matching abilities that are regarded as most important and/or most useful.

For example, a section on searching on certificates by the email address
subjectAltName extension would present the following template.

(userCertificate:componentFilterMatch:=item:{
component "toBeSigned.extensions.*",
rule componentFilterMatch,
value and:{
item:{ component "extnId",
rule objectIdentifierMatch, value 2.5.29.17 },
item:{ component "extnValue.content.*.rfc822Name",
rule caseIgnoreMatch, value "EMAIL-ADDRESS" } } } )

A user doesn't need to know any ASN.1 to form a query. They just copy
the template and substitute EMAIL-ADDRESS with the name of interest
(e.g. [email-masked]). There would also be a bit of ABNF
to describe the syntax of the different blanks to fill in in the templates
but that would be required no matter what approach is taken for the
LDAP/PKI profiles.

[Tom Gindin] They need to have the exact ASN.1 layout of the certificate.
They also appear to need to know the matching rule names in considerable
detail.

More sophisticated users can read up on the component matching rules
and try things not covered by the examples, something that wouldn't
be possible with ad-hoc specific definitions.

[Aside: I've changed my mind on how to handle constructs like the
extension value, which is a DER encoding stuffed into an OCTET STRING.
It will be more convenient and useful to extend the component reference
syntax to allow the contents of the OCTET STRING to be treated much
like an open type. So "extnValue" references the OCTET STRING and
"extnValue.content" references the ASN.1 value encoded into that OCTET
STRING, which in this case is expected to be of the GeneralNames type. ]

[Tom Gindin] That's a relief. Frankly, one of the main uses for component
filtering on the PKI formats is to pick up extension values, and if you
can't treat the extension value as an open type you can't filter on
KeyUsage bits, EKU values, or SubjectAltName values. You would still be
able to get the SubjectPublicKey algorithm and the issuer name, at least.

> and with no
> ability to index on the component field (as opposed to
> searching on it).

Why do you assume that component fields can't be effectively indexed ?
I've been implementing the component matching rules as a background job
and lately I've been working on the indexing support. There's a
variety of approaches, with different space/time characteristics,
but I've found indexing support for component matching to be
eminently do-able.

[Tom Gindin] It's possible to create an index out of a component value, but
isn't that more invasive to the implementation of a directory or LDAP
server than defining a simplified search syntax for those components?
Also, how does the user control whether the directory indexes on
SubjectAltName, which is a privacy issue? In my proposal, the decision on
indexing is sent to the CA and RA on a per-user basis (inside CRMF's
publication control).

> This does not mean that I disapprove of the idea of component
> filtering in
> LDAP searches, which IMHO will solve a number of important problems.
> However, in view of the very high proportion of ASN.1 usage within
> directory attributes actually accounted for by the small number of
> PKI-based data structures, wouldn't it be reasonable to define a search
> syntax for them which uses keywords to identify fields,
> rather than the
> generic ASN.1 facility you proposed?

The problem with defining a specific assertion syntax with assigned
keywords is that it defines the limits of what matching can be performed.
If there isn't a syntax/keyword for what you want to do you have to wait
until a suitable syntax/keyword is assigned by some standard, if ever.
A generic facility doesn't have this problem. The component references,
though verbose, are uniform, unambiguous and work for any ASN.1 type
definition.

[Tom Gindin] A generic facility is desirable as a fallback. I do not think
it is desirable as the normal way to get subfields of SubjectAltName or
KeyUsage, however.

> I cannot believe that
> it is really
> appropriate to require LDAP queries for known ASN.1 types to specify
> matching rules within the query.

An ASN.1 type may be known, but that doesn't mean that particular
component parts will always be matched in the same way. Most of the
time a string component will be matched by caseIgnoreMatch but I don't
think it is unreasonable to be able to sometimes match it according
to caseIgnoreOrderingMatch, caseIgnoreSubstringsMatch,
approximateStringMatch,
or presentMatch, among other possibilities. I believe the ability to vary
the matching semantics is useful. However for some component types
(e.g. OBJECT IDENTIFIER, BOOLEAN) there isn't much choice on how to match,
so there is scope to make the rule optional and to assume a reasonable
default rule when the rule is omitted. I wouldn't want to make the default
rules dependent on the attribute syntax because then component matching
can't be completely specified until the matching semantics for each
component of the syntax had been specified in an RFC.

With optional rules the template above would simplify to the following:

(userCertificate:componentFilterMatch:=item:{
component "toBeSigned.extensions.*",
rule componentFilterMatch,
value and:{
item:{ component "extnId", value 2.5.29.17 },
item:{ component "extnValue.content.*.rfc822Name",
value "EMAIL-ADDRESS" } } } )

Such simplifications aren't so important if most users are just filling
in the blanks in a template, although it might make it possible to
reduce the number of templates. For example, one template might suffice
for all subjectAltName cases.

(userCertificate:componentFilterMatch:=item:{
component "toBeSigned.extensions.*",
rule componentFilterMatch,
value and:{
item:{ component "extnId", value 2.5.29.17 },
item:{ component "extnValue.content.*.ALT-NAME-TYPE",
value ALT-NAME-VALUE } } } )

[Tom Gindin] That won't be very helpful for the compound types, nor for
OTHER-NAME. However, it would give you a match for 5 of the 8 base types
in GeneralName.

Regards,
Steven

>
> Tom Gindin
>
>
> "Steven Legg" on 01/15/2001 10:56:28 PM
>
> Please respond to
>
> To: Tom Gindin/Watson/IBM@IBMUS, "'Stephen Kent'"
> cc:
> Subject: RE: Basic Cert-2-Directory mapping question
>
>
>
>
> Tom,
>
> > -----Original Message-----
> > From: Tom Gindin [mailto:[email-masked]]
> > Sent: Saturday, 13 January 2001 18:48
> > To: Stephen Kent
> > Cc: [email-masked]
> > Subject: Re: Basic Cert-2-Directory mapping question
> >
> >
> >
> > Steve:
> >
> > Isn't a substantial part of this problem the question of how to
> > publish a certificate in a directory where it will be
> > searchable by a field
> > within SubjectAltName, most importantly the e-mail address
> > when that is
> > included? Most of the arguments which I have ever heard
> for including
> > e-mail address in the subject DN were actually searchability
> > arguments.
> > The names in SubjectAltName are typically hierarchically
> assigned, of
> > course, but they aren't X.500-based.
> > Assuming that an EE wants their certificate published
> > under the e-mail
> > address, IMHO they should be able to request the RA or CA to
> > perform one of
> > the following actions on a successful certificate issuance
> (using the
> > publication info control or a similar mechanism):
> > 1 Add a directory attribute for e-mail address whose value
> > is the e-mail
> > address in the SubjectAltName to the directory entry named by
> > the Subject
> > DN. Very often, the RA or CA has the privilege and the
> > knowledge to do
> > this and the EE has only one or neither.
> > 2 Send a certificate announcement to the domain of the
> > e-mail address,
> > in the hope and (reasonable) expectation that the
> certificate will be
> > published there.
> >
> > Similar, but less practically important, considerations
> > apply to other
> > addresses in SubjectAltName. IMHO we also need to profile
> > which directory
> > attributes should normally be used when indexing a
> > certificate under fields
> > within SubjectAltName, especially since there are at least
> two fairly
> > common attributes for e-mail address.
>
> Rather than using other attributes as surrogates for searching for
> certificates with particular fields (of subjectAltName or any other
> component) I think it is more appropriate to have the capability to
> search for those certificates directly. The refinement of the
> component
> matching rules in my last reply to David Chadwick would make
> it possible
> to search for entries containing certificates with a particular
> SubjectAltName regardless of whether the alternate name was reflected
> in any other attribute(s) in the entry. Such a solution
> avoids questions
> about which other attributes to search, and doesn't require
> RAs or CAs to
> populate said attributes.
>
> Regards,
> Steven
>
> >
> > Tom Gindin
> >
> > P.S. - The opinions above are my own, and not necessarily
> > those of my
> > employer.
> >

Received: from geos.coastside.net (geos.coastside.net [207.213.212.4]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id UAA22284 for ; Thu, 18 Jan 2001 20:08:54 -0800 (PST)
Received: from heatherdale (dsl-63-194-153-52.coastside.net [63.194.153.52]) by geos.coastside.net (8.11.0/8.11.1) with SMTP id f0J4EUc14623; Thu, 18 Jan 2001 20:14:30 -0800 (PST)
From: "Michael Myers"
To: "Frank Balluffi" , "'Peter Sylvester'"
Cc:
Subject: RE: DID & DIP requirements
Date: Thu, 18 Jan 2001 20:18:40 -0800
Message-ID:
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)
In-Reply-To: <[email-masked]>
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300

I've been accused of being the cause for more than a few acronyms within
PKIX, most recently DPV and DPD. But I haven't a clue what DID and DIP are.
Enlightenment or clarification requested.

Mike

> -----Original Message-----
> From: Frank Balluffi [mailto:[email-masked]]
> Sent: Thursday, January 18, 2001 1:03 PM
> To: 'Peter Sylvester'
> Cc: [email-masked]
> Subject: RE: DID & DIP requirements
>
>
> Peter Sylvester said:
>
> > Which server, DPV or DPD?
> > The DPV client is assumed not to have trust in anything
> > else than the server. The server maintains a trust base. It
> > comes to a solution by what local or external means.
>
> Since I'm no longer clear about what the differences are between
> a DPV and a
> DPD server, whoever is performing the task of discovering paths.
> Put simply,
> it is not clear to me that such a server knows when it has discovered a
> complete path. In other words, there seem to be two types of trust points:
> points along the path and points at the end of the path.
>
> Frank
>
> > -----Original Message-----
> > From: Peter Sylvester [mailto:[email-masked]]
> > Sent: Thursday, January 18, 2001 2:25 PM
> > To: [email-masked]; [email-masked]
> > Cc: [email-masked]
> > Subject: RE: DID & DIP requirements
> >
> >
> > Frank wrote:
> >
> > > Peter Sylvester wrote:
> > >
> > > > - A client may indicate one or more certificates to be validated.
> > > >
> > > > - 1 - Each certificate may be accompagnied by a 'lump' of
> > certificates
> > > > that may assist the server to find a valid path for that
> > > > particular certificate.
> > > >
> > > > 2 - There may be an additional bunch of certificates that may be
> > > > used by the server to determine valid paths.
> > > >
> > > > I tended to have 1, because for different certs the paths may be
> > > > different, but I may be wrong since even if one throws all the
> > > > different hints in 1 into one bag, the server could probably
> > > > find out the good stuff anyway.
> > >
> > > 2 seems more efficient to me. I can't see any downside to 2.
> >
> > Sounds reasonable.
> >
> > >
> > > How does the server know when it has completed the process
> > of discovering a
> > > path? It finds a self-signed certificate [this would break
> > RFC 2459 path
> > > validation]? The server maintains a collection of trusted
> > certificates? The
> > > client sends a collection of trusted certificates?
> >
> > Which server, DPV or DPD?
> > The DPV client is assumed not to have trust in anything
> > else than the server. The server maintains a trust base. It
> > comes to a solution by what local or external means.
> >
> >
> > In DPD this may be completely the other way around.
> >
> > >
> > > The client and server algorithmic descriptions should help
> > resolve this.
> >
> > For DPV you have no algorithmic description in the same way as
> > you don't know how a OCSP responder came to his conclusion.
> >
> > >
> > > I would argue that having the protocol define a functional
> > equivalent path
> > > discovery algorithm, like RFC 2459 does for path
> > validation, will help
> > > implementers.
> >
> > For a DPV you don't need that. The DPV server verifies against against
> > his local trust base.
> >
> > for DPD I am not sure at all, it rather sems to me like a
> > search in a directory
> > anyway, and you may need to ask the DPD server several times.
> >
> > Peter
> >
>

Received: from geos.coastside.net (geos.coastside.net [207.213.212.4]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id UAA22014 for ; Thu, 18 Jan 2001 20:04:58 -0800 (PST)
Received: from heatherdale (dsl-63-194-153-52.coastside.net [63.194.153.52]) by geos.coastside.net (8.11.0/8.11.1) with SMTP id f0J4ASc14414; Thu, 18 Jan 2001 20:10:28 -0800 (PST)
From: "Michael Myers"
To: "Stephen Kent" , "Peter Sylvester"
Cc:
Subject: RE: DPD & DPV requirements
Date: Thu, 18 Jan 2001 20:14:38 -0800
Message-ID:
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)
In-Reply-To:
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300

I too remain curious since it has been my assertion all along, as expressed
in the DPV draft, that a DPV server is in fact a concentrator of PKI
"awareness".\

Mike

> -----Original Message-----
> From: Stephen Kent [mailto:[email-masked]]
> Sent: Thursday, January 18, 2001 8:13 AM
> To: Peter Sylvester
> Cc: [email-masked]
> Subject: RE: DPD & DPV requirements
>
>
> At 3:30 PM +0100 1/17/01, Peter Sylvester wrote:
> > > But, the need for both severs to perform path validation still seems
> > > to be true.
> >
> >Not necessarily: If the DPV server just has to say Yes/No, then
> >it may not be PKI aware.
>
> Huh? The DPV server says yes or no based on evaluation of the path
> relative to specified parameters, and based on available revocation
> status data. How does it do this if is is not PKI aware?
>
> Steve
>
>

Received: from arnie.adacel.com.au (arnie.adacel.com.au [203.36.26.147]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id QAA17887 for ; Thu, 18 Jan 2001 16:23:11 -0800 (PST)
Received: (qmail 13005 invoked from network); 19 Jan 2001 00:38:34 -0000
Received: from unknown (HELO osmium) (203.8.85.176) by arnie.adacel.com.au with SMTP; 19 Jan 2001 00:38:34 -0000
Reply-To:
From: "Steven Legg"
To: "'Michael Str der'"
Cc: "'ietf-pkix'"
Subject: Certificate Matching was:RE: Basic Cert-2-Directory mapping question
Date: Fri, 19 Jan 2001 11:29:50 +1100
Message-ID: <[email-masked]>
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 8.5, Build 4.71.2377.0
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2120.0
In-Reply-To: <[email-masked]>
Importance: Normal

Michael,

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On Behalf
> Of Michael
> Str der
> Sent: Tuesday, 16 January 2001 21:50
> To: ietf-pkix
> Subject: Re: Basic Cert-2-Directory mapping question
>
>
> Tom Gindin wrote:
> >
> > wouldn't it be reasonable to define a search
> > syntax for them which uses keywords to identify fields,
> rather than the
> > generic ASN.1 facility you proposed? I cannot believe that
> it is really
> > appropriate to require LDAP queries for known ASN.1 types to specify
> > matching rules within the query.
>
> As far as I understand this I-D the LDAP client will just construct
> LDAP filter strings as usual. The LDAP server deals with the ugly
> stuff as it deals with ASN.1 structures when doing searches anyway.
>
> Steve, David, correct me if I'm wrong.

More precisely, the assertions in an LDAP filter are still text strings,
so a user doesn't need to understand BER to use component matching.
An understanding of the ASN.1 syntax definition of the attribute type
being searched helps, but it is possible to write the PKI profiles such
that ASN.1-unaware users can easily formulate useful queries.

An LDAP filter has actually always been a mix of BER and text encodings.
APIs generally hide the BER parts from users. An LDAP filter has a string
representation according to RFC 2254, but this is not used by the LDAP
search operation.

Regards,
Steven

> Ciao, Michael.

Received: from arnie.adacel.com.au (arnie.adacel.com.au [203.36.26.147]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id QAA16223 for ; Thu, 18 Jan 2001 16:04:58 -0800 (PST)
Received: (qmail 11122 invoked from network); 19 Jan 2001 00:20:11 -0000
Received: from unknown (HELO osmium) (203.8.85.176) by arnie.adacel.com.au with SMTP; 19 Jan 2001 00:20:11 -0000
Reply-To:
From: "Steven Legg"
To: "'Tom Gindin'"
Cc:
Subject: Certificate Matching was:RE: Basic Cert-2-Directory mapping question
Date: Fri, 19 Jan 2001 11:11:24 +1100
Message-ID: <[email-masked]>
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 8.5, Build 4.71.2377.0
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2120.0
In-Reply-To:
Importance: Normal

Tom,

> -----Original Message-----
> From: Tom Gindin [mailto:[email-masked]]
> Sent: Tuesday, 16 January 2001 15:30
> To: [email-masked]
> Cc: 'Stephen Kent'; [email-masked]
> Subject: RE: Basic Cert-2-Directory mapping question
>
>
>
> The technique you documented has some effects equivalent to the
> alternative 1 I proposed,

But also what I think are important differences. For a start, the use
of surrogate attributes to search for certificates throws responsibility
for managing the relationship between the surrogates and the certificate
onto the directory clients. It isn't necessarily the case that the
authority responsible for managing values of the surrogate attribute
(e.g. email addresses) is the same as the authority that manages
certificates.
The different authorities could end up stepping on each other's toes, and
access control policies could get in the way of any one authority managing
the relationship.

It isn't always appropriate that the value of the surrogate attribute
matches the value of the corresponding field in the certificate.
Maybe the certificate is valid but uses a superseded value for the
surrogate attribute (maybe the user has changed ISPs and is waiting for
an updated certificate). Maybe the certificate is in a secondary
repository that doesn't/can't hold the surrogate attributes (a partial
replica perhaps). Maybe the certificate is being stored in an entry
other than the certificate owner's nominal entry. Not requiring there
to be a relationship between the fields of a certificate and the other
attributes in an entry gives us more flexibility in how and where to
store certificates in a directory.

Using surrogate search attributes to support searching on certificates
also doesn't help to isolate one of a number of certificates stored in
the same entry. A matching rule that directly matches a component
in a certificate can be combined with the valuesReturnFilter control
so that the directory server only returns the certificate that matches.
With surrogate search attributes the client will get back all
certificates in the entry and have to filter them itself to find
which is the one it actually wants.

> although with a syntax which requires
> considerable knowledge of ASN.1 to formulate an LDAP query

I recognize that the need to understand ASN.1 in order to formulate a
query is an obstacle to acceptance. To get around that I propose adding
component matching templates to the LDAP/PKI profile for the set of
matching abilities that are regarded as most important and/or most useful.

For example, a section on searching on certificates by the email address
subjectAltName extension would present the following template.

(userCertificate:componentFilterMatch:=item:{
component "toBeSigned.extensions.*",
rule componentFilterMatch,
value and:{
item:{ component "extnId",
rule objectIdentifierMatch, value 2.5.29.17 },
item:{ component "extnValue.content.*.rfc822Name",
rule caseIgnoreMatch, value "EMAIL-ADDRESS" } } } )

A user doesn't need to know any ASN.1 to form a query. They just copy
the template and substitute EMAIL-ADDRESS with the name of interest
(e.g. [email-masked]). There would also be a bit of ABNF
to describe the syntax of the different blanks to fill in in the templates
but that would be required no matter what approach is taken for the
LDAP/PKI profiles.

More sophisticated users can read up on the component matching rules
and try things not covered by the examples, something that wouldn't
be possible with ad-hoc specific definitions.

[Aside: I've changed my mind on how to handle constructs like the
extension value, which is a DER encoding stuffed into an OCTET STRING.
It will be more convenient and useful to extend the component reference
syntax to allow the contents of the OCTET STRING to be treated much
like an open type. So "extnValue" references the OCTET STRING and
"extnValue.content" references the ASN.1 value encoded into that OCTET
STRING, which in this case is expected to be of the GeneralNames type. ]

> and with no
> ability to index on the component field (as opposed to
> searching on it).

Why do you assume that component fields can't be effectively indexed ?
I've been implementing the component matching rules as a background job
and lately I've been working on the indexing support. There's a
variety of approaches, with different space/time characteristics,
but I've found indexing support for component matching to be
eminently do-able.

> This does not mean that I disapprove of the idea of component
> filtering in
> LDAP searches, which IMHO will solve a number of important problems.
> However, in view of the very high proportion of ASN.1 usage within
> directory attributes actually accounted for by the small number of
> PKI-based data structures, wouldn't it be reasonable to define a search
> syntax for them which uses keywords to identify fields,
> rather than the
> generic ASN.1 facility you proposed?

The problem with defining a specific assertion syntax with assigned
keywords is that it defines the limits of what matching can be performed.
If there isn't a syntax/keyword for what you want to do you have to wait
until a suitable syntax/keyword is assigned by some standard, if ever.
A generic facility doesn't have this problem. The component references,
though verbose, are uniform, unambiguous and work for any ASN.1 type
definition.

> I cannot believe that
> it is really
> appropriate to require LDAP queries for known ASN.1 types to specify
> matching rules within the query.

An ASN.1 type may be known, but that doesn't mean that particular
component parts will always be matched in the same way. Most of the
time a string component will be matched by caseIgnoreMatch but I don't
think it is unreasonable to be able to sometimes match it according
to caseIgnoreOrderingMatch, caseIgnoreSubstringsMatch,
approximateStringMatch,
or presentMatch, among other possibilities. I believe the ability to vary
the matching semantics is useful. However for some component types
(e.g. OBJECT IDENTIFIER, BOOLEAN) there isn't much choice on how to match,
so there is scope to make the rule optional and to assume a reasonable
default rule when the rule is omitted. I wouldn't want to make the default
rules dependent on the attribute syntax because then component matching
can't be completely specified until the matching semantics for each
component of the syntax had been specified in an RFC.

With optional rules the template above would simplify to the following:

(userCertificate:componentFilterMatch:=item:{
component "toBeSigned.extensions.*",
rule componentFilterMatch,
value and:{
item:{ component "extnId", value 2.5.29.17 },
item:{ component "extnValue.content.*.rfc822Name",
value "EMAIL-ADDRESS" } } } )

Such simplifications aren't so important if most users are just filling
in the blanks in a template, although it might make it possible to
reduce the number of templates. For example, one template might suffice
for all subjectAltName cases.

(userCertificate:componentFilterMatch:=item:{
component "toBeSigned.extensions.*",
rule componentFilterMatch,
value and:{
item:{ component "extnId", value 2.5.29.17 },
item:{ component "extnValue.content.*.ALT-NAME-TYPE",
value ALT-NAME-VALUE } } } )

Regards,
Steven

>
> Tom Gindin
>
>
> "Steven Legg" on 01/15/2001 10:56:28 PM
>
> Please respond to
>
> To: Tom Gindin/Watson/IBM@IBMUS, "'Stephen Kent'"
> cc:
> Subject: RE: Basic Cert-2-Directory mapping question
>
>
>
>
> Tom,
>
> > -----Original Message-----
> > From: Tom Gindin [mailto:[email-masked]]
> > Sent: Saturday, 13 January 2001 18:48
> > To: Stephen Kent
> > Cc: [email-masked]
> > Subject: Re: Basic Cert-2-Directory mapping question
> >
> >
> >
> > Steve:
> >
> > Isn't a substantial part of this problem the question of how to
> > publish a certificate in a directory where it will be
> > searchable by a field
> > within SubjectAltName, most importantly the e-mail address
> > when that is
> > included? Most of the arguments which I have ever heard
> for including
> > e-mail address in the subject DN were actually searchability
> > arguments.
> > The names in SubjectAltName are typically hierarchically
> assigned, of
> > course, but they aren't X.500-based.
> > Assuming that an EE wants their certificate published
> > under the e-mail
> > address, IMHO they should be able to request the RA or CA to
> > perform one of
> > the following actions on a successful certificate issuance
> (using the
> > publication info control or a similar mechanism):
> > 1 Add a directory attribute for e-mail address whose value
> > is the e-mail
> > address in the SubjectAltName to the directory entry named by
> > the Subject
> > DN. Very often, the RA or CA has the privilege and the
> > knowledge to do
> > this and the EE has only one or neither.
> > 2 Send a certificate announcement to the domain of the
> > e-mail address,
> > in the hope and (reasonable) expectation that the
> certificate will be
> > published there.
> >
> > Similar, but less practically important, considerations
> > apply to other
> > addresses in SubjectAltName. IMHO we also need to profile
> > which directory
> > attributes should normally be used when indexing a
> > certificate under fields
> > within SubjectAltName, especially since there are at least
> two fairly
> > common attributes for e-mail address.
>
> Rather than using other attributes as surrogates for searching for
> certificates with particular fields (of subjectAltName or any other
> component) I think it is more appropriate to have the capability to
> search for those certificates directly. The refinement of the
> component
> matching rules in my last reply to David Chadwick would make
> it possible
> to search for entries containing certificates with a particular
> SubjectAltName regardless of whether the alternate name was reflected
> in any other attribute(s) in the entry. Such a solution
> avoids questions
> about which other attributes to search, and doesn't require
> RAs or CAs to
> populate said attributes.
>
> Regards,
> Steven
>
> >
> > Tom Gindin
> >
> > P.S. - The opinions above are my own, and not necessarily
> > those of my
> > employer.
> >
> >
> >
>
>
>
>

Received: from po1.bbn.com (PO1.BBN.COM [192.1.50.38]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA14852 for ; Thu, 18 Jan 2001 15:46:14 -0800 (PST)
Received: from [128.33.238.87] (TC087.BBN.COM [128.33.238.87]) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id SAA15374; Thu, 18 Jan 2001 18:51:39 -0500 (EST)
Mime-Version: 1.0
X-Sender: [email-masked] (Unverified)
Message-Id:
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Date: Thu, 18 Jan 2001 17:06:45 -0500
To: David Kemp
From: Stephen Kent
Subject: RE: Basic Cert-2-Directory mapping question
Cc: [email-masked]
Content-Type: text/plain; charset="us-ascii" ; format="flowed"

Dave,

>Skip,
>
>I favor the implicit approach.
>
>Existing DNs schemas have tremendous inertia, and in addition to
>more intellectual reasons, registering existing country-based
>DNs within DNS is overwhelmingly the path of least resistance.
>In order to support Internet directory interoperability, it is far
>easier to say (to the DoD PKI, for example):
>
> "You have to register a DNS record for OU=DoD."
>
>rather than:
>
> "You have to change all of your certificates and directories to
> include a new top-level RDN."
>
>I agree with Bob's goal of eliminating the need to pass certs in
>session handshakes and messages. If there were only two options (change
>the DN or add an extension), then only the first moves toward that
>goal. But you have proposed a third option: leave the cert alone!
>For my part, I am simply in awe of the elegance of that approach.
>It might even work.

I don't agree that doing away with transmission of certs and CRLs
inline via protocols, is a good idea in general. I understand why Bob
wants to do this in his examples, but there is another side to the
story. Reliance on the availability of a repository as a precursor to
secure communications makes the secure communications more vulnerable
to denial of service attacks, as well as creating likely greater
delays security association creation. So, for protocols like SSL and
IPsec, I'm more comfortable with passing this data inline, rather
than relying on retrieving it from a server.

E-mail is the really good example of a general purpose application
where it is necessary to retrieve a certificate for an encryption key
from a server (or receive it inline from the peer who is the target
of the message) prior to communication. But, for signed-only
messages, passing cert chains and CRLs is still a reasonable strategy.

Steve

Received: from po1.bbn.com (PO1.BBN.COM [192.1.50.38]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA14787 for ; Thu, 18 Jan 2001 15:45:07 -0800 (PST)
Received: from [128.33.238.87] (TC087.BBN.COM [128.33.238.87]) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id SAA15320; Thu, 18 Jan 2001 18:50:33 -0500 (EST)
Mime-Version: 1.0
X-Sender: [email-masked] (Unverified)
Message-Id:
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Date: Thu, 18 Jan 2001 11:12:37 -0500
To: Peter Sylvester
From: Stephen Kent
Subject: RE: DPD & DPV requirements
Cc: [email-masked]
Content-Type: text/plain; charset="us-ascii" ; format="flowed"

At 3:30 PM +0100 1/17/01, Peter Sylvester wrote:
> > But, the need for both severs to perform path validation still seems
> > to be true.
>
>Not necessarily: If the DPV server just has to say Yes/No, then
>it may not be PKI aware.

Huh? The DPV server says yes or no based on evaluation of the path
relative to specified parameters, and based on available revocation
status data. How does it do this if is is not PKI aware?

Steve

Received: from ext-mail.valicert.com (ns1.valicert.com [63.65.221.10]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA06534 for ; Thu, 18 Jan 2001 13:01:26 -0800 (PST)
Received: from CONVERSION-DAEMON by ext-mail.valicert.com (PMDF V5.2-33 #46613) id <[email-masked]> for [email-masked]; Thu, 18 Jan 2001 13:07:10 -0800 (PST)
Received: from polaris.valicert.com ([192.168.2.34]) by ext-mail.valicert.com (PMDF V5.2-33 #46613) with ESMTP id <[email-masked]>; Thu, 18 Jan 2001 13:07:09 -0800 (PST)
Received: by exchange.valicert.com with Internet Mail Service (5.5.2650.21) id ; Thu, 18 Jan 2001 13:02:51 -0800
Content-return: allowed
Date: Thu, 18 Jan 2001 13:02:51 -0800
From: Frank Balluffi
Subject: RE: DID & DIP requirements
To: "'Peter Sylvester'"
Cc: [email-masked]
Message-id: <[email-masked]>
MIME-version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-type: text/plain; charset="iso-8859-1"

Peter Sylvester said:

> Which server, DPV or DPD?
> The DPV client is assumed not to have trust in anything
> else than the server. The server maintains a trust base. It
> comes to a solution by what local or external means.

Since I'm no longer clear about what the differences are between a DPV and a
DPD server, whoever is performing the task of discovering paths. Put simply,
it is not clear to me that such a server knows when it has discovered a
complete path. In other words, there seem to be two types of trust points:
points along the path and points at the end of the path.

Frank

> -----Original Message-----
> From: Peter Sylvester [mailto:[email-masked]]
> Sent: Thursday, January 18, 2001 2:25 PM
> To: [email-masked]; [email-masked]
> Cc: [email-masked]
> Subject: RE: DID & DIP requirements
>
>
> Frank wrote:
>
> > Peter Sylvester wrote:
> >
> > > - A client may indicate one or more certificates to be validated.
> > >
> > > - 1 - Each certificate may be accompagnied by a 'lump' of
> certificates
> > > that may assist the server to find a valid path for that
> > > particular certificate.
> > >
> > > 2 - There may be an additional bunch of certificates that may be
> > > used by the server to determine valid paths.
> > >
> > > I tended to have 1, because for different certs the paths may be
> > > different, but I may be wrong since even if one throws all the
> > > different hints in 1 into one bag, the server could probably
> > > find out the good stuff anyway.
> >
> > 2 seems more efficient to me. I can't see any downside to 2.
>
> Sounds reasonable.
>
> >
> > How does the server know when it has completed the process
> of discovering a
> > path? It finds a self-signed certificate [this would break
> RFC 2459 path
> > validation]? The server maintains a collection of trusted
> certificates? The
> > client sends a collection of trusted certificates?
>
> Which server, DPV or DPD?
> The DPV client is assumed not to have trust in anything
> else than the server. The server maintains a trust base. It
> comes to a solution by what local or external means.
>
>
> In DPD this may be completely the other way around.
>
> >
> > The client and server algorithmic descriptions should help
> resolve this.
>
> For DPV you have no algorithmic description in the same way as
> you don't know how a OCSP responder came to his conclusion.
>
> >
> > I would argue that having the protocol define a functional
> equivalent path
> > discovery algorithm, like RFC 2459 does for path
> validation, will help
> > implementers.
>
> For a DPV you don't need that. The DPV server verifies against against
> his local trust base.
>
> for DPD I am not sure at all, it rather sems to me like a
> search in a directory
> anyway, and you may need to ask the DPD server several times.
>
> Peter
>

Received: from edelweb.fr (edelweb.fr [212.234.46.16]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA00476 for ; Thu, 18 Jan 2001 11:19:10 -0800 (PST)
Received: from champagne.edelweb.fr (localhost.edelweb.fr [127.0.0.1]) by edelweb.fr with ESMTP id UAA16444; Thu, 18 Jan 2001 20:24:41 +0100 (MET)
Received: from champagne.edelweb.fr (champagne.edelweb.fr [193.51.14.161]) by edelweb.fr (nospam/1.3); Thu, 18 Jan 2001 20:24:41 +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 UAA29899; Thu, 18 Jan 2001 20:24:40 +0100 (MET)
From: Peter Sylvester
Received: (sylvest@localhost) by emeriau.edelweb.fr (8.7.6/8.6.6) id UAA20501; Thu, 18 Jan 2001 20:24:39 +0100 (MET)
Date: Thu, 18 Jan 2001 20:24:39 +0100 (MET)
Message-Id: <[email-masked]>
To: [email-masked], [email-masked]
Subject: RE: DID & DIP requirements
Cc: [email-masked]

Frank wrote:

> Peter Sylvester wrote:
>
> > - A client may indicate one or more certificates to be validated.
> >
> > - 1 - Each certificate may be accompagnied by a 'lump' of certificates
> > that may assist the server to find a valid path for that
> > particular certificate.
> >
> > 2 - There may be an additional bunch of certificates that may be
> > used by the server to determine valid paths.
> >
> > I tended to have 1, because for different certs the paths may be
> > different, but I may be wrong since even if one throws all the
> > different hints in 1 into one bag, the server could probably
> > find out the good stuff anyway.
>
> 2 seems more efficient to me. I can't see any downside to 2.

Sounds reasonable.

>
> How does the server know when it has completed the process of discovering a
> path? It finds a self-signed certificate [this would break RFC 2459 path
> validation]? The server maintains a collection of trusted certificates? The
> client sends a collection of trusted certificates?

Which server, DPV or DPD?
The DPV client is assumed not to have trust in anything
else than the server. The server maintains a trust base. It
comes to a solution by what local or external means.

In DPD this may be completely the other way around.

>
> The client and server algorithmic descriptions should help resolve this.

For DPV you have no algorithmic description in the same way as
you don't know how a OCSP responder came to his conclusion.

>
> I would argue that having the protocol define a functional equivalent path
> discovery algorithm, like RFC 2459 does for path validation, will help
> implementers.

For a DPV you don't need that. The DPV server verifies against against
his local trust base.

for DPD I am not sure at all, it rather sems to me like a search in a directory
anyway, and you may need to ask the DPD server several times.

Peter

Received: from stingray.missi.ncsc.mil (stingray.missi.ncsc.mil [144.51.50.20]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA28983 for ; Thu, 18 Jan 2001 11:02:35 -0800 (PST)
Received: from stingray.missi.ncsc.mil (root@localhost) by stingray.missi.ncsc.mil with ESMTP id OAA03676 for ; Thu, 18 Jan 2001 14:07:48 -0500 (EST)
Message-Id: <[email-masked]>
Date: Thu, 18 Jan 2001 14:08:56 -0500 (EST)
From: David Kemp
Reply-To: David Kemp
Subject: Re: Two questions on delta-CRL
To: [email-masked]
MIME-Version: 1.0
Content-Type: TEXT/plain; charset=us-ascii
Content-MD5: PfQJjRb2VsJhTuShps174g==

Russ,

I'm not in favor of standards documents splitting hairs. So if
"issued" equals "distributed", then new-part-1 MUST be modified
so that it agrees with X.509, in order to enable delta-CRLs to
serve any useful purpose.

It makes sense to issue (and push to a global directory) full CRLs
every 24 hours and deltas every 15 minutes. It makes NO sense to
push full CRLs every 15 minutes, in addition to the deltas.

Dave

From: Russ Housley
>
>
> I think we may be splitting hairs on the term "issue." I am not
> sure that I would consider a CRL that was generated but not distributed
> to be "issued."

Received: from mailgw2a.lmco.com (mailgw2a.lmco.com [192.91.147.7]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA28138 for ; Thu, 18 Jan 2001 10:34:39 -0800 (PST)
Received: from emss03g01.ems.lmco.com (emss03g01.ems.lmco.com [141.240.4.144]) by mailgw2a.lmco.com (8.8.8/8.8.8) with ESMTP id NAA27900; Thu, 18 Jan 2001 13:40:13 -0500 (EST)
Received: from CONVERSION-DAEMON by lmco.com (PMDF V5.2-32 #38888) id <[email-masked]>; Thu, 18 Jan 2001 13:39:14 -0500 (EST)
Received: from emss03i00.ems.lmco.com ([141.240.31.211]) by lmco.com (PMDF V5.2-32 #38888) with ESMTP id <[email-masked]>; Thu, 18 Jan 2001 13:15:57 -0500 (EST)
Received: by emss03i00.orl.lmco.com with Internet Mail Service (5.5.2650.21) id ; Thu, 18 Jan 2001 13:17:05 -0500
Content-return: allowed
Date: Thu, 18 Jan 2001 13:17:04 -0500
From: "Slone, Skip"
Subject: RE: Basic Cert-2-Directory mapping question
To: "'David Kemp'" , [email-masked]
Message-id:
MIME-version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-type: text/plain
Content-transfer-encoding: 7BIT

Dave,

You wrote:

"For my part, I am simply in awe of the elegance of that approach.
It might even work."

Thanks for the vote of confidence. In theory, the approach I've outlined
could actually be extended to the entire set of possible DNs by taking it up
one level. That is -- and remember I'm talking theory, here -- by extending
the concept to include the registration of "AVA RRs" under "." any
syntactically valid DN could be resolved in this fashion. Of course,
there's a difference between "theoretically possible" and getting it through
IANA...

-- Skip

-----Original Message-----
From: David Kemp [mailto:[email-masked]]
Sent: Wednesday, January 17, 2001 4:06 PM
To: [email-masked]
Subject: RE: Basic Cert-2-Directory mapping question

Skip,

I favor the implicit approach.

Existing DNs schemas have tremendous inertia, and in addition to
more intellectual reasons, registering existing country-based
DNs within DNS is overwhelmingly the path of least resistance.
In order to support Internet directory interoperability, it is far
easier to say (to the DoD PKI, for example):

"You have to register a DNS record for OU=DoD."

rather than:

"You have to change all of your certificates and directories to
include a new top-level RDN."

I agree with Bob's goal of eliminating the need to pass certs in
session handshakes and messages. If there were only two options (change
the DN or add an extension), then only the first moves toward that
goal. But you have proposed a third option: leave the cert alone!
For my part, I am simply in awe of the elegance of that approach.
It might even work.

Dave

From: "Bob Jueneman"
>
> Ron,
>
> I don't think we are on the same page.
>
> I don't conceive of the dir= attribute as constituting a non-DIT RDN.
> Instead, I am suggesting that we should add the dir= attribute as a full
> RDN component at the top of the existing DIT.
>
> I believe that it really belongs there, to qualify the lower level entries
> as belonging to that particular directory, just as is the case with
"normal"
> DN qualification.. So yes, I believe that you ought to be able to see
> that entry when browsing the directory, not withstanding the act that
> it would normally be static.

> The alternative, using an LDAP-style qualifier to precede the DN, is
> what strikes me as being abhorrent.
>
> If I have a DN that includes at the top of the DIT the name of the
> directory root itself, then that DN can be handled by all applications
> that know how to parse DNs generally. Otherwise, we are left with
> protocol-specific hacks, like URLs with trailing DNs.
>
> Bob
>
>
>
> From: "Ramsay, Ron"
>
> > Bob,
> >
> > While it may be true that 'c=us' does not try to say something about
> > countries, I don't believe this is relevant. The importance of this RDN
in
> > the DN is that, notionally, there is an entry with the DN 'c=us'. When
> > browsing an X.500 DIT, you should be able to see all the superior
entries as
> > indicated bu the RDNs in the entry DN. This is the semantic meaning of
the
> > DN, not 'what does country mean in this DN'. To this extent, the idea of
> > adding a non-DIT RDN to the DN is abhorrent and will create real
problems.
> > (LDAP directories generally aren't browsable so I guess my remarks don't
> > apply to them.)
> >
> > Ron.

[ 15 additional messages snipped ... ]

Received: from mail.spyrus.com (mail.spyrus.com [207.212.34.20]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA25543 for ; Thu, 18 Jan 2001 09:40:44 -0800 (PST)
Received: from RHOUSLEY-PC.spyrus.com ([209.172.119.210]) by mail.spyrus.com (8.9.3/8.9.3) with ESMTP id JAA17768; Thu, 18 Jan 2001 09:45:41 -0800 (PST)
Message-Id: <[email-masked]>
X-Sender: [email-masked]
X-Mailer: QUALCOMM Windows Eudora Version 5.0.2
Date: Thu, 18 Jan 2001 12:43:12 -0500
To: "David P. Kemp"
From: Russ Housley
Subject: Re: Two questions on delta-CRL
Cc: [email-masked]
In-Reply-To: <[email-masked]>
Mime-Version: 1.0
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit

I think we may be splitting hairs on the term "issue." I am not
sure that I would consider a CRL that was generated but not distributed
to be "issued."

From RFC 2459:

5.2.4  Delta CRL Indicator

The delta CRL indicator is a critical CRL extension that
identifies a

delta-CRL.  The use of delta-CRLs can significantly
improve

processing time for applications which store revocation
information

in a format other than the CRL structure.  This allows
changes to be

added to the local database while ignoring unchanged
information that

is already in the local database.

When a delta-CRL is issued, the CAs MUST also issue a
complete CRL.

The value of BaseCRLNumber identifies the CRL number of
the base CRL

that was used as the starting point in the generation of
this delta-

CRL.  The delta-CRL contains the changes between the
base CRL and the

current CRL issued along with the delta-CRL.  It is the
decision of a

CA as to whether to provide delta-CRLs.  Again, a
delta-CRL MUST NOT

be issued without a corresponding complete CRL.
The value of

CRLNumber for both the delta-CRL and the corresponding
complete CRL

MUST be identical.

A CRL user constructing a locally held CRL from delta-CRLs
MUST

consider the constructed CRL incomplete and unusable if the
CRLNumber

of the received delta-CRL is more than one greater than the
CRLnumber

of the delta-CRL last processed.

id-ce-deltaCRLIndicator OBJECT IDENTIFIER ::= { id-ce 27
}

deltaCRLIndicator ::= BaseCRLNumber

BaseCRLNumber ::= CRLNumber

Russ

At 10:36 AM 1/16/2001 -0500, David P. Kemp wrote:

It is not true that an application
would need to retrieve multiple

deltas to resync.

Each delta CRL specifies the base against which it was issued.  A
CA

could choose the scheme you describe where each delta is from the

previous delta.  But a CA could also choose a scheme where each
delta

is from the previous base.  In the latter scheme, an application
which had

lost its revocation information (or been offline for a month) would

have to obtain the daily full CRL and a single delta CRL.

As Sharon has pointed out, there is NO requirement in either
X.509-2000

or X.509-1997 to publish a complete CRL when a delta is published.
To the

contrary:

"Depending on the policy of the responsible authority,
several

dCRLs may be published before a new base CRL is
published."

-- X.509-2000, section 8.5.2.5, CRL scope extension

and

"Note - it is the decision of the CA as to whether or not to
distribute

the CRLs issued between two base CRLs."

-- X.509-1997, section 12.6.3.3, Delta CRL indicator field

Draft-ietf-pkix-new-part1-01 says that a conforming CA MUST *issue*

a complete CRL for every delta, but it does not say that the issued

full CRL must be published anywhere except to /dev/null.  Note
that

neither of the two suggested ways a PKIX application can construct

a complete CRL from deltas involves retrieving a current full CRL.

(There are technical reasons for requiring only a single
"revocation

state" to exist at any moment in time, and locally constructing a
full

CRL is one means of capturing that state.)

I strongly disagree with any suggestion that PKIX requirements for
base

CRL publication should be more restrictive than X.509's.  And I
agree

that new-part-1 should make it clear that "issuing" a full CRL
for

every delta does not *in any way* require publishing that full CRL.

Regards,

Dave

> From: Michael Ströder <[email-masked]>

> Sam Schaen wrote:

> > I believe the requirement for issuing a complete CRL when a
delta CRL is

> > released makes sense.

> > [..]

> > The availability of a current full CRL also allows an
application to

> > resynchronize at any point.

> I think this is the most important argument. An application
might

> loose the stored CRL or the CRL got corrupt by e.g. a system
crash.

> The damage for the application is limited to the loss of some

> network-bandwidth. Resynchronization is simple.

> E.g. if you issue a full CRL each day (24h) and delta-CRLs
every

> hour the application will have to obtain the last full CRL and
every

> delta CRL issued since then to get up to date (max. 24
accesses

> instead of one).

> If you want to relax the requirement of issuing full and delta
CRLs

> at the same time you have to mandate

> 1. that the CRL issuer stores all delta URLs from the last full
CRL

> and

> 2. you have to provide appropriate service access points to
obtain

> all necessary delta CRLs.

> The application logic gets more complicated though.

> Ciao, Michael.

Received: from prv-mail20.provo.novell.com (prv-mail20.provo.novell.com [137.65.81.122]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id IAA21046 for ; Thu, 18 Jan 2001 08:34:10 -0800 (PST)
Received: from INET-PRV-Message_Server by prv-mail20.provo.novell.com with Novell_GroupWise; Thu, 18 Jan 2001 09:39:16 -0700
Message-Id:
X-Mailer: Novell GroupWise Internet Agent 5.5.5.1
Date: Thu, 18 Jan 2001 09:39:13 -0700
From: "Tolga Acar"
To: ,
Subject: Re: oid....
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="=_0D565D24.4F2E7B4C"

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

--=_0D565D24.4F2E7B4C
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable

KC,

Nortel OI ::=3D {iso(1) member-body(2) us(840) nt(113533))}
NortelAlgorithm OI ::=3D {Nortel 7 66}
pbeWithMD5AndCast5CBC OI ::=3D {NortelAlgorithm 12}

This is defined by Nortel ;-))

- Tolga

>>> "Kwok Lee" 1/18/01 7:52:49 >>>

Hi all,=20
Sorry. A beginner question.=20
What is the OID for pbeWithSHAAndCast5CBC?=20
Also, where does it get defined?=20
Thanks a lot.=20
kc=20

--=_0D565D24.4F2E7B4C
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

KC,

Nortel OI ::=3D  {iso(1) member-body(2) us(840) nt(113533))}=

NortelAlgorithm  OI=20
::=3D      {Nortel 7 66}

pbeWithMD5AndCast5CBC    OI=20
::=3D           =20
{NortelAlgorithm 12}

This is defined by Nortel ;-))

- Tolga

>>> "Kwok Lee" <[email-masked]> =
1/18/01=20
7:52:49 >>>

Hi all,

Sorry. A beginner question. =

What is the OID for pbeWithSHAAndCast5CBC? =

Also, where does it get defined?

Thanks a lot.
kc

--=_0D565D24.4F2E7B4C--

Received: from mail.ec.auckland.ac.nz (mail.student.auckland.ac.nz [130.216.35.201]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA19415 for ; Thu, 18 Jan 2001 08:06:58 -0800 (PST)
Received: from kahu.cs.auckland.ac.nz ([email-masked] [130.216.36.13]) by mail.ec.auckland.ac.nz (8.9.3/8.8.6/cs-master) with SMTP id FAA03564 for ; Fri, 19 Jan 2001 05:12:38 +1300 (NZDT) (sender [email-masked])
Received: by kahu.cs.auckland.ac.nz (relaymail v0.9) id <97983435814611>; Fri, 19 Jan 2001 05:12:38 (NZDT)
From: [email-masked] (Peter Gutmann)
To: [email-masked]
Subject: Re: Basic Cert-2-Directory mapping question
Sender: [email-masked]
Reply-To: [email-masked]
X-Charge-To: pgut001
X-Authenticated: relaymail v0.9 on kahu.cs.auckland.ac.nz
Date: Fri, 19 Jan 2001 05:12:38 (NZDT)
Message-ID: <[email-masked]>

[Repeated message from a week or two back]

Sorry about the duplicate folks, but that wasn't from here, from the headers it
came from a Gemplus site in Singapore.

>Received: from difool.gemplus.com (difool.gemplus.com [195.25.133.180])
> by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA11463
> for ; Thu, 18 Jan 2001 06:46:00 -0800 (PST)
>Received: from mail-prod.singapore.asp.gemplus.com (mail-prod.singapore.asp.gemplus.com [172.27.101.72])
> by difool.gemplus.com (Postfix) with ESMTP id D0B14C1E7
> for ; Thu, 18 Jan 2001 15:50:59 +0100 (MET)
>Received: by mail-prod.singapore.asp.gemplus.com; Thu, 18 Jan 2001 22:46:43 +0800

Peter.

Received: from smtprch1.nortel.com (smtprch1.nortelnetworks.com [192.135.215.14]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA11859 for ; Thu, 18 Jan 2001 06:48:49 -0800 (PST)
Received: from zsc4c000.us.nortel.com by smtprch1.nortel.com; Thu, 18 Jan 2001 08:52:55 -0600
Received: by zsc4c000.us.nortel.com with Internet Mail Service (5.5.2652.35) id ; Thu, 18 Jan 2001 06:52:52 -0800
Message-ID: <[email-masked]>
From: "Kwok Lee"
To: "[email-masked]'"
Subject: oid....
Date: Thu, 18 Jan 2001 06:52:49 -0800
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2652.35)
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0815E.53ABA280"

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_01C0815E.53ABA280
Content-Type: text/plain;
charset="iso-8859-1"

Hi all,

Sorry. A beginner question.
What is the OID for pbeWithSHAAndCast5CBC?
Also, where does it get defined?

Thanks a lot.
kc

------_=_NextPart_001_01C0815E.53ABA280
Content-Type: text/html;
charset="iso-8859-1"

oid....

Hi all,

Sorry. A beginner question.

What is the OID for pbeWithSHAAndCast5CBC?

Also, where does it get defined?

Thanks a lot.

kc

------_=_NextPart_001_01C0815E.53ABA280--

Received: from ext-mail.valicert.com (ns1.valicert.com [63.65.221.10]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA11652 for ; Thu, 18 Jan 2001 06:48:05 -0800 (PST)
Received: from CONVERSION-DAEMON by ext-mail.valicert.com (PMDF V5.2-33 #46613) id <[email-masked]> for [email-masked]; Thu, 18 Jan 2001 06:53:42 -0800 (PST)
Received: from polaris.valicert.com ([192.168.2.34]) by ext-mail.valicert.com (PMDF V5.2-33 #46613) with ESMTP id <[email-masked]>; Thu, 18 Jan 2001 06:53:42 -0800 (PST)
Received: by exchange.valicert.com with Internet Mail Service (5.5.2650.21) id ; Thu, 18 Jan 2001 06:49:24 -0800
Content-return: allowed
Date: Thu, 18 Jan 2001 06:49:22 -0800
From: Frank Balluffi
Subject: RE: DID & DIP requirements
To: "'Peter Sylvester'"
Cc: [email-masked]
Message-id: <[email-masked]>
MIME-version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-type: text/plain; charset="iso-8859-1"

Peter Sylvester wrote:

> - A client may indicate one or more certificates to be validated.
>
> - 1 - Each certificate may be accompagnied by a 'lump' of certificates
> that may assist the server to find a valid path for that
> particular certificate.
>
> 2 - There may be an additional bunch of certificates that may be
> used by the server to determine valid paths.
>
> I tended to have 1, because for different certs the paths may be
> different, but I may be wrong since even if one throws all the
> different hints in 1 into one bag, the server could probably
> find out the good stuff anyway.

2 seems more efficient to me. I can't see any downside to 2.

How does the server know when it has completed the process of discovering a
path? It finds a self-signed certificate [this would break RFC 2459 path
validation]? The server maintains a collection of trusted certificates? The
client sends a collection of trusted certificates?

The client and server algorithmic descriptions should help resolve this.

I would argue that having the protocol define a functional equivalent path
discovery algorithm, like RFC 2459 does for path validation, will help
implementers.

Frank

Received: from difool.gemplus.com (difool.gemplus.com [195.25.133.180]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA11463 for ; Thu, 18 Jan 2001 06:46:00 -0800 (PST)
Received: from mail-prod.singapore.asp.gemplus.com (mail-prod.singapore.asp.gemplus.com [172.27.101.72]) by difool.gemplus.com (Postfix) with ESMTP id D0B14C1E7 for ; Thu, 18 Jan 2001 15:50:59 +0100 (MET)
Received: by mail-prod.singapore.asp.gemplus.com; Thu, 18 Jan 2001 22:46:43 +0800
From: [email-masked] (Peter Gutmann)
To: [email-masked]
Subject: Re: Basic Cert-2-Directory mapping question
Cc: [email-masked]
Sender: [email-masked]
Reply-To: [email-masked]
X-Charge-To: pgut001
X-Authenticated: relaymail v0.9 on kahu.cs.auckland.ac.nz
Date: Tue, 9 Jan 2001 20:35:17 (NZDT)
Message-Id: <[email-masked]>
Precedence: bulk
List-Archive: http://www.imc.org/ietf-pkix/mail-archive/
List-ID:
List-Unsubscribe: mailto:[email-masked]?body=unsubscribe

Stephen Kent writes:

>I think your analysis shows that we have a lot of folks playing CA who are
>not "qualified" to do so.

(Wibbly-wobbly effect, fade to shot of John Cleese being turned on
a spit by some nuns)
JOHN CLEESE: And now for something completely different...
(Fairly empty generic modern room. End entity being rushed into
the room on a dolly. PKI architects are flipping through
standards documents)
PKI ARCHITECT 1: commonName qualified with a serialNumber in the same RDN!
PKI ARCHITECT 2: firstName + surname + generationQualifier (if required) +
dnQualifier!
(Sysadmin enters and interrupts them)
SYSADMIN: The end entity is ready.
PKI ARCHITECT 1: Good, take her into the PKI frightening room.
SYSADMIN: Right.
PKI ARCHITECT 2: I say, it's a bit barren in here isn't it?
PKI ARCHITECT 1: Yes, more junk please sysadmin. The smart cards, the
Safekeyper, and the biometrics.
SYSADMIN: Yes, most certainly.
PKI ARCHITECT 1: And get the machine that issues certificates!
(Sysadmin wheels in a cart containing a PC which has "Intel
Inside" and "Designed for Microsoft Windows" stickers on it)
END ENTITY: What's that for?
PKI ARCHITECT 1: That's the machine that issues certificates
(Machine goes PING and pops up a "Save certificate as..." dialog)
PKI ARCHITECT 1: You see, that means the end entity has been certified!
PKI ARCHITECT 2: And that is the most expensive machine in the whole building!
PKI ARCHITECT 1: Yes, it cost over three quarters of a million pounds.
PKI ARCHITECT 2: Aren't you lucky?!
SYSADMIN: The CEO is here doctor.
PKI ARCHITECT 1: Switch everything on!
(Bleep... whirrr... bing... rumble rumble)
CEO: Ah very impressive, very impressive, and what are you doing
this morning?
PKI ARCHITECT 2: It is a certification.
CEO: Ahhh,.. and what sort of thing is that?
PKI ARCHITECT 2: Well, that's where we certify uncontestably and undeniably
that someone we've never met before who lives on the other
side of the planet and who we know only as a (possibly
forged) email address really is who they claim to be and can
be trusted to write good cheques, buy alcohol, sign
contracts, and run a dot-com selling PKI services.
CEO: Wonderful what you can do nowadays. (PING) Ahh, I see that
you have the machine that issues certificates. This is my
favorite. You see we leased it back from the company we sold
it to and that way it comes out of the monthly current budget
and not the capital account.
(Applause)
Thank you, thank you, we try to do our best, well do carry
on.
(CEO leaves)
PKI ARCHITECT 1: Lovely, lovely, jolly good, that's better, much much better.
PKI ARCHITECT 2: Yes, that's more like it.
PKI ARCHITECT 1: Uhh... still something missing though.
PKI ARCHITECT 1+2:END ENTITY!
PKI ARCHITECT 2: Yes, where's the end entity?
PKI ARCHITECT 1: Anyone seen the end entity?
SYSADMIN: Ahhh... here she is!
PKI ARCHITECT 1: Bring her over here.
PKI ARCHITECT 2: Mind the machine.
PKI ARCHITECT 1: Hello, now don't you worry.
PKI ARCHITECT 2: We'll soon have you certified!
PKI ARCHITECT 1: Leave it all to us, you'll never know what hit you.
END ENTITY: Will it be a nonRepudiation certificate?
PKI ARCHITECT 1: Now I think it's a little early to start imposing roles on it,
don't you? Now a word of advice, you may find that you
suffer for some time a totally irrational feeling of
depression, PKID as we call it. So, it's lots of happy pills
for you and you can find out all about the certification when
you get home. It's available on Betamax, VHS, and Super-8.
(Reporters and photographers enter the PKI frightening room)
PKI ARCHITECT 1: Who are you?
NOTARY PUBLIC: I am the end entity's notary public.
PKI ARCHITECT 1: I am sorry, only people involved are allowed in here.
END ENTITY: What do I do?
PKI ARCHITECT 2: Yes?
END ENTITY: What do I Do?
PKI ARCHITECT 2: Nothing dear, you're not "qualified"!
(Machine that issues certificates blue screens, camera zooms in to
reveal text that says "And now for something completely
different...")

Peter :-).

--=_mh.ndn.15da.3a5abe7f_=--

--=_mh.ndn.15da.3a5abe7f_=--

Received: from mail-relay-1.ision.net (mail-relay-1.ision.net [194.163.252.74]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id EAA02246 for ; Thu, 18 Jan 2001 04:45:40 -0800 (PST)
Received: from sysiphos.maz-hh.de (sysiphos.maz-hh.de [192.109.56.14]) by mail-relay-1.ision.net (8.9.3) with ESMTP id (multiple receipients); Thu, 18 Jan 2001 13:41:47 +0100 (MET)
Received: from hora.timeproof.de (timegate.maz-hh.de [192.109.56.29]) by sysiphos.maz-hh.de (8.9.3/8.9.3) with ESMTP id NAA08691; Thu, 18 Jan 2001 13:51:18 +0100 (MET)
Received: from timeproof.de (pc107 [192.168.111.107]) by hora.timeproof.de (8.9.3+Sun/8.9.3) with ESMTP id NAA19916; Thu, 18 Jan 2001 13:51:16 +0100 (MET)
Message-ID: <[email-masked]>
Date: Thu, 18 Jan 2001 13:58:43 +0100
From: Joerg Seidel
Organization: timeproof
X-Mailer: Mozilla 4.76 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Peter Sylvester
CC: [email-masked]
Subject: Re: time stamping interoperability tests
References: <[email-masked]>
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit

Hello all,

we set up a test server too. You can check for interoperability under:

test.timeproof.de Port 318

Regards
Jörg Seidel
--
__________________________________________________________________

Jörg Seidel phone +49-40-76629-1911
Director Technology fax +49-40-76629-551
timeproof GmbH
Harburger Schloßstraße 6-12 mailto:[email-masked]
DE 21079 Hamburg http://www.timeproof.de
__________________________________________________________________

Received: from edelweb.fr (edelweb.fr [212.234.46.16]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id CAA20510 for ; Thu, 18 Jan 2001 02:22:37 -0800 (PST)
Received: from champagne.edelweb.fr (localhost.edelweb.fr [127.0.0.1]) by edelweb.fr with ESMTP id LAA12647; Thu, 18 Jan 2001 11:28:18 +0100 (MET)
Received: from champagne.edelweb.fr (champagne.edelweb.fr [193.51.14.161]) by edelweb.fr (nospam/1.3); Thu, 18 Jan 2001 11:28:18 +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 LAA28145; Thu, 18 Jan 2001 11:28:17 +0100 (MET)
From: Peter Sylvester
Received: (sylvest@localhost) by emeriau.edelweb.fr (8.7.6/8.6.6) id LAA20380; Thu, 18 Jan 2001 11:28:16 +0100 (MET)
Date: Thu, 18 Jan 2001 11:28:16 +0100 (MET)
Message-Id: <[email-masked]>
To: [email-masked], [email-masked]
Subject: RE: Basic Cert-2-Directory mapping question

>
> I agree with Bob's goal of eliminating the need to pass certs in
> session handshakes and messages. If there were only two options (change
> the DN or add an extension), then only the first moves toward that
> goal. But you have proposed a third option: leave the cert alone!
> For my part, I am simply in awe of the elegance of that approach.

> It might even work.
> Dave

If the goal is to limit the size of for example an S/MIME signature,
a signer MAY add an attribute (signed or unsigned) to the signature if
it is necessary which is similar to an access method in an AIA or SIA.

Whether the attribute is actually part of some cert, is another question.

Received: from computer (adsl-63-202-81-108.dsl.snfc21.pacbell.net [63.202.81.108]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id XAA28347 for ; Wed, 17 Jan 2001 23:31:22 -0800 (PST)
Message-Id: <[email-masked]>
From: "KJ"
To:
Subject: As seen on National Television !!!
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Date: Wed, 17 Jan 2001 23:37:35

This really is worth your valuable time, so...
PLEASE PRINT THIS NOW FOR READING AT YOUR LEISURE, YOU WILL NOT REGRET IT.
++++++++++++++++++++++++++++++++++++++++++++++++++
Dear Friend,

You can earn $50,000 or more in next the 90 days sending E-mail. Seem impossible? Read on
for details.
Is there a catch? NO!!! There is no catch. Just send your emails; and, You will be on your way to
financial freedom.

AS SEEN ON NATIONAL TELEVISION:

Thank you for your time and Interest. This is the letter you've been reading about in the news
Lately.

Due to the popularity of this letter on the Internet, a major nightly news program recently devoted
an entire show to the investigation of the program described below to see, if it really can make people
money.

The show also investigated whether or not the program was legal.
Their findings proved once and for all that there are, absolutely no laws prohibiting the participation
in the program. This has helped to show people that this is a simple, harmless, and fun way to make
some extra money at home.

The results of this show have been truly remarkable.
So many people are participating that those involved are doing, much better than ever before.
Since everyone makes more as more people try it out, its been very exciting to be a part of lately.
You will understand once you experience it.

"HERE IT IS BELOW."
================================================
*** Print This Now (IF YOU HAVE NOT already done it) for Future Reference ***

The following income opportunity is one you may be interested in taking a look at. It can be
started with
VERY LITTLE investment and the income return is TREMENDOUS!!!

$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$

If you would like to make at least $50,000 in less than 90 days! Please read the enclosed
Program...THEN
READ IT AGAIN!!!

$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$

THIS IS A LEGITIMATE, LEGAL, MONEYMAKING OPPORTUNITY.

It does not require you to come into contact with people, do any hard work, and best of all, you
never have
to leave the house except to get the mail. If you believe that someday you'll get that big break that
you've been waiting for, THIS IS IT!

Simply follow the instructions, and your dreams will come true. This Multi-level e-mail order-
marketing
program work perfectly, 100% of EVERY TIME. E-mail is the sales tool of the future. Take
advantage of
this non-commercialized method of advertising NOW!

The longer you wait, the more savvy people will be taking your business using e-mail. Get what is
rightfully yours. Program yourself for success and dare to think BIG.

MULTI-LEVEL MARKETING (MLM) has finally gained respectability. It is being taught in the
Harvard
Business School, and both Stanford Research and the Wall Street Journal have stated that
between 50%
and 65% of all goods and services will be sold through multi-level methods by the mid to late
1990's.

This is a Multi-Billion Dollar industry and of the 500,000 millionaires in the U.S., 20% (100,000)
made their
fortune in the last several years in MLM. Moreover, statistics have show that 45 people become
millionaires everyday through Multi-Level Marketing.

You may have heard this story before, but over the summer, Donald Trump made an appearance
on the
David Letterman show. Dave asked him what he would do if he lost everything and had to start
over from
scratch. Without hesitating, Trump said he would find a good network marketing company and get
to
work.

The audience started to hoot and boo him. He looked out at the audience and dead-panned his
response
"That's why I'm sitting up here; and, you are all sitting out there!"

With network marketing, you have two sources of income.

Direct commissions from sales you make yourself and commissions from sales made by people
you
introduce to the business.

Residual income is the secret of the wealthy.
It means investing time or money once and getting paid again and again and again. In network
marketing, it
also means getting paid for the work of others.

The enclosed information is something I almost let slip through my fingers. Fortunately, sometime
later I re-
read everything and gave some thought and study to it.

My name is Jonathan Rourke. Two years ago, the corporation I worked at for the past twelve
years
down-sized and my position was eliminated. After unproductive job interviews, I decided to open
my own
business. Over the past year, I incurred many unforeseen financial problems. I owed my family,
friends,
and creditors over $35,000. The economy was taking a toll on my business and I just couldn't
seem to
make ends meet.

I had to refinance and borrow against my home to support my family and struggling business. AT
THAT
MOMENT something significant happened in my life and I am writing to share the experience in
hopes that
this will change your life FOREVER FINANCIALLY!!!

In mid December of 1997, I received this program via e-mail. Six months prior to receiving this
program, I
had been sending away for information on various business opportunities. All of the programs I
received,
in my opinion, were not cost effective. They were either too difficult for me to comprehend or the
initial
investment was too much for me to risk to see if they would work or not. One claimed that I would
make a
million dollars in one year... it didn't tell me I'd have to write a book to make it!

But like I was saying, in December of 1997 I received this program. I didn't send for it, or ask for it,
they
just got my name off a mailing list. THANK GOODNESS FOR THAT !!! After reading it several
times, to make
sure I was reading it correctly, I couldn't believe my eyes. Here was a MONEY MAKING
PHENOMENON.

I could invest as much as I wanted to start, without putting me further into debt. After I got a
pencil and
paper and figured it out, I would at least get my money back. But like most of you I was still a
little skeptical
and a little worried about the legal aspects of it all. So I checked it out with the U.S. Post Office
(1-800-
725-2161 24-hrs) and they confirmed that it is indeed legal! After determining the program was
LEGAL and
NOT A CHAIN LETTER, I decided "WHY NOT."

Initially I sent out 10,000 e-mails. It cost me about $15 for my time on-line. The great thing about
e-mail is
that I don't need any money for printing to send out the program, and because all of my orders are
fulfilled
via e-mail, the only expense is my time. I am telling you like it is. I hope it doesn't turn you off, but
I
promised myself that I would not "rip-off" anyone, no matter how much money it cost me.

In less than one week, I was starting to receive orders for REPORT #1. By January 13, I had
received 26
orders for REPORT #1. Your goal is to "RECEIVE at least 20 ORDERS FOR REPORT #1
WITHIN 2 WEEKS.
IF YOU DON'T, SEND OUT MORE PROGRAMS UNTIL YOU DO!"
My first step in making $50,000 in 90 days was done.

By January 30, I had received 196 orders for REPORT #2. Your goal is to "RECEIVE AT LEAST
100+
ORDERS FOR REPORT #2 WITHIN 2 WEEKS. IF NOT, SEND OUT MORE PROGRAMS UNTIL
YOU DO. ONCE
YOU HAVE 100 ORDERS, THE REST IS EASY, RELAX, YOU WILL MAKE YOUR $50,000
GOAL."
Well, I had 196 orders for REPORT #2, 96 more than I needed. So I sat back and relaxed. By
March 1, of
my e-mailing of 10,000, I received $58,000 with more coming in every day.

I paid off ALL my debts and bought a much-needed new car. Please take time to read the
attached
program,
IT WILL CHANGE YOUR LIFE FOREVER!!! Remember, it won't work if you don't try it.
This program does work, but you must follow it EXACTLY! Especially the rules of not trying to
place your
name in a different place. It won't work, you'll lose out on a lot of money!

In order for this program to work, you must meet your goal of 20+ orders for REPORT #1, and
100+ orders
for REPORT #2 and you will make $50,000 or more in 90 days. I AM LIVING PROOF THAT IT
WORKS!!!

If you choose not to participate in this program, I am sorry. It really is a great opportunity with
little cost or
risk to you. If you choose to participate, follow the program and you will be on your way to
financial
security.

If you are a fellow business owner and are if financial trouble like I was, or you want to start your
own
business, consider this a sign. I DID!

Sincerely, Jonathan Rourke

PS Do you have any idea what 11,700 $5 bills ($58,000) look like piled up on a kitchen table? IT'S
AWESOME!
------------------------------------------------------
A PERSONAL NOTE FROM THE ORIGINATOR OF THIS PROGRAM:

By the time you have read the enclosed program, you may have concluded that an amateur could
not have
created such a legal program that works.

Let me tell you a little about myself. I had a profitable business for 10 years. Then in 1979 my
business
began falling off. I was doing the same things that were previously successful for me, but it wasn't
working. Finally, I figured it out. It wasn't me, it was the economy. Inflation and recession had
replaced
the stable economy that had been with us since 1945.

I don't have to tell you what happened to the unemployment rates...because many of you know
from first
hand experience. There were more failures and bankruptcies than ever before.

The middle class was vanishing. Those who knew what they were doing invested wisely and
moved up.
Those who did not, including those who never had anything to save or invest, were moving down
into the
ranks of the poor. As the saying goes, "THE RICH GET RICHER AND THE POOR GET
POORER." The
traditional methods of making money will never allow you to "move up" or "get rich", inflation will
see to
that.

You have just received information that can give you financial freedom for the rest of your life, with
"NO
RISK" and "JUST A LITTLE BIT OF EFFORT." You can make more money in the next few
months than you
have ever imagined.

I should also point out that I would not see a penny of this money, nor anyone else who has
provided a
testimonial for this program. I have already made over 4 MILLION DOLLARS! I have retired from
the
program after sending out over 16,000 programs. Now I have several offices that do this program
and
several other programs here and over seas.

Follow the program EXACTLY AS INSTRUCTED. Do not change it in any way. It works
exceedingly well
as it is now. Remember to e-mail a copy of this exciting report to everyone you can think of. One
of the
people you send this to may send out 50,000...and your name will be on every one of them!
Remember
though, the more you send out the more potential customers you will reach.

So my friend, I have given you the ideas, information, materials and opportunity to become
financially
independent,
IT IS UP TO YOU NOW!

******************************************************

THINK ABOUT IT:

Before you delete this program from your mailbox, as I almost did, take a little time to read it and
REALLY
THINK ABOUT IT. Get a pencil and figure out what could happen when YOU participate. Figure
out the
worst possible response and no matter how you calculate it, you will still make a lot of money!
You will definitely get back what you invested. Any doubts you have will vanish when your first
orders
come in. IT WORKS!

Jody Jacobs, Richmond, VA

******************************************************

HERE'S HOW THIS AMAZING PROGRAM WILL MAKE YOU
THOUSANDS OF DOLLAR$

INSTRUCTIONS:

This method of raising capital REALLY WORKS 100%
EVERY TIME. I am sure that you could use up to $50,000 or more in the next 90 days.

Before you say, "BULL... ", please read this program carefully. This is not a chain letter, but a
perfectly
legal money making opportunity. Basically, this is what you do: As with all multi-level
businesses, we build
our business by recruiting new partners and selling our products. Every state in the USA allows
you to
recruit new multi-level business partners, and we offer a product for EVERY dollar sent. YOUR
ORDERS
COME BY MAIL AND ARE FILLED BY E-MAIL, so you are not involved in personal selling. You
do it
privately in your own home, store, or office.

This is the GREATEST Multi-Level Mail Order Marketing anywhere:

This is what you MUST do:

1. Order all 4 reports shown on the list below (you can't sell them if you don't order them).

* For each report, send $5.00 CASH, the NAME &
NUMBER OF THE REPORT YOU ARE ORDERING, YOUR E-MAIL ADDRESS, YOUR NAME &
RETURN
ADDRESS (in case of a problem) to the person whose name appears on the list next to the
report.

MAKE SURE YOUR RETURN ADDRESS IS ON YOUR ENVELOPE
IN CASE OF ANY MAIL PROBLEMS!

* When you place your order, make sure you order each of the four reports. You will need all four
reports
so that you can save them on your computer and resell them.

* Within a few days, you will receive, via e-mail, each of the four reports.
Save them on your computer so they will be accessible for you to send to the 1,000's of people
who will
order them from you.

2. IMPORTANT-- DO NOT alter the names of the people who are listed next to each report, or
their
sequence on the list, in any way other than is instructed below in steps "a" through "f" or you will
lose out
on the majority of your profits. Once you understand the way this works, you'll also see how it
doesn't
work if you change it. Remember, this method has been tested, and if you alter it, it will not work.

a. Look below for the listing of available reports.

b. After you've ordered the four reports, take this Advertisement and remove the name and
address under
REPORT #4. This person has made it through the cycle and is no doubt counting their $50,000!

c. Move the name and address under REPORT #3 down to REPORT #4.

d. Move the name and address under REPORT #2 down to REPORT #3.

e. Move the name and address under REPORT #1 down to REPORT #2.

f. Insert your name/address in the REPORT #1 position.

Please make sure you copy every name and address ACCURATELY! Copy and paste method
works well.

3. Take this entire letter, including the modified list of names, and save it to your computer. Make
NO
changes to the Instruction portion of this letter.

Your cost to participate in this is practically nothing (surely you can afford $20). You obviously
already
have an Internet Connection and e-mail is FREE!

To assist you with marketing your business on the Internet, the 4 reports you purchase will
provide you
with invaluable marketing information which includes how to send bulk e-mails, where to find
thousands of
free classified ads and much, much more.

There are two primary methods of building your downline:

METHOD #1: SENDING BULK E-MAIL

Let's say that you decide to start small, just to see
how it goes, and we'll assume you and all those involved send out only 2,000 programs each.
Let's also
assume that the mailing receives a 0.5% response. Using a good list, the response could be
much better.
Also, many people will send out hundreds of thousands of programs instead of 2,000. But
continuing with
this example, you send out only 2,000 programs. With a 0.5% response, that is only 10 orders for
REPORT
#1. Those 10 people respond by sending out 2,000 programs each for a total of 20,000. Out of
those
0.5%, 100 people respond and order REPORT #2.

Those 100 people mail out 2,000 programs each for a total of 200,000. The 0.5% response to that
is 1,000
orders for REPORT #3. Those 1,000 send out 2,000 programs each for a 2,000,000 total. The
0.5%
response to that is 10,000 orders for REPORT #4. That amounts to 10,000 each of $5 bills for you
in CASH
MONEY!!!

Your total income in this example is $50 + $500 + $5,000+ $50,000 for a total of $55,550!!!

REMEMBER FRIEND, THIS IS ASSUMING 1,990 OUT OF THE 2,000 PEOPLE YOU MAIL TO
WILL DO
ABSOLUTELY NOTHING AND TRASH THIS PROGRAM!
DARE TO THINK FOR A MOMENT WHAT WOULD HAPPEN IF EVERYONE, OR HALF-SENT
OUT 100,000
PROGRAMS INSTEAD OF 2,000. Believe me, many people will do just that, and more! By the
way, your
cost to participate in this is practically nothing. You obviously already have an Internet connection
and e-
mail is FREE !!!

REPORT #2 will show you the best methods for bulk e-mailing, tell you where to obtain free bulk
e-mail
software and where to obtain e-mail lists.

METHOD #2 - PLACING FREE ADS ON THE INTERNET

1. Advertising on the 'Net is very, very inexpensive, and there are HUNDREDS of FREE places to
advertise.
Let's say you decide to start small just to see how well it works. Assume your goal is to get
ONLY 10
people to participate on your first level. (Placing a lot of FREE ads on the Internet will EASILY get
a larger
response). Also, assume that everyone else in YOUR ORGANIZATION gets ONLY 10 downline
members.

Follow this example to achieve the STAGGERING results Below (same as email example):

1st level-your 10 members with $5.........$50
2nd level-10 members from those 10 ($5 x 100).......$500
3rd level-10 members from those 100 ($5 x 1,000) $5,000
4th level-10 members from those 1,000 ($5 x 10k) $50,000

THIS TOTALS ---------------------------$55,550

Remember friends, this assumes that the people who participate only recruits 10 people each.
Think for a
moment what would happen if they got 20 people to
participate! Most people get 100's of participants!

THINK ABOUT IT!

For every $5.00 you receive, all you must do is e-mail them the report they ordered. THAT'S IT!
ALWAYS
PROVIDE SAME-DAY SERVICE ON ALL ORDERS! This will guarantee that the e-mail THEY
send out, with
YOUR name and address on it, will be prompt because they can't advertise until they receive the
report!

------------------------------------------
AVAILABLE REPORTS
------------------------------------------

*** Order Each REPORT by NUMBER and NAME ***

Notes:

- ALWAYS SEND $5 CASH (U.S. CURRENCY) FOR EACH REPORT
CHEQUES NOT ACCEPTED
- ALWAYS SEND YOUR ORDER VIA FIRST CLASS MAIL
- Make sure the cash is concealed by wrapping it in at least two sheets of paper
(IF NOT MORE SO THAT THE BILL CAN'T BE SEEN AGAINST LIGHT)
- On one of those sheets of paper, include:
(a) the number & name of the report you are ordering,
(b) your e-mail address, and
(c) your name & postal address (as return address in case the post office encounters problems).

PLACE YOUR ORDER FOR THESE REPORTS NOW:
______________________________________________________
REPORT #1 "The Insider's Guide to Advertising for Free on the Internet."

ORDER REPORT #1 FROM:
Jeffrey Gilliam
3212 Jefferson St. PMB #283
Napa, CA 94558
______________________________________________________
REPORT #2 "The Insider's Guide to Sending Bulk E-mail
on the Internet."

ORDER REPORT #2 FROM:

Ben Marchessault
383 Kupaua Place
Honolulu, HI 96821
______________________________________________________
REPORT #3 "The Secrets to Multilevel Marketing on the
Internet."

ORDER REPORT #3 FROM:

Brett Spohn
129 Buchland Rd
P O Box 102
Brownstown, PA 17508

______________________________________________________
REPORT #4 "How to become a Millionaire utilizing the Power of Multilevel
Marketing and the Internet."

ORDER REPORT #4 FROM:

Tim Weidman
3943 Oregon Pike
Ephrata, PA 17522
______________________________________________________

About 50,000 new people get online every month!

******* TIPS FOR SUCCESS *******

* TREAT THIS AS YOUR BUSINESS! Be prompt, professional, and follow the directions
accurately.

* Send for the four reports IMMEDIATELY so you will have them when the orders start coming in
because:

* When you receive a $5 order, you MUST send out the requested product/report.

* ALWAYS PROVIDE SAME-DAY SERVICES ON THE ORDERS YOU RECEIVE.

* Be patient and persistent with this program. If you follow the instructions exactly, your results
WILL BE
SUCCESSFUL!

* ABOVE ALL, HAVE FAITH IN YOURSELF AND KNOW YOU WILL SUCCEED!

******* YOUR SUCCESS GUIDELINES *******

Follow these guidelines to guarantee your success:

If you don't receive 20 orders for REPORT #1 within two weeks, continue advertising or sending e-
mails
until you do. Then, a couple of weeks later you should receive at least 100 orders for REPORT#2.
If you
don't, continue advertising or sending e-mails until you do.

Once you have received 100 or more orders for REPORT #2, YOU CAN RELAX, because the
system is
already working for you, and the cash will continue to roll in!

THIS IS IMPORTANT TO REMEMBER:

Every time your name is moved down on the list, you are placed in front of a DIFFERENT report.
You can KEEP TRACK of your PROGRESS by watching which report people are ordering from
you. If you
want to generate more income, send another batch of e-mails or
continue placing ads and start the whole process again! There is no limit to the income you will
generate
from this business!

Before you make your decision as to whether or not you participate in this program. Please
answer one
question..... DO YOU WANT TO CHANGE YOUR LIFE?
If the answer is yes, please look at the following facts about this program:

1. YOU ARE SELLING A PRODUCT WHICH DOES NOT COST ANYTHING TO PRODUCE!

2. YOU ARE SELLING A PRODUCT WHICH DOES NOT COST ANYTHING TO SHIP!

3. YOU ARE SELLING A PRODUCT WHICH DOES NOT COST YOU ANYTHING TO
ADVERTISE (except for
bulk mailing cost)!

4. YOU ARE UTILIZING THE POWER OF THE INTERNET AND THE POWER OF MULTI-LEVEL
MARKETING TO
DISTRIBUTE YOUR PRODUCT ALL OVER THE WORLD!

5. YOUR ONLY EXPENSES OTHER THAN YOUR INITIAL $20 AND BULK MAILING COST
INVESTMENT IS
YOUR TIME!

6. VIRTUALLY ALL OF THE INCOME YOU GENERATE FROM THIS PROGRAM IS PURE
PROFIT!

7. THIS PROGRAM WILL CHANGE YOUR LIFE FOREVER.

******* T E S T I M O N I A L S *******

This program does work, but you must follow it EXACTLY! Especially the rule of not trying to
place your
name in a different position, it won't work and you'll lose a lot of potential income. I'm living proof
that it
works. It really is a great opportunity to make relatively easy money, with little cost to you. If you
do
choose to participate, follow the program exactly, and you'll be on your way to financial security.

Steven Bardfield, Portland, OR
******************************************************

My name is Mitchell. My wife, Jody, and I live in Chicago, IL. I am a cost accountant with a major
U.S.
Corporation and I make pretty good money. When I received the program, I grumbled to Jody
about
receiving "junk mail." I made fun of the whole thing, spouting my knowledge of the population and
percentages involved. I "knew" it wouldn't work. Jody totally ignored my supposed intelligence and
jumped in with both feet. I made merciless fun of her, and was ready to lay the old "I told you so"
on her
when the thing didn't work... well, the laugh was on me!

Within two weeks, she had received over 50 responses.
Within 45 days, she had received over $147,200 in $5 bills! I was shocked! I was sure that I had it
all
figured and that it wouldn't work. I AM a believer now. I have joined Jody in her "hobby." I did have
seven
more years until retirement, but I think of the "rat race" and it's not for me. We owe it all to MLM.

Mitchell Wolf MD., Chicago, IL
******************************************************

The main reason for this letter is to convince you that this system is honest, lawful, extremely
profitable,
and is a way to get a large amount of money in a short time. I was approached several times
before I
checked this out. I joined just to see what one could expect in return for the minimal effort and
money
required. To my astonishment, I received $36,470.00 in the first 14 weeks, with money still
coming in.

Charles Morris, Esq.
***************************************************

Not being the gambling type, it took me several weeks to make up my mind to participate in this
plan. But
conservative that I am, I decided that the initial investment was so little that there was just no way
that I
wouldn't get enough orders to at least get my money back. Boy, was I surprised when I found my
medium-size post office box crammed with orders!
For awhile, it got so overloaded that I had to start picking up my mail at the window. I'll make
more money
this year than any 10 years of my life before. The nice thing about this deal is that it doesn't
matter where
people live. There simply isn't a better investment with a faster return.

Paige Willis, Des Moines, IA
**************************************************

I had received this program before. I deleted it, but later I wondered if I shouldn't have given it a try.
Of
course, I had no idea who to contact to get another copy, so I had to wait until I was e-mailed
another
program. Eleven months passed then it came...I didn't delete this one!!! I made more than $41,000
on the
first try!!

Violet Wilson, Johnstown, PA
****************************************************

This is my third time to participate in this plan. We have quit our jobs, and will soon buy a home
on the
beach and live off the interest on our money. The only way on earth that this plan will work for you
is if
you do it. For your sake, and for your family's sake don't pass up this golden opportunity. Good
luck and
happy spending!

Kerry Ford, Centerport, NY
***************************************************
ORDER YOUR REPORTS TODAY AND GET STARTED ON YOUR ROAD
TO FINANCIAL FREEDOM!

NOW IS THE TIME FOR YOUR TURN DECISIVE ACTION YIELDS POWERFUL RESULTS
______________________________________________________

FOR YOUR INFORMATION:

If you need help with starting a business, registering a business name, learning how income tax
is
handled, etc., contact your local office of the Small Business Administration (a Federal agency)
1-
(800)827-5722 for free help and answers to questions. Also, the Internal Revenue Service offers
free
help via telephone and free seminars about business tax requirements.

IT IS TOTALLY UP TO YOU HOW!!!
CAN YOU HANDLE SUCCESS AND ALL THAT MONEY???

___________________________________________________________
Under Bills.1618 Title III passed by the 105th US Congress this letter cannot be considered spam
as the
sender includes contact information and a method of removal. This is a one time e-mail
transmission. No
request for removal is necessary

Received: from unipamplona.edu.co (r198h34.telecom.com.co [200.21.198.34]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id VAA16554; Wed, 17 Jan 2001 21:12:30 -0800 (PST)
From: [email-masked]
Received: from libero.it by unipamplona.edu.co (SMI-8.6/SMI-SVR4) id AAA26101; Thu, 18 Jan 2001 00:37:20 -0500
Subject: Obtain Biotech IPOs! 25
Date: Thu, 18 Jan 2001 00:14:08
Message-Id: <[email-masked]>
Reply-To: [email-masked]
Mime-Version: 1.0
Content-Type: text/html; charset="us-ascii"
Apparently-To:
Apparently-To:
Apparently-To:
Apparently-To:
Apparently-To:
Apparently-To:
Apparently-To:
Apparently-To:
Apparently-To:
Apparently-To:

Help Beta Test Our Site and Be Eligible to Purchase Shares of Future IPOs
In Which We Participate**

eMedsecurities
has selected you as a possible participant to help test our online stock-trading
engine for knowledge-based investing in the life sciences. For your cooperation,
you will be eligible to purchase shares of future IPOs in which
we participate, for as long as
you maintain your account with us. This is limited to only 50 qualified
testers!  Request More Information.**

eMedsecurities… The Cure for the Common Portfolio!

eMedsecurities provides you with a wealth of information, all compiled
in a single, easy-to-use resource.  Learn about new research and upcoming treatments
for muscular dystrophy, multiple sclerosis, Parkinson's disease, Huntington's
chorea and much more.  Obtain critical investment
information about the companies that are developing these treatments.  eMedsecurities empowers you to make more informed investment decisions.
Request More Information.**

Participation in eMedsecurities’ Beta Test allows you:

Eligibility to purchase shares
of IPOs in which eMedsecurities participates for as long as you maintain your account**

Valuable research of the entire
product pipeline of companies, including stages of clinical development, by industry or specific disease

Useful information about industry trends, recent developments and upcoming IPOs

Commitment to customer service featuring our Live Customer Service Online

Dedication to fast trade executions at the best possible
price.

The following guidelines will explain what we expect from an eMedsecurities Beta Tester:

Open a funded eMedsecurities account

Visit our online trading site once a
week

Execute trades through our web site in accordance with your normal
practice

Submit feedback to eMedsecurities' development team through a
questionnaire sent via email

Provide us with additional feedback regarding the site as needed.

The test is limited to only 50 Beta Testers so sign up now to be
considered!  Request More Information.**

Please note:
All applications for the Beta Test must be
submitted by January 24, 2001 to be considered.

Please
be advised that your information will stay in our proprietary database and will
not be sold, traded, given or otherwise provided to outside vendors.  We respect
your privacy.

By
submitting your information, you implicitly state that this is something that
interests you and that you

agree to receive periodic emails from
eMedsecurities.

Research indicated that you might benefit from
our offer.  To be removed instantly and permanently from our database, simply
click here.
We respect all removal requests.

** Restrictions Apply:  Beta
test not open to residents of:  HI, IL, MI, MN, MS, NE, NH, TN, TX.
Initial Public Offerings are considered speculative investments and as such may not be appropriate for every
investor. If an investor chooses to participate in IPOs, there are certain restrictions that apply:  Flipping- The first time an investor sells his/her shares within the first 30 days the issue is trading in the secondary market, that investor will not be allocated
shares for the next 90 days following the sale.  The second time that investor “flips”, they will not be allocated IPO shares for 180 days.  The third time that investor “flips”, they lose their IPO allocations permanently.
Transferring shares- If
the investor transfers IPO shares out of their account within the first 30 days the issue is trading in the secondary market, they will permanently lose their IPO allocations.
Beta investors will be chosen from all the applicants based on their income, net worth and investing experience.
IPO shares will only be allocated from transactions in which eMedsecurities
participates in the underwriting.
A0008-1-A2

Received: from webserver.onlineevents.com.au ([203.111.80.201]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id QAA11384 for ; Wed, 17 Jan 2001 16:49:00 -0800 (PST)
From: [email-masked]
Received: from max1-34.losangeles.corecomm.net by webserver.onlineevents.com.au with SMTP (Microsoft Exchange Internet Mail Service Version 5.0.1459.44) id C0CGL63T; Wed, 17 Jan 2001 14:55:27 +1100
DATE: 16 Jan 01 6:45:38 PM
Message-ID: <2w81t2Of2vJIo3>
SUBJECT: RE; THANK YOU

Dear Friend and Partner,

Think of all the things you could do if you had more free time and money wasn't an
object

What kind of car would you be driving?

Where would you live?

Where would you go on vacation?

Now, for a limited time, 300+ money making and saving secrets can be yours for less
than $10.00.

Click here http://www.300moneysecrets.com/ and ORDER NOW!!!!!!!!!!!!!!

Get information now, that could make you millions!!!!

** REMOVE ** REMOVE ** REMOVE ** REMOVE ** REMOVE **

To be removed from our mailing list, please email [email-masked] All REMOVE requests AUTOMATICALLY honored upon receipt. PLEASE understand that any effort to disrupt, close or block this REMOVE account can only result in difficulties for others wanting to be removed from our mailing list as it will be impossible to take anyone off the list if the remove instruction can not be received.

Received: from po1.bbn.com (PO1.BBN.COM [192.1.50.38]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA04310 for ; Wed, 17 Jan 2001 14:27:26 -0800 (PST)
Received: from [128.33.238.14] (TC014.BBN.COM [128.33.238.14]) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id RAA09387; Wed, 17 Jan 2001 17:32:56 -0500 (EST)
Mime-Version: 1.0
X-Sender: [email-masked]
Message-Id:
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Date: Wed, 17 Jan 2001 14:10:15 -0500
To: Denis Pinkas
From: Stephen Kent
Subject: Re: DPD & DPV requirements
Cc: PKIX-List
Content-Type: text/plain; charset="us-ascii" ; format="flowed"

Denis,

Your message is really too big, so I'll trim it in my response, with
the attendant possibility that I'll through away some context that
will later cause confusion, ...

>Steve,
>
>I have seen an avalanche of messages on that topic, but let me reply to your
>message which is not that old.
>
>
>
>[Steve]
>
>Self-signed certs are not the only way to deal with multiple roots, and it
>often seems to me that they are a poor way, when we want to make use of
>features like naming constraints. Why not just have cross certs issued to
>other "roots" by a local CA and embed the naming (and policy?) constraints
>into those cross certs?
>
>
>[Denis]
>
>This would be quite an artificial way to do this, and more complex than
>simply adding the elements to define the policy and naming constraints. The
>proposal is simply to define the policy constraints and the name
>constraints. Take a look at the document being progressed in the S/MIME WG
>which defines a validation policy format for non repudiation: Electronic
>Signature Policies

I don't think of it as artificial at all. Cross certification is a
standard way to create links between PKIs, and to express constraints
on these links. It has the advantage that path validation can be
applied uniformly rather than having to treat each trust point
specially, associating name and policy constraints etc. via special
means. But, I'm not hard over on this.

>
>
>[Steve]
>
>I see your example, but I also stand by my observation that providing
>anything other than the target cert per se has potential problems and adds
>complexity to the server. We'll have to decide whether we want to impose
>such adde complexity on servers, and whether we can provide clean,
>algorithmic means of dealing with this complexity.
>
>[Denis]
>
>You say "that providing anything other than the target cert per se has
>potential problems and adds complexity to the server". However, you do not
>provide arguments to support this statement.

Any means of referring to a cert, other than providing the cert, is
problematic. For example, issuer name and serial number is ambiguous
because we can't guarantee uniqueness of issuer names. A hash of a
cert fails to help me locate the cert if I can't find it in a local
cache. A subject key identifier has a similar problem. We had
similar discussions re certificate references in the attribute
certificate realm.

Your example does not seem to address this concern, or maybe we're
just miscommunicating on another level.

>
> >
>
>[Steve]
>
>A DPV client MAY be not PKI-aware, but that is not the only case we agreed
>to address. I'll need to see more comments from WG members to persuade me
>that we wish to restrict DPV interactions to clients that are presumed to be
>PKI-ignorant, to use your term.
>
>[Denis]
>
>I would rephrase your wording as :" Make sure that a DPV client can be used
>by a PKI-ignorant client".

OK.

>
>
>
>[Steve]
>
>There was some sentiment for having the "was it valid then" function as
>provided in SCVP, but if there is not continued support we could delete it.
>I want to get more feedback on this issue.
>
>[Denis]
>
>So, let us wait and see ...

I'm not seeing any support for retrospective queries, so I think we'll drop it.

>
>
>
>[Steve]
>
>I'll remove it if I hear from a few more people who agree that it is best
>provided as a separate call to a TSA.
>
>[Denis]
>
>Up to now, there has been one other message posted to the list, asking for
>the TSA removal.

OK, done.

>
>
>[Steve]
>
>As I noted, a client might acquire cert paths and CRLs via a protocol like
>SSL or IKE. Such clients could be ASN.1 capable but want to offload
>validation for the reasons cited earlier.
>
>[Denis]
>
>I agree with you that "we already have application protocols where a client
>that is not PKI-aware might acquire cert paths and/or revocation data that
>he could pass on to a DPV server." The S/MIME example I provided is one such
>example. However, this would mean that each blob able to contain such cert
>paths and/or revocation data would have to be passed "as it is", i.e.
>without being opened by the application. I made the list of such data
>structures for three documents from the S/MIME working group. If we proceed
>in that direction, then we should ask the other working groups (e.g. IPSEC,
>TLS) to provide us with a list of the data structures that are relevant. If
>this list is not too large, then it could make sense to support all of them,
>otherwise, we would have to consider that this is not practical.
>
>If you agree with this idea, it could be interesting that we raise the
>question to the other working groups.

Good points. I have glibly discussed having these apps pass in certs
and CRLs, but without taking into account the implications of this
model. If we agree to support data structures from these protocols,
then we make life easier for these clients, but servers have to be
aware of each distinct data structure. We might standardize on a
few, common formats now in use, and encourage future apps to make use
of these structures, while still providing tags to identify them and
thus accommodate new structures if needed.

>
>
>[Steve]
>
>If we don't agree on whether a DPV client might still pass on certs and CRLs
>acquired via a protocol exchange, we can't proceed along these lines. Such a
>DPV client looks a lot like a DPD client in terms of what it might pass to
>the server in a request. In any case the servers do much the same function,
>with the primary differences being the form in which validation parameters
>are specified by the client, and the form of the answers returned by the
>server. The vast majority of the processing performed by the servers for DPD
>and DPV is the same, even for a PKI-ignorant client.
>
>[Denis]
>
>The resolution on that point is pending the result of the number of "blob"
>data structures that would need to be supported for:
>
>a) certificate(s) or certificate references that *might* be useful for the
>server,
>b) revocation information that *might* be useful for the server.
>

yes. see comments above.

>
>[Steve]
>
>I don't think I have seen anyone suggest that DPD return partial path info,
>but maybe I have overlooked this. We obviously have different models here.
>
>[Denis]
>
>If the request parameters are "coarse" (e.g. no naming constraints or no
>certification policy constraints), nothing would prevent the server to find
>more than one acceptable certification path.

But these multiple paths should each be complete, not partial,
relative to whatever constraints were established.

>
>
>[Steve]
>
>Protocols 2 & 3 are quite similar because I assume that a DPV client using
>ASN.1 will be able to supply cert path and revocation status data in cases
>such as the ones I noted, e.g., when the protocols allow clients to pass
>this info around even if they do not understand it. We have examples of such
>protocols now. It's a reasonable design approach, allowing a mix of
>PKI-aware and PKI-ignorant implementations for the same protocol.
>
>[Denis]
>
>A DPD client is supposed to be both ASN.1-aware and PKI-aware, so he may
>format the cerths and the revocation data that he already got from the
>application protocols in any desired way. The same assumption does not
>necessarily stand for a DPV client that might be ASN.1-aware but would be
>PKI-ignorant.

If we adopt a small set of data structures for passing certs and CRLs
(and maybe OCSP responses), then why can't DPD clients use the same
structures? If so, then the ASN.1 protocols (2 & 3) look a lot alike.
Anyway, I don't think we should devote too much more energy to this
discussion, for 2 reasons. As I mentioned in responses to other
messages this week, if we want to have different request/response
formats for DPV and DPD (in ASN.1), then I'm comfortable doing that,
even though I bet we'll see quite a bit of overlap in arguments.
Paul's message suggests that we not mandate non-ASN.1 (e.g., XML)
support in DPV for now, so that we can make progress more quickly
here. These two observations suggest that we don't need to argue
about the similarities or differences for the 3 protocol cases you
described.

>
>
>[Steve]
>
>I begin to see the differences in our perspectives here. Yes, return of a
>single path and associated revocation status data would seem to suffice for
>DPV, but I don't think that DPD necessarily returns multiple paths, and I
>certainly don't think of it doing so in most cases. Also, why would a DPV
>server not return OSCP responses as part of its revocation status data, in
>an opaque blob? I would assume that either type of server might return
>either CRLs or OCSP responses, unless otherwise directed by the client (or
>by locally configured parameters).
>
>[Denis]
>
>It is what I said. So we strongly agree. :-) If the OCSP response is part of
>the blob, then it is no more directly visible. To this respect the
>individual OCSP response that is indeed returned is of no interest anymore
>since it is part of the revocation data blob.

OK.

>
>
>[Steve]
>
>The wording here may be confusing me. Are you saying that DPD could be
>implemented as an extension to OCSP (as has been proposed), because an OCSP
>client must be PKI-aware, whereas a DPV client is nominally PKI-ignorant and
>thus would never use OCSP in the first place?
>
>[Denis]
>
>Yes, I mean this.
>
>[Steve]
>
>I agree with that analysis, although it only suggests that the DPD/OCSP
>combination is plausible, not necessarily preferable, and that a DPV/OCSP
>combination is less plausible. though not impossible.
>
>[Denis]
>
>Good ! Since the later combination is, using your terminology, "less
>plausible", I do not see why we should support it, taking into consideration
>one further argument: the caller may be ASN1-ignorant (and XML-aware). In
>such case it is not possible to piggy back the DPV protocol on top on an
>ASN.1 protocol.

OK.

>This means that there is no need to piggy back the two protocols (i.e. OCSP
>and DPV) ... unless more information than simply revocation status data is
>returned. OCSP *theoretically* allows to carry extensions. We have observed,
>by experience, that different people had different interpretations on how
>such extensions would work. :-(
>
>At this point of time, I would imagine that DPV would also be able to carry
>some extensions, e.g. to ask some additional information on the account of
>the leaf certificate holder. We should take great care on how such
>extensions would be supported.

I always worry about extensions in protocols, as they create
opportunities for vendor-specific functions that result in
non-interoperability. if we have an extension facility I would want a
criticality flag analogous to v3 certificate extensions. If I had my
druthers, I would not provide extensions but would insist on new
version numbers as we add protocol features and change syntax. But,
you can't always get what you want ...

Steve

Received: from po1.bbn.com (PO1.BBN.COM [192.1.50.38]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA04282 for ; Wed, 17 Jan 2001 14:27:15 -0800 (PST)
Received: from [128.33.238.14] (TC014.BBN.COM [128.33.238.14]) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id RAA09348; Wed, 17 Jan 2001 17:32:32 -0500 (EST)
Mime-Version: 1.0
X-Sender: [email-masked]
Message-Id:
In-Reply-To:
References:
Date: Wed, 17 Jan 2001 11:02:23 -0500
To: "Michael Myers"
From: Stephen Kent
Subject: RE: DPD & DPV Basics
Cc: "PKIX List"
Content-Type: text/plain; charset="us-ascii" ; format="flowed"

Mike,

>Steve,
>
>Are we talking about the same thing? Given a client-side initiation, it's
>an OCSP request from an IPSEC GW/whatever to an OCSP server regarding that
>incoming cert, then that GW/whatever turns around, gets *its* own OCSP
>signed validation back from that same server (which public key the client
>trusts) and drops it into the IPSEC handshake.

I guess we're not talking about the same thing.

I thought we were talking about a query to a DPV server by an IPsec
client, where the DPV server then made use of an OCSP server. Thus I
interpreted your comment as suggesting that the DPV server return not
only an OCSP response, but also the cert for the OCSP responder. My
observation is that if on choose to do this, why stop at the OCSP
server cert, given that there is potentially much more context that
might be required. For instance, do we assume that the OCSP server's
cert has to fall under one of the trust anchors specified by the DPV
client?

I would not have guessed, from the original message below, that the
focus of your message was pushing OCSP responses in IKE.

Steve

>
>
>
>Mike
>
> > -----Original Message-----
> > From: Stephen Kent [mailto:[email-masked]]
> > Sent: Tuesday, January 16, 2001 7:41 PM
> > To: Michael Myers
> > Cc: PKIX List
> > Subject: RE: DPD & DPV Basics
> >
> >
> > Mike,
> >
> > >Carlin,
> > >
> > >It might also be useful to extend this concept the "asymmetric
> > OCSP" case,
> > >where a client's trusted server not only confirms the validity of the
> > >client's certificate via an external trust server but acquires from that
> > >same server an assertion of the validity of its (the protocol server's)
> > >certificate. This response could be included in-band to the
> > client and so
> > >relieve the client of any further interaction with infrastructure to
> > >establish the server's trustworthiness. IPSEC's protocol
> > architecture seems
> > >well suited to this design.
> >
> > One could imagine doing this, but when do we stop providing such
> > info? Do we provide a cert path and revocation status data for the
> > OCSP responder too?
> >
> > Maybe one should include the OCSP server's cert in an NR package, but
> > for a DPV server, I think it would not be appropriate to pass back
> > this info discretely.
> >
> > Steve
> >
> >

Received: from po1.bbn.com (PO1.BBN.COM [192.1.50.38]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA04254 for ; Wed, 17 Jan 2001 14:26:55 -0800 (PST)
Received: from [128.33.238.14] (TC014.BBN.COM [128.33.238.14]) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id RAA09342; Wed, 17 Jan 2001 17:32:29 -0500 (EST)
Mime-Version: 1.0
X-Sender: [email-masked]
Message-Id:
In-Reply-To:
References:
Date: Wed, 17 Jan 2001 10:47:26 -0500
To: [email-masked]
From: Stephen Kent
Subject: RE: Basic Cert-2-Directory mapping question
Cc: [email-masked]
Content-Type: text/plain; charset="us-ascii" ; format="flowed"

John,

> >As I read your suggestion, you want to add an element to the DN
> >that directs the user to the appropriate directory. The new
> >element is syntactically an RDN, but semantically is something
> >different. The resulting new-style DN appears to me to
> >semantically comparable to an LDAP URL.
>
>
>I don't think the proposed "dir" attribute is semantically very different
>from any other naming attributes. What we're trying to do with names in
>certificates is to maintain the X.500 illusion that a DN uniquely
>identifies an entry in some global directory. But we don't have a single
>global directory; instead we have a collection of directories which don't
>talk to one another - i.e. instead of the single DN root assumed by X.500,
>we actually have multiple roots, one for each directory.

I think this is a debatable point. The X.500 model assumes
interconnection of top level (country or international, not
multinational organizations) directories via knowledge references.
Adding in a dir attribute, to compensate for the lack of these TLDs,
does seem to violate the semantics of X.500 naming and of operation.
Your text above makes clear how this approach deviates from the
original model (with good motivations), but that does change the
semantics.

Steve

Received: from stingray.missi.ncsc.mil (stingray.missi.ncsc.mil [144.51.50.20]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA29181 for ; Wed, 17 Jan 2001 13:00:04 -0800 (PST)
Received: from stingray.missi.ncsc.mil (root@localhost) by stingray.missi.ncsc.mil with ESMTP id QAA12467 for ; Wed, 17 Jan 2001 16:05:13 -0500 (EST)
Message-Id: <[email-masked]>
Date: Wed, 17 Jan 2001 16:06:23 -0500 (EST)
From: David Kemp
Reply-To: David Kemp
Subject: RE: Basic Cert-2-Directory mapping question
To: [email-masked]
MIME-Version: 1.0
Content-Type: TEXT/plain; charset=us-ascii
Content-MD5: y5ZjQxmdbM52R/s7BoiFHg==

Skip,

I favor the implicit approach.

Existing DNs schemas have tremendous inertia, and in addition to
more intellectual reasons, registering existing country-based
DNs within DNS is overwhelmingly the path of least resistance.
In order to support Internet directory interoperability, it is far
easier to say (to the DoD PKI, for example):

"You have to register a DNS record for OU=DoD."

rather than:

"You have to change all of your certificates and directories to
include a new top-level RDN."

I agree with Bob's goal of eliminating the need to pass certs in
session handshakes and messages. If there were only two options (change
the DN or add an extension), then only the first moves toward that
goal. But you have proposed a third option: leave the cert alone!
For my part, I am simply in awe of the elegance of that approach.
It might even work.

Dave

From: "Bob Jueneman"
>
> Ron,
>
> I don't think we are on the same page.
>
> I don't conceive of the dir= attribute as constituting a non-DIT RDN.
> Instead, I am suggesting that we should add the dir= attribute as a full
> RDN component at the top of the existing DIT.
>
> I believe that it really belongs there, to qualify the lower level entries
> as belonging to that particular directory, just as is the case with "normal"
> DN qualification.. So yes, I believe that you ought to be able to see
> that entry when browsing the directory, not withstanding the act that
> it would normally be static.

> The alternative, using an LDAP-style qualifier to precede the DN, is
> what strikes me as being abhorrent.
>
> If I have a DN that includes at the top of the DIT the name of the
> directory root itself, then that DN can be handled by all applications
> that know how to parse DNs generally. Otherwise, we are left with
> protocol-specific hacks, like URLs with trailing DNs.
>
> Bob
>
>
>
> From: "Ramsay, Ron"
>
> > Bob,
> >
> > While it may be true that 'c=us' does not try to say something about
> > countries, I don't believe this is relevant. The importance of this RDN in
> > the DN is that, notionally, there is an entry with the DN 'c=us'. When
> > browsing an X.500 DIT, you should be able to see all the superior entries as
> > indicated bu the RDNs in the entry DN. This is the semantic meaning of the
> > DN, not 'what does country mean in this DN'. To this extent, the idea of
> > adding a non-DIT RDN to the DN is abhorrent and will create real problems.
> > (LDAP directories generally aren't browsable so I guess my remarks don't
> > apply to them.)
> >
> > Ron.

[ 15 additional messages snipped ... ]

Received: from webserver.onlineevents.com.au ([203.111.80.201]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA24327 for ; Wed, 17 Jan 2001 11:12:47 -0800 (PST)
From: [email-masked]
Received: from max1-34.losangeles.corecomm.net by webserver.onlineevents.com.au with SMTP (Microsoft Exchange Internet Mail Service Version 5.0.1459.44) id C0CGL63T; Wed, 17 Jan 2001 14:55:27 +1100
DATE: 16 Jan 01 6:45:38 PM
Message-ID: <2w81t2Of2vJIo3>
SUBJECT: RE; THANK YOU

Dear Friend and Partner,

Think of all the things you could do if you had more free time and money wasn't an
object

What kind of car would you be driving?

Where would you live?

Where would you go on vacation?

Now, for a limited time, 300+ money making and saving secrets can be yours for less
than $10.00.

Click here http://www.300moneysecrets.com/ and ORDER NOW!!!!!!!!!!!!!!

Get information now, that could make you millions!!!!

** REMOVE ** REMOVE ** REMOVE ** REMOVE ** REMOVE **

To be removed from our mailing list, please email [email-masked] All REMOVE requests AUTOMATICALLY honored upon receipt. PLEASE understand that any effort to disrupt, close or block this REMOVE account can only result in difficulties for others wanting to be removed from our mailing list as it will be impossible to take anyone off the list if the remove instruction can not be received.

Received: from mailgw2a.lmco.com (mailgw2a.lmco.com [192.91.147.7]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA20118 for ; Wed, 17 Jan 2001 09:50:12 -0800 (PST)
Received: from emss03g01.ems.lmco.com (emss03g01.ems.lmco.com [141.240.4.144]) by mailgw2a.lmco.com (8.8.8/8.8.8) with ESMTP id MAA24392; Wed, 17 Jan 2001 12:55:49 -0500 (EST)
Received: from CONVERSION-DAEMON by lmco.com (PMDF V5.2-32 #38888) id <[email-masked]>; Wed, 17 Jan 2001 12:54:41 -0500 (EST)
Received: from emss03i00.ems.lmco.com ([141.240.31.211]) by lmco.com (PMDF V5.2-32 #38888) with ESMTP id <[email-masked]>; Wed, 17 Jan 2001 12:54:22 -0500 (EST)
Received: by emss03i00.orl.lmco.com with Internet Mail Service (5.5.2650.21) id ; Wed, 17 Jan 2001 12:55:30 -0500
Content-return: allowed
Date: Wed, 17 Jan 2001 12:55:29 -0500
From: "Slone, Skip"
Subject: RE: Basic Cert-2-Directory mapping question
To: "'Bob Jueneman'" , [email-masked]
Cc: [email-masked]
Message-id:
MIME-version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-type: text/plain
Content-transfer-encoding: 7BIT

Bob,

A couple of thoughts come to mind while reading your response and subsequent
responses to your response.

First, with respect to your bandwidth conservation approach, it seems like
what you're after is not too far afield from the DPV/DPD discussions going
on in a separate thread. Have you considered that work as a possible way of
addressing your requirement?

Second, given the different directions this discussion is going, I'm having
a hard time telling whether we're saying the same thing or not. My concern
with DN semantics is only a concern if we introduce a new RDN construct that
behaves differently from any other RDN. That is, if the RDN is constructed
using the distinguished attribute value(s) in an entry, and if that RDN
names an actual entry (or at least something modelled as a DSE), then I have
no concerns about semantic drift. On the other hand, if the thing that is
syntactically an RDN has no relevance to a directory entry, but is actually
closer to the concept of a DSA's access point, then I have a problem since
such a construct would cause breakage to occur with existing clients and
servers. At one point, I thought you were proposing such a new construct.
After reading your response to Ron, I don't think that's what you were
saying.

Are you suggesting instead that we simply come up with a new attribute type
to be used in naming objects in a way that facilitates location of the
relevant repository? If so, how does this differ from the domainComponent
attribute type which already does just that? Further, how does this move us
closer to finding repositories for the gazillions of DNs whose most
significant RDN is something other than dc or this new thing?

Separately, it seems much of this discussion is drifting steadily away from
the PKIX charter. Can I suggest that, in order to improve the SNR for
people with little to no interest in directories, we move the pure naming
discussion to another forum such as ldapext? With this in mind, I would like
to draw your attention to a note I just posted there on the topic of
LDAP/X.500 alignment. IMO, that note provides an adequate segue into the
topic.

-- Skip

-----Original Message-----
From: Bob Jueneman [mailto:[email-masked]]
Sent: Tuesday, January 16, 2001 9:35 PM
To: [email-masked]; [email-masked]
Cc: [email-masked]
Subject: RE: Basic Cert-2-Directory mapping question

Skip,

Just so it's clear, I probably should have defined at least one use
model for what we have been talking about -- at least the use
that I have in mind.

what I'm trying to get away from this the necessity of wasting all
of the bandwidth that is currently being used to repetitively
download entire certificate chains containing the same information,
over and over again to the same client. This is particularly the
case in SSL/TLS and S/MIME, and I predict that when we start
sending signed EDI transactions it will be the case there as well.

What I want to do to minimize all of this is to send only two things
with a given transaction -- the digital signature itself, stripped down
as far as possible; and the name of the signer, in a minimal form
as possible without imposing a rigid repository schema.

ideally, the name of the signer should be a DN, whether in the form
of a classical civil name structure, and DNS name, or some other form
that is searchable, such as a DUNS number.

Ideally, the structure of the DN should be compatible with existing
RDN syntax, but perhaps with the addition of a new attribute type.
I think that we are agreed that SOMETHING new is going to be
required, and if that is the case a new attribute that is consistent with
the
current RDN syntactic structure would to my mind be preferable to
introducing something else, such as a URL or URI.

Although I don't want to get completely hung up on the use of a
dir= RDN qualifier vs. a more explicit URL-type qualifier, I'm don't
think I agree with your concern about the paradigm shift in the
DN semantics a dir= type of qualifier would cause. Maybe I just
don't understand.

I am inclined to say that "DN semantics" is close to being an oxymoron.
The fact is that the semantic definitions of most of the usual DN
attributes are conspicuously vague. Consider "serial", "locality",
commonName,
or even "country". Yes, we all understand what a country is -- it's
whatever the UN says it is, or isn't, and questions about disputed
territories
are brushed aside. But that isn't a semantic definition, that is simply a
name to
territory definition or mapping. The real question is what is the
relationship
between the country and the end-entity identified by the rest of the DN --
is it merely a directory qualifier, or is it the country of residence?,
citizenship?
place of doing business? location of the home office? country of
incorporation of an enterprise? If I am referring to a ship, for example,
that
is owned an operated by a UK company, registered in Liberia ,and
is currently docked in Miami, what country should I use for the RDN
of that ship?

Since X.500 doesn't attempt to answer that question, I would claim that
the only effective semantics for country is as a directory qualifier, under
the
old universal X.500 directory-in-the-sky assumption of a monopoly directory
service, or at least a monopoly naming infrastructure per country.

Since we know by now that the original assumption is no longer valid,
if indeed it ever was, we can certainly use country to mean whatever
we choose it to mean in terms of semantics, just as people have
distorted the semantics of organization, and particularly
organizationalUnit, to contain just about anything they want.

(I'm not really suggesting an RDN containing a MPEG of my cat, but
things that are nearly as strange have been done in the past.
That doesn't make them "right", of course, just ubiquitous.)

But what that leaves us with is the need to qualify what used to be a root,
i.e., country, and to supply a new root, meaning basically who owns,
operates, and defines the semantics and schema for all of the rest of t
he RDNs which follow.

I would submit that despite the semantic "recommendations" provided by
the standards organizations, it is really the directory service provider who

defines such things, or in some cases the Certificate Authority who creates
a
certificate, whether or not they actual deposit that certificate in an X.500

directory

>From this point of view, I believe that using a dir= type of directory
service
provider is not some kind of an ugly hack, but a reflection of reality, and
a
completely legitimate RDN qualifier. It specifies in a consistent DN syntax
what the root of the DIT really is -- the name of the directory that
contains
and defines it.

Now I'll grant that it isn't very likely that existing X.500 directories
would
suddenly change their DIT structure to explicitly include a dir= component
at the Top. But I don't think that would be at all necessary, either -- it
can be
done implicitly.

I wouldn't think it would be all that hard to define the attribute matching
rules so that if the dir attribute (or one of the multi-=valued RDN
components)
is the DNS address of the directory that is being accessed, the result is
TRUE, and otherwise FALSE.

Another approach which might or might not work would be to use an alias,
although I don't know whether it is possible to define an alias for a node,
rather than for a leaf.

For example, in Novell's own DIT, we don't even define c=US as the top
component, although perhaps we "should".

But I would assume/hope that if we were concerned about that, we could
define an alias of c=us, o=Novell Inc. to point to the o=Novell node that is

actually at the top of our DIT.

Since you said that you actually considered this type of an approach
at one time, perhaps you can say more about what led you away from
that approach. I think you were right the first time.

Regards,

Bob

>>> "Slone, Skip" 01/16/01 01:45PM >>>
John,

You wrote, "I don't think the proposed "dir" attribute is semantically very
different
from any other naming attributes" and that "the mechanism for searching has
to treat the "dir" RDN somewhat differently from the other RDNs."

My concern with different semantics is not a matter of degree; it's the fact
that the semantics of DN must change -- at all -- to incorporate this
concept. If there are other ways to deal with the problem, I see no
compelling reason to change the semantics of something so fundamentally and
deeply entrenched in dozens of standards as DN.

I must add here that I have not always opposed this concept. I actually
pursued this line of thinking two or three years ago in a different forum
(X.500) while working a different problem (Related Entries). At that time, I
was proposing that a "dnQualifer" be added to a DN to specify an access
point through which the entry named by the DN could be found. While pursuing
that line of thinking (which explored several syntactic/semantic variants),
the semantic-shift problem kept getting in the way. In the end, we settled
on a separate mechanism rather than change the semantics of DN. Flawed as it
may be, DN is still a widely accepted concept; changing it will be an uphill
struggle.

-- Skip

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Tuesday, January 16, 2001 10:52 AM
To: Slone, Skip
Cc: 'Bob Jueneman'; [email-masked]
Subject: RE: Basic Cert-2-Directory mapping question

>As I read your suggestion, you want to add an element to the DN
>that directs the user to the appropriate directory. The new
>element is syntactically an RDN, but semantically is something
>different. The resulting new-style DN appears to me to
>semantically comparable to an LDAP URL.

I don't think the proposed "dir" attribute is semantically very different
from any other naming attributes. What we're trying to do with names in
certificates is to maintain the X.500 illusion that a DN uniquely
identifies an entry in some global directory. But we don't have a single
global directory; instead we have a collection of directories which don't
talk to one another - i.e. instead of the single DN root assumed by X.500,
we actually have multiple roots, one for each directory.

The obvious way to resolve this sort of problem is to introduce a new
"meta-root" that sits above all the directory roots. This corresponds to
adding an RDN to the most significant end of each DN that names the
particular directory within which the named entry lies. Precisely how a
directory is named is TBD, but it must give an end-system enough
information to for a query for that directory, without requiring prior
knowledge of the directory, so an obvious possibility (for an LDAP
directory) is scheme and hostport portions of an LDAP URL.

Individual directories could either store this attribute explicitly within
the entry (which would mean that these directories could be directly
searched using the full DN) or, more likely, the "dir" attribute would have
to be removed before searching an individual directory. So yes, the
mechanism for searching has to treat the "dir" RDN somewhat differently
from the other RDNs, but in terms of a naming model, it behaves just like
any other RDN.

As Bob points out, the "dir" attribute could be multi-valued, allowing
information about an entry to reside in multiple directories (provided that
the directories can all agree to use the same name for the entry).

John

"Slone, Skip" on 01/16/2001 09:16:13 AM

To: "'Bob Jueneman'"
cc: [email-masked]
Subject: RE: Basic Cert-2-Directory mapping question

Bob,

I'm glad to hear we agree on the nature of the problem. From that point of
agreement, we can move the discussion to one of "what do we do about it?"

In abstract terms, it appears to me that "what we can do about it" falls
into two broad categories:
1) we can create a mechanism for explicitly identifying the appropriate
directory, or
2) we can remove the barriers that currently prevent the directory from
being discovered implicitly based upon existing information

I would say that your approach fits in category 1, while my approach fits
in
category 2. Either approach has validity IMHO and is worthy of
consideration.

As I read your suggestion, you want to add an element to the DN that
directs
the user to the appropriate directory. The new element is syntactically an
RDN, but semantically is something different. The resulting new-style DN
appears to me to semantically comparable to an LDAP URL.

Assuming we're on the same page up to this point, I'll say that my concern
with this approach is that it changes the semantics of DN, potentially
causing interoperability problems in that both clients and servers that
understand the semantics as currently defined would have problems when
encountering the new-style name. If we were to go with a "category 1" fix
to the problem, I would rather see a new mechanism employed, such as a new
PKIX-defined certificate extension that explicitly gives repository
location
information. As a new construct, we would be free to define whatever
semantics we want, and could readily use existing concepts such as URLs.

Now, in defense of my approach, I think we can all probably agree that *IF*
the original concept of X.500-style distributed, global name resolution
were
a practical reality, we would be able to plug into the nearest DSA and find
the named entry regardless of where it resides physically. Of course I
emphasized the word "if" to imply that we can also probably agree that that
original X.500 concept is not going to occur anytime soon, if ever. What I
was proposing instead, was a "category 2" fix -- a way of removing that
barrier by providing an alternative way of doing distributed name
resolution. The alternative mechanism I proposed was one which builds upon
an existing, working, global infrastructure that already has the requisite
registration infrastructure in place. Without digging into the specifics,
I
would like to know if you or others believe that this *concept* has merit.

-- Skip

-----Original Message-----
From: Bob Jueneman [mailto:[email-masked]]
Sent: Monday, January 15, 2001 2:11 PM
To: [email-masked]
Cc: [email-masked]
Subject: RE: Basic Cert-2-Directory mapping question

Skip,

I don't particularly like the mechanism you've proposed, at least as
I understand it. But I absolutely and completely agree with you
as to the nature of the problem that has to be solved.

Civil attribute type names will always be with us, and hence must be
dealt with, for at least two fundamental reasons:

1. An address is not a name, although it may be a pseudonym. I
don't want to be forced to change my identity, or to an extent
my basis "self-hood," every time I change my ISP. And I especially
don't want some system administrator telling me that my name
must be limited to 8 characters, or that I have to change my name
because someone else has already used that same name within
that same system administrator's ill-conceived naming scheme.

2. E-mail address and other cyberspace identifiers fail to provide the
essence of PKI from a nonrepudiation standpoint, i.e., what I call the
"where do you send the sheriff" question.

Granted, not all uses of PKI will or should involve legal nonrepudiation.
But to the extent that at least some uses WILL have legal consequences,
then the establishment of a globally unique and credible identity that is
grounded in "meat-space" rather then cyberspace is absolutely essential.

For those legally binding transaction to be worth anything at all, they
have to be enforceable. And that means that a judgement may have
to be enforced upon someone, either by seizing the assets or putting
them in jail. And only in science fiction does the sheriff ride off into
cyberspace to arrest someone.

If I as a relying party wish to trade with someone, then I either want to
charge her credit card (in which case PKI is demonstrably not necessary)
or I want to know that she is the Mary Smith who resides at 123 Anywhere
St,
Metropolis, NY.

The inclusion of that civil address not only servers to distinguish her
from the other Mary Smiths, but more importantly it establishes a nexus
or link between her identity and her probable whereabouts, and
probably valuable real property as well.

So civil addresses, both corporate or "organizationalPerson", or the
harder-to-deal-with residentialPerson type will presumably always
be with us, and will have to be dealt with.

And unfortunately, perhaps, here int he US the simple and inescapable
fact of the matter is that neither the federal nor the state governments
operate the type of presumptively authoritative name registration
authorities that are relatively common in other countries. I am perfectly
free to move from one city to another, or from address to another in
the same city, and to never notify anyone in authority at all, including
the tax authorities. No one will ever say, "Papers, please."

(Granted, if I choose to do that I may not be able to register to vote,
but over half the population doesn't vote anyway. And the last time
I registered, no one checked to see that I actually lived there -- that
one of the problems we have with our voting system, even outside
of the State of Florida.. And I may not be able to get a driver's license
in order to legally drive a car, but a lot of illegal immigrants don't have
driver's licenses either, although that doesn't keep them from driving.)

So merely trying to ignore the problem of civil addressing schemes
won't solve that problem. And neither will various approaches that
make certain assumptions about monopoly name registration
authorities, or try to divine or impute where a directory containing
a particular name might be found based on some kind of a Karnak
mentalist act.

The primary issue is not the question of whether the name space
is flat or hierarchical, or how hierarchical, much less what the
"approved" schema is. What will be, will be, for reasons that
are beyond our scope and power to influence, even if we wanted
to.

So.

We cannot force a person to deposit his certificate or other useful
information into a specific directory, even if we wanted to. Nor can
we reliably impute a likely directory where such information might
be found, at least in the absence of a monopoly or governmental
mandate.

The best we can do is to ASK the user where he has deposited
such information, if anywhere, and to include that information
EXPLICITLY in any directory or pseudo-directory reference, such
as a DN.

Although at one time I liked the notion of prefixing the DN with a
URL, I have come to believe that John Wray's suggestion is the
better way forward.

He said:
>
>Bob,
>
>Accepting the fact that the X.500 dream of a single global directory is
not
>going to happen any time soon, DNs can still be turned into globally
>significant pointers into a federation of directories in the way you
>suggest, but it doesn't require altering the DN syntax (and therefore
>doesn't have to break existing implementations). All that's needed is a
DN
>attribute that names the particular directory within which the name
>resides. e.g. instead of "c=us;..;cn=My Name" you'd have "dir=My
>Directory;c=us;...;cn=My Name", where "My Directory" is the URL of a
>directory access point.

By including an explicit directory qualifier of the form dir="directory
URL"
at the root (top) of the RDN chain, we have implicitly qualified all of the
rest
of the RDN, which is a Good Thing.

By defining the syntax of the "dir" attribute appropriately, we could
include
both the access type (LDAP, http, etc.) and port number appropriately,
either a default or explicitly indicated.

And by making the dir component multivalued, we could accommodate
a choice of multiple directories and multiple directory types.

Once again -- the essence of the problem is not the format of the directory
name but where a directory containing that name can be found.
Including that information as a top-level qualifying component solves that
problem (and potentially several others, such as name scope qualification)
very neatly.

Bob

Robert R. Jueneman
'Security Architect
Novell, Inc. -- the leading provider of Net services software
>
>
>
>
>
>
>
>>>> "Slone, Skip" 01/15/01 09:08AM >>>
>Oscar,
>
>No offense taken, thus no apology needed.
>
>My comments from the soapbox last week were actually intended for the
>community at large, and were meant to convey frustration at the apparent
>unwillingness of solution providers in general to hear about -- and solve
--
>real world problems that are faced by users like myself in large, complex
>environments.
>
>When I say "my environment is not so simple," the response I hear is
"let's
>not talk about the complexity; let's make some simplifying assumptions
>instead."
>
>When I say "I have a nail AND a screw and need to put them both in the
>wall," the response I hear is "we have provided you with a perfectly
>adequate hammer, therefore you don't have a screw."
>
>As I was using the nail/hammer analogy, dc-based names are the nails;
>civil-attribute-based names are the screws. No matter how good a job my
>company does of using nails and nails alone, we still have tens of
thousands
>of trading partners, many of whom prefer screws to nails and will continue
>to use them indefinitely. Without a screwdriver, it's hard to do business
>with them.
>
>I don't really care what the screwdriver looks like. I've suggested a
>fairly simple design that I think will work. So far, no one has commented
on
>the design. What I've heard instead is a chorus of "we still don't like
>screws." Well, I don't like them either, but I still have to deal with
>them. If I'm simply overlooking a screwdriver that we have lying around
>somewhere, I would appreciate someone pointing it out to me.
>
> -- Skip
>
>
>-----Original Message-----
>From: Oscar Jacobsson [mailto:[email-masked]]
>Sent: Thursday, January 11, 2001 5:16 PM
>To: Slone, Skip
>Cc: 'Sharon Boeyen'; [email-masked]
>Subject: RE: Basic Cert-2-Directory mapping question
>
>
>> From: Slone, Skip [mailto:[email-masked]]
>> In response to this, I'm inclined to join Sharon on Marshall's soapbox
and
>> echo her words:
>>
>> "... I believe a more constructive approach is to accept the fact that
>> different parts of the world and different environments will use a
variety
>> of nameforms ... We are not the global naming police either and should
not
>> try to impose the rules that anyone uses to name entities to which they
>> issue certificates."
>
>I'm sorry if I came across as clamouring for rules be imposed. I know that
>this working group has a tendency to be wary of suggestions that don't
cater
>for distinguished names containing cat MPEGs, so I should probably have
been
>more careful. The requirements I suggested were for a possible naming
>standards document, conformance to which need not be enforced.
>
>The case at hand is not, IMHO, one of dictating that "all distinguished
>names must be according to our will, or you shall feel our wrath". A
>document however, outlining a naming strategy that would require of the
>users of certificates named accordingly no a-priori knowledge of their
>issuer (save for eventually having to reach something explicitly trusted
in
>the chain) in order to perform path validation, is something I would
>personally consider very valuable indeed. I'm reasonably confident that
>organizations intending to act as certification authorities or trusted
third
>parties would agree.
>
>> And to quote someone Sharon and I both know, "If all you have is a
hammer,
>> every problem looks like a nail."
>
>It seems I was less than clear here as well. :-(
>
>My intention was to point out that there are actually two separate
problems
>here (one nail, if you will, and one screw) each looking for its own
>solution:
>
>1. Defining a repository, and subsequently entry, discovery process for
>arbitrarily named entries.
>
>2. Defining a naming scheme that _if applied_ would automate this
repository
>and entry discovery process.
>
>I am only trying to address the second of these problems. The first is
only
>an issue because nobody seems to have properly addressed the second before
>deploying certificates on the Internet en masse. The further we wait
before
>addressing number two, the more of a problem number one will become.
>
>I should probably make a habit of pointing out that the opinions stated
here
>are my very own, and not necessarily those of my employer.
>
>Cheers,
>
>//oscar

Received: from host6.janus.surfnet.nl (IDENT:root@localhost [192.87.0.23] (may be forged)) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA15764 for ; Wed, 17 Jan 2001 08:31:09 -0800 (PST)
Received: from surfnet.nl (host2.janus.surfnet.nl [192.87.0.19]) by host6.janus.surfnet.nl (8.11.0/8.11.0) with ESMTP id f0HGZv910474; Wed, 17 Jan 2001 17:35:58 +0100
Message-ID: <[email-masked]>
Date: Wed, 17 Jan 2001 17:37:04 +0100
From: Janus Liebregts
Organization: SURFnet bv
X-Mailer: Mozilla 4.7 [en] (Win98; I)
X-Accept-Language: en,nl
MIME-Version: 1.0
To: Bob Jueneman
CC: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Re: Basic Cert-2-Directory mapping question
References:
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Bob Jueneman wrote:
> The fact is that the semantic definitions of most of the usual DN
> attributes are conspicuously vague. Consider "serial", "locality", commonName,
> or even "country". Yes, we all understand what a country is -- it's
> whatever the UN says it is, or isn't, and questions about disputed territories
> are brushed aside. But that isn't a semantic definition, that is simply a name to
> territory definition or mapping. The real question is what is the relationship
> between the country and the end-entity identified by the rest of the DN --
> is it merely a directory qualifier, or is it the country of residence?, citizenship?
> place of doing business? location of the home office? country of
> incorporation of an enterprise? If I am referring to a ship, for example, that
> is owned an operated by a UK company, registered in Liberia ,and
> is currently docked in Miami, what country should I use for the RDN
> of that ship?

Bob,

this relationship depends on the context and can have several forms.

1. in a 'doing-business'-pki
2. in a 'legal'-pki or as you call it a 'send-the-sheriff'-pki
in both cases not the DN of the ship is important, but the company
responsible for the ship and it's representative, I suggest the captain.

In a 'doing business'-pki what matters is, which authorizations does the
captain have. The captain could be an dutchman acting on behalf of a UK
company and the same person could also act on behalf of another
(Liberian) company.
So the DN of the captain: cn=captain, o=UK-company, c=GB
which has a 'Role Occupant'DN: cn=John Smith, l=Eindhoven, c=NL

in the 'legal'-pki where the ship is operated by a company under the
legal system of Liberia:
cn=captain, o=Liberian-company, c=LR
with the same 'Role Occupant'

in these cases country represents the legal system of UK and Liberia
so cn= operates on behalf of o= which operates under the laws of c=
and cn= operates as a citizen of l= under the laws of c= or laws of
st=,c=

what l= represents depends on local law.

An other possible solution for solving the jurisdiction problem is
defining yet another certificate extension as done in the
'Internet X.509 Public Key Infrastructure Qualified Certificates
Profile' (http://www.ietf.org/internet-drafts/draft-ietf-pkix-qc-06.txt)
but this requires other law systems to recognize and accept this
extension. This will be the case in the countries of the European Union
by means of the ETSI QCP-standards which implements the EU-directive on
digital signatures.
According to this ietf-draft:
"A typical statement suitable for inclusion in the Qualified Certificate
Statements extension MAY be a statement by the issuer that the
certificate is issued as a Qualified Certificate in accordance with a
particular legal system"
and
"The issuer field SHALL identify the organization responsible for
issuing the certificate. The name SHOULD be an officially registered
name of the organization"

3. 'access & authorization'-pki
it doesn't matter what is meant by country, any company can make his own
rules for his own domain or even choose some other or mixed naming
scheme. When inter-businnes 'access & authorization' is required, you
have to agree on a naming policy and build a:

4. 'branch oriented A&A'-pki
There we could have the super-branch-organisation (Root) which certifies
members, with names recognized by all it's members (domain) and which
can give some meaning to country. One company can be member of more
branches and can have different names in different domains, so the
branch oriented pki's gather and form a:

5. 'inter branch oriented A&A'-pki

etc....

For building legal pki's, I think governments should take their
responsibility by building national pki's issuing identity certificates
to persons and companies.

>From legal point of view there should be a federation of pki's; one per
legal system.
In the CP of such a national RootCA their should be some lines:
"The issuer name SHOULD be an officially registered name of the person
or organization"
and
"The certificates are issued in accordance with the (fill in your
country) legal system"

The dutch law defines some Naming Authorities (NA)

-NA for persons: local authorities (de gemeente, burgerlijke stand
http://www.wetten.nu/wetgeving/nl00087/nl00087-08.cfm)
-NA for local authorities: the community council (de gemeenteraad
http://www.wetten.nu/wetgeving/nl00096/nl00096-02.cfm#P788_75618)
-NA for companies: chambers of commerce have a delegated task
(Handelsregisterwet 1996 & Handelsnaamwet)
(excuse my bad translations in the above)

The first step in my opinion would be bringing in line the used
Organizational Name in certificates with the name registered with the
local Chamber of Commerce. The Chamber of Commerce could operate their
own CA and doing the task they already do: registering companies,
distinguishing between them and register which person has which
authorization or which people can act on behalf of this organization.

As this infrastructure is not in place yet, I suggest, when building
national or legal pki's, Naming Authorities should bring in line the
used names with the ones as registered with the Chamber of Commerce. The
dutch Chamber of commerce has an on-line register with officially
registered company names: http://www.kvk.nl/kvk/kvk-online.html?type=h
(for using it read Handelsnaam=company name, Plaatsnaam=city, Start
zoeken= start searching)

Step 1. register officially (according to law) the name
Step 2. make a DN from 'officially registered name'
c=NL (according to dutch law), o= organizational name (according to
chamber of commerce), cn/ou= whatever (according to organization)
c=NL (according to dutch law), l= community name (according to the
community council), cn=personsname (according to local authorities,
burgelijke stand in the Netherlands)
Step 3. certify the binding public-key/DN

My overall view is, make the contents of a certificate as bare as
possible and store everything else in the ldap-entry belonging to this
certificate. This is an entry which is controlled by the (privacy wishes
of the) subject.

But the basic question is where to find that ldap-entry, not knowing the
starting point. In my point of view every pki can have it's own
bootstrap. Pki's based on dc-naming have their bootstrap in DNS by the
named.root (ftp://ftp.rs.internic.net/domain/named.root) and adding a
SRV-record. I think a legal-pki based on X.521-naming will have some
sort of bootstrap defining the ip-adresses of the top level DSA's in
some similar file.

We claim to operate the c=NL tree according to SURFnet, which is
according to NameFlow which is our bootstrap
(http://www.nameflow.net/nameflow.html). I would be happy if some other
organizations, also would operate a C=NL tree with some other guarantees
about naming entities. I as a trust builder then could choose my level
of trust, until then let's build the infrastructure on the current
naming policy...

regards,
janus
ldap://ldap.surfnet.nl/cn=Janus Liebregts,o=SURFnet,c=NL

Received: from marcy.adiron.com ([128.230.111.5]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA10494 for ; Wed, 17 Jan 2001 07:26:17 -0800 (PST)
Received: from localhost (polar@localhost) by marcy.adiron.com (8.9.1/8.9.0) with ESMTP id KAA04148; Wed, 17 Jan 2001 10:26:30 -0500
X-Authentication-Warning: marcy.adiron.com: polar owned process doing -bs
Date: Wed, 17 Jan 2001 10:26:29 -0500 (EST)
From: Polar Humenn
To: Bob Jueneman
cc: [email-masked], [email-masked], [email-masked]
Subject: RE: Basic Cert-2-Directory mapping question
In-Reply-To:
Message-ID:
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

Bob,

I think the thing you are trying to get here is:

1. I have a signature made by a private key.
2. How do I find the corresponding public key to verify it.
3. How do I trust the public key.

You want a minimal stripped down signature, and a pointer the place in
which one *might* find the public key. At this point, I don't even need a
certificate, correct? I can just simply trust the public key.

However, for non-repudiation, and "where do I send the sherrif" motif,
certification of that public key is necessary to tie it to some attributes
in which you can make a trust decision. This is necessary, because that
certificate must be a matter of *public* record. However, public records
are strewn all over the place. You cannot go into the Motor Vehichle
department of Utah and ask for a copy of someones New York State Drivers
License, or their birth certificate.

It seems fundamental to me, that you need a protocol, a pointer to a
service of that protcol, and an identifier with which to get that
certificate.

In CORBA, there is a service called the Person IDentification Service
(PIDS). This service was built my many learned people in the business of
identification, i.e. hosptial patient registration. In this service, they
encounter all such problems as spliting and merging identities based on
*traits*, i.e. the two John Smiths problem. Traits can be considered very
dynamic things and change all the time. However, the basic cruxt is that
it all comes down to an object reference called an Identity.

Now, I know in the IETF you may not have the luxury of flinging CORBA
object references around, however, the basic premise is that you have the
following items in order to identify something:

1: a specification of a protocol,
2: a location of a service supporting that protocol,
3: and an identifier within that protocol.

Item 1, isn't much good if you don't have item 2 as well. And Item 3
is pretty much useless without 1 and 2.

Whether that service is LDAP, DAP, DNS, CORBA Naming, or PIDS, it doesn't
much matter, but there has to be something. Having the Identifer (#3) is
just not good enough.

Finding the end entity certificate (i.e. the signing key) shouldn't be
that hard. A signature can contain all items 1,2,3. Since the signing
entity can provide that information, correct?

However, I think the basic problem lies path discovery and validation
because certificates themselves do not contain items 1 and 2 of their
issuers.

Would you say that this is a correct interpretation of the problem?
Unfortuately, a certificate is a signature and it's missing important
information about its signer, such where to find its public key, and quite
possibly a certificate for that public key.

I seem to remember something about an AuthorityInfo extension. Does that
solve the problem well enough?

Cheers,
-Polar

On Tue, 16 Jan 2001, Bob Jueneman wrote:

> Skip,
>
> Just so it's clear, I probably should have defined at least one use
> model for what we have been talking about -- at least the use
> that I have in mind.
>
> what I'm trying to get away from this the necessity of wasting all
> of the bandwidth that is currently being used to repetitively
> download entire certificate chains containing the same information,
> over and over again to the same client. This is particularly the
> case in SSL/TLS and S/MIME, and I predict that when we start
> sending signed EDI transactions it will be the case there as well.
>
> What I want to do to minimize all of this is to send only two things
> with a given transaction -- the digital signature itself, stripped down
> as far as possible; and the name of the signer, in a minimal form
> as possible without imposing a rigid repository schema.
>
> ideally, the name of the signer should be a DN, whether in the form
> of a classical civil name structure, and DNS name, or some other form
> that is searchable, such as a DUNS number.
>
> Ideally, the structure of the DN should be compatible with existing
> RDN syntax, but perhaps with the addition of a new attribute type.
> I think that we are agreed that SOMETHING new is going to be
> required, and if that is the case a new attribute that is consistent with the
> current RDN syntactic structure would to my mind be preferable to
> introducing something else, such as a URL or URI.
>
> Although I don't want to get completely hung up on the use of a
> dir= RDN qualifier vs. a more explicit URL-type qualifier, I'm don't
> think I agree with your concern about the paradigm shift in the
> DN semantics a dir= type of qualifier would cause. Maybe I just
> don't understand.
>
> I am inclined to say that "DN semantics" is close to being an oxymoron.
> The fact is that the semantic definitions of most of the usual DN
> attributes are conspicuously vague. Consider "serial", "locality", commonName,
> or even "country". Yes, we all understand what a country is -- it's
> whatever the UN says it is, or isn't, and questions about disputed territories
> are brushed aside. But that isn't a semantic definition, that is simply a name to
> territory definition or mapping. The real question is what is the relationship
> between the country and the end-entity identified by the rest of the DN --
> is it merely a directory qualifier, or is it the country of residence?, citizenship?
> place of doing business? location of the home office? country of
> incorporation of an enterprise? If I am referring to a ship, for example, that
> is owned an operated by a UK company, registered in Liberia ,and
> is currently docked in Miami, what country should I use for the RDN
> of that ship?
>
> Since X.500 doesn't attempt to answer that question, I would claim that
> the only effective semantics for country is as a directory qualifier, under the
> old universal X.500 directory-in-the-sky assumption of a monopoly directory
> service, or at least a monopoly naming infrastructure per country.
>
> Since we know by now that the original assumption is no longer valid,
> if indeed it ever was, we can certainly use country to mean whatever
> we choose it to mean in terms of semantics, just as people have
> distorted the semantics of organization, and particularly
> organizationalUnit, to contain just about anything they want.
>
> (I'm not really suggesting an RDN containing a MPEG of my cat, but
> things that are nearly as strange have been done in the past.
> That doesn't make them "right", of course, just ubiquitous.)
>
> But what that leaves us with is the need to qualify what used to be a root,
> i.e., country, and to supply a new root, meaning basically who owns,
> operates, and defines the semantics and schema for all of the rest of t
> he RDNs which follow.
>
> I would submit that despite the semantic "recommendations" provided by
> the standards organizations, it is really the directory service provider who
> defines such things, or in some cases the Certificate Authority who creates a
> certificate, whether or not they actual deposit that certificate in an X.500
> directory
>
> >From this point of view, I believe that using a dir= type of directory service
> provider is not some kind of an ugly hack, but a reflection of reality, and a
> completely legitimate RDN qualifier. It specifies in a consistent DN syntax
> what the root of the DIT really is -- the name of the directory that contains
> and defines it.
>
> Now I'll grant that it isn't very likely that existing X.500 directories would
> suddenly change their DIT structure to explicitly include a dir= component
> at the Top. But I don't think that would be at all necessary, either -- it can be
> done implicitly.
>
> I wouldn't think it would be all that hard to define the attribute matching
> rules so that if the dir attribute (or one of the multi-=valued RDN components)
> is the DNS address of the directory that is being accessed, the result is
> TRUE, and otherwise FALSE.
>
> Another approach which might or might not work would be to use an alias,
> although I don't know whether it is possible to define an alias for a node,
> rather than for a leaf.
>
> For example, in Novell's own DIT, we don't even define c=US as the top
> component, although perhaps we "should".
>
> But I would assume/hope that if we were concerned about that, we could
> define an alias of c=us, o=Novell Inc. to point to the o=Novell node that is
> actually at the top of our DIT.
>
> Since you said that you actually considered this type of an approach
> at one time, perhaps you can say more about what led you away from
> that approach. I think you were right the first time.
>
> Regards,
>
> Bob
>
> >>> "Slone, Skip" 01/16/01 01:45PM >>>
> John,
>
> You wrote, "I don't think the proposed "dir" attribute is semantically very
> different
> from any other naming attributes" and that "the mechanism for searching has
> to treat the "dir" RDN somewhat differently from the other RDNs."
>
> My concern with different semantics is not a matter of degree; it's the fact
> that the semantics of DN must change -- at all -- to incorporate this
> concept. If there are other ways to deal with the problem, I see no
> compelling reason to change the semantics of something so fundamentally and
> deeply entrenched in dozens of standards as DN.
>
> I must add here that I have not always opposed this concept. I actually
> pursued this line of thinking two or three years ago in a different forum
> (X.500) while working a different problem (Related Entries). At that time, I
> was proposing that a "dnQualifer" be added to a DN to specify an access
> point through which the entry named by the DN could be found. While pursuing
> that line of thinking (which explored several syntactic/semantic variants),
> the semantic-shift problem kept getting in the way. In the end, we settled
> on a separate mechanism rather than change the semantics of DN. Flawed as it
> may be, DN is still a widely accepted concept; changing it will be an uphill
> struggle.
>
> -- Skip
>
> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: Tuesday, January 16, 2001 10:52 AM
> To: Slone, Skip
> Cc: 'Bob Jueneman'; [email-masked]
> Subject: RE: Basic Cert-2-Directory mapping question
>
>
>
> >As I read your suggestion, you want to add an element to the DN
> >that directs the user to the appropriate directory. The new
> >element is syntactically an RDN, but semantically is something
> >different. The resulting new-style DN appears to me to
> >semantically comparable to an LDAP URL.
>
>
> I don't think the proposed "dir" attribute is semantically very different
> from any other naming attributes. What we're trying to do with names in
> certificates is to maintain the X.500 illusion that a DN uniquely
> identifies an entry in some global directory. But we don't have a single
> global directory; instead we have a collection of directories which don't
> talk to one another - i.e. instead of the single DN root assumed by X.500,
> we actually have multiple roots, one for each directory.
>
> The obvious way to resolve this sort of problem is to introduce a new
> "meta-root" that sits above all the directory roots. This corresponds to
> adding an RDN to the most significant end of each DN that names the
> particular directory within which the named entry lies. Precisely how a
> directory is named is TBD, but it must give an end-system enough
> information to for a query for that directory, without requiring prior
> knowledge of the directory, so an obvious possibility (for an LDAP
> directory) is scheme and hostport portions of an LDAP URL.
>
> Individual directories could either store this attribute explicitly within
> the entry (which would mean that these directories could be directly
> searched using the full DN) or, more likely, the "dir" attribute would have
> to be removed before searching an individual directory. So yes, the
> mechanism for searching has to treat the "dir" RDN somewhat differently
> from the other RDNs, but in terms of a naming model, it behaves just like
> any other RDN.
>
> As Bob points out, the "dir" attribute could be multi-valued, allowing
> information about an entry to reside in multiple directories (provided that
> the directories can all agree to use the same name for the entry).
>
> John
>
>
>
>
>
>
>
>
> "Slone, Skip" on 01/16/2001 09:16:13 AM
>
> To: "'Bob Jueneman'"
> cc: [email-masked]
> Subject: RE: Basic Cert-2-Directory mapping question
>
>
> Bob,
>
> I'm glad to hear we agree on the nature of the problem. From that point of
> agreement, we can move the discussion to one of "what do we do about it?"
>
> In abstract terms, it appears to me that "what we can do about it" falls
> into two broad categories:
> 1) we can create a mechanism for explicitly identifying the appropriate
> directory, or
> 2) we can remove the barriers that currently prevent the directory from
> being discovered implicitly based upon existing information
>
> I would say that your approach fits in category 1, while my approach fits
> in
> category 2. Either approach has validity IMHO and is worthy of
> consideration.
>
> As I read your suggestion, you want to add an element to the DN that
> directs
> the user to the appropriate directory. The new element is syntactically an
> RDN, but semantically is something different. The resulting new-style DN
> appears to me to semantically comparable to an LDAP URL.
>
> Assuming we're on the same page up to this point, I'll say that my concern
> with this approach is that it changes the semantics of DN, potentially
> causing interoperability problems in that both clients and servers that
> understand the semantics as currently defined would have problems when
> encountering the new-style name. If we were to go with a "category 1" fix
> to the problem, I would rather see a new mechanism employed, such as a new
> PKIX-defined certificate extension that explicitly gives repository
> location
> information. As a new construct, we would be free to define whatever
> semantics we want, and could readily use existing concepts such as URLs.
>
> Now, in defense of my approach, I think we can all probably agree that *IF*
> the original concept of X.500-style distributed, global name resolution
> were
> a practical reality, we would be able to plug into the nearest DSA and find
> the named entry regardless of where it resides physically. Of course I
> emphasized the word "if" to imply that we can also probably agree that that
> original X.500 concept is not going to occur anytime soon, if ever. What I
> was proposing instead, was a "category 2" fix -- a way of removing that
> barrier by providing an alternative way of doing distributed name
> resolution. The alternative mechanism I proposed was one which builds upon
> an existing, working, global infrastructure that already has the requisite
> registration infrastructure in place. Without digging into the specifics,
> I
> would like to know if you or others believe that this *concept* has merit.
>
> -- Skip
>
>
> -----Original Message-----
> From: Bob Jueneman [mailto:[email-masked]]
> Sent: Monday, January 15, 2001 2:11 PM
> To: [email-masked]
> Cc: [email-masked]
> Subject: RE: Basic Cert-2-Directory mapping question
>
>
> Skip,
>
> I don't particularly like the mechanism you've proposed, at least as
> I understand it. But I absolutely and completely agree with you
> as to the nature of the problem that has to be solved.
>
> Civil attribute type names will always be with us, and hence must be
> dealt with, for at least two fundamental reasons:
>
> 1. An address is not a name, although it may be a pseudonym. I
> don't want to be forced to change my identity, or to an extent
> my basis "self-hood," every time I change my ISP. And I especially
> don't want some system administrator telling me that my name
> must be limited to 8 characters, or that I have to change my name
> because someone else has already used that same name within
> that same system administrator's ill-conceived naming scheme.
>
> 2. E-mail address and other cyberspace identifiers fail to provide the
> essence of PKI from a nonrepudiation standpoint, i.e., what I call the
> "where do you send the sheriff" question.
>
> Granted, not all uses of PKI will or should involve legal nonrepudiation.
> But to the extent that at least some uses WILL have legal consequences,
> then the establishment of a globally unique and credible identity that is
> grounded in "meat-space" rather then cyberspace is absolutely essential.
>
> For those legally binding transaction to be worth anything at all, they
> have to be enforceable. And that means that a judgement may have
> to be enforced upon someone, either by seizing the assets or putting
> them in jail. And only in science fiction does the sheriff ride off into
> cyberspace to arrest someone.
>
> If I as a relying party wish to trade with someone, then I either want to
> charge her credit card (in which case PKI is demonstrably not necessary)
> or I want to know that she is the Mary Smith who resides at 123 Anywhere
> St,
> Metropolis, NY.
>
> The inclusion of that civil address not only servers to distinguish her
> from the other Mary Smiths, but more importantly it establishes a nexus
> or link between her identity and her probable whereabouts, and
> probably valuable real property as well.
>
> So civil addresses, both corporate or "organizationalPerson", or the
> harder-to-deal-with residentialPerson type will presumably always
> be with us, and will have to be dealt with.
>
> And unfortunately, perhaps, here int he US the simple and inescapable
> fact of the matter is that neither the federal nor the state governments
> operate the type of presumptively authoritative name registration
> authorities that are relatively common in other countries. I am perfectly
> free to move from one city to another, or from address to another in
> the same city, and to never notify anyone in authority at all, including
> the tax authorities. No one will ever say, "Papers, please."
>
> (Granted, if I choose to do that I may not be able to register to vote,
> but over half the population doesn't vote anyway. And the last time
> I registered, no one checked to see that I actually lived there -- that
> one of the problems we have with our voting system, even outside
> of the State of Florida.. And I may not be able to get a driver's license
> in order to legally drive a car, but a lot of illegal immigrants don't have
> driver's licenses either, although that doesn't keep them from driving.)
>
> So merely trying to ignore the problem of civil addressing schemes
> won't solve that problem. And neither will various approaches that
> make certain assumptions about monopoly name registration
> authorities, or try to divine or impute where a directory containing
> a particular name might be found based on some kind of a Karnak
> mentalist act.
>
> The primary issue is not the question of whether the name space
> is flat or hierarchical, or how hierarchical, much less what the
> "approved" schema is. What will be, will be, for reasons that
> are beyond our scope and power to influence, even if we wanted
> to.
>
> So.
>
> We cannot force a person to deposit his certificate or other useful
> information into a specific directory, even if we wanted to. Nor can
> we reliably impute a likely directory where such information might
> be found, at least in the absence of a monopoly or governmental
> mandate.
>
> The best we can do is to ASK the user where he has deposited
> such information, if anywhere, and to include that information
> EXPLICITLY in any directory or pseudo-directory reference, such
> as a DN.
>
> Although at one time I liked the notion of prefixing the DN with a
> URL, I have come to believe that John Wray's suggestion is the
> better way forward.
>
> He said:
> >
> >Bob,
> >
> >Accepting the fact that the X.500 dream of a single global directory is
> not
> >going to happen any time soon, DNs can still be turned into globally
> >significant pointers into a federation of directories in the way you
> >suggest, but it doesn't require altering the DN syntax (and therefore
> >doesn't have to break existing implementations). All that's needed is a
> DN
> >attribute that names the particular directory within which the name
> >resides. e.g. instead of "c=us;..;cn=My Name" you'd have "dir=My
> >Directory;c=us;...;cn=My Name", where "My Directory" is the URL of a
> >directory access point.
>
> By including an explicit directory qualifier of the form dir="directory
> URL"
> at the root (top) of the RDN chain, we have implicitly qualified all of the
> rest
> of the RDN, which is a Good Thing.
>
> By defining the syntax of the "dir" attribute appropriately, we could
> include
> both the access type (LDAP, http, etc.) and port number appropriately,
> either a default or explicitly indicated.
>
> And by making the dir component multivalued, we could accommodate
> a choice of multiple directories and multiple directory types.
>
> Once again -- the essence of the problem is not the format of the directory
> name but where a directory containing that name can be found.
> Including that information as a top-level qualifying component solves that
> problem (and potentially several others, such as name scope qualification)
> very neatly.
>
> Bob
>
> Robert R. Jueneman
> 'Security Architect
> Novell, Inc. -- the leading provider of Net services software
> >
> >
> >
> >
> >
> >
> >
> >>>> "Slone, Skip" 01/15/01 09:08AM >>>
> >Oscar,
> >
> >No offense taken, thus no apology needed.
> >
> >My comments from the soapbox last week were actually intended for the
> >community at large, and were meant to convey frustration at the apparent
> >unwillingness of solution providers in general to hear about -- and solve
> --
> >real world problems that are faced by users like myself in large, complex
> >environments.
> >
> >When I say "my environment is not so simple," the response I hear is
> "let's
> >not talk about the complexity; let's make some simplifying assumptions
> >instead."
> >
> >When I say "I have a nail AND a screw and need to put them both in the
> >wall," the response I hear is "we have provided you with a perfectly
> >adequate hammer, therefore you don't have a screw."
> >
> >As I was using the nail/hammer analogy, dc-based names are the nails;
> >civil-attribute-based names are the screws. No matter how good a job my
> >company does of using nails and nails alone, we still have tens of
> thousands
> >of trading partners, many of whom prefer screws to nails and will continue
> >to use them indefinitely. Without a screwdriver, it's hard to do business
> >with them.
> >
> >I don't really care what the screwdriver looks like. I've suggested a
> >fairly simple design that I think will work. So far, no one has commented
> on
> >the design. What I've heard instead is a chorus of "we still don't like
> >screws." Well, I don't like them either, but I still have to deal with
> >them. If I'm simply overlooking a screwdriver that we have lying around
> >somewhere, I would appreciate someone pointing it out to me.
> >
> > -- Skip
> >
> >
> >-----Original Message-----
> >From: Oscar Jacobsson [mailto:[email-masked]]
> >Sent: Thursday, January 11, 2001 5:16 PM
> >To: Slone, Skip
> >Cc: 'Sharon Boeyen'; [email-masked]
> >Subject: RE: Basic Cert-2-Directory mapping question
> >
> >
> >> From: Slone, Skip [mailto:[email-masked]]
> >> In response to this, I'm inclined to join Sharon on Marshall's soapbox
> and
> >> echo her words:
> >>
> >> "... I believe a more constructive approach is to accept the fact that
> >> different parts of the world and different environments will use a
> variety
> >> of nameforms ... We are not the global naming police either and should
> not
> >> try to impose the rules that anyone uses to name entities to which they
> >> issue certificates."
> >
> >I'm sorry if I came across as clamouring for rules be imposed. I know that
> >this working group has a tendency to be wary of suggestions that don't
> cater
> >for distinguished names containing cat MPEGs, so I should probably have
> been
> >more careful. The requirements I suggested were for a possible naming
> >standards document, conformance to which need not be enforced.
> >
> >The case at hand is not, IMHO, one of dictating that "all distinguished
> >names must be according to our will, or you shall feel our wrath". A
> >document however, outlining a naming strategy that would require of the
> >users of certificates named accordingly no a-priori knowledge of their
> >issuer (save for eventually having to reach something explicitly trusted
> in
> >the chain) in order to perform path validation, is something I would
> >personally consider very valuable indeed. I'm reasonably confident that
> >organizations intending to act as certification authorities or trusted
> third
> >parties would agree.
> >
> >> And to quote someone Sharon and I both know, "If all you have is a
> hammer,
> >> every problem looks like a nail."
> >
> >It seems I was less than clear here as well. :-(
> >
> >My intention was to point out that there are actually two separate
> problems
> >here (one nail, if you will, and one screw) each looking for its own
> >solution:
> >
> >1. Defining a repository, and subsequently entry, discovery process for
> >arbitrarily named entries.
> >
> >2. Defining a naming scheme that _if applied_ would automate this
> repository
> >and entry discovery process.
> >
> >I am only trying to address the second of these problems. The first is
> only
> >an issue because nobody seems to have properly addressed the second before
> >deploying certificates on the Internet en masse. The further we wait
> before
> >addressing number two, the more of a problem number one will become.
> >
> >I should probably make a habit of pointing out that the opinions stated
> here
> >are my very own, and not necessarily those of my employer.
> >
> >Cheers,
> >
> >//oscar
>
>
>

-------------------------------------------------------------------
Polar Humenn Adiron, LLC
mailto:[email-masked] 2-212 CST
Phone: 315-443-3171 Syracuse, NY 13244-4100
Fax: 315-443-4745 http://www.adiron.com

Received: from eagle.verisign.com (eagle.verisign.com [208.206.241.105]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA09091 for ; Wed, 17 Jan 2001 07:18:21 -0800 (PST)
Received: from postal-gw2.verisign.com (verisign.com [63.104.27.102]) by eagle.verisign.com (8.9.3/BCH1.7.1) with ESMTP id HAA01398; Wed, 17 Jan 2001 07:25:29 -0800 (PST)
Received: by postal-gw.verisign.com with Internet Mail Service (5.5.2650.21) id ; Wed, 17 Jan 2001 07:23:38 -0800
Message-ID: <[email-masked]>
From: Philip Hallam-Baker
To: "'Steve Hanna'" , Stephen Kent
Cc: PKIX List
Subject: RE: Need to support non-ASN.1 DPV clients?
Date: Wed, 17 Jan 2001 07:23:36 -0800
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"

There are two questions, should such clients be supported? should they be
supported by PKIX?

I assert that the answer to the first question is yes, the latter no. We
have not submitted XKMS to the PKIX list because (amongst other reasons) the
group have 20 odd drafts to clear from the pipeline as it is.

Furthermore, last time someone submitted a non-ASN.1 spec to the list
someone assumed it must have been a mistake and took the time and trouble to
'correct' it for them.

There is a lot more to XML than a syntax. Simply converting ASN.1 to XML
does not meet the needs of the XML space. Without XML experts you can't
write a spec to meet their needs.

Phill

> -----Original Message-----
> From: Steve Hanna [mailto:[email-masked]]
> Sent: Wednesday, January 17, 2001 9:40 AM
> To: Stephen Kent
> Cc: PKIX List
> Subject: Need to support non-ASN.1 DPV clients?
>
>
> Stephen Kent wrote:
> > It sounds like we need to decide whether non-PKI aware,
> > non-ASN.1-capable clients need to be supported. If so,
> we should
> > probably define a set of requirements for such clients
> and include this
> > item in that list. I would suggest that such clients
> are an important
> > group and should be supported.
> >
> > I put this question to the list in my strawman spec over 2
> weeks ago,
> > and have not yet gotten a concrete proposal on how to
> accommodate such
> > clients. I will soon decide that we will NOT support them for now,
> > unless I see such a proposal.
>
> Yes, that question is highlighted in your requirements
> document. As you
> point out there, it is important to resolve this question promptly in
> order to decide on DPV and DPD requirements. But, as you
> pointed out in
> yesterday's email, the question has not been discussed on this mailing
> list in a substantial manner since your requirements document was
> published. Therefore, I'd like to start a thread specifically
> addressed
> to this question:
>
> Do we need to support non-PKI aware, non-ASN.1-capable DPV clients?
>
> Let's settle this now. If you believe that such support is
> necessary and
> should be included in this effort or if you believe that it
> should not,
> please speak up now and explain why or why not.
>
> As for a "concrete proposal", I doubt that it will be hard to come up
> with a proposal if we decide that support for non-ASN.1-capable DPV
> clients is needed.
>
> -Steve
>
> P.S. I will set aside the more specific points we were discussing
> regarding non-ASN.1-capable clients until this more basic question is
> resolved.
>

Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA07431 for ; Wed, 17 Jan 2001 06:37:02 -0800 (PST)
Received: from eastmail1.East.Sun.COM ([129.148.1.240]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id GAA10695; Wed, 17 Jan 2001 06:42:35 -0800 (PST)
Received: from sunlabs.East.Sun.COM (sunlabs.East.Sun.COM [129.148.75.250]) by eastmail1.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id JAA18687; Wed, 17 Jan 2001 09:42:34 -0500 (EST)
Received: from sun.com (dhcp75-155 [129.148.75.155]) by sunlabs.East.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA15897; Wed, 17 Jan 2001 09:42:34 -0500 (EST)
Message-ID: <[email-masked]>
Date: Wed, 17 Jan 2001 09:39:38 -0500
From: Steve Hanna
Organization: Sun Microsystems, Inc.
X-Mailer: Mozilla 4.75 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Stephen Kent
CC: PKIX List
Subject: Need to support non-ASN.1 DPV clients?
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Stephen Kent wrote:
> It sounds like we need to decide whether non-PKI aware,
> non-ASN.1-capable clients need to be supported. If so, we should
> probably define a set of requirements for such clients and include this
> item in that list. I would suggest that such clients are an important
> group and should be supported.
>
> I put this question to the list in my strawman spec over 2 weeks ago,
> and have not yet gotten a concrete proposal on how to accommodate such
> clients. I will soon decide that we will NOT support them for now,
> unless I see such a proposal.

Yes, that question is highlighted in your requirements document. As you
point out there, it is important to resolve this question promptly in
order to decide on DPV and DPD requirements. But, as you pointed out in
yesterday's email, the question has not been discussed on this mailing
list in a substantial manner since your requirements document was
published. Therefore, I'd like to start a thread specifically addressed
to this question:

Do we need to support non-PKI aware, non-ASN.1-capable DPV clients?

Let's settle this now. If you believe that such support is necessary and
should be included in this effort or if you believe that it should not,
please speak up now and explain why or why not.

As for a "concrete proposal", I doubt that it will be hard to come up
with a proposal if we decide that support for non-ASN.1-capable DPV
clients is needed.

-Steve

P.S. I will set aside the more specific points we were discussing
regarding non-ASN.1-capable clients until this more basic question is
resolved.

Received: from prv-mail20.provo.novell.com (prv-mail20.provo.novell.com [137.65.81.122]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id GAA07108 for ; Wed, 17 Jan 2001 06:29:36 -0800 (PST)
Received: from INET-PRV-Message_Server by prv-mail20.provo.novell.com with Novell_GroupWise; Wed, 17 Jan 2001 07:34:42 -0700
Message-Id:
X-Mailer: Novell GroupWise Internet Agent 5.5.5.1
Date: Wed, 17 Jan 2001 07:34:39 -0700
From: "Bob Jueneman"
To: , ,
Cc:
Subject: RE: Basic Cert-2-Directory mapping question
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id GAA07109

Ron,

I don't think we are on the same page.

I don't conceive of the dir= attribute as constituting a non-DIT RDN.
Instead, I am suggesting that we should add the dir= attribute as a full
RDN component at the top of the existing DIT.

I believe that it really belongs there, to qualify the lower level entries
as belonging to that particular directory, just as is the case with "normal"
DN qualification.. So yes, I believe that you ought to be able to see
that entry when browsing the directory, not withstanding the act that
it would normally be static.

The alternative, using an LDAP-style qualifier to precede the DN, is
what strikes me as being abhorrent.

If I have a DN that includes at the top of the DIT the name of the
directory root itself, then that DN can be handled by all applications
that know how to parse DNs generally. Otherwise, we are left with
protocol-specific hacks, like URLs with trailing DNs.

Bob

>>> "Ramsay, Ron" 01/16/01 08:09PM >>>
Bob,

While it may be true that 'c=us' does not try to say something about
countries, I don't believe this is relevant. The importance of this RDN in
the DN is that, notionally, there is an entry with the DN 'c=us'. When
browsing an X.500 DIT, you should be able to see all the superior entries as
indicated bu the RDNs in the entry DN. This is the semantic meaning of the
DN, not 'what does country mean in this DN'. To this extent, the idea of
adding a non-DIT RDN to the DN is abhorrent and will create real problems.
(LDAP directories generally aren't browsable so I guess my remarks don't
apply to them.)

Ron.

-----Original Message-----
From: Bob Jueneman [mailto:[email-masked]]
Sent: Wednesday, 17 January 2001 13:35
To: [email-masked]; [email-masked]
Cc: [email-masked]
Subject: RE: Basic Cert-2-Directory mapping question

Skip,

Just so it's clear, I probably should have defined at least one use
model for what we have been talking about -- at least the use
that I have in mind.

what I'm trying to get away from this the necessity of wasting all
of the bandwidth that is currently being used to repetitively
download entire certificate chains containing the same information,
over and over again to the same client. This is particularly the
case in SSL/TLS and S/MIME, and I predict that when we start
sending signed EDI transactions it will be the case there as well.

What I want to do to minimize all of this is to send only two things
with a given transaction -- the digital signature itself, stripped down
as far as possible; and the name of the signer, in a minimal form
as possible without imposing a rigid repository schema.

ideally, the name of the signer should be a DN, whether in the form
of a classical civil name structure, and DNS name, or some other form
that is searchable, such as a DUNS number.

Ideally, the structure of the DN should be compatible with existing
RDN syntax, but perhaps with the addition of a new attribute type.
I think that we are agreed that SOMETHING new is going to be
required, and if that is the case a new attribute that is consistent with
the
current RDN syntactic structure would to my mind be preferable to
introducing something else, such as a URL or URI.

Although I don't want to get completely hung up on the use of a
dir= RDN qualifier vs. a more explicit URL-type qualifier, I'm don't
think I agree with your concern about the paradigm shift in the
DN semantics a dir= type of qualifier would cause. Maybe I just
don't understand.

I am inclined to say that "DN semantics" is close to being an oxymoron.
The fact is that the semantic definitions of most of the usual DN
attributes are conspicuously vague. Consider "serial", "locality",
commonName,
or even "country". Yes, we all understand what a country is -- it's
whatever the UN says it is, or isn't, and questions about disputed
territories
are brushed aside. But that isn't a semantic definition, that is simply a
name to
territory definition or mapping. The real question is what is the
relationship
between the country and the end-entity identified by the rest of the DN --
is it merely a directory qualifier, or is it the country of residence?,
citizenship?
place of doing business? location of the home office? country of
incorporation of an enterprise? If I am referring to a ship, for example,
that
is owned an operated by a UK company, registered in Liberia ,and
is currently docked in Miami, what country should I use for the RDN
of that ship?

Since X.500 doesn't attempt to answer that question, I would claim that
the only effective semantics for country is as a directory qualifier, under
the
old universal X.500 directory-in-the-sky assumption of a monopoly directory
service, or at least a monopoly naming infrastructure per country.

Since we know by now that the original assumption is no longer valid,
if indeed it ever was, we can certainly use country to mean whatever
we choose it to mean in terms of semantics, just as people have
distorted the semantics of organization, and particularly
organizationalUnit, to contain just about anything they want.

(I'm not really suggesting an RDN containing a MPEG of my cat, but
things that are nearly as strange have been done in the past.
That doesn't make them "right", of course, just ubiquitous.)

But what that leaves us with is the need to qualify what used to be a root,
i.e., country, and to supply a new root, meaning basically who owns,
operates, and defines the semantics and schema for all of the rest of t
he RDNs which follow.

I would submit that despite the semantic "recommendations" provided by
the standards organizations, it is really the directory service provider who

defines such things, or in some cases the Certificate Authority who creates
a
certificate, whether or not they actual deposit that certificate in an X.500

directory

>From this point of view, I believe that using a dir= type of directory
service
provider is not some kind of an ugly hack, but a reflection of reality, and
a
completely legitimate RDN qualifier. It specifies in a consistent DN syntax
what the root of the DIT really is -- the name of the directory that
contains
and defines it.

Now I'll grant that it isn't very likely that existing X.500 directories
would
suddenly change their DIT structure to explicitly include a dir= component
at the Top. But I don't think that would be at all necessary, either -- it
can be
done implicitly.

I wouldn't think it would be all that hard to define the attribute matching
rules so that if the dir attribute (or one of the multi-=valued RDN
components)
is the DNS address of the directory that is being accessed, the result is
TRUE, and otherwise FALSE.

Another approach which might or might not work would be to use an alias,
although I don't know whether it is possible to define an alias for a node,
rather than for a leaf.

For example, in Novell's own DIT, we don't even define c=US as the top
component, although perhaps we "should".

But I would assume/hope that if we were concerned about that, we could
define an alias of c=us, o=Novell Inc. to point to the o=Novell node that is

actually at the top of our DIT.

Since you said that you actually considered this type of an approach
at one time, perhaps you can say more about what led you away from
that approach. I think you were right the first time.

Regards,

Bob

>>> "Slone, Skip" 01/16/01 01:45PM >>>
John,

You wrote, "I don't think the proposed "dir" attribute is semantically very
different
from any other naming attributes" and that "the mechanism for searching has
to treat the "dir" RDN somewhat differently from the other RDNs."

My concern with different semantics is not a matter of degree; it's the fact
that the semantics of DN must change -- at all -- to incorporate this
concept. If there are other ways to deal with the problem, I see no
compelling reason to change the semantics of something so fundamentally and
deeply entrenched in dozens of standards as DN.

I must add here that I have not always opposed this concept. I actually
pursued this line of thinking two or three years ago in a different forum
(X.500) while working a different problem (Related Entries). At that time, I
was proposing that a "dnQualifer" be added to a DN to specify an access
point through which the entry named by the DN could be found. While pursuing
that line of thinking (which explored several syntactic/semantic variants),
the semantic-shift problem kept getting in the way. In the end, we settled
on a separate mechanism rather than change the semantics of DN. Flawed as it
may be, DN is still a widely accepted concept; changing it will be an uphill
struggle.

-- Skip

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Tuesday, January 16, 2001 10:52 AM
To: Slone, Skip
Cc: 'Bob Jueneman'; [email-masked]
Subject: RE: Basic Cert-2-Directory mapping question

>As I read your suggestion, you want to add an element to the DN
>that directs the user to the appropriate directory. The new
>element is syntactically an RDN, but semantically is something
>different. The resulting new-style DN appears to me to
>semantically comparable to an LDAP URL.

I don't think the proposed "dir" attribute is semantically very different
from any other naming attributes. What we're trying to do with names in
certificates is to maintain the X.500 illusion that a DN uniquely
identifies an entry in some global directory. But we don't have a single
global directory; instead we have a collection of directories which don't
talk to one another - i.e. instead of the single DN root assumed by X.500,
we actually have multiple roots, one for each directory.

The obvious way to resolve this sort of problem is to introduce a new
"meta-root" that sits above all the directory roots. This corresponds to
adding an RDN to the most significant end of each DN that names the
particular directory within which the named entry lies. Precisely how a
directory is named is TBD, but it must give an end-system enough
information to for a query for that directory, without requiring prior
knowledge of the directory, so an obvious possibility (for an LDAP
directory) is scheme and hostport portions of an LDAP URL.

Individual directories could either store this attribute explicitly within
the entry (which would mean that these directories could be directly
searched using the full DN) or, more likely, the "dir" attribute would have
to be removed before searching an individual directory. So yes, the
mechanism for searching has to treat the "dir" RDN somewhat differently
from the other RDNs, but in terms of a naming model, it behaves just like
any other RDN.

As Bob points out, the "dir" attribute could be multi-valued, allowing
information about an entry to reside in multiple directories (provided that
the directories can all agree to use the same name for the entry).

John

"Slone, Skip" on 01/16/2001 09:16:13 AM

To: "'Bob Jueneman'"
cc: [email-masked]
Subject: RE: Basic Cert-2-Directory mapping question

Bob,

I'm glad to hear we agree on the nature of the problem. From that point of
agreement, we can move the discussion to one of "what do we do about it?"

In abstract terms, it appears to me that "what we can do about it" falls
into two broad categories:
1) we can create a mechanism for explicitly identifying the appropriate
directory, or
2) we can remove the barriers that currently prevent the directory from
being discovered implicitly based upon existing information

I would say that your approach fits in category 1, while my approach fits
in
category 2. Either approach has validity IMHO and is worthy of
consideration.

As I read your suggestion, you want to add an element to the DN that
directs
the user to the appropriate directory. The new element is syntactically an
RDN, but semantically is something different. The resulting new-style DN
appears to me to semantically comparable to an LDAP URL.

Assuming we're on the same page up to this point, I'll say that my concern
with this approach is that it changes the semantics of DN, potentially
causing interoperability problems in that both clients and servers that
understand the semantics as currently defined would have problems when
encountering the new-style name. If we were to go with a "category 1" fix
to the problem, I would rather see a new mechanism employed, such as a new
PKIX-defined certificate extension that explicitly gives repository
location
information. As a new construct, we would be free to define whatever
semantics we want, and could readily use existing concepts such as URLs.

Now, in defense of my approach, I think we can all probably agree that *IF*
the original concept of X.500-style distributed, global name resolution
were
a practical reality, we would be able to plug into the nearest DSA and find
the named entry regardless of where it resides physically. Of course I
emphasized the word "if" to imply that we can also probably agree that that
original X.500 concept is not going to occur anytime soon, if ever. What I
was proposing instead, was a "category 2" fix -- a way of removing that
barrier by providing an alternative way of doing distributed name
resolution. The alternative mechanism I proposed was one which builds upon
an existing, working, global infrastructure that already has the requisite
registration infrastructure in place. Without digging into the specifics,
I
would like to know if you or others believe that this *concept* has merit.

-- Skip

-----Original Message-----
From: Bob Jueneman [mailto:[email-masked]]
Sent: Monday, January 15, 2001 2:11 PM
To: [email-masked]
Cc: [email-masked]
Subject: RE: Basic Cert-2-Directory mapping question

Skip,

I don't particularly like the mechanism you've proposed, at least as
I understand it. But I absolutely and completely agree with you
as to the nature of the problem that has to be solved.

Civil attribute type names will always be with us, and hence must be
dealt with, for at least two fundamental reasons:

1. An address is not a name, although it may be a pseudonym. I
don't want to be forced to change my identity, or to an extent
my basis "self-hood," every time I change my ISP. And I especially
don't want some system administrator telling me that my name
must be limited to 8 characters, or that I have to change my name
because someone else has already used that same name within
that same system administrator's ill-conceived naming scheme.

2. E-mail address and other cyberspace identifiers fail to provide the
essence of PKI from a nonrepudiation standpoint, i.e., what I call the
"where do you send the sheriff" question.

Granted, not all uses of PKI will or should involve legal nonrepudiation.
But to the extent that at least some uses WILL have legal consequences,
then the establishment of a globally unique and credible identity that is
grounded in "meat-space" rather then cyberspace is absolutely essential.

For those legally binding transaction to be worth anything at all, they
have to be enforceable. And that means that a judgement may have
to be enforced upon someone, either by seizing the assets or putting
them in jail. And only in science fiction does the sheriff ride off into
cyberspace to arrest someone.

If I as a relying party wish to trade with someone, then I either want to
charge her credit card (in which case PKI is demonstrably not necessary)
or I want to know that she is the Mary Smith who resides at 123 Anywhere
St,
Metropolis, NY.

The inclusion of that civil address not only servers to distinguish her
from the other Mary Smiths, but more importantly it establishes a nexus
or link between her identity and her probable whereabouts, and
probably valuable real property as well.

So civil addresses, both corporate or "organizationalPerson", or the
harder-to-deal-with residentialPerson type will presumably always
be with us, and will have to be dealt with.

And unfortunately, perhaps, here int he US the simple and inescapable
fact of the matter is that neither the federal nor the state governments
operate the type of presumptively authoritative name registration
authorities that are relatively common in other countries. I am perfectly
free to move from one city to another, or from address to another in
the same city, and to never notify anyone in authority at all, including
the tax authorities. No one will ever say, "Papers, please."

(Granted, if I choose to do that I may not be able to register to vote,
but over half the population doesn't vote anyway. And the last time
I registered, no one checked to see that I actually lived there -- that
one of the problems we have with our voting system, even outside
of the State of Florida.. And I may not be able to get a driver's license
in order to legally drive a car, but a lot of illegal immigrants don't have
driver's licenses either, although that doesn't keep them from driving.)

So merely trying to ignore the problem of civil addressing schemes
won't solve that problem. And neither will various approaches that
make certain assumptions about monopoly name registration
authorities, or try to divine or impute where a directory containing
a particular name might be found based on some kind of a Karnak
mentalist act.

The primary issue is not the question of whether the name space
is flat or hierarchical, or how hierarchical, much less what the
"approved" schema is. What will be, will be, for reasons that
are beyond our scope and power to influence, even if we wanted
to.

So.

We cannot force a person to deposit his certificate or other useful
information into a specific directory, even if we wanted to. Nor can
we reliably impute a likely directory where such information might
be found, at least in the absence of a monopoly or governmental
mandate.

The best we can do is to ASK the user where he has deposited
such information, if anywhere, and to include that information
EXPLICITLY in any directory or pseudo-directory reference, such
as a DN.

Although at one time I liked the notion of prefixing the DN with a
URL, I have come to believe that John Wray's suggestion is the
better way forward.

He said:
>
>Bob,
>
>Accepting the fact that the X.500 dream of a single global directory is
not
>going to happen any time soon, DNs can still be turned into globally
>significant pointers into a federation of directories in the way you
>suggest, but it doesn't require altering the DN syntax (and therefore
>doesn't have to break existing implementations). All that's needed is a
DN
>attribute that names the particular directory within which the name
>resides. e.g. instead of "c=us;..;cn=My Name" you'd have "dir=My
>Directory;c=us;...;cn=My Name", where "My Directory" is the URL of a
>directory access point.

By including an explicit directory qualifier of the form dir="directory
URL"
at the root (top) of the RDN chain, we have implicitly qualified all of the
rest
of the RDN, which is a Good Thing.

By defining the syntax of the "dir" attribute appropriately, we could
include
both the access type (LDAP, http, etc.) and port number appropriately,
either a default or explicitly indicated.

And by making the dir component multivalued, we could accommodate
a choice of multiple directories and multiple directory types.

Once again -- the essence of the problem is not the format of the directory
name but where a directory containing that name can be found.
Including that information as a top-level qualifying component solves that
problem (and potentially several others, such as name scope qualification)
very neatly.

Bob

Robert R. Jueneman
'Security Architect
Novell, Inc. -- the leading provider of Net services software
>
>
>
>
>
>
>
>>>> "Slone, Skip" 01/15/01 09:08AM >>>
>Oscar,
>
>No offense taken, thus no apology needed.
>
>My comments from the soapbox last week were actually intended for the
>community at large, and were meant to convey frustration at the apparent
>unwillingness of solution providers in general to hear about -- and solve
--
>real world problems that are faced by users like myself in large, complex
>environments.
>
>When I say "my environment is not so simple," the response I hear is
"let's
>not talk about the complexity; let's make some simplifying assumptions
>instead."
>
>When I say "I have a nail AND a screw and need to put them both in the
>wall," the response I hear is "we have provided you with a perfectly
>adequate hammer, therefore you don't have a screw."
>
>As I was using the nail/hammer analogy, dc-based names are the nails;
>civil-attribute-based names are the screws. No matter how good a job my
>company does of using nails and nails alone, we still have tens of
thousands
>of trading partners, many of whom prefer screws to nails and will continue
>to use them indefinitely. Without a screwdriver, it's hard to do business
>with them.
>
>I don't really care what the screwdriver looks like. I've suggested a
>fairly simple design that I think will work. So far, no one has commented
on
>the design. What I've heard instead is a chorus of "we still don't like
>screws." Well, I don't like them either, but I still have to deal with
>them. If I'm simply overlooking a screwdriver that we have lying around
>somewhere, I would appreciate someone pointing it out to me.
>
> -- Skip
>
>
>-----Original Message-----
>From: Oscar Jacobsson [mailto:[email-masked]]
>Sent: Thursday, January 11, 2001 5:16 PM
>To: Slone, Skip
>Cc: 'Sharon Boeyen'; [email-masked]
>Subject: RE: Basic Cert-2-Directory mapping question
>
>
>> From: Slone, Skip [mailto:[email-masked]]
>> In response to this, I'm inclined to join Sharon on Marshall's soapbox
and
>> echo her words:
>>
>> "... I believe a more constructive approach is to accept the fact that
>> different parts of the world and different environments will use a
variety
>> of nameforms ... We are not the global naming police either and should
not
>> try to impose the rules that anyone uses to name entities to which they
>> issue certificates."
>
>I'm sorry if I came across as clamouring for rules be imposed. I know that
>this working group has a tendency to be wary of suggestions that don't
cater
>for distinguished names containing cat MPEGs, so I should probably have
been
>more careful. The requirements I suggested were for a possible naming
>standards document, conformance to which need not be enforced.
>
>The case at hand is not, IMHO, one of dictating that "all distinguished
>names must be according to our will, or you shall feel our wrath". A
>document however, outlining a naming strategy that would require of the
>users of certificates named accordingly no a-priori knowledge of their
>issuer (save for eventually having to reach something explicitly trusted
in
>the chain) in order to perform path validation, is something I would
>personally consider very valuable indeed. I'm reasonably confident that
>organizations intending to act as certification authorities or trusted
third
>parties would agree.
>
>> And to quote someone Sharon and I both know, "If all you have is a
hammer,
>> every problem looks like a nail."
>
>It seems I was less than clear here as well. :-(
>
>My intention was to point out that there are actually two separate
problems
>here (one nail, if you will, and one screw) each looking for its own
>solution:
>
>1. Defining a repository, and subsequently entry, discovery process for
>arbitrarily named entries.
>
>2. Defining a naming scheme that _if applied_ would automate this
repository
>and entry discovery process.
>
>I am only trying to address the second of these problems. The first is
only
>an issue because nobody seems to have properly addressed the second before
>deploying certificates on the Internet en masse. The further we wait
before
>addressing number two, the more of a problem number one will become.
>
>I should probably make a habit of pointing out that the opinions stated
here
>are my very own, and not necessarily those of my employer.
>
>Cheers,
>
>//oscar

Received: from edelweb.fr (edelweb.fr [212.234.46.16]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA06793 for ; Wed, 17 Jan 2001 06:25:21 -0800 (PST)
Received: from champagne.edelweb.fr (localhost.edelweb.fr [127.0.0.1]) by edelweb.fr with ESMTP id PAA05513; Wed, 17 Jan 2001 15:30:49 +0100 (MET)
Received: from champagne.edelweb.fr (champagne.edelweb.fr [193.51.14.161]) by edelweb.fr (nospam/1.3); Wed, 17 Jan 2001 15:30:50 +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 PAA23816; Wed, 17 Jan 2001 15:30:47 +0100 (MET)
From: Peter Sylvester
Received: (sylvest@localhost) by emeriau.edelweb.fr (8.7.6/8.6.6) id PAA20052; Wed, 17 Jan 2001 15:30:47 +0100 (MET)
Date: Wed, 17 Jan 2001 15:30:47 +0100 (MET)
Message-Id: <[email-masked]>
To: [email-masked], [email-masked]
Subject: RE: DPD & DPV requirements
Cc: [email-masked]

> But, the need for both severs to perform path validation still seems
> to be true.

Not necessarily: If the DPV server just has to say Yes/No, then
it may not be PKI aware.

Received: from mailgw2a.lmco.com (mailgw2a.lmco.com [192.91.147.7]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id FAA04973 for ; Wed, 17 Jan 2001 05:54:18 -0800 (PST)
Received: from emss03g01.ems.lmco.com (emss03g01.ems.lmco.com [141.240.4.144]) by mailgw2a.lmco.com (8.8.8/8.8.8) with ESMTP id IAA01100; Wed, 17 Jan 2001 08:59:54 -0500 (EST)
Received: from CONVERSION-DAEMON by lmco.com (PMDF V5.2-32 #38888) id <[email-masked]>; Wed, 17 Jan 2001 08:58:51 -0500 (EST)
Received: from emss03i00.ems.lmco.com ([141.240.31.211]) by lmco.com (PMDF V5.2-32 #38888) with ESMTP id <[email-masked]>; Wed, 17 Jan 2001 08:58:40 -0500 (EST)
Received: by emss03i00.orl.lmco.com with Internet Mail Service (5.5.2650.21) id ; Wed, 17 Jan 2001 08:59:44 -0500
Content-return: allowed
Date: Wed, 17 Jan 2001 08:59:42 -0500
From: "Slone, Skip"
Subject: RE: DPD & DPV requirements
To: "'Stephen Kent'"
Cc: PKIX-List
Message-id:
MIME-version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-type: text/plain
Content-transfer-encoding: 7BIT

Thanks, Steve. I'm not wedded to a particular solution either -- I'll just
keep an eye on things from the perspective of my particular requirements.

-- Skip

-----Original Message-----
From: Stephen Kent [mailto:[email-masked]]
Sent: Tuesday, January 16, 2001 9:04 PM
To: Slone, Skip
Cc: PKIX-List
Subject: RE: DPD & DPV requirements

Skip,

>Steve,
>
>Judging from your response, I think I did both of us a disservice by
>providing too many details from my stream of consciousness. Here's the
>distilled essence of what I intended to say:
>
>In your requirements document you wrote, "Finally, this analysis suggests
>that there are relatively few differences between a DPD and a DPV server
...
>[T]he WG must decide if two distinct protocol formats, with different
syntax
>are warranted, or if a single [one] is appropriate." You then went on to
>conclude that they were sufficiently similar to justify a single set of
>requirements.
>
>Based on the way the discussions have gone, I'm questioning this
conclusion.
>By separating the two, DPV could focus on simplicity and efficiency (to
>better serve highly constrained clients), while DPD focuses on completeness
>(to serve the needs of highly capable, but perhaps contextually constrained
>clients). DPV could consume DPD services, creating a complete solution to a
>wide range of problems.
>
>It is this last paragraph that I'd like comment on. Without some sense of
>agreement at this conceptual level, it's fruitless to dig into details.
>

I think we are seeing some divergence in arguments for the two types
of servers, wrt queries and responses. They may be small enough to
use a unified format with options, or we may have two distinct
formats with a lot of overlap. I'm not wedded to either approach.
But, the need for both severs to perform path validation still seems
to be true.

Steve

Received: from edelweb.fr (edelweb.fr [212.234.46.16]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id FAA03270; Wed, 17 Jan 2001 05:27:55 -0800 (PST)
Received: from champagne.edelweb.fr (localhost.edelweb.fr [127.0.0.1]) by edelweb.fr with ESMTP id OAA05119; Wed, 17 Jan 2001 14:33:31 +0100 (MET)
Received: from champagne.edelweb.fr (champagne.edelweb.fr [193.51.14.161]) by edelweb.fr (nospam/1.3); Wed, 17 Jan 2001 14:33:31 +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 OAA23536; Wed, 17 Jan 2001 14:33:28 +0100 (MET)
From: Peter Sylvester
Received: (sylvest@localhost) by emeriau.edelweb.fr (8.7.6/8.6.6) id OAA20039; Wed, 17 Jan 2001 14:33:28 +0100 (MET)
Date: Wed, 17 Jan 2001 14:33:28 +0100 (MET)
Message-Id: <[email-masked]>
To: [email-masked], [email-masked]
Subject: Re: DPD & DPV Basics
Cc: [email-masked]

> With respect to S/MIME, several others have said that S/MIME agents must
> be able to parse CMS and ASN.1. Therefore, it is reasonable to expect
> them to be PKI-aware. This seems sensible to me.

They are ASN1-aware but not necessary PKI-aware.

> But if you *did* want to use a DPV server for verifying signatures on
> S/MIME messages, it seems to me that you would need to deal with issues
> similar to the ones raised above and in the previous message regarding
> TLS/SSL: ensuring that the subject name or subject alternative name
> matches the From line, checking that the appropriate key usage and
> extended key usage bits are set, and getting the public key with
> parameters from the DPV server. There's also the separate issue of how
> (or whether) to send CRLs included with the message to the DPV server. A
> full-fledged S/MIME implementation would raise lots of more interesting
> issues: discovering a path to a previously unknown party in order to
> send them an encrypted email, determine which certificates and CRLs to
> send with a signed email (based on the intended recipients), etc. But
> that's clearly out of scope for DPV.

In an S/MIME message the originating field are not included in the
signature. Furthermore, you might not even have a certificate available
in an S/MIME signed message.

Anyway, in the first place I'd use a service that takes the whole
signature and not just the certs.

For encrytion certs: You might think of first using an 'untrusted'
directory lookup, and then make a DPV request for those certs, the
response may also include additional encryption certs like for
example your outgoing company firewal, the other companies mail
firewall, you internal company document recovery cert or some
paranoiac government cert.

Received: from edelweb.fr (edelweb.fr [212.234.46.16]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id FAA01676 for ; Wed, 17 Jan 2001 05:09:41 -0800 (PST)
Received: from champagne.edelweb.fr (localhost.edelweb.fr [127.0.0.1]) by edelweb.fr with ESMTP id OAA05039; Wed, 17 Jan 2001 14:15:08 +0100 (MET)
Received: from champagne.edelweb.fr (champagne.edelweb.fr [193.51.14.161]) by edelweb.fr (nospam/1.3); Wed, 17 Jan 2001 14:15: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 OAA23494; Wed, 17 Jan 2001 14:15:06 +0100 (MET)
From: Peter Sylvester
Received: (sylvest@localhost) by emeriau.edelweb.fr (8.7.6/8.6.6) id OAA20034; Wed, 17 Jan 2001 14:15:06 +0100 (MET)
Date: Wed, 17 Jan 2001 14:15:06 +0100 (MET)
Message-Id: <[email-masked]>
To: [email-masked], [email-masked]
Subject: RE: DPD & DPV requirements
Cc: [email-masked]

Frank wrote:

> I'm confused. Are people saying that the certificate whose path the client
> would like to discover or validate is in the unordered lump of certificates
> or that a separate lump of certificates may be sent to assist the server? I
> thought the latter.

This is not quite clear to me either.

Before going to specify a syntax we should state it differently,
here some ideas:

- A client may indicate one or more certificates to be validated.

- 1 - Each certificate may be accompagnied by a 'lump' of certificates
that may assist the server to find a valid path for that
particular certificate.

2 - There may be an additional bunch of certificates that may be
used by the server to determine valid paths.

I tended to have 1, because for different certs the paths may be
different, but I may be wrong since even if one throws all the
different hints in 1 into one bag, the server could probably
find out the good stuff anyway.

Peter

Received: from edelweb.fr (edelweb.fr [212.234.46.16]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id DAA26275; Wed, 17 Jan 2001 03:52:03 -0800 (PST)
Received: from champagne.edelweb.fr (localhost.edelweb.fr [127.0.0.1]) by edelweb.fr with ESMTP id MAA04788; Wed, 17 Jan 2001 12:57:38 +0100 (MET)
Received: from champagne.edelweb.fr (champagne.edelweb.fr [193.51.14.161]) by edelweb.fr (nospam/1.3); Wed, 17 Jan 2001 12:57:39 +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 MAA23383; Wed, 17 Jan 2001 12:57:36 +0100 (MET)
From: Peter Sylvester
Received: (sylvest@localhost) by emeriau.edelweb.fr (8.7.6/8.6.6) id MAA20012; Wed, 17 Jan 2001 12:57:36 +0100 (MET)
Date: Wed, 17 Jan 2001 12:57:36 +0100 (MET)
Message-Id: <[email-masked]>
To: [email-masked], [email-masked]
Subject: Re: DPD & DPV Basics
Cc: [email-masked], [email-masked]

>
> Typical IETF situation. We all agree that the answer is obvious. We just
> don't agree what the answer is!

Worse, we don't even have a common meaning of the question. :-)

> It sounds like some applications are PKI-ignorant but ASN.1-savvy (able
> to parse a certificate). Others are PKI-ignorant and ASN.1-ignorant
> (unable to parse a certificate).

The question is: Do we want to support both types of client at the same time with
the same protocol.

For a non asn1 client we can have at least two solutions where X ist the
ASN1 DPV protocol, and Y is the same formulated in another code.

non-asn1-application - non-asn1 DPV front end - DPV client -X- DPV server - PKI

non-asn1-application - non-asn1 DPV client -Y- non-asn1 DPV server - PKI

For example, if I would need an application like XML-DSIG, I would like to
feed the key info and a certificate, and get back an answer that the
application can authenticate by simpler means, and the answer would
have a xml 'view' of the returned data i.e. textual versions of the x509
cert etc.

> An ASN.1-savvy application only needs a DPV server to determine whether
> a particular certificate is trustworthy (whether there is a valid path
> to the certificate, according to the appropriate policies). The
> ASN.1-savvy application can parse the certificate to check the key usage
> and extended key usage and get the name and public key. See Note 1 below
> for a minor detail.

The question from the client is not 'is this cert trustworthy', but:
Is this cert trustworthy for *my* application. The details of whether
whatever current (mis-)interpretation if certificate details is useful
for an application can be completely hidden from the application.

> An ASN.1-ignorant application needs a DPV server to determine whether a
> certificate is trustworthy. But it also needs the DPV server to check
> the key usage and extended key usage, check the name, and return the
> public key. The ASN.1-ignorant application also needs the DPV protocol
> to not use ASN.1 (except for objects that the application can treat like
> blobs, like the certificate).

As said a non-asn1 application is also interested in getting extracts
from certificate like for example in the xml-dsig case. It can get
also certs like blobs. The question is how much data need to be extracted
from asn1 encoded data, for example an embedded OCSP response.

> Does everyone (or almost everyone) agree with this analysis? If so, do
> you also agree that both of these kinds of applications should be
> supported (PKI-ignorant and ASN.1-savvy and PKI-ignorant and
> ASN.1-ignorant)?

One can see this as one protocol on top of another, since the non-asn1 application
need more data than the asn1 aware application, at least if we assume that PKI
is asn1 based.

> Once we have agreement on all that, then I think we will have a useful
> context for discussing DPV requirements.

Do I agree with your analysis? At least there is some overlap. ;-)

PS

Received: from geos.coastside.net (geos.coastside.net [207.213.212.4]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id XAA25859 for ; Tue, 16 Jan 2001 23:34:08 -0800 (PST)
Received: from heatherdale (dsl-63-194-153-52.coastside.net [63.194.153.52]) by geos.coastside.net (8.11.0/8.11.1) with SMTP id f0H7dFc08307; Tue, 16 Jan 2001 23:39:15 -0800 (PST)
From: "Michael Myers"
To: "Stephen Kent"
Cc: "PKIX List"
Subject: RE: DPD & DPV Basics
Date: Tue, 16 Jan 2001 23:43:22 -0800
Message-ID:
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:
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300

Steve,

Are we talking about the same thing? Given a client-side initiation, it's
an OCSP request from an IPSEC GW/whatever to an OCSP server regarding that
incoming cert, then that GW/whatever turns around, gets *its* own OCSP
signed validation back from that same server (which public key the client
trusts) and drops it into the IPSEC handshake.

This scenario should bear no impact on the protocol's definition (modulo
IPSEC implementation impact, of course.) It's an enterprise trust policy
issue. It's just using the BOTW protocol as defined, although in a somewhat
interesting way in order to: 1) simplify the client side (esp. wrt the road
warrior); and 2) concentrate processing power in the back office where in
fact such power exists. It also simplifies things tremendously at the
system level.

BTW, I've been kicking this around with various IPSEC folk as far back as
the Binghamton interop. Harkins and I also discussed it in Orlando. CF
also my message to Khaja on this list on Fri Sep 1 12:50:51 2000 re: "OCSP
in S/MIME and IPSEC".

Mike

> -----Original Message-----
> From: Stephen Kent [mailto:[email-masked]]
> Sent: Tuesday, January 16, 2001 7:41 PM
> To: Michael Myers
> Cc: PKIX List
> Subject: RE: DPD & DPV Basics
>
>
> Mike,
>
> >Carlin,
> >
> >It might also be useful to extend this concept the "asymmetric
> OCSP" case,
> >where a client's trusted server not only confirms the validity of the
> >client's certificate via an external trust server but acquires from that
> >same server an assertion of the validity of its (the protocol server's)
> >certificate. This response could be included in-band to the
> client and so
> >relieve the client of any further interaction with infrastructure to
> >establish the server's trustworthiness. IPSEC's protocol
> architecture seems
> >well suited to this design.
>
> One could imagine doing this, but when do we stop providing such
> info? Do we provide a cert path and revocation status data for the
> OCSP responder too?
>
> Maybe one should include the OCSP server's cert in an NR package, but
> for a DPV server, I think it would not be appropriate to pass back
> this info discretely.
>
> Steve
>
>

Received: from webserver.onlineevents.com.au ([203.111.80.201]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id UAA12665 for ; Tue, 16 Jan 2001 20:28:09 -0800 (PST)
From: [email-masked]
Received: from max1-34.losangeles.corecomm.net by webserver.onlineevents.com.au with SMTP (Microsoft Exchange Internet Mail Service Version 5.0.1459.44) id C0CGL63T; Wed, 17 Jan 2001 14:55:27 +1100
DATE: 16 Jan 01 6:45:38 PM
Message-ID: <2w81t2Of2vJIo3>
SUBJECT: RE; THANK YOU

Dear Friend and Partner,

Think of all the things you could do if you had more free time and money wasn't an
object

What kind of car would you be driving?

Where would you live?

Where would you go on vacation?

Now, for a limited time, 300+ money making and saving secrets can be yours for less
than $10.00.

Click here http://www.300moneysecrets.com/ and ORDER NOW!!!!!!!!!!!!!!

Get information now, that could make you millions!!!!

** REMOVE ** REMOVE ** REMOVE ** REMOVE ** REMOVE **

To be removed from our mailing list, please email [email-masked] All REMOVE requests AUTOMATICALLY honored upon receipt. PLEASE understand that any effort to disrupt, close or block this REMOVE account can only result in difficulties for others wanting to be removed from our mailing list as it will be impossible to take anyone off the list if the remove instruction can not be received.

Received: from po1.bbn.com (PO1.BBN.COM [192.1.50.38]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id TAA11456 for ; Tue, 16 Jan 2001 19:37:25 -0800 (PST)
Received: from [128.33.238.30] (TC013.BBN.COM [128.33.238.13]) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id WAA23551; Tue, 16 Jan 2001 22:42:56 -0500 (EST)
Mime-Version: 1.0
X-Sender: [email-masked]
Message-Id:
In-Reply-To:
References:
Date: Tue, 16 Jan 2001 22:40:54 -0500
To: "Michael Myers"
From: Stephen Kent
Subject: RE: DPD & DPV Basics
Cc: "PKIX List"
Content-Type: text/plain; charset="us-ascii" ; format="flowed"

Mike,

>Carlin,
>
>It might also be useful to extend this concept the "asymmetric OCSP" case,
>where a client's trusted server not only confirms the validity of the
>client's certificate via an external trust server but acquires from that
>same server an assertion of the validity of its (the protocol server's)
>certificate. This response could be included in-band to the client and so
>relieve the client of any further interaction with infrastructure to
>establish the server's trustworthiness. IPSEC's protocol architecture seems
>well suited to this design.

One could imagine doing this, but when do we stop providing such
info? Do we provide a cert path and revocation status data for the
OCSP responder too?

Maybe one should include the OCSP server's cert in an NR package, but
for a DPV server, I think it would not be appropriate to pass back
this info discretely.

Steve

Received: from [165.227.249.17] (ip17.proper.com [165.227.249.17]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id TAA11145 for ; Tue, 16 Jan 2001 19:28:53 -0800 (PST)
Mime-Version: 1.0
X-Sender: [email-masked]
Message-Id:
In-Reply-To:
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Date: Tue, 16 Jan 2001 19:33:04 -0800
To: PKIX List
From: Paul Hoffman / IMC
Subject: Re: DPD & DPV Basics
Content-Type: text/plain; charset="us-ascii" ; format="flowed"

At 9:00 PM -0500 1/16/01, Stephen Kent wrote:
>>It sounds like we need to decide whether non-PKI aware,
>>non-ASN.1-capable clients need to be supported. If so, we should
>>probably define a set of requirements for such clients and include this
>>item in that list. I would suggest that such clients are an important
>>group and should be supported.
>
>I put this question to the list in my strawman spec over 2 weeks
>ago, and have not yet gotten a concrete proposal on how to
>accommodate such clients. I will soon decide that we will NOT
>support them for now, unless I see such a proposal.

I think that many vendors would like these clients to be able to
exist, but have bitten the bullet and done the ASN.1 to at least
parse the cert. Given the strong arguments we had when I first
proposed SCVP for non-ASN.1 clients, and the fact that none of the
vendors wanted to say in public that this is what they needed, I
think it is OK to limit the scope of the discussion to a client that
can parse a cert and knows what pieces it needs to implement its
security policy.

--Paul Hoffman, Director
--Internet Mail Consortium

Received: from aspams52.ca.com (aspams52.cai.com [155.35.248.76]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id TAA10365 for ; Tue, 16 Jan 2001 19:04:45 -0800 (PST)
Received: by aspams52.ca.com with Internet Mail Service (5.5.2650.21) id ; Wed, 17 Jan 2001 14:09:48 +1100
Message-ID: <[email-masked]>
From: "Ramsay, Ron"
To: Bob Jueneman , [email-masked], [email-masked]
Cc: [email-masked]
Subject: RE: Basic Cert-2-Directory mapping question
Date: Wed, 17 Jan 2001 14:09:40 +1100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"

Bob,

While it may be true that 'c=us' does not try to say something about
countries, I don't believe this is relevant. The importance of this RDN in
the DN is that, notionally, there is an entry with the DN 'c=us'. When
browsing an X.500 DIT, you should be able to see all the superior entries as
indicated bu the RDNs in the entry DN. This is the semantic meaning of the
DN, not 'what does country mean in this DN'. To this extent, the idea of
adding a non-DIT RDN to the DN is abhorrent and will create real problems.
(LDAP directories generally aren't browsable so I guess my remarks don't
apply to them.)

Ron.

-----Original Message-----
From: Bob Jueneman [mailto:[email-masked]]
Sent: Wednesday, 17 January 2001 13:35
To: [email-masked]; [email-masked]
Cc: [email-masked]
Subject: RE: Basic Cert-2-Directory mapping question

Skip,

Just so it's clear, I probably should have defined at least one use
model for what we have been talking about -- at least the use
that I have in mind.

what I'm trying to get away from this the necessity of wasting all
of the bandwidth that is currently being used to repetitively
download entire certificate chains containing the same information,
over and over again to the same client. This is particularly the
case in SSL/TLS and S/MIME, and I predict that when we start
sending signed EDI transactions it will be the case there as well.

What I want to do to minimize all of this is to send only two things
with a given transaction -- the digital signature itself, stripped down
as far as possible; and the name of the signer, in a minimal form
as possible without imposing a rigid repository schema.

ideally, the name of the signer should be a DN, whether in the form
of a classical civil name structure, and DNS name, or some other form
that is searchable, such as a DUNS number.

Ideally, the structure of the DN should be compatible with existing
RDN syntax, but perhaps with the addition of a new attribute type.
I think that we are agreed that SOMETHING new is going to be
required, and if that is the case a new attribute that is consistent with
the
current RDN syntactic structure would to my mind be preferable to
introducing something else, such as a URL or URI.

Although I don't want to get completely hung up on the use of a
dir= RDN qualifier vs. a more explicit URL-type qualifier, I'm don't
think I agree with your concern about the paradigm shift in the
DN semantics a dir= type of qualifier would cause. Maybe I just
don't understand.

I am inclined to say that "DN semantics" is close to being an oxymoron.
The fact is that the semantic definitions of most of the usual DN
attributes are conspicuously vague. Consider "serial", "locality",
commonName,
or even "country". Yes, we all understand what a country is -- it's
whatever the UN says it is, or isn't, and questions about disputed
territories
are brushed aside. But that isn't a semantic definition, that is simply a
name to
territory definition or mapping. The real question is what is the
relationship
between the country and the end-entity identified by the rest of the DN --
is it merely a directory qualifier, or is it the country of residence?,
citizenship?
place of doing business? location of the home office? country of
incorporation of an enterprise? If I am referring to a ship, for example,
that
is owned an operated by a UK company, registered in Liberia ,and
is currently docked in Miami, what country should I use for the RDN
of that ship?

Since X.500 doesn't attempt to answer that question, I would claim that
the only effective semantics for country is as a directory qualifier, under
the
old universal X.500 directory-in-the-sky assumption of a monopoly directory
service, or at least a monopoly naming infrastructure per country.

Since we know by now that the original assumption is no longer valid,
if indeed it ever was, we can certainly use country to mean whatever
we choose it to mean in terms of semantics, just as people have
distorted the semantics of organization, and particularly
organizationalUnit, to contain just about anything they want.

(I'm not really suggesting an RDN containing a MPEG of my cat, but
things that are nearly as strange have been done in the past.
That doesn't make them "right", of course, just ubiquitous.)

But what that leaves us with is the need to qualify what used to be a root,
i.e., country, and to supply a new root, meaning basically who owns,
operates, and defines the semantics and schema for all of the rest of t
he RDNs which follow.

I would submit that despite the semantic "recommendations" provided by
the standards organizations, it is really the directory service provider who

defines such things, or in some cases the Certificate Authority who creates
a
certificate, whether or not they actual deposit that certificate in an X.500

directory

>From this point of view, I believe that using a dir= type of directory
service
provider is not some kind of an ugly hack, but a reflection of reality, and
a
completely legitimate RDN qualifier. It specifies in a consistent DN syntax
what the root of the DIT really is -- the name of the directory that
contains
and defines it.

Now I'll grant that it isn't very likely that existing X.500 directories
would
suddenly change their DIT structure to explicitly include a dir= component
at the Top. But I don't think that would be at all necessary, either -- it
can be
done implicitly.

I wouldn't think it would be all that hard to define the attribute matching
rules so that if the dir attribute (or one of the multi-=valued RDN
components)
is the DNS address of the directory that is being accessed, the result is
TRUE, and otherwise FALSE.

Another approach which might or might not work would be to use an alias,
although I don't know whether it is possible to define an alias for a node,
rather than for a leaf.

For example, in Novell's own DIT, we don't even define c=US as the top
component, although perhaps we "should".

But I would assume/hope that if we were concerned about that, we could
define an alias of c=us, o=Novell Inc. to point to the o=Novell node that is

actually at the top of our DIT.

Since you said that you actually considered this type of an approach
at one time, perhaps you can say more about what led you away from
that approach. I think you were right the first time.

Regards,

Bob

>>> "Slone, Skip" 01/16/01 01:45PM >>>
John,

You wrote, "I don't think the proposed "dir" attribute is semantically very
different
from any other naming attributes" and that "the mechanism for searching has
to treat the "dir" RDN somewhat differently from the other RDNs."

My concern with different semantics is not a matter of degree; it's the fact
that the semantics of DN must change -- at all -- to incorporate this
concept. If there are other ways to deal with the problem, I see no
compelling reason to change the semantics of something so fundamentally and
deeply entrenched in dozens of standards as DN.

I must add here that I have not always opposed this concept. I actually
pursued this line of thinking two or three years ago in a different forum
(X.500) while working a different problem (Related Entries). At that time, I
was proposing that a "dnQualifer" be added to a DN to specify an access
point through which the entry named by the DN could be found. While pursuing
that line of thinking (which explored several syntactic/semantic variants),
the semantic-shift problem kept getting in the way. In the end, we settled
on a separate mechanism rather than change the semantics of DN. Flawed as it
may be, DN is still a widely accepted concept; changing it will be an uphill
struggle.

-- Skip

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Tuesday, January 16, 2001 10:52 AM
To: Slone, Skip
Cc: 'Bob Jueneman'; [email-masked]
Subject: RE: Basic Cert-2-Directory mapping question

>As I read your suggestion, you want to add an element to the DN
>that directs the user to the appropriate directory. The new
>element is syntactically an RDN, but semantically is something
>different. The resulting new-style DN appears to me to
>semantically comparable to an LDAP URL.

I don't think the proposed "dir" attribute is semantically very different
from any other naming attributes. What we're trying to do with names in
certificates is to maintain the X.500 illusion that a DN uniquely
identifies an entry in some global directory. But we don't have a single
global directory; instead we have a collection of directories which don't
talk to one another - i.e. instead of the single DN root assumed by X.500,
we actually have multiple roots, one for each directory.

The obvious way to resolve this sort of problem is to introduce a new
"meta-root" that sits above all the directory roots. This corresponds to
adding an RDN to the most significant end of each DN that names the
particular directory within which the named entry lies. Precisely how a
directory is named is TBD, but it must give an end-system enough
information to for a query for that directory, without requiring prior
knowledge of the directory, so an obvious possibility (for an LDAP
directory) is scheme and hostport portions of an LDAP URL.

Individual directories could either store this attribute explicitly within
the entry (which would mean that these directories could be directly
searched using the full DN) or, more likely, the "dir" attribute would have
to be removed before searching an individual directory. So yes, the
mechanism for searching has to treat the "dir" RDN somewhat differently
from the other RDNs, but in terms of a naming model, it behaves just like
any other RDN.

As Bob points out, the "dir" attribute could be multi-valued, allowing
information about an entry to reside in multiple directories (provided that
the directories can all agree to use the same name for the entry).

John

"Slone, Skip" on 01/16/2001 09:16:13 AM

To: "'Bob Jueneman'"
cc: [email-masked]
Subject: RE: Basic Cert-2-Directory mapping question

Bob,

I'm glad to hear we agree on the nature of the problem. From that point of
agreement, we can move the discussion to one of "what do we do about it?"

In abstract terms, it appears to me that "what we can do about it" falls
into two broad categories:
1) we can create a mechanism for explicitly identifying the appropriate
directory, or
2) we can remove the barriers that currently prevent the directory from
being discovered implicitly based upon existing information

I would say that your approach fits in category 1, while my approach fits
in
category 2. Either approach has validity IMHO and is worthy of
consideration.

As I read your suggestion, you want to add an element to the DN that
directs
the user to the appropriate directory. The new element is syntactically an
RDN, but semantically is something different. The resulting new-style DN
appears to me to semantically comparable to an LDAP URL.

Assuming we're on the same page up to this point, I'll say that my concern
with this approach is that it changes the semantics of DN, potentially
causing interoperability problems in that both clients and servers that
understand the semantics as currently defined would have problems when
encountering the new-style name. If we were to go with a "category 1" fix
to the problem, I would rather see a new mechanism employed, such as a new
PKIX-defined certificate extension that explicitly gives repository
location
information. As a new construct, we would be free to define whatever
semantics we want, and could readily use existing concepts such as URLs.

Now, in defense of my approach, I think we can all probably agree that *IF*
the original concept of X.500-style distributed, global name resolution
were
a practical reality, we would be able to plug into the nearest DSA and find
the named entry regardless of where it resides physically. Of course I
emphasized the word "if" to imply that we can also probably agree that that
original X.500 concept is not going to occur anytime soon, if ever. What I
was proposing instead, was a "category 2" fix -- a way of removing that
barrier by providing an alternative way of doing distributed name
resolution. The alternative mechanism I proposed was one which builds upon
an existing, working, global infrastructure that already has the requisite
registration infrastructure in place. Without digging into the specifics,
I
would like to know if you or others believe that this *concept* has merit.

-- Skip

-----Original Message-----
From: Bob Jueneman [mailto:[email-masked]]
Sent: Monday, January 15, 2001 2:11 PM
To: [email-masked]
Cc: [email-masked]
Subject: RE: Basic Cert-2-Directory mapping question

Skip,

I don't particularly like the mechanism you've proposed, at least as
I understand it. But I absolutely and completely agree with you
as to the nature of the problem that has to be solved.

Civil attribute type names will always be with us, and hence must be
dealt with, for at least two fundamental reasons:

1. An address is not a name, although it may be a pseudonym. I
don't want to be forced to change my identity, or to an extent
my basis "self-hood," every time I change my ISP. And I especially
don't want some system administrator telling me that my name
must be limited to 8 characters, or that I have to change my name
because someone else has already used that same name within
that same system administrator's ill-conceived naming scheme.

2. E-mail address and other cyberspace identifiers fail to provide the
essence of PKI from a nonrepudiation standpoint, i.e., what I call the
"where do you send the sheriff" question.

Granted, not all uses of PKI will or should involve legal nonrepudiation.
But to the extent that at least some uses WILL have legal consequences,
then the establishment of a globally unique and credible identity that is
grounded in "meat-space" rather then cyberspace is absolutely essential.

For those legally binding transaction to be worth anything at all, they
have to be enforceable. And that means that a judgement may have
to be enforced upon someone, either by seizing the assets or putting
them in jail. And only in science fiction does the sheriff ride off into
cyberspace to arrest someone.

If I as a relying party wish to trade with someone, then I either want to
charge her credit card (in which case PKI is demonstrably not necessary)
or I want to know that she is the Mary Smith who resides at 123 Anywhere
St,
Metropolis, NY.

The inclusion of that civil address not only servers to distinguish her
from the other Mary Smiths, but more importantly it establishes a nexus
or link between her identity and her probable whereabouts, and
probably valuable real property as well.

So civil addresses, both corporate or "organizationalPerson", or the
harder-to-deal-with residentialPerson type will presumably always
be with us, and will have to be dealt with.

And unfortunately, perhaps, here int he US the simple and inescapable
fact of the matter is that neither the federal nor the state governments
operate the type of presumptively authoritative name registration
authorities that are relatively common in other countries. I am perfectly
free to move from one city to another, or from address to another in
the same city, and to never notify anyone in authority at all, including
the tax authorities. No one will ever say, "Papers, please."

(Granted, if I choose to do that I may not be able to register to vote,
but over half the population doesn't vote anyway. And the last time
I registered, no one checked to see that I actually lived there -- that
one of the problems we have with our voting system, even outside
of the State of Florida.. And I may not be able to get a driver's license
in order to legally drive a car, but a lot of illegal immigrants don't have
driver's licenses either, although that doesn't keep them from driving.)

So merely trying to ignore the problem of civil addressing schemes
won't solve that problem. And neither will various approaches that
make certain assumptions about monopoly name registration
authorities, or try to divine or impute where a directory containing
a particular name might be found based on some kind of a Karnak
mentalist act.

The primary issue is not the question of whether the name space
is flat or hierarchical, or how hierarchical, much less what the
"approved" schema is. What will be, will be, for reasons that
are beyond our scope and power to influence, even if we wanted
to.

So.

We cannot force a person to deposit his certificate or other useful
information into a specific directory, even if we wanted to. Nor can
we reliably impute a likely directory where such information might
be found, at least in the absence of a monopoly or governmental
mandate.

The best we can do is to ASK the user where he has deposited
such information, if anywhere, and to include that information
EXPLICITLY in any directory or pseudo-directory reference, such
as a DN.

Although at one time I liked the notion of prefixing the DN with a
URL, I have come to believe that John Wray's suggestion is the
better way forward.

He said:
>
>Bob,
>
>Accepting the fact that the X.500 dream of a single global directory is
not
>going to happen any time soon, DNs can still be turned into globally
>significant pointers into a federation of directories in the way you
>suggest, but it doesn't require altering the DN syntax (and therefore
>doesn't have to break existing implementations). All that's needed is a
DN
>attribute that names the particular directory within which the name
>resides. e.g. instead of "c=us;..;cn=My Name" you'd have "dir=My
>Directory;c=us;...;cn=My Name", where "My Directory" is the URL of a
>directory access point.

By including an explicit directory qualifier of the form dir="directory
URL"
at the root (top) of the RDN chain, we have implicitly qualified all of the
rest
of the RDN, which is a Good Thing.

By defining the syntax of the "dir" attribute appropriately, we could
include
both the access type (LDAP, http, etc.) and port number appropriately,
either a default or explicitly indicated.

And by making the dir component multivalued, we could accommodate
a choice of multiple directories and multiple directory types.

Once again -- the essence of the problem is not the format of the directory
name but where a directory containing that name can be found.
Including that information as a top-level qualifying component solves that
problem (and potentially several others, such as name scope qualification)
very neatly.

Bob

Robert R. Jueneman
'Security Architect
Novell, Inc. -- the leading provider of Net services software
>
>
>
>
>
>
>
>>>> "Slone, Skip" 01/15/01 09:08AM >>>
>Oscar,
>
>No offense taken, thus no apology needed.
>
>My comments from the soapbox last week were actually intended for the
>community at large, and were meant to convey frustration at the apparent
>unwillingness of solution providers in general to hear about -- and solve
--
>real world problems that are faced by users like myself in large, complex
>environments.
>
>When I say "my environment is not so simple," the response I hear is
"let's
>not talk about the complexity; let's make some simplifying assumptions
>instead."
>
>When I say "I have a nail AND a screw and need to put them both in the
>wall," the response I hear is "we have provided you with a perfectly
>adequate hammer, therefore you don't have a screw."
>
>As I was using the nail/hammer analogy, dc-based names are the nails;
>civil-attribute-based names are the screws. No matter how good a job my
>company does of using nails and nails alone, we still have tens of
thousands
>of trading partners, many of whom prefer screws to nails and will continue
>to use them indefinitely. Without a screwdriver, it's hard to do business
>with them.
>
>I don't really care what the screwdriver looks like. I've suggested a
>fairly simple design that I think will work. So far, no one has commented
on
>the design. What I've heard instead is a chorus of "we still don't like
>screws." Well, I don't like them either, but I still have to deal with
>them. If I'm simply overlooking a screwdriver that we have lying around
>somewhere, I would appreciate someone pointing it out to me.
>
> -- Skip
>
>
>-----Original Message-----
>From: Oscar Jacobsson [mailto:[email-masked]]
>Sent: Thursday, January 11, 2001 5:16 PM
>To: Slone, Skip
>Cc: 'Sharon Boeyen'; [email-masked]
>Subject: RE: Basic Cert-2-Directory mapping question
>
>
>> From: Slone, Skip [mailto:[email-masked]]
>> In response to this, I'm inclined to join Sharon on Marshall's soapbox
and
>> echo her words:
>>
>> "... I believe a more constructive approach is to accept the fact that
>> different parts of the world and different environments will use a
variety
>> of nameforms ... We are not the global naming police either and should
not
>> try to impose the rules that anyone uses to name entities to which they
>> issue certificates."
>
>I'm sorry if I came across as clamouring for rules be imposed. I know that
>this working group has a tendency to be wary of suggestions that don't
cater
>for distinguished names containing cat MPEGs, so I should probably have
been
>more careful. The requirements I suggested were for a possible naming
>standards document, conformance to which need not be enforced.
>
>The case at hand is not, IMHO, one of dictating that "all distinguished
>names must be according to our will, or you shall feel our wrath". A
>document however, outlining a naming strategy that would require of the
>users of certificates named accordingly no a-priori knowledge of their
>issuer (save for eventually having to reach something explicitly trusted
in
>the chain) in order to perform path validation, is something I would
>personally consider very valuable indeed. I'm reasonably confident that
>organizations intending to act as certification authorities or trusted
third
>parties would agree.
>
>> And to quote someone Sharon and I both know, "If all you have is a
hammer,
>> every problem looks like a nail."
>
>It seems I was less than clear here as well. :-(
>
>My intention was to point out that there are actually two separate
problems
>here (one nail, if you will, and one screw) each looking for its own
>solution:
>
>1. Defining a repository, and subsequently entry, discovery process for
>arbitrarily named entries.
>
>2. Defining a naming scheme that _if applied_ would automate this
repository
>and entry discovery process.
>
>I am only trying to address the second of these problems. The first is
only
>an issue because nobody seems to have properly addressed the second before
>deploying certificates on the Internet en masse. The further we wait
before
>addressing number two, the more of a problem number one will become.
>
>I should probably make a habit of pointing out that the opinions stated
here
>are my very own, and not necessarily those of my employer.
>
>Cheers,
>
>//oscar

Received: from prv-mail20.provo.novell.com (prv-mail20.provo.novell.com [137.65.81.122]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id SAA09495 for ; Tue, 16 Jan 2001 18:29:42 -0800 (PST)
Received: from INET-PRV-Message_Server by prv-mail20.provo.novell.com with Novell_GroupWise; Tue, 16 Jan 2001 19:34:37 -0700
Message-Id:
X-Mailer: Novell GroupWise Internet Agent 5.5.5.1
Date: Tue, 16 Jan 2001 19:34:33 -0700
From: "Bob Jueneman"
To: ,
Cc:
Subject: RE: Basic Cert-2-Directory mapping question
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id SAA09496

Skip,

Just so it's clear, I probably should have defined at least one use
model for what we have been talking about -- at least the use
that I have in mind.

what I'm trying to get away from this the necessity of wasting all
of the bandwidth that is currently being used to repetitively
download entire certificate chains containing the same information,
over and over again to the same client. This is particularly the
case in SSL/TLS and S/MIME, and I predict that when we start
sending signed EDI transactions it will be the case there as well.

What I want to do to minimize all of this is to send only two things
with a given transaction -- the digital signature itself, stripped down
as far as possible; and the name of the signer, in a minimal form
as possible without imposing a rigid repository schema.

ideally, the name of the signer should be a DN, whether in the form
of a classical civil name structure, and DNS name, or some other form
that is searchable, such as a DUNS number.

Ideally, the structure of the DN should be compatible with existing
RDN syntax, but perhaps with the addition of a new attribute type.
I think that we are agreed that SOMETHING new is going to be
required, and if that is the case a new attribute that is consistent with the
current RDN syntactic structure would to my mind be preferable to
introducing something else, such as a URL or URI.

Although I don't want to get completely hung up on the use of a
dir= RDN qualifier vs. a more explicit URL-type qualifier, I'm don't
think I agree with your concern about the paradigm shift in the
DN semantics a dir= type of qualifier would cause. Maybe I just
don't understand.

I am inclined to say that "DN semantics" is close to being an oxymoron.
The fact is that the semantic definitions of most of the usual DN
attributes are conspicuously vague. Consider "serial", "locality", commonName,
or even "country". Yes, we all understand what a country is -- it's
whatever the UN says it is, or isn't, and questions about disputed territories
are brushed aside. But that isn't a semantic definition, that is simply a name to
territory definition or mapping. The real question is what is the relationship
between the country and the end-entity identified by the rest of the DN --
is it merely a directory qualifier, or is it the country of residence?, citizenship?
place of doing business? location of the home office? country of
incorporation of an enterprise? If I am referring to a ship, for example, that
is owned an operated by a UK company, registered in Liberia ,and
is currently docked in Miami, what country should I use for the RDN
of that ship?

Since X.500 doesn't attempt to answer that question, I would claim that
the only effective semantics for country is as a directory qualifier, under the
old universal X.500 directory-in-the-sky assumption of a monopoly directory
service, or at least a monopoly naming infrastructure per country.

Since we know by now that the original assumption is no longer valid,
if indeed it ever was, we can certainly use country to mean whatever
we choose it to mean in terms of semantics, just as people have
distorted the semantics of organization, and particularly
organizationalUnit, to contain just about anything they want.

(I'm not really suggesting an RDN containing a MPEG of my cat, but
things that are nearly as strange have been done in the past.
That doesn't make them "right", of course, just ubiquitous.)

But what that leaves us with is the need to qualify what used to be a root,
i.e., country, and to supply a new root, meaning basically who owns,
operates, and defines the semantics and schema for all of the rest of t
he RDNs which follow.

I would submit that despite the semantic "recommendations" provided by
the standards organizations, it is really the directory service provider who
defines such things, or in some cases the Certificate Authority who creates a
certificate, whether or not they actual deposit that certificate in an X.500
directory

>From this point of view, I believe that using a dir= type of directory service
provider is not some kind of an ugly hack, but a reflection of reality, and a
completely legitimate RDN qualifier. It specifies in a consistent DN syntax
what the root of the DIT really is -- the name of the directory that contains
and defines it.

Now I'll grant that it isn't very likely that existing X.500 directories would
suddenly change their DIT structure to explicitly include a dir= component
at the Top. But I don't think that would be at all necessary, either -- it can be
done implicitly.

I wouldn't think it would be all that hard to define the attribute matching
rules so that if the dir attribute (or one of the multi-=valued RDN components)
is the DNS address of the directory that is being accessed, the result is
TRUE, and otherwise FALSE.

Another approach which might or might not work would be to use an alias,
although I don't know whether it is possible to define an alias for a node,
rather than for a leaf.

For example, in Novell's own DIT, we don't even define c=US as the top
component, although perhaps we "should".

But I would assume/hope that if we were concerned about that, we could
define an alias of c=us, o=Novell Inc. to point to the o=Novell node that is
actually at the top of our DIT.

Since you said that you actually considered this type of an approach
at one time, perhaps you can say more about what led you away from
that approach. I think you were right the first time.

Regards,

Bob

>>> "Slone, Skip" 01/16/01 01:45PM >>>
John,

You wrote, "I don't think the proposed "dir" attribute is semantically very
different
from any other naming attributes" and that "the mechanism for searching has
to treat the "dir" RDN somewhat differently from the other RDNs."

My concern with different semantics is not a matter of degree; it's the fact
that the semantics of DN must change -- at all -- to incorporate this
concept. If there are other ways to deal with the problem, I see no
compelling reason to change the semantics of something so fundamentally and
deeply entrenched in dozens of standards as DN.

I must add here that I have not always opposed this concept. I actually
pursued this line of thinking two or three years ago in a different forum
(X.500) while working a different problem (Related Entries). At that time, I
was proposing that a "dnQualifer" be added to a DN to specify an access
point through which the entry named by the DN could be found. While pursuing
that line of thinking (which explored several syntactic/semantic variants),
the semantic-shift problem kept getting in the way. In the end, we settled
on a separate mechanism rather than change the semantics of DN. Flawed as it
may be, DN is still a widely accepted concept; changing it will be an uphill
struggle.

-- Skip

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Tuesday, January 16, 2001 10:52 AM
To: Slone, Skip
Cc: 'Bob Jueneman'; [email-masked]
Subject: RE: Basic Cert-2-Directory mapping question

>As I read your suggestion, you want to add an element to the DN
>that directs the user to the appropriate directory. The new
>element is syntactically an RDN, but semantically is something
>different. The resulting new-style DN appears to me to
>semantically comparable to an LDAP URL.

I don't think the proposed "dir" attribute is semantically very different
from any other naming attributes. What we're trying to do with names in
certificates is to maintain the X.500 illusion that a DN uniquely
identifies an entry in some global directory. But we don't have a single
global directory; instead we have a collection of directories which don't
talk to one another - i.e. instead of the single DN root assumed by X.500,
we actually have multiple roots, one for each directory.

The obvious way to resolve this sort of problem is to introduce a new
"meta-root" that sits above all the directory roots. This corresponds to
adding an RDN to the most significant end of each DN that names the
particular directory within which the named entry lies. Precisely how a
directory is named is TBD, but it must give an end-system enough
information to for a query for that directory, without requiring prior
knowledge of the directory, so an obvious possibility (for an LDAP
directory) is scheme and hostport portions of an LDAP URL.

Individual directories could either store this attribute explicitly within
the entry (which would mean that these directories could be directly
searched using the full DN) or, more likely, the "dir" attribute would have
to be removed before searching an individual directory. So yes, the
mechanism for searching has to treat the "dir" RDN somewhat differently
from the other RDNs, but in terms of a naming model, it behaves just like
any other RDN.

As Bob points out, the "dir" attribute could be multi-valued, allowing
information about an entry to reside in multiple directories (provided that
the directories can all agree to use the same name for the entry).

John

"Slone, Skip" on 01/16/2001 09:16:13 AM

To: "'Bob Jueneman'"
cc: [email-masked]
Subject: RE: Basic Cert-2-Directory mapping question

Bob,

I'm glad to hear we agree on the nature of the problem. From that point of
agreement, we can move the discussion to one of "what do we do about it?"

In abstract terms, it appears to me that "what we can do about it" falls
into two broad categories:
1) we can create a mechanism for explicitly identifying the appropriate
directory, or
2) we can remove the barriers that currently prevent the directory from
being discovered implicitly based upon existing information

I would say that your approach fits in category 1, while my approach fits
in
category 2. Either approach has validity IMHO and is worthy of
consideration.

As I read your suggestion, you want to add an element to the DN that
directs
the user to the appropriate directory. The new element is syntactically an
RDN, but semantically is something different. The resulting new-style DN
appears to me to semantically comparable to an LDAP URL.

Assuming we're on the same page up to this point, I'll say that my concern
with this approach is that it changes the semantics of DN, potentially
causing interoperability problems in that both clients and servers that
understand the semantics as currently defined would have problems when
encountering the new-style name. If we were to go with a "category 1" fix
to the problem, I would rather see a new mechanism employed, such as a new
PKIX-defined certificate extension that explicitly gives repository
location
information. As a new construct, we would be free to define whatever
semantics we want, and could readily use existing concepts such as URLs.

Now, in defense of my approach, I think we can all probably agree that *IF*
the original concept of X.500-style distributed, global name resolution
were
a practical reality, we would be able to plug into the nearest DSA and find
the named entry regardless of where it resides physically. Of course I
emphasized the word "if" to imply that we can also probably agree that that
original X.500 concept is not going to occur anytime soon, if ever. What I
was proposing instead, was a "category 2" fix -- a way of removing that
barrier by providing an alternative way of doing distributed name
resolution. The alternative mechanism I proposed was one which builds upon
an existing, working, global infrastructure that already has the requisite
registration infrastructure in place. Without digging into the specifics,
I
would like to know if you or others believe that this *concept* has merit.

-- Skip

-----Original Message-----
From: Bob Jueneman [mailto:[email-masked]]
Sent: Monday, January 15, 2001 2:11 PM
To: [email-masked]
Cc: [email-masked]
Subject: RE: Basic Cert-2-Directory mapping question

Skip,

I don't particularly like the mechanism you've proposed, at least as
I understand it. But I absolutely and completely agree with you
as to the nature of the problem that has to be solved.

Civil attribute type names will always be with us, and hence must be
dealt with, for at least two fundamental reasons:

1. An address is not a name, although it may be a pseudonym. I
don't want to be forced to change my identity, or to an extent
my basis "self-hood," every time I change my ISP. And I especially
don't want some system administrator telling me that my name
must be limited to 8 characters, or that I have to change my name
because someone else has already used that same name within
that same system administrator's ill-conceived naming scheme.

2. E-mail address and other cyberspace identifiers fail to provide the
essence of PKI from a nonrepudiation standpoint, i.e., what I call the
"where do you send the sheriff" question.

Granted, not all uses of PKI will or should involve legal nonrepudiation.
But to the extent that at least some uses WILL have legal consequences,
then the establishment of a globally unique and credible identity that is
grounded in "meat-space" rather then cyberspace is absolutely essential.

For those legally binding transaction to be worth anything at all, they
have to be enforceable. And that means that a judgement may have
to be enforced upon someone, either by seizing the assets or putting
them in jail. And only in science fiction does the sheriff ride off into
cyberspace to arrest someone.

If I as a relying party wish to trade with someone, then I either want to
charge her credit card (in which case PKI is demonstrably not necessary)
or I want to know that she is the Mary Smith who resides at 123 Anywhere
St,
Metropolis, NY.

The inclusion of that civil address not only servers to distinguish her
from the other Mary Smiths, but more importantly it establishes a nexus
or link between her identity and her probable whereabouts, and
probably valuable real property as well.

So civil addresses, both corporate or "organizationalPerson", or the
harder-to-deal-with residentialPerson type will presumably always
be with us, and will have to be dealt with.

And unfortunately, perhaps, here int he US the simple and inescapable
fact of the matter is that neither the federal nor the state governments
operate the type of presumptively authoritative name registration
authorities that are relatively common in other countries. I am perfectly
free to move from one city to another, or from address to another in
the same city, and to never notify anyone in authority at all, including
the tax authorities. No one will ever say, "Papers, please."

(Granted, if I choose to do that I may not be able to register to vote,
but over half the population doesn't vote anyway. And the last time
I registered, no one checked to see that I actually lived there -- that
one of the problems we have with our voting system, even outside
of the State of Florida.. And I may not be able to get a driver's license
in order to legally drive a car, but a lot of illegal immigrants don't have
driver's licenses either, although that doesn't keep them from driving.)

So merely trying to ignore the problem of civil addressing schemes
won't solve that problem. And neither will various approaches that
make certain assumptions about monopoly name registration
authorities, or try to divine or impute where a directory containing
a particular name might be found based on some kind of a Karnak
mentalist act.

The primary issue is not the question of whether the name space
is flat or hierarchical, or how hierarchical, much less what the
"approved" schema is. What will be, will be, for reasons that
are beyond our scope and power to influence, even if we wanted
to.

So.

We cannot force a person to deposit his certificate or other useful
information into a specific directory, even if we wanted to. Nor can
we reliably impute a likely directory where such information might
be found, at least in the absence of a monopoly or governmental
mandate.

The best we can do is to ASK the user where he has deposited
such information, if anywhere, and to include that information
EXPLICITLY in any directory or pseudo-directory reference, such
as a DN.

Although at one time I liked the notion of prefixing the DN with a
URL, I have come to believe that John Wray's suggestion is the
better way forward.

He said:
>
>Bob,
>
>Accepting the fact that the X.500 dream of a single global directory is
not
>going to happen any time soon, DNs can still be turned into globally
>significant pointers into a federation of directories in the way you
>suggest, but it doesn't require altering the DN syntax (and therefore
>doesn't have to break existing implementations). All that's needed is a
DN
>attribute that names the particular directory within which the name
>resides. e.g. instead of "c=us;..;cn=My Name" you'd have "dir=My
>Directory;c=us;...;cn=My Name", where "My Directory" is the URL of a
>directory access point.

By including an explicit directory qualifier of the form dir="directory
URL"
at the root (top) of the RDN chain, we have implicitly qualified all of the
rest
of the RDN, which is a Good Thing.

By defining the syntax of the "dir" attribute appropriately, we could
include
both the access type (LDAP, http, etc.) and port number appropriately,
either a default or explicitly indicated.

And by making the dir component multivalued, we could accommodate
a choice of multiple directories and multiple directory types.

Once again -- the essence of the problem is not the format of the directory
name but where a directory containing that name can be found.
Including that information as a top-level qualifying component solves that
problem (and potentially several others, such as name scope qualification)
very neatly.

Bob

Robert R. Jueneman
'Security Architect
Novell, Inc. -- the leading provider of Net services software
>
>
>
>
>
>
>
>>>> "Slone, Skip" 01/15/01 09:08AM >>>
>Oscar,
>
>No offense taken, thus no apology needed.
>
>My comments from the soapbox last week were actually intended for the
>community at large, and were meant to convey frustration at the apparent
>unwillingness of solution providers in general to hear about -- and solve
--
>real world problems that are faced by users like myself in large, complex
>environments.
>
>When I say "my environment is not so simple," the response I hear is
"let's
>not talk about the complexity; let's make some simplifying assumptions
>instead."
>
>When I say "I have a nail AND a screw and need to put them both in the
>wall," the response I hear is "we have provided you with a perfectly
>adequate hammer, therefore you don't have a screw."
>
>As I was using the nail/hammer analogy, dc-based names are the nails;
>civil-attribute-based names are the screws. No matter how good a job my
>company does of using nails and nails alone, we still have tens of
thousands
>of trading partners, many of whom prefer screws to nails and will continue
>to use them indefinitely. Without a screwdriver, it's hard to do business
>with them.
>
>I don't really care what the screwdriver looks like. I've suggested a
>fairly simple design that I think will work. So far, no one has commented
on
>the design. What I've heard instead is a chorus of "we still don't like
>screws." Well, I don't like them either, but I still have to deal with
>them. If I'm simply overlooking a screwdriver that we have lying around
>somewhere, I would appreciate someone pointing it out to me.
>
> -- Skip
>
>
>-----Original Message-----
>From: Oscar Jacobsson [mailto:[email-masked]]
>Sent: Thursday, January 11, 2001 5:16 PM
>To: Slone, Skip
>Cc: 'Sharon Boeyen'; [email-masked]
>Subject: RE: Basic Cert-2-Directory mapping question
>
>
>> From: Slone, Skip [mailto:[email-masked]]
>> In response to this, I'm inclined to join Sharon on Marshall's soapbox
and
>> echo her words:
>>
>> "... I believe a more constructive approach is to accept the fact that
>> different parts of the world and different environments will use a
variety
>> of nameforms ... We are not the global naming police either and should
not
>> try to impose the rules that anyone uses to name entities to which they
>> issue certificates."
>
>I'm sorry if I came across as clamouring for rules be imposed. I know that
>this working group has a tendency to be wary of suggestions that don't
cater
>for distinguished names containing cat MPEGs, so I should probably have
been
>more careful. The requirements I suggested were for a possible naming
>standards document, conformance to which need not be enforced.
>
>The case at hand is not, IMHO, one of dictating that "all distinguished
>names must be according to our will, or you shall feel our wrath". A
>document however, outlining a naming strategy that would require of the
>users of certificates named accordingly no a-priori knowledge of their
>issuer (save for eventually having to reach something explicitly trusted
in
>the chain) in order to perform path validation, is something I would
>personally consider very valuable indeed. I'm reasonably confident that
>organizations intending to act as certification authorities or trusted
third
>parties would agree.
>
>> And to quote someone Sharon and I both know, "If all you have is a
hammer,
>> every problem looks like a nail."
>
>It seems I was less than clear here as well. :-(
>
>My intention was to point out that there are actually two separate
problems
>here (one nail, if you will, and one screw) each looking for its own
>solution:
>
>1. Defining a repository, and subsequently entry, discovery process for
>arbitrarily named entries.
>
>2. Defining a naming scheme that _if applied_ would automate this
repository
>and entry discovery process.
>
>I am only trying to address the second of these problems. The first is
only
>an issue because nobody seems to have properly addressed the second before
>deploying certificates on the Internet en masse. The further we wait
before
>addressing number two, the more of a problem number one will become.
>
>I should probably make a habit of pointing out that the opinions stated
here
>are my very own, and not necessarily those of my employer.
>
>Cheers,
>
>//oscar

Received: from po1.bbn.com (PO1.BBN.COM [192.1.50.38]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id SAA08777 for ; Tue, 16 Jan 2001 18:03:54 -0800 (PST)
Received: from [128.33.238.30] (TC059.BBN.COM [128.33.238.59]) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id VAA19171; Tue, 16 Jan 2001 21:09:15 -0500 (EST)
Mime-Version: 1.0
X-Sender: [email-masked]
Message-Id:
In-Reply-To:
References:
Date: Tue, 16 Jan 2001 21:04:13 -0500
To: "Slone, Skip"
From: Stephen Kent
Subject: RE: DPD & DPV requirements
Cc: PKIX-List
Content-Type: text/plain; charset="us-ascii" ; format="flowed"

Skip,

>Steve,
>
>Judging from your response, I think I did both of us a disservice by
>providing too many details from my stream of consciousness. Here's the
>distilled essence of what I intended to say:
>
>In your requirements document you wrote, "Finally, this analysis suggests
>that there are relatively few differences between a DPD and a DPV server ...
>[T]he WG must decide if two distinct protocol formats, with different syntax
>are warranted, or if a single [one] is appropriate." You then went on to
>conclude that they were sufficiently similar to justify a single set of
>requirements.
>
>Based on the way the discussions have gone, I'm questioning this conclusion.
>By separating the two, DPV could focus on simplicity and efficiency (to
>better serve highly constrained clients), while DPD focuses on completeness
>(to serve the needs of highly capable, but perhaps contextually constrained
>clients). DPV could consume DPD services, creating a complete solution to a
>wide range of problems.
>
>It is this last paragraph that I'd like comment on. Without some sense of
>agreement at this conceptual level, it's fruitless to dig into details.
>

I think we are seeing some divergence in arguments for the two types
of servers, wrt queries and responses. They may be small enough to
use a unified format with options, or we may have two distinct
formats with a lot of overlap. I'm not wedded to either approach.
But, the need for both severs to perform path validation still seems
to be true.

Steve

Received: from po1.bbn.com (PO1.BBN.COM [192.1.50.38]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id SAA08733 for ; Tue, 16 Jan 2001 18:03:37 -0800 (PST)
Received: from [128.33.238.30] (TC059.BBN.COM [128.33.238.59]) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id VAA19166; Tue, 16 Jan 2001 21:08:59 -0500 (EST)
Mime-Version: 1.0
X-Sender: [email-masked]
Message-Id:
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Date: Tue, 16 Jan 2001 21:00:46 -0500
To: Steve Hanna
From: Stephen Kent
Subject: Re: DPD & DPV Basics
Cc: PKIX List
Content-Type: multipart/alternative; boundary="============_-1232425100==_ma============"

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

Steve,

>Stephen Kent wrote:
> > I agree with your example, in almost every detail (I'd like to see
> > reference to the trust anchors in the call, not have the reference
> > implicit by client ID).
>
>I'm glad to hear we're approaching agreement on this. Why would you like
>to make the trust anchors explicit, especially if the rest of the
>validation parameters are implicit? Or are you simply arguing that the
>client should have consider flexibility in deciding which parameters are
>explicit and which ones implicit?

I'm open to specifying parameters as a mix of explicit ones and ones
specified by reference to a policy configured at the server, with the
explicit ones overriding the specified ones, UNLESS the policy
precludes such override. I think this is what the strawman spec says.

> > I think the current spec alludes to the capability you describe,
> > specifically it says:
> >
> > "For a non-PKI aware, non-ASN.1-capable client, the results returned
> > by the DPV protocol should not be merely a certificate and a status
> > indication. Rather, the contents of a certificate that are relevant to
> > the client application should be returned as distinct values, in a
> > syntax appropriate for the client. For example, the public key and
> > associated algorithm, the subject name (and/or alternate names) and
> > the issuer name (and alternate names), the key usage bits, and the
> > extended key usage field are all candidate values to be returned as
> > distinct objects to the client."
> >
> > We have not included these specific requirements so far, because we
> > have not agreed whether it is appropriate to provide the results in
> > ASN.1 or via some other means, a tension noted elsewhere in the
> > requirements spec.
>
>It sounds like we need to decide whether non-PKI aware,
>non-ASN.1-capable clients need to be supported. If so, we should
>probably define a set of requirements for such clients and include this
>item in that list. I would suggest that such clients are an important
>group and should be supported.

I put this question to the list in my strawman spec over 2 weeks ago,
and have not yet gotten a concrete proposal on how to accommodate
such clients. I will soon decide that we will NOT support them for
now, unless I see such a proposal.

> > I would expect the (IKE) client to send in the target cert and either
> > explicit validation parameters, or a reference to a stored set.
> > Checking the key usage could be done at the server or in the client.
> > But I do expect the client to do the ID matching against the returned
> > cert or cert contents. I would not want the the server to do this
> > because it is application specific and we don't want to require
> > servers to know about such things for every application that might
> > make use of them.
>
>I am also reluctant to have the server perform application-specific
>checks. But matching an ID against a set of subject names and subject
>alternative names can be complicated. This is especially true for email
>addresses and DNS host names (for TLS/SSL connections), since there are
>legacy conventions for including these names in X.500 names, as well as
>specific name types for subject alternative names.
>
>Therefore, I think there's a strong case that, at least for non-PKI
>aware, non-ASN.1-capable clients, the DPV server should perform this
>check.

I sympathize with the concern, but there is still the issue of why
should we do this application-specific function, vs. others that
might arise in the future?

Steve

--============_-1232425100==_ma============
Content-Type: text/enriched; charset="us-ascii"

Steve,

Stephen Kent wrote:

> I agree with your example, in almost every detail (I'd like to see

> reference to the trust anchors in the call, not have the reference

> implicit by client ID).

I'm glad to hear we're approaching agreement on this. Why would you
like

to make the trust anchors explicit, especially if the rest of the

validation parameters are implicit? Or are you simply arguing that the

client should have consider flexibility in deciding which parameters
are

explicit and which ones implicit?

I'm open to specifying parameters as a mix of explicit ones and ones
specified by reference to a policy configured at the server, with the
explicit ones overriding the specified ones, UNLESS the policy
precludes such override. I think this is what the strawman spec says.

> I think the current spec alludes to the capability you
describe,

> specifically it says:

> "For a non-PKI aware, non-ASN.1-capable client, the results returned

> by the DPV protocol should not be merely a certificate and a status

> indication. Rather, the contents of a certificate that are relevant
to

> the client application should be returned as distinct values, in a

> syntax appropriate for the client. For example, the public key and

> associated algorithm, the subject name (and/or alternate names) and

> the issuer name (and alternate names), the key usage bits, and the

> extended key usage field are all candidate values to be returned as

> distinct objects to the client."

> We have not included these specific requirements so far, because we

> have not agreed whether it is appropriate to provide the results in

> ASN.1 or via some other means, a tension noted elsewhere in the

> requirements spec.

It sounds like we need to decide whether non-PKI aware,

non-ASN.1-capable clients need to be supported. If so, we should

probably define a set of requirements for such clients and include
this

item in that list. I would suggest that such clients are an important

group and should be supported.

I put this question to the list in my strawman spec over 2 weeks ago,
and have not yet gotten a concrete proposal on how to accommodate such
clients. I will soon decide that we will NOT support them for now,
unless I see such a proposal.

> I would expect the (IKE) client to send in the target cert
and either

> explicit validation parameters, or a reference to a stored set.

> Checking the key usage could be done at the server or in the client.

> But I do expect the client to do the ID matching against the
returned

> cert or cert contents. I would not want the the server to do this

> because it is application specific and we don't want to require

> servers to know about such things for every application that might

> make use of them.

I am also reluctant to have the server perform application-specific

checks. But matching an ID against a set of subject names and subject

alternative names can be complicated. This is especially true for
email

addresses and DNS host names (for TLS/SSL connections), since there
are

legacy conventions for including these names in X.500 names, as well
as

specific name types for subject alternative names.

Therefore, I think there's a strong case that, at least for non-PKI

aware, non-ASN.1-capable clients, the DPV server should perform this

check.

I sympathize with the concern, but there is still the issue of why
should we do this application-specific function,
vs. others that might arise in the future?

Steve

--============_-1232425100==_ma============--

Received: from geos.coastside.net (geos.coastside.net [207.213.212.4]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id QAA05734 for ; Tue, 16 Jan 2001 16:08:46 -0800 (PST)
Received: from heatherdale (dsl-63-194-153-52.coastside.net [63.194.153.52]) by geos.coastside.net (8.11.0/8.11.1) with SMTP id f0H0E8c12574; Tue, 16 Jan 2001 16:14:08 -0800 (PST)
From: "Michael Myers"
To: "Covey, Carlin" , "PKIX List"
Subject: RE: DPD & DPV Basics
Date: Tue, 16 Jan 2001 16:18:13 -0800
Message-ID:
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.00.2314.1300
Importance: Normal
In-Reply-To: <[email-masked]>

Carlin,

It might also be useful to extend this concept the "asymmetric OCSP" case,
where a client's trusted server not only confirms the validity of the
client's certificate via an external trust server but acquires from that
same server an assertion of the validity of its (the protocol server's)
certificate. This response could be included in-band to the client and so
relieve the client of any further interaction with infrastructure to
establish the server's trustworthiness. IPSEC's protocol architecture seems
well suited to this design.

Mike

> -----Original Message-----
> From: Covey, Carlin [mailto:[email-masked]]
> Sent: Monday, January 15, 2001 1:21 PM
> To: PKIX List
> Subject: RE: DPD & DPV Basics
>
>
> It seems to me that DPV would be very useful for devices that
> are bandwidth limited, such as cell phones, or are protocol-
> complexity-limited, such as VPN devices implemented in hardware.
> In both these cases the device would not be interested in the
> supporting evidence, just a good/not-good indication.
>
> Regards,
> Carlin
>
> ----------------------------
> - Carlin Covey
> Cylink Corp.
>
> -----Original Message-----
> From: Steve Hanna [mailto:[email-masked]]
> Sent: Monday, January 15, 2001 12:10 PM
> To: Stephen Kent
> Cc: PKIX List
> Subject: Re: DPD & DPV Basics
>
>
> Stephen Kent wrote:
> > Maybe the root of our disagreement is the assumption of what
> > the common requirement is for a DPV client. My strawman cites
> > PKI-ignorant (to use Denis' term) clients as a major motivation for
> > DPV, which seems incompatible with a DPV server that requires perfect
> > inputs.
>
> From this message and several others, I gather that the basic motivation
> for having a DPV server is to provide services to simple, "PKI-ignorant"
> clients. Could someone please supply some examples of such clients? What
> protocols will they be speaking (other than the DPV protocol)? This
> would be very useful in determining the proper requirements for the DPV
> protocol.
>
> Thanks,
>
> Steve
>

Received: from geos.coastside.net (geos.coastside.net [207.213.212.4]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA04762 for ; Tue, 16 Jan 2001 15:54:51 -0800 (PST)
Received: from heatherdale (dsl-63-194-153-52.coastside.net [63.194.153.52]) by geos.coastside.net (8.11.0/8.11.1) with SMTP id f0H00Kc11565; Tue, 16 Jan 2001 16:00:22 -0800 (PST)
From: "Michael Myers"
To: "Stephen Kent"
Cc: "PKIX-List"
Subject: RE: DPD & DPV requirements - Recursion Issues
Date: Tue, 16 Jan 2001 16:04:25 -0800
Message-ID:
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.00.2314.1300
Importance: Normal
In-Reply-To:

Steve,

An OCSP responder may aggregate data but choose not to aggregate risk. An
OCSP responder's response may (and I stress MAY) be nothing more than a
blind relay of an ultimate authority's assertion. There is nothing in our
current protocol syntax or semantics that precludes such deployment of this
protocol. Hence my assertion regarding transparency.

Mike

> -----Original Message-----
> From: Stephen Kent [mailto:[email-masked]]
> Sent: Tuesday, January 16, 2001 12:40 PM
> To: Michael Myers
> Cc: PKIX-List
> Subject: RE: DPD & DPV requirements - Recursion Issues
>
>
> Mike,
>
> >
> > > . . .
> > > the question I asked was whether the OCSP response carried data that
> > > tied it to a requestor, not a responder.
> >
> >As Rick Salz noted, RFC 2560 enables such binding via the nonce
> mechanism.
> >Use of this mechanism is not however mandated. Also, Rich Akney was a
> >strong advocate of the OPTIONAL requestorName syntax in an OCSP request.
> >The definition of the production of response signature in RFC
> 2560 does not
> >include the contents of the request in its hash. We might wish
> to consider
> >amending this in the OCSPv2 I-D but it's not yet clear to me
> that we should
> >inhibit response transparency. A relying party might very well
> wish to know
> >who is ultimately standing behind a certificate.
>
> The nonce is not a big concern, if it is just a way to match a
> request and a response, and can safely be ignored by the client,
> given suitable protection for the client/server query/response
> exchange. The requestorName is more of an issue, as it makes clear
> that the client or the server was not the requestor, in the case of
> nested or recursive server interactions.
>
> I'm confused by your last sentence; presumably the OCSP responder
> stands behind the response, irrespective of the identity of the
> requestor, right?
>
> Steve
>
>

Received: from po1.bbn.com (PO1.BBN.COM [192.1.50.38]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAB29080 for ; Tue, 16 Jan 2001 14:04:48 -0800 (PST)
Received: from [128.33.238.30] (TC030.BBN.COM [128.33.238.30]) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id RAA03546; Tue, 16 Jan 2001 17:10:17 -0500 (EST)
Mime-Version: 1.0
X-Sender: [email-masked] (Unverified)
Message-Id:
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Date: Tue, 16 Jan 2001 15:41:25 -0500
To: Michael Myers
From: Stephen Kent
Subject: RE: DPD & DPV requirements
Cc: [email-masked]
Content-Type: text/plain; charset="us-ascii" ; format="flowed"

Mike,

>Steve, Frank, all:
>
>The ReqCert syntax of OCSPv2 imports Certificate syntax from X.509, yielding
>a single X.509 certificate in a request. At this stage, I have no objection
>to amending ReqCert to use CertificateSet syntax defined in RFC 2630 (i.e.
>CMS) to enable a "certificate lump" since the syntax of CertificateSet
>enables specification of a single certificate (although prefaced then by a
>SET OF, but otherwise we're looking at a SEQ OF anyway). OCSPv2 is already
>requiring linkage to 2630 via import of IssuerAndSerialNumber for
>certificate identification purposes.

I was not suggesting that the target cert be transferred this way,
only the lump of certs that a client might optionally send along to a
server.

Steve

Received: from po1.bbn.com (PO1.BBN.COM [192.1.50.38]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA29068 for ; Tue, 16 Jan 2001 14:04:42 -0800 (PST)
Received: from [128.33.238.30] (TC030.BBN.COM [128.33.238.30]) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id RAA03527; Tue, 16 Jan 2001 17:10:10 -0500 (EST)
Mime-Version: 1.0
X-Sender: [email-masked] (Unverified)
Message-Id:
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Date: Tue, 16 Jan 2001 15:39:46 -0500
To: Michael Myers
From: Stephen Kent
Subject: RE: DPD & DPV requirements - Recursion Issues
Cc: PKIX-List
Content-Type: text/plain; charset="us-ascii" ; format="flowed"

Mike,

>
> > . . .
> > the question I asked was whether the OCSP response carried data that
> > tied it to a requestor, not a responder.
>
>As Rick Salz noted, RFC 2560 enables such binding via the nonce mechanism.
>Use of this mechanism is not however mandated. Also, Rich Akney was a
>strong advocate of the OPTIONAL requestorName syntax in an OCSP request.
>The definition of the production of response signature in RFC 2560 does not
>include the contents of the request in its hash. We might wish to consider
>amending this in the OCSPv2 I-D but it's not yet clear to me that we should
>inhibit response transparency. A relying party might very well wish to know
>who is ultimately standing behind a certificate.

The nonce is not a big concern, if it is just a way to match a
request and a response, and can safely be ignored by the client,
given suitable protection for the client/server query/response
exchange. The requestorName is more of an issue, as it makes clear
that the client or the server was not the requestor, in the case of
nested or recursive server interactions.

I'm confused by your last sentence; presumably the OCSP responder
stands behind the response, irrespective of the identity of the
requestor, right?

Steve

Received: from po1.bbn.com (PO1.BBN.COM [192.1.50.38]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA29053 for ; Tue, 16 Jan 2001 14:04:30 -0800 (PST)
Received: from [128.33.238.30] (TC030.BBN.COM [128.33.238.30]) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id RAA03387; Tue, 16 Jan 2001 17:09:50 -0500 (EST)
Mime-Version: 1.0
X-Sender: [email-masked] (Unverified)
Message-Id:
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Date: Tue, 16 Jan 2001 14:30:07 -0500
To: Ambarish Malpani
From: Stephen Kent
Subject: RE: DPD & DPV Basics
Cc: PKIX List
Content-Type: text/plain; charset="us-ascii" ; format="flowed"

Ambarish,

>Hi Steve,
> I agree with both this mail and the one you sent to Carlin
>earlier - I would fully expect the client to send the server
>the kind of use it wants to use the certificate for (IPSec, S/MIME,
>SSL) and the appropriate information that would depend on the
>protocol (the e-mail address of the sender/recipient, the address
>it thinks it is connecting to, etc).
>
>The DPV server needs to figure out what the right key usage/
>extended key usage bits are, how to do validation, etc. I would
>expect servers to support commonly known protocols and be expandable
>for other/future protocols.

As I mentioned in my response to Steve Hanna, I think this is not a
good model, because it suggests that the protocol and server can
anticipate all the requirements for ID matching that any client might
require. I prefer a model in which the server returns extracted data
from the cert for use by the client, for clients that are not capable
of parsing the target cert.

Steve

Received: from mailgw2a.lmco.com (mailgw2a.lmco.com [192.91.147.7]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA25286 for ; Tue, 16 Jan 2001 12:39:42 -0800 (PST)
Received: from emss03g01.ems.lmco.com (emss03g01.ems.lmco.com [141.240.4.144]) by mailgw2a.lmco.com (8.8.8/8.8.8) with ESMTP id PAA20860; Tue, 16 Jan 2001 15:45:15 -0500 (EST)
Received: from CONVERSION-DAEMON by lmco.com (PMDF V5.2-32 #38888) id <[email-masked]>; Tue, 16 Jan 2001 15:44:20 -0500 (EST)
Received: from emss03i00.ems.lmco.com ([141.240.31.211]) by lmco.com (PMDF V5.2-32 #38888) with ESMTP id <[email-masked]>; Tue, 16 Jan 2001 15:44:09 -0500 (EST)
Received: by emss03i00.orl.lmco.com with Internet Mail Service (5.5.2650.21) id ; Tue, 16 Jan 2001 15:45:17 -0500
Content-return: allowed
Date: Tue, 16 Jan 2001 15:45:17 -0500
From: "Slone, Skip"
Subject: RE: Basic Cert-2-Directory mapping question
To: "[email-masked]'"
Cc: "'Bob Jueneman'" , [email-masked]
Message-id:
MIME-version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-type: text/plain
Content-transfer-encoding: 7BIT

John,

You wrote, "I don't think the proposed "dir" attribute is semantically very
different
from any other naming attributes" and that "the mechanism for searching has
to treat the "dir" RDN somewhat differently from the other RDNs."

My concern with different semantics is not a matter of degree; it's the fact
that the semantics of DN must change -- at all -- to incorporate this
concept. If there are other ways to deal with the problem, I see no
compelling reason to change the semantics of something so fundamentally and
deeply entrenched in dozens of standards as DN.

I must add here that I have not always opposed this concept. I actually
pursued this line of thinking two or three years ago in a different forum
(X.500) while working a different problem (Related Entries). At that time, I
was proposing that a "dnQualifer" be added to a DN to specify an access
point through which the entry named by the DN could be found. While pursuing
that line of thinking (which explored several syntactic/semantic variants),
the semantic-shift problem kept getting in the way. In the end, we settled
on a separate mechanism rather than change the semantics of DN. Flawed as it
may be, DN is still a widely accepted concept; changing it will be an uphill
struggle.

-- Skip

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Tuesday, January 16, 2001 10:52 AM
To: Slone, Skip
Cc: 'Bob Jueneman'; [email-masked]
Subject: RE: Basic Cert-2-Directory mapping question

>As I read your suggestion, you want to add an element to the DN
>that directs the user to the appropriate directory. The new
>element is syntactically an RDN, but semantically is something
>different. The resulting new-style DN appears to me to
>semantically comparable to an LDAP URL.

I don't think the proposed "dir" attribute is semantically very different
from any other naming attributes. What we're trying to do with names in
certificates is to maintain the X.500 illusion that a DN uniquely
identifies an entry in some global directory. But we don't have a single
global directory; instead we have a collection of directories which don't
talk to one another - i.e. instead of the single DN root assumed by X.500,
we actually have multiple roots, one for each directory.

The obvious way to resolve this sort of problem is to introduce a new
"meta-root" that sits above all the directory roots. This corresponds to
adding an RDN to the most significant end of each DN that names the
particular directory within which the named entry lies. Precisely how a
directory is named is TBD, but it must give an end-system enough
information to for a query for that directory, without requiring prior
knowledge of the directory, so an obvious possibility (for an LDAP
directory) is scheme and hostport portions of an LDAP URL.

Individual directories could either store this attribute explicitly within
the entry (which would mean that these directories could be directly
searched using the full DN) or, more likely, the "dir" attribute would have
to be removed before searching an individual directory. So yes, the
mechanism for searching has to treat the "dir" RDN somewhat differently
from the other RDNs, but in terms of a naming model, it behaves just like
any other RDN.

As Bob points out, the "dir" attribute could be multi-valued, allowing
information about an entry to reside in multiple directories (provided that
the directories can all agree to use the same name for the entry).

John

"Slone, Skip" on 01/16/2001 09:16:13 AM

To: "'Bob Jueneman'"
cc: [email-masked]
Subject: RE: Basic Cert-2-Directory mapping question

Bob,

I'm glad to hear we agree on the nature of the problem. From that point of
agreement, we can move the discussion to one of "what do we do about it?"

In abstract terms, it appears to me that "what we can do about it" falls
into two broad categories:
1) we can create a mechanism for explicitly identifying the appropriate
directory, or
2) we can remove the barriers that currently prevent the directory from
being discovered implicitly based upon existing information

I would say that your approach fits in category 1, while my approach fits
in
category 2. Either approach has validity IMHO and is worthy of
consideration.

As I read your suggestion, you want to add an element to the DN that
directs
the user to the appropriate directory. The new element is syntactically an
RDN, but semantically is something different. The resulting new-style DN
appears to me to semantically comparable to an LDAP URL.

Assuming we're on the same page up to this point, I'll say that my concern
with this approach is that it changes the semantics of DN, potentially
causing interoperability problems in that both clients and servers that
understand the semantics as currently defined would have problems when
encountering the new-style name. If we were to go with a "category 1" fix
to the problem, I would rather see a new mechanism employed, such as a new
PKIX-defined certificate extension that explicitly gives repository
location
information. As a new construct, we would be free to define whatever
semantics we want, and could readily use existing concepts such as URLs.

Now, in defense of my approach, I think we can all probably agree that *IF*
the original concept of X.500-style distributed, global name resolution
were
a practical reality, we would be able to plug into the nearest DSA and find
the named entry regardless of where it resides physically. Of course I
emphasized the word "if" to imply that we can also probably agree that that
original X.500 concept is not going to occur anytime soon, if ever. What I
was proposing instead, was a "category 2" fix -- a way of removing that
barrier by providing an alternative way of doing distributed name
resolution. The alternative mechanism I proposed was one which builds upon
an existing, working, global infrastructure that already has the requisite
registration infrastructure in place. Without digging into the specifics,
I
would like to know if you or others believe that this *concept* has merit.

-- Skip

-----Original Message-----
From: Bob Jueneman [mailto:[email-masked]]
Sent: Monday, January 15, 2001 2:11 PM
To: [email-masked]
Cc: [email-masked]
Subject: RE: Basic Cert-2-Directory mapping question

Skip,

I don't particularly like the mechanism you've proposed, at least as
I understand it. But I absolutely and completely agree with you
as to the nature of the problem that has to be solved.

Civil attribute type names will always be with us, and hence must be
dealt with, for at least two fundamental reasons:

1. An address is not a name, although it may be a pseudonym. I
don't want to be forced to change my identity, or to an extent
my basis "self-hood," every time I change my ISP. And I especially
don't want some system administrator telling me that my name
must be limited to 8 characters, or that I have to change my name
because someone else has already used that same name within
that same system administrator's ill-conceived naming scheme.

2. E-mail address and other cyberspace identifiers fail to provide the
essence of PKI from a nonrepudiation standpoint, i.e., what I call the
"where do you send the sheriff" question.

Granted, not all uses of PKI will or should involve legal nonrepudiation.
But to the extent that at least some uses WILL have legal consequences,
then the establishment of a globally unique and credible identity that is
grounded in "meat-space" rather then cyberspace is absolutely essential.

For those legally binding transaction to be worth anything at all, they
have to be enforceable. And that means that a judgement may have
to be enforced upon someone, either by seizing the assets or putting
them in jail. And only in science fiction does the sheriff ride off into
cyberspace to arrest someone.

If I as a relying party wish to trade with someone, then I either want to
charge her credit card (in which case PKI is demonstrably not necessary)
or I want to know that she is the Mary Smith who resides at 123 Anywhere
St,
Metropolis, NY.

The inclusion of that civil address not only servers to distinguish her
from the other Mary Smiths, but more importantly it establishes a nexus
or link between her identity and her probable whereabouts, and
probably valuable real property as well.

So civil addresses, both corporate or "organizationalPerson", or the
harder-to-deal-with residentialPerson type will presumably always
be with us, and will have to be dealt with.

And unfortunately, perhaps, here int he US the simple and inescapable
fact of the matter is that neither the federal nor the state governments
operate the type of presumptively authoritative name registration
authorities that are relatively common in other countries. I am perfectly
free to move from one city to another, or from address to another in
the same city, and to never notify anyone in authority at all, including
the tax authorities. No one will ever say, "Papers, please."

(Granted, if I choose to do that I may not be able to register to vote,
but over half the population doesn't vote anyway. And the last time
I registered, no one checked to see that I actually lived there -- that
one of the problems we have with our voting system, even outside
of the State of Florida.. And I may not be able to get a driver's license
in order to legally drive a car, but a lot of illegal immigrants don't have
driver's licenses either, although that doesn't keep them from driving.)

So merely trying to ignore the problem of civil addressing schemes
won't solve that problem. And neither will various approaches that
make certain assumptions about monopoly name registration
authorities, or try to divine or impute where a directory containing
a particular name might be found based on some kind of a Karnak
mentalist act.

The primary issue is not the question of whether the name space
is flat or hierarchical, or how hierarchical, much less what the
"approved" schema is. What will be, will be, for reasons that
are beyond our scope and power to influence, even if we wanted
to.

So.

We cannot force a person to deposit his certificate or other useful
information into a specific directory, even if we wanted to. Nor can
we reliably impute a likely directory where such information might
be found, at least in the absence of a monopoly or governmental
mandate.

The best we can do is to ASK the user where he has deposited
such information, if anywhere, and to include that information
EXPLICITLY in any directory or pseudo-directory reference, such
as a DN.

Although at one time I liked the notion of prefixing the DN with a
URL, I have come to believe that John Wray's suggestion is the
better way forward.

He said:
>
>Bob,
>
>Accepting the fact that the X.500 dream of a single global directory is
not
>going to happen any time soon, DNs can still be turned into globally
>significant pointers into a federation of directories in the way you
>suggest, but it doesn't require altering the DN syntax (and therefore
>doesn't have to break existing implementations). All that's needed is a
DN
>attribute that names the particular directory within which the name
>resides. e.g. instead of "c=us;..;cn=My Name" you'd have "dir=My
>Directory;c=us;...;cn=My Name", where "My Directory" is the URL of a
>directory access point.

By including an explicit directory qualifier of the form dir="directory
URL"
at the root (top) of the RDN chain, we have implicitly qualified all of the
rest
of the RDN, which is a Good Thing.

By defining the syntax of the "dir" attribute appropriately, we could
include
both the access type (LDAP, http, etc.) and port number appropriately,
either a default or explicitly indicated.

And by making the dir component multivalued, we could accommodate
a choice of multiple directories and multiple directory types.

Once again -- the essence of the problem is not the format of the directory
name but where a directory containing that name can be found.
Including that information as a top-level qualifying component solves that
problem (and potentially several others, such as name scope qualification)
very neatly.

Bob

Robert R. Jueneman
'Security Architect
Novell, Inc. -- the leading provider of Net services software
>
>
>
>
>
>
>
>>>> "Slone, Skip" 01/15/01 09:08AM >>>
>Oscar,
>
>No offense taken, thus no apology needed.
>
>My comments from the soapbox last week were actually intended for the
>community at large, and were meant to convey frustration at the apparent
>unwillingness of solution providers in general to hear about -- and solve
--
>real world problems that are faced by users like myself in large, complex
>environments.
>
>When I say "my environment is not so simple," the response I hear is
"let's
>not talk about the complexity; let's make some simplifying assumptions
>instead."
>
>When I say "I have a nail AND a screw and need to put them both in the
>wall," the response I hear is "we have provided you with a perfectly
>adequate hammer, therefore you don't have a screw."
>
>As I was using the nail/hammer analogy, dc-based names are the nails;
>civil-attribute-based names are the screws. No matter how good a job my
>company does of using nails and nails alone, we still have tens of
thousands
>of trading partners, many of whom prefer screws to nails and will continue
>to use them indefinitely. Without a screwdriver, it's hard to do business
>with them.
>
>I don't really care what the screwdriver looks like. I've suggested a
>fairly simple design that I think will work. So far, no one has commented
on
>the design. What I've heard instead is a chorus of "we still don't like
>screws." Well, I don't like them either, but I still have to deal with
>them. If I'm simply overlooking a screwdriver that we have lying around
>somewhere, I would appreciate someone pointing it out to me.
>
> -- Skip
>
>
>-----Original Message-----
>From: Oscar Jacobsson [mailto:[email-masked]]
>Sent: Thursday, January 11, 2001 5:16 PM
>To: Slone, Skip
>Cc: 'Sharon Boeyen'; [email-masked]
>Subject: RE: Basic Cert-2-Directory mapping question
>
>
>> From: Slone, Skip [mailto:[email-masked]]
>> In response to this, I'm inclined to join Sharon on Marshall's soapbox
and
>> echo her words:
>>
>> "... I believe a more constructive approach is to accept the fact that
>> different parts of the world and different environments will use a
variety
>> of nameforms ... We are not the global naming police either and should
not
>> try to impose the rules that anyone uses to name entities to which they
>> issue certificates."
>
>I'm sorry if I came across as clamouring for rules be imposed. I know that
>this working group has a tendency to be wary of suggestions that don't
cater
>for distinguished names containing cat MPEGs, so I should probably have
been
>more careful. The requirements I suggested were for a possible naming
>standards document, conformance to which need not be enforced.
>
>The case at hand is not, IMHO, one of dictating that "all distinguished
>names must be according to our will, or you shall feel our wrath". A
>document however, outlining a naming strategy that would require of the
>users of certificates named accordingly no a-priori knowledge of their
>issuer (save for eventually having to reach something explicitly trusted
in
>the chain) in order to perform path validation, is something I would
>personally consider very valuable indeed. I'm reasonably confident that
>organizations intending to act as certification authorities or trusted
third
>parties would agree.
>
>> And to quote someone Sharon and I both know, "If all you have is a
hammer,
>> every problem looks like a nail."
>
>It seems I was less than clear here as well. :-(
>
>My intention was to point out that there are actually two separate
problems
>here (one nail, if you will, and one screw) each looking for its own
>solution:
>
>1. Defining a repository, and subsequently entry, discovery process for
>arbitrarily named entries.
>
>2. Defining a naming scheme that _if applied_ would automate this
repository
>and entry discovery process.
>
>I am only trying to address the second of these problems. The first is
only
>an issue because nobody seems to have properly addressed the second before
>deploying certificates on the Internet en masse. The further we wait
before
>addressing number two, the more of a problem number one will become.
>
>I should probably make a habit of pointing out that the opinions stated
here
>are my very own, and not necessarily those of my employer.
>
>Cheers,
>
>//oscar

Received: from indy.gradient.com ([email-masked] [192.92.110.1]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA23669 for ; Tue, 16 Jan 2001 12:14:11 -0800 (PST)
Received: from bigbird.gradient.com (bigbird.gradient.com [192.92.110.50]) by indy.gradient.com (8.9.1a/8.9.1) with ESMTP id PAA18471; Tue, 16 Jan 2001 15:19:43 -0500 (EST)
Received: by bigbird.gradient.com with Internet Mail Service (5.5.2650.10) id ; Tue, 16 Jan 2001 15:18:02 -0500
Message-ID: <[email-masked]>
From: Hal Lockhart
To: "'Steve Hanna'"
Cc: PKIX List
Subject: RE: DPD & DPV Basics
Date: Tue, 16 Jan 2001 15:18:02 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.10)
Content-Type: text/plain; charset="iso-8859-1"

> Typical IETF situation. We all agree that the answer is
> obvious. We just
> don't agree what the answer is!

Wow! I'm going to save that one. I know we will be quoting it years from
now.

Hal

Received: from mailgw2a.lmco.com (mailgw2a.lmco.com [192.91.147.7]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA21985 for ; Tue, 16 Jan 2001 11:35:00 -0800 (PST)
Received: from emss03g01.ems.lmco.com (emss03g01.ems.lmco.com [141.240.4.144]) by mailgw2a.lmco.com (8.8.8/8.8.8) with ESMTP id OAA09660; Tue, 16 Jan 2001 14:40:14 -0500 (EST)
Received: from CONVERSION-DAEMON by lmco.com (PMDF V5.2-32 #38888) id <[email-masked]>; Tue, 16 Jan 2001 14:38:51 -0500 (EST)
Received: from emss03i00.ems.lmco.com ([141.240.31.211]) by lmco.com (PMDF V5.2-32 #38888) with ESMTP id <[email-masked]>; Tue, 16 Jan 2001 14:37:50 -0500 (EST)
Received: by emss03i00.orl.lmco.com with Internet Mail Service (5.5.2650.21) id ; Tue, 16 Jan 2001 14:38:57 -0500
Content-return: allowed
Date: Tue, 16 Jan 2001 14:38:55 -0500
From: "Slone, Skip"
Subject: RE: DPD & DPV requirements
To: "'Stephen Kent'"
Cc: PKIX-List
Message-id:
MIME-version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-type: text/plain
Content-transfer-encoding: 7BIT

Steve,

Judging from your response, I think I did both of us a disservice by
providing too many details from my stream of consciousness. Here's the
distilled essence of what I intended to say:

In your requirements document you wrote, "Finally, this analysis suggests
that there are relatively few differences between a DPD and a DPV server ...
[T]he WG must decide if two distinct protocol formats, with different syntax
are warranted, or if a single [one] is appropriate." You then went on to
conclude that they were sufficiently similar to justify a single set of
requirements.

Based on the way the discussions have gone, I'm questioning this conclusion.
By separating the two, DPV could focus on simplicity and efficiency (to
better serve highly constrained clients), while DPD focuses on completeness
(to serve the needs of highly capable, but perhaps contextually constrained
clients). DPV could consume DPD services, creating a complete solution to a
wide range of problems.

It is this last paragraph that I'd like comment on. Without some sense of
agreement at this conceptual level, it's fruitless to dig into details.

-- Skip

-----Original Message-----
From: Stephen Kent [mailto:[email-masked]]
Sent: Monday, January 15, 2001 10:26 PM
To: Slone, Skip
Cc: PKIX-List
Subject: RE: DPD & DPV requirements

Skip,

>Steve,
>
>Thanks for your response. You've raised some good points that have caused
>me to reflect a little deeper on how this subject would play out. In my
>reflection, I reread the requirements message that prompted all this
>discussion. The question now in my mind is whether we should take another
>look at the differences between the DPV and DPD services. As of this moment
>in time, it seems to me that perhaps we should consider the two to be
>distinctly different animals, and that we should modify the requirements
>document accordingly. I know this is bordering on radical, so I ask you to
>bear with me for a few minutes while I explain my thinking...
>
>Specifically, if we consider a DPV server to be nothing more than a special
>case of a DPD client, we can keep the DPV client/server protocol extremely
>simple. At the same time, we can allow the DPD client/server protocol to
>represent the complex, signed, nested data structures necessary to convey
>the various scenarios discussed on this thread over the last several days.
>This separation also provides the restrictions necessary to accommodate the
>concerns expressed regarding concepts like transitive trust.

I think you have already lost me. Maybe this is because I have not
seen strong arguments that result in the need for recursive call
support, but I'l read on ...

>If we go down this path of cleanly separating DPV and DPD services, a DPV
>client could request service using an extremely simple query. For example,
>(other than the PDU headers) the query could contain as little as a
>certificate, and the result could be as simple as a boolean.

The client must specify validation parameters, either directly or via
reference to a policy, so no, the query cannot be as simple as you
suggest.

>The client
>might also express something like a required policy along with the
>certificate, but a default scenario would allow this part to be omitted,
>catering to highly constrained and/or "PKI-ignorant clients" (to quote you
>and Denis).

PKI-ignorant clients are candidates for using the reference approach
to specifying the validation parameters.

>Alternatively, the response might express a slightly more
>complex thought like "valid under policy X."

I think this is the minimum, simple query, and even here we need a
strong reference to the policy, e.g., a hash to go along with the URL.

>The DPV server would be a
>highly capable PKI-aware entity, responsible for obtaining the primitive
>elements (certs and certificate validity status information) from whatever
>sources are available, and for making a determination as to whether the
>presented certificate is valid under some given policy at some given point
>in time.

The "some policy" must be well defined, by the client.

>The determination of validity could be determined, in part, by the
>sources of the primitive elements. For example, if a blob of certs and
>status information is obtained within a signed structure, the validity of
>the enclosing signature would be taken into account.

You're loosing me again. Is the suggestion that receipt of a signed
blob of certs from some source relieves the DPV server from needing
to verify these certs? One could imagine that, if we allow recursive
calls among DPV servers, but this makes for a more complex system and
syntax, and I'd want to see good arguments about the benefits before
we head down that path.

>By contrast, DPD would be a vehicle for gathering the primitive elements
>needed to perform path validation, but would not necessarily make any
>judgements on the validity of those elements.

If a DPD server returns junk as an acceptable response I don't think
that's especially useful, and it makes verification of "correct
operation" either very hard or trivial :-).

> The DPD protocol would be
>sufficiently flexible to allow the DPD client to express a variety of
>starting elements (e.g., certs, CRLDPs, etc.) and/or path-related
>constraints (name constraints, policy constraints, policy mapping
>constraints, etc., as well as any new DPD-specific constraints). A service
>control in the protocol could allow the specification of whether the client
>requires complete paths in the response or if partial paths are acceptible.
>The DPD server could be permitted to gather its data from any available
>source (LDAP server, web server, FTP server, OCSP server, or DPD server),
as
>long as that source is consistent with the constraints specified by the DPD
>client. The response PDU, which could (should?) itself be a signed
>structure, can contain any primitive elements gathered by this DPD server,
>as well as any nested, signed structures that resolve to primitive elements
>at some arbitrary, yet pragmatically constrained level of depth. I know it
>sounds complicated, but I suspect a fairly straightforward, recursive data
>structure could be specified to convey such a PDU.

Yes, it sounds complicated, and it is not clear what problem we're
solving by allow this complexity. The proposed requirement for a DPD
server is a simple one to understand, i.e., the server performs the
function of collecting a complete cert path and associated revocation
status data controlled by the same set of parameters that the client
will use to validate the path. That means that the answer returned to
a client will be useful for verifying the target cert, which is the
goal for the client in the first place. You don't include details to
motivate what the client does with the potentially piecemeal data
returned by a DPD server as suggested above. I think you need to
provide that, not just the high level scenario that initiated this
threat, if we are to consider this alternative.

>In the scenario I previously described, companies A and B would provide DPD
>services at their boundaries. The RP inside company A would request either
>DPV or DPD services from a company A server. That server would then request
>DPD services from company B's server. The path validation elements would be
>collected at company A (either at the DPV server or the RP itself) where
the
>determination of validity would take place. In this scenario, there is no
>need for DPV recursion, but DPV or DPD servers are permitted to act as DPD
>clients as necessary. Path validation itself takes place at one point,
using
>all the essential elements gathered, and based in part on validating the
>signatures on DPD responses from non-controlled sources.
>
>Note that actual implementations could provide a combined DPV/DPD service
>without implementing the more complex DPD protocol by keeping the DPV/DPD
>interface internal to the system.

of course.

>Is this too radical a departure from the previously articulated
>requirements?

Well, it's not the radical part that bothers me; it's the lack of
explicit, detailed motivation. The scenario you described can be
satisfied by the previous proposal for DPD and DPV services, so the
challenge is to articulate why creating a more complex interface to a
DPD server, but allowing it to return possible junk, is desirable. I
just don't see the point, yet.

Steve

Received: from geos.coastside.net (geos.coastside.net [207.213.212.4]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA21229 for ; Tue, 16 Jan 2001 11:27:58 -0800 (PST)
Received: from heatherdale (dsl-63-194-153-52.coastside.net [63.194.153.52]) by geos.coastside.net (8.11.0/8.11.1) with SMTP id f0GJXOs29188; Tue, 16 Jan 2001 11:33:24 -0800 (PST)
From: "Michael Myers"
To: "Frank Balluffi" , "'Michael Myers'"
Cc:
Subject: RE: DPD & DPV requirements
Date: Tue, 16 Jan 2001 11:37:29 -0800
Message-ID:
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.00.2314.1300
Importance: Normal
In-Reply-To: <[email-masked]>

I took it as the former.

Mike

> -----Original Message-----
> From: Frank Balluffi [mailto:[email-masked]]
> Sent: Monday, January 15, 2001 9:55 PM
> To: 'Michael Myers'
> Cc: [email-masked]
> Subject: RE: DPD & DPV requirements
>
>
> Mike Myers said:
>
> > The ReqCert syntax of OCSPv2 imports Certificate syntax from
> > X.509, yielding
> > a single X.509 certificate in a request. At this stage, I
> > have no objection
> > to amending ReqCert to use CertificateSet syntax defined in
> > RFC 2630 (i.e.
> > CMS) to enable a "certificate lump" since the syntax of CertificateSet
> > enables specification of a single certificate (although
> > prefaced then by a
> > SET OF, but otherwise we're looking at a SEQ OF anyway).
> > OCSPv2 is already
> > requiring linkage to 2630 via import of IssuerAndSerialNumber for
> > certificate identification purposes.
>
> I'm confused. Are people saying that the certificate whose path the client
> would like to discover or validate is in the unordered lump of
> certificates
> or that a separate lump of certificates may be sent to assist the
> server? I
> thought the latter.
>
> Frank
>

Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA19865 for ; Tue, 16 Jan 2001 11:15:40 -0800 (PST)
Received: from eastmail2.East.Sun.COM ([129.148.1.241]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA26113; Tue, 16 Jan 2001 11:21:12 -0800 (PST)
Received: from sunlabs.East.Sun.COM (sunlabs.East.Sun.COM [129.148.75.250]) by eastmail2.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id OAA26457; Tue, 16 Jan 2001 14:21:10 -0500 (EST)
Received: from sun.com (dhcp75-155 [129.148.75.155]) by sunlabs.East.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id OAA25907; Tue, 16 Jan 2001 14:21:09 -0500 (EST)
Message-ID: <[email-masked]>
Date: Tue, 16 Jan 2001 14:18:15 -0500
From: Steve Hanna
Organization: Sun Microsystems, Inc.
X-Mailer: Mozilla 4.75 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Stephen Kent
CC: PKIX List
Subject: Re: DPD & DPV Basics
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Stephen Kent wrote:
> I agree with your example, in almost every detail (I'd like to see
> reference to the trust anchors in the call, not have the reference
> implicit by client ID).

I'm glad to hear we're approaching agreement on this. Why would you like
to make the trust anchors explicit, especially if the rest of the
validation parameters are implicit? Or are you simply arguing that the
client should have consider flexibility in deciding which parameters are
explicit and which ones implicit?

> I think the current spec alludes to the capability you describe,
> specifically it says:
>
> "For a non-PKI aware, non-ASN.1-capable client, the results returned
> by the DPV protocol should not be merely a certificate and a status
> indication. Rather, the contents of a certificate that are relevant to
> the client application should be returned as distinct values, in a
> syntax appropriate for the client. For example, the public key and
> associated algorithm, the subject name (and/or alternate names) and
> the issuer name (and alternate names), the key usage bits, and the
> extended key usage field are all candidate values to be returned as
> distinct objects to the client."
>
> We have not included these specific requirements so far, because we
> have not agreed whether it is appropriate to provide the results in
> ASN.1 or via some other means, a tension noted elsewhere in the
> requirements spec.

It sounds like we need to decide whether non-PKI aware,
non-ASN.1-capable clients need to be supported. If so, we should
probably define a set of requirements for such clients and include this
item in that list. I would suggest that such clients are an important
group and should be supported.

> I would expect the (IKE) client to send in the target cert and either
> explicit validation parameters, or a reference to a stored set.
> Checking the key usage could be done at the server or in the client.
> But I do expect the client to do the ID matching against the returned
> cert or cert contents. I would not want the the server to do this
> because it is application specific and we don't want to require
> servers to know about such things for every application that might
> make use of them.

I am also reluctant to have the server perform application-specific
checks. But matching an ID against a set of subject names and subject
alternative names can be complicated. This is especially true for email
addresses and DNS host names (for TLS/SSL connections), since there are
legacy conventions for including these names in X.500 names, as well as
specific name types for subject alternative names.

Therefore, I think there's a strong case that, at least for non-PKI
aware, non-ASN.1-capable clients, the DPV server should perform this
check.

-Steve

Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA19306; Tue, 16 Jan 2001 10:58:44 -0800 (PST)
Received: from eastmail1.East.Sun.COM ([129.148.1.240]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA12159; Tue, 16 Jan 2001 11:04:16 -0800 (PST)
Received: from sunlabs.East.Sun.COM (sunlabs.East.Sun.COM [129.148.75.250]) by eastmail1.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id OAA16199; Tue, 16 Jan 2001 14:04:15 -0500 (EST)
Received: from sun.com (dhcp75-155 [129.148.75.155]) by sunlabs.East.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id OAA24842; Tue, 16 Jan 2001 14:04:14 -0500 (EST)
Message-ID: <[email-masked]>
Date: Tue, 16 Jan 2001 14:01:20 -0500
From: Steve Hanna
Organization: Sun Microsystems, Inc.
X-Mailer: Mozilla 4.75 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Paul Hoffman / IMC
CC: PKIX List , Ambarish Malpani
Subject: Re: DPD & DPV Basics
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Paul Hoffman / IMC wrote:
> Where you go wrong on both of your responses is to assume that an
> application that can parse a cert is the same thing as one which is
> PKI-aware. This is not the case. A program that can parse a cert just
> fine might still want/need a DPV to do the path checking (which
> includes the CA policy checking) and the validity checking.

Ambarish Malpani wrote:
> I agree with both this mail and the one you sent to Carlin
> earlier - I would fully expect the client to send the server
> the kind of use it wants to use the certificate for (IPSec, S/MIME,
> SSL) and the appropriate information that would depend on the
> protocol (the e-mail address of the sender/recipient, the address
> it thinks it is connecting to, etc).
>
> The DPV server needs to figure out what the right key usage/
> extended key usage bits are, how to do validation, etc. I would
> expect servers to support commonly known protocols and be expandable
> for other/future protocols.

Typical IETF situation. We all agree that the answer is obvious. We just
don't agree what the answer is!

It sounds like some applications are PKI-ignorant but ASN.1-savvy (able
to parse a certificate). Others are PKI-ignorant and ASN.1-ignorant
(unable to parse a certificate).

An ASN.1-savvy application only needs a DPV server to determine whether
a particular certificate is trustworthy (whether there is a valid path
to the certificate, according to the appropriate policies). The
ASN.1-savvy application can parse the certificate to check the key usage
and extended key usage and get the name and public key. See Note 1 below
for a minor detail.

An ASN.1-ignorant application needs a DPV server to determine whether a
certificate is trustworthy. But it also needs the DPV server to check
the key usage and extended key usage, check the name, and return the
public key. The ASN.1-ignorant application also needs the DPV protocol
to not use ASN.1 (except for objects that the application can treat like
blobs, like the certificate).

Does everyone (or almost everyone) agree with this analysis? If so, do
you also agree that both of these kinds of applications should be
supported (PKI-ignorant and ASN.1-savvy and PKI-ignorant and
ASN.1-ignorant)?

Once we have agreement on all that, then I think we will have a useful
context for discussing DPV requirements.

Thanks,

Steve

Note 1: If the certificate provided to the DPV server contains a DSA key
with inherited parameters, even an ASN.1-savvy application can't get
those parameters from the certificate (since they are inherited from
other certificates that the application may not have). In that
circumstance, the DPV server must return these parameters to the
application.

Received: from po1.bbn.com (PO1.BBN.COM [192.1.50.38]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA18339 for ; Tue, 16 Jan 2001 10:26:20 -0800 (PST)
Received: from [128.33.238.102] (TC102.BBN.COM [128.33.238.102]) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id NAA00643; Tue, 16 Jan 2001 13:31:50 -0500 (EST)
Mime-Version: 1.0
X-Sender: [email-masked] (Unverified)
Message-Id:
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]>
Date: Tue, 16 Jan 2001 12:18:25 -0500
To: Steve Hanna
From: Stephen Kent
Subject: Re: DPD & DPV Basics
Cc: PKIX List
Content-Type: multipart/alternative; boundary="============_-1232452540==_ma============"

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

Steve,

>
>
>I certainly don't think these requirements are impossible to meet.
>However, they should be added to the requirements for DPV (which are
>diverging quickly from the requirements for DPD).
>

I agree with your example, in almost every detail (I'd like to see
reference to the trust anchors in the call, not have the reference
implicit by client ID). I think the current spec alludes to the
capability you describe, specifically it says:

"For a non-PKI aware, non-ASN.1-capable client, the results returned
by the DPV protocol should not be merely a certificate and a status
indication. Rather, the contents of a certificate that are relevant
to the client application should be returned as distinct values, in a
syntax appropriate for the client. For example, the public key and
associated algorithm, the subject name (and/or alternate names) and
the issuer name (and alternate names), the key usage bits, and the
extended key usage field are all candidate values to be returned as
distinct objects to the client."

We have not included these specific requirements so far, because we
have not agreed whether it is appropriate to provide the results in
ASN.1 or via some other means, a tension noted elsewhere in the
requirements spec.

Steve

--============_-1232452540==_ma============
Content-Type: text/enriched; charset="us-ascii"

Steve,

<

I certainly don't think these requirements are impossible to meet.

However, they should be added to the requirements for DPV (which are

diverging quickly from the requirements for DPD).

I agree with your example, in almost every detail (I'd like to see
reference to the trust anchors in the call, not have the reference
implicit by client ID). I think the current spec alludes to the
capability you describe, specifically it says:

"TimesFor a non-PKI aware,
non-ASN.1-capable client, the results returned by the DPV protocol
should not be merely a certificate and a status indication. Rather, the
contents of a certificate that are relevant to the client application
should be returned as distinct values, in a syntax appropriate for the
client. For example, the public key and associated algorithm, the
subject name (and/or alternate names) and the issuer name (and
alternate names), the key usage bits, and the extended key usage field
are all candidate values to be returned as distinct objects to the
client."

We have not included these specific
requirements so far, because we have not agreed whether it is
appropriate to provide the results in ASN.1 or via some other means, a
tension noted elsewhere in the requirements spec.

Steve

--============_-1232452540==_ma============--

Received: from po1.bbn.com (PO1.BBN.COM [192.1.50.38]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA18317 for ; Tue, 16 Jan 2001 10:26:08 -0800 (PST)
Received: from [128.33.238.102] (TC102.BBN.COM [128.33.238.102]) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id NAA00609; Tue, 16 Jan 2001 13:31:37 -0500 (EST)
Mime-Version: 1.0
X-Sender: [email-masked] (Unverified)
Message-Id:
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Date: Tue, 16 Jan 2001 13:20:00 -0500
To: Steve Hanna
From: Stephen Kent
Subject: Re: DPD & DPV Basics
Cc: PKIX List
Content-Type: text/plain; charset="us-ascii" ; format="flowed"

Steve,

I'll weigh in on the IPsec scenario too.

I would expect the (IKE) client to send in the target cert and either
explicit validation parameters, or a reference to a stored set.
Checking the key usage could be done at the server or in the client.
But I do expect the client to do the ID matching against the returned
cert or cert contents. I would not want the the server to do this
because it is application specific and we don't want to require
servers to know about such things for every application that might
make use of them.

Steve

Received: from brot.celocom.de (brot.celocom.de [212.78.104.200]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA10923 for ; Tue, 16 Jan 2001 08:16:36 -0800 (PST)
Received: from frolic.celocom.de (frolic.celocom.de [212.78.104.90]) by brot.celocom.de (Postfix) with ESMTP id 473712FD7; Tue, 16 Jan 2001 17:22:08 +0100 (CET)
Received: from celocom.de (bernd.celocom.de [212.78.104.41]) by frolic.celocom.de (Postfix) with ESMTP id 5B1E6108003; Tue, 16 Jan 2001 17:22:07 +0100 (CET)
Message-ID: <[email-masked]>
Date: Tue, 16 Jan 2001 17:22:06 +0100
From: Bernd Matthes
Reply-To: [email-masked]
Organization: Celo Communications -- http://www.celocom.com
X-Mailer: Mozilla 4.75 [en] (WinNT; U)
X-Accept-Language: de,en
MIME-Version: 1.0
To: [email-masked]
Cc: [email-masked], [email-masked]
Subject: Re: question to time stamp draft: case of error
References: <[email-masked]>
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms59C99297B07DF21C81502811"

This is a cryptographically signed message in MIME format.

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

> [email-masked] wrote:
>
> Jean-Marc Desperrier ([email-masked]) asked a
> similar question in December and Ari Kermaier ([email-masked]) wrote:
>
> > The PKIFailureInfo structure described in
> draft-ietf-pkix-rfc2510bis-02
> > includes systemFailure(25) which, while not very descriptive, might
> fit the
> > bill for hardware failure.
>
> Denis, will you be adding systemFailure(25) to the PKIFailureInfo in
> the RFC version of the Time Stamping Protocol?

And additional badSenderNonce(18)?
I think, if a time stamp query contains a wrong nonce, this is also a
helpful value.

BTW,
if a signed ts query is received, it should be possible to send
appropriate
errors send back like badMessageCheck(1), signerNotTrusted(20) or
notAuthorized(23).
Is it generally planned that the new RFC provides a signed time stamp
query?
The last draft-ietf-pkix-time-stamp-12.txt say nothing about this fact.

>
> I agree with Jean-Marc and Ari that it would be very useful to add
> this additional value to the PKIFailureInfo since the latest time
> stamping draft currently indicates that:
>
> "These are the only values of PKIFailureInfo that are supported.
> Compliant servers MUST NOT produce any other values. Compliant clients
> MAY ignore any other values."
>
> By not adding during the final editing of the RFC
> version, this useful value could not ever be used to indicate this
> type of error.
>

with kind regards
--
Mors certa, hora incerta. In dubio pro mille.
--------------------------------------------------------------------
Bernd Matthes Celo Communications GmbH
Senior Software Engineer Weissenfelser Strasse 46a
Nachrichtentechniker D 06217 Merseburg
Dipl.-Ing.(FH) http://www.celocom.com
f. technische Informatik mailto:[email-masked]
http://www.worldbug.de Tel.: +49 3461/3318-0
mailto:[email-masked] Fax: +49 3461/415072
--------------------------------------------------------------------
"When in doubt, use brute force." (Ken Thompson)
--------------ms59C99297B07DF21C81502811
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

MIIKSgYJKoZIhvcNAQcCoIIKOzCCCjcCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC
B9YwggSgMIIECaADAgECAhBsOnTzXfzOOQkJistWSC3oMA0GCSqGSIb3DQEBBAUAMIHMMRcw
FQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y
azFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5
IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRp
dmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTAwMDEyNzAwMDAw
MFoXDTAxMDIwOTIzNTk1OVowggESMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UE
CxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9y
ZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMV
UGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBO
ZXRzY2FwZSBGdWxsIFNlcnZpY2UxFjAUBgNVBAMUDUJlcm5kIE1hdHRoZXMxITAfBgkqhkiG
9w0BCQEWEm1haW5idWdAY2Vsb2NvbS5kZTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA
5XDGxWjDOe+gHZygtVsNACVkbiY27ug06wI9DGzn4+ibdyEoqNnMlqe7dHSHsLG5f9Fl8gBa
ZgwOUnNClgnjCbqoByj4In82wWwUG97DndueKQhN78pYDRBWhGXKo/YSGI2l5rw7fjYnlTlw
6QQF0OGpFNBXzkNCBC4muSaI2YUCAwEAAaOCATgwggE0MAkGA1UdEwQCMAAwgawGA1UdIASB
pDCBoTCBngYLYIZIAYb4RQEHAQEwgY4wKAYIKwYBBQUHAgEWHGh0dHBzOi8vd3d3LnZlcmlz
aWduLmNvbS9DUFMwYgYIKwYBBQUHAgIwVjAVFg5WZXJpU2lnbiwgSW5jLjADAgEBGj1WZXJp
U2lnbidzIENQUyBpbmNvcnAuIGJ5IHJlZmVyZW5jZSBsaWFiLiBsdGQuIChjKTk3IFZlcmlT
aWduMBEGCWCGSAGG+EIBAQQEAwIHgDAwBgpghkgBhvhFAQYHBCIWIDFjNzhjMGNiYWZjMzg2
YzQzYzFmMWFjYTY5NzY4Nzk3MDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNp
Z24uY29tL2NsYXNzMS5jcmwwDQYJKoZIhvcNAQEEBQADgYEAsvJl1q8TirOQUfjbbyZKmVdi
k+2YQmQr64uvnEGf0Vp/laotPE49SR5Vu9GwGA2cPY/CPrb9v/bc3mOnCBlJ2m/xQIITJRxv
A66enfch2KSRLjl+VyU5BeIkq3UZekTAy76DPozOEwd6Azf4fLJy6AIh/DRS0GS9w/l2sLYQ
FAAwggMuMIICl6ADAgECAhEA0nYujRQMPX2yqCVdr+4NdTANBgkqhkiG9w0BAQIFADBfMQsw
CQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xNzA1BgNVBAsTLkNsYXNzIDEg
UHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkwHhcNOTgwNTEyMDAwMDAw
WhcNMDgwNTEyMjM1OTU5WjCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsT
FlZlcmlTaWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVw
b3NpdG9yeS9SUEEgSW5jb3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1Zl
cmlTaWduIENsYXNzIDEgQ0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZh
bGlkYXRlZDCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAu1pEigQWu1X9A3qKLZRPFXg2
uA1Ksm+cVL+86HcqnbnwaLuV2TFBcHqBS7lIE1YtxwjhhEKrwKKSq0RcqkLwgg4C6S/7wju7
vsknCl22sDZCM7VuVIhPh0q/Gdr5FegPh7Yc48zGmo5/aiSS4/zgZbqnsX7vyds3ashKyAkG
5JkCAwEAAaN8MHowEQYJYIZIAYb4QgEBBAQDAgEGMEcGA1UdIARAMD4wPAYLYIZIAYb4RQEH
AQEwLTArBggrBgEFBQcCARYfd3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQTAPBgNV
HRMECDAGAQH/AgEAMAsGA1UdDwQEAwIBBjANBgkqhkiG9w0BAQIFAAOBgQCIuDc73dqUNwCt
qp/hgQFxHpJqbS/28Z3TymQ43BuYDAeGW4UVag+5SYWklfEXfWe0fy0s3ZpCnsM+tI6q5QsG
3vJWKvozx74Z11NMw73I4xe1pElCY+zCphcPXVgaSTyQXFWjZSAA/Rgg5V+CprGoksVYasGN
Azzrw80FopCubjGCAjwwggI4AgEBMIHhMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEf
MB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWdu
LmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYG
A1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29u
YSBOb3QgVmFsaWRhdGVkAhBsOnTzXfzOOQkJistWSC3oMAkGBSsOAwIaBQCggbEwGAYJKoZI
hvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDEwMTE2MTYyMjA3WjAjBgkq
hkiG9w0BCQQxFgQU3oTLRQib5N+Pim5DQ7RUWO1/OqowUgYJKoZIhvcNAQkPMUUwQzAKBggq
hkiG9w0DBzAOBggqhkiG9w0DAgICAIAwBwYFKw4DAgcwDQYIKoZIhvcNAwICAUAwDQYIKoZI
hvcNAwICASgwDQYJKoZIhvcNAQEBBQAEgYDPUpFffRV9jAdqENKtsJwjS8c5m6ZVTwkqdaTY
ts0eNgiAs0L5qta4XPgXl5gWRr/7kb7eoRc0i19UdOCdQmECZCf3acRjNrakALMGqGSqbrr4
gJnCS/ra+LeanPaRHSp37ddNTI1AFcmD5mwirufeDRo81wq8YdPePV1CrT98fQ==
--------------ms59C99297B07DF21C81502811--

Received: from capricorn.iris.com (capricorn.iris.com [198.112.211.43]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA08294 for ; Tue, 16 Jan 2001 07:46:29 -0800 (PST)
From: [email-masked]
Subject: RE: Basic Cert-2-Directory mapping question
To: "Slone, Skip"
Cc: "'Bob Jueneman'" , [email-masked]
X-Mailer: Lotus Notes Release 5.0.2c February 2, 2000
Message-ID:
Date: Tue, 16 Jan 2001 10:52:15 -0500
X-MIMETrack: Serialize by Router on Capricorn/Iris(Build V60_01012001|January 01, 2001) at 01/16/2001 10:52:03 AM
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii

>As I read your suggestion, you want to add an element to the DN
>that directs the user to the appropriate directory. The new
>element is syntactically an RDN, but semantically is something
>different. The resulting new-style DN appears to me to
>semantically comparable to an LDAP URL.

I don't think the proposed "dir" attribute is semantically very different
from any other naming attributes. What we're trying to do with names in
certificates is to maintain the X.500 illusion that a DN uniquely
identifies an entry in some global directory. But we don't have a single
global directory; instead we have a collection of directories which don't
talk to one another - i.e. instead of the single DN root assumed by X.500,
we actually have multiple roots, one for each directory.

The obvious way to resolve this sort of problem is to introduce a new
"meta-root" that sits above all the directory roots. This corresponds to
adding an RDN to the most significant end of each DN that names the
particular directory within which the named entry lies. Precisely how a
directory is named is TBD, but it must give an end-system enough
information to for a query for that directory, without requiring prior
knowledge of the directory, so an obvious possibility (for an LDAP
directory) is scheme and hostport portions of an LDAP URL.

Individual directories could either store this attribute explicitly within
the entry (which would mean that these directories could be directly
searched using the full DN) or, more likely, the "dir" attribute would have
to be removed before searching an individual directory. So yes, the
mechanism for searching has to treat the "dir" RDN somewhat differently
from the other RDNs, but in terms of a naming model, it behaves just like
any other RDN.

As Bob points out, the "dir" attribute could be multi-valued, allowing
information about an entry to reside in multiple directories (provided that
the directories can all agree to use the same name for the entry).

John

"Slone, Skip" on 01/16/2001 09:16:13 AM

To: "'Bob Jueneman'"
cc: [email-masked]
Subject: RE: Basic Cert-2-Directory mapping question

Bob,

I'm glad to hear we agree on the nature of the problem. From that point of
agreement, we can move the discussion to one of "what do we do about it?"

In abstract terms, it appears to me that "what we can do about it" falls
into two broad categories:
1) we can create a mechanism for explicitly identifying the appropriate
directory, or
2) we can remove the barriers that currently prevent the directory from
being discovered implicitly based upon existing information

I would say that your approach fits in category 1, while my approach fits
in
category 2. Either approach has validity IMHO and is worthy of
consideration.

As I read your suggestion, you want to add an element to the DN that
directs
the user to the appropriate directory. The new element is syntactically an
RDN, but semantically is something different. The resulting new-style DN
appears to me to semantically comparable to an LDAP URL.

Assuming we're on the same page up to this point, I'll say that my concern
with this approach is that it changes the semantics of DN, potentially
causing interoperability problems in that both clients and servers that
understand the semantics as currently defined would have problems when
encountering the new-style name. If we were to go with a "category 1" fix
to the problem, I would rather see a new mechanism employed, such as a new
PKIX-defined certificate extension that explicitly gives repository
location
information. As a new construct, we would be free to define whatever
semantics we want, and could readily use existing concepts such as URLs.

Now, in defense of my approach, I think we can all probably agree that *IF*
the original concept of X.500-style distributed, global name resolution
were
a practical reality, we would be able to plug into the nearest DSA and find
the named entry regardless of where it resides physically. Of course I
emphasized the word "if" to imply that we can also probably agree that that
original X.500 concept is not going to occur anytime soon, if ever. What I
was proposing instead, was a "category 2" fix -- a way of removing that
barrier by providing an alternative way of doing distributed name
resolution. The alternative mechanism I proposed was one which builds upon
an existing, working, global infrastructure that already has the requisite
registration infrastructure in place. Without digging into the specifics,
I
would like to know if you or others believe that this *concept* has merit.

-- Skip

-----Original Message-----
From: Bob Jueneman [mailto:[email-masked]]
Sent: Monday, January 15, 2001 2:11 PM
To: [email-masked]
Cc: [email-masked]
Subject: RE: Basic Cert-2-Directory mapping question

Skip,

I don't particularly like the mechanism you've proposed, at least as
I understand it. But I absolutely and completely agree with you
as to the nature of the problem that has to be solved.

Civil attribute type names will always be with us, and hence must be
dealt with, for at least two fundamental reasons:

1. An address is not a name, although it may be a pseudonym. I
don't want to be forced to change my identity, or to an extent
my basis "self-hood," every time I change my ISP. And I especially
don't want some system administrator telling me that my name
must be limited to 8 characters, or that I have to change my name
because someone else has already used that same name within
that same system administrator's ill-conceived naming scheme.

2. E-mail address and other cyberspace identifiers fail to provide the
essence of PKI from a nonrepudiation standpoint, i.e., what I call the
"where do you send the sheriff" question.

Granted, not all uses of PKI will or should involve legal nonrepudiation.
But to the extent that at least some uses WILL have legal consequences,
then the establishment of a globally unique and credible identity that is
grounded in "meat-space" rather then cyberspace is absolutely essential.

For those legally binding transaction to be worth anything at all, they
have to be enforceable. And that means that a judgement may have
to be enforced upon someone, either by seizing the assets or putting
them in jail. And only in science fiction does the sheriff ride off into
cyberspace to arrest someone.

If I as a relying party wish to trade with someone, then I either want to
charge her credit card (in which case PKI is demonstrably not necessary)
or I want to know that she is the Mary Smith who resides at 123 Anywhere
St,
Metropolis, NY.

The inclusion of that civil address not only servers to distinguish her
from the other Mary Smiths, but more importantly it establishes a nexus
or link between her identity and her probable whereabouts, and
probably valuable real property as well.

So civil addresses, both corporate or "organizationalPerson", or the
harder-to-deal-with residentialPerson type will presumably always
be with us, and will have to be dealt with.

And unfortunately, perhaps, here int he US the simple and inescapable
fact of the matter is that neither the federal nor the state governments
operate the type of presumptively authoritative name registration
authorities that are relatively common in other countries. I am perfectly
free to move from one city to another, or from address to another in
the same city, and to never notify anyone in authority at all, including
the tax authorities. No one will ever say, "Papers, please."

(Granted, if I choose to do that I may not be able to register to vote,
but over half the population doesn't vote anyway. And the last time
I registered, no one checked to see that I actually lived there -- that
one of the problems we have with our voting system, even outside
of the State of Florida.. And I may not be able to get a driver's license
in order to legally drive a car, but a lot of illegal immigrants don't have
driver's licenses either, although that doesn't keep them from driving.)

So merely trying to ignore the problem of civil addressing schemes
won't solve that problem. And neither will various approaches that
make certain assumptions about monopoly name registration
authorities, or try to divine or impute where a directory containing
a particular name might be found based on some kind of a Karnak
mentalist act.

The primary issue is not the question of whether the name space
is flat or hierarchical, or how hierarchical, much less what the
"approved" schema is. What will be, will be, for reasons that
are beyond our scope and power to influence, even if we wanted
to.

So.

We cannot force a person to deposit his certificate or other useful
information into a specific directory, even if we wanted to. Nor can
we reliably impute a likely directory where such information might
be found, at least in the absence of a monopoly or governmental
mandate.

The best we can do is to ASK the user where he has deposited
such information, if anywhere, and to include that information
EXPLICITLY in any directory or pseudo-directory reference, such
as a DN.

Although at one time I liked the notion of prefixing the DN with a
URL, I have come to believe that John Wray's suggestion is the
better way forward.

He said:
>
>Bob,
>
>Accepting the fact that the X.500 dream of a single global directory is
not
>going to happen any time soon, DNs can still be turned into globally
>significant pointers into a federation of directories in the way you
>suggest, but it doesn't require altering the DN syntax (and therefore
>doesn't have to break existing implementations). All that's needed is a
DN
>attribute that names the particular directory within which the name
>resides. e.g. instead of "c=us;..;cn=My Name" you'd have "dir=My
>Directory;c=us;...;cn=My Name", where "My Directory" is the URL of a
>directory access point.

By including an explicit directory qualifier of the form dir="directory
URL"
at the root (top) of the RDN chain, we have implicitly qualified all of the
rest
of the RDN, which is a Good Thing.

By defining the syntax of the "dir" attribute appropriately, we could
include
both the access type (LDAP, http, etc.) and port number appropriately,
either a default or explicitly indicated.

And by making the dir component multivalued, we could accommodate
a choice of multiple directories and multiple directory types.

Once again -- the essence of the problem is not the format of the directory
name but where a directory containing that name can be found.
Including that information as a top-level qualifying component solves that
problem (and potentially several others, such as name scope qualification)
very neatly.

Bob

Robert R. Jueneman
'Security Architect
Novell, Inc. -- the leading provider of Net services software
>
>
>
>
>
>
>
>>>> "Slone, Skip" 01/15/01 09:08AM >>>
>Oscar,
>
>No offense taken, thus no apology needed.
>
>My comments from the soapbox last week were actually intended for the
>community at large, and were meant to convey frustration at the apparent
>unwillingness of solution providers in general to hear about -- and solve
--
>real world problems that are faced by users like myself in large, complex
>environments.
>
>When I say "my environment is not so simple," the response I hear is
"let's
>not talk about the complexity; let's make some simplifying assumptions
>instead."
>
>When I say "I have a nail AND a screw and need to put them both in the
>wall," the response I hear is "we have provided you with a perfectly
>adequate hammer, therefore you don't have a screw."
>
>As I was using the nail/hammer analogy, dc-based names are the nails;
>civil-attribute-based names are the screws. No matter how good a job my
>company does of using nails and nails alone, we still have tens of
thousands
>of trading partners, many of whom prefer screws to nails and will continue
>to use them indefinitely. Without a screwdriver, it's hard to do business
>with them.
>
>I don't really care what the screwdriver looks like. I've suggested a
>fairly simple design that I think will work. So far, no one has commented
on
>the design. What I've heard instead is a chorus of "we still don't like
>screws." Well, I don't like them either, but I still have to deal with
>them. If I'm simply overlooking a screwdriver that we have lying around
>somewhere, I would appreciate someone pointing it out to me.
>
> -- Skip
>
>
>-----Original Message-----
>From: Oscar Jacobsson [mailto:[email-masked]]
>Sent: Thursday, January 11, 2001 5:16 PM
>To: Slone, Skip
>Cc: 'Sharon Boeyen'; [email-masked]
>Subject: RE: Basic Cert-2-Directory mapping question
>
>
>> From: Slone, Skip [mailto:[email-masked]]
>> In response to this, I'm inclined to join Sharon on Marshall's soapbox
and
>> echo her words:
>>
>> "... I believe a more constructive approach is to accept the fact that
>> different parts of the world and different environments will use a
variety
>> of nameforms ... We are not the global naming police either and should
not
>> try to impose the rules that anyone uses to name entities to which they
>> issue certificates."
>
>I'm sorry if I came across as clamouring for rules be imposed. I know that
>this working group has a tendency to be wary of suggestions that don't
cater
>for distinguished names containing cat MPEGs, so I should probably have
been
>more careful. The requirements I suggested were for a possible naming
>standards document, conformance to which need not be enforced.
>
>The case at hand is not, IMHO, one of dictating that "all distinguished
>names must be according to our will, or you shall feel our wrath". A
>document however, outlining a naming strategy that would require of the
>users of certificates named accordingly no a-priori knowledge of their
>issuer (save for eventually having to reach something explicitly trusted
in
>the chain) in order to perform path validation, is something I would
>personally consider very valuable indeed. I'm reasonably confident that
>organizations intending to act as certification authorities or trusted
third
>parties would agree.
>
>> And to quote someone Sharon and I both know, "If all you have is a
hammer,
>> every problem looks like a nail."
>
>It seems I was less than clear here as well. :-(
>
>My intention was to point out that there are actually two separate
problems
>here (one nail, if you will, and one screw) each looking for its own
>solution:
>
>1. Defining a repository, and subsequently entry, discovery process for
>arbitrarily named entries.
>
>2. Defining a naming scheme that _if applied_ would automate this
repository
>and entry discovery process.
>
>I am only trying to address the second of these problems. The first is
only
>an issue because nobody seems to have properly addressed the second before
>deploying certificates on the Internet en masse. The further we wait
before
>addressing number two, the more of a problem number one will become.
>
>I should probably make a habit of pointing out that the opinions stated
here
>are my very own, and not necessarily those of my employer.
>
>Cheers,
>
>//oscar

Received: from stingray.missi.ncsc.mil (stingray.missi.ncsc.mil [144.51.50.20]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA05988 for ; Tue, 16 Jan 2001 07:29:48 -0800 (PST)
Received: from stingray.missi.ncsc.mil (root@localhost) by stingray.missi.ncsc.mil with ESMTP id KAA08768 for ; Tue, 16 Jan 2001 10:34:50 -0500 (EST)
Message-Id: <[email-masked]>
Date: Tue, 16 Jan 2001 10:36:03 -0500 (EST)
From: "David P. Kemp"
Reply-To: "David P. Kemp"
Subject: Re: Two questions on delta-CRL
To: [email-masked]
MIME-Version: 1.0
Content-Type: TEXT/plain; charset=ISO-8859-1
Content-MD5: hoYwFBSQ+ZsIik5b+Uwozw==
X-Mailer: dtmail 1.3.0 CDE Version 1.3 SunOS 5.7 sun4u sparc
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from QUOTED-PRINTABLE to 8bit by ns.secondary.com id HAA05992

It is not true that an application would need to retrieve multiple
deltas to resync.

Each delta CRL specifies the base against which it was issued. A CA
could choose the scheme you describe where each delta is from the
previous delta. But a CA could also choose a scheme where each delta
is from the previous base. In the latter scheme, an application which had
lost its revocation information (or been offline for a month) would
have to obtain the daily full CRL and a single delta CRL.

As Sharon has pointed out, there is NO requirement in either X.509-2000
or X.509-1997 to publish a complete CRL when a delta is published. To the
contrary:

"Depending on the policy of the responsible authority, several
dCRLs may be published before a new base CRL is published."

-- X.509-2000, section 8.5.2.5, CRL scope extension

and

"Note - it is the decision of the CA as to whether or not to distribute
the CRLs issued between two base CRLs."

-- X.509-1997, section 12.6.3.3, Delta CRL indicator field

Draft-ietf-pkix-new-part1-01 says that a conforming CA MUST *issue*
a complete CRL for every delta, but it does not say that the issued
full CRL must be published anywhere except to /dev/null. Note that
neither of the two suggested ways a PKIX application can construct
a complete CRL from deltas involves retrieving a current full CRL.
(There are technical reasons for requiring only a single "revocation
state" to exist at any moment in time, and locally constructing a full
CRL is one means of capturing that state.)

I strongly disagree with any suggestion that PKIX requirements for base
CRL publication should be more restrictive than X.509's. And I agree
that new-part-1 should make it clear that "issuing" a full CRL for
every delta does not *in any way* require publishing that full CRL.

Regards,
Dave

> From: Michael Ströder
>
> Sam Schaen wrote:
> >
> > I believe the requirement for issuing a complete CRL when a delta CRL is
> > released makes sense.
> > [..]
> > The availability of a current full CRL also allows an application to
> > resynchronize at any point.
>
> I think this is the most important argument. An application might
> loose the stored CRL or the CRL got corrupt by e.g. a system crash.
> The damage for the application is limited to the loss of some
> network-bandwidth. Resynchronization is simple.
>
> E.g. if you issue a full CRL each day (24h) and delta-CRLs every
> hour the application will have to obtain the last full CRL and every
> delta CRL issued since then to get up to date (max. 24 accesses
> instead of one).
>
> If you want to relax the requirement of issuing full and delta CRLs
> at the same time you have to mandate
> 1. that the CRL issuer stores all delta URLs from the last full CRL
> and
> 2. you have to provide appropriate service access points to obtain
> all necessary delta CRLs.
>
> The application logic gets more complicated though.
>
> Ciao, Michael.

Received: from mailgw2a.lmco.com (mailgw2a.lmco.com [192.91.147.7]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA01315 for ; Tue, 16 Jan 2001 06:22:22 -0800 (PST)
Received: from emss03g01.ems.lmco.com (emss03g01.ems.lmco.com [141.240.4.144]) by mailgw2a.lmco.com (8.8.8/8.8.8) with ESMTP id JAA16539; Tue, 16 Jan 2001 09:26:26 -0500 (EST)
Received: from CONVERSION-DAEMON by lmco.com (PMDF V5.2-32 #38888) id <[email-masked]>; Tue, 16 Jan 2001 09:25:18 -0500 (EST)
Received: from emss03i00.ems.lmco.com ([141.240.31.211]) by lmco.com (PMDF V5.2-32 #38888) with ESMTP id <[email-masked]>; Tue, 16 Jan 2001 09:24:56 -0500 (EST)
Received: by emss03i00.orl.lmco.com with Internet Mail Service (5.5.2650.21) id ; Tue, 16 Jan 2001 09:26:05 -0500
Content-return: allowed
Date: Tue, 16 Jan 2001 09:26:05 -0500
From: "Slone, Skip"
Subject: RE: Basic Cert-2-Directory mapping question
To: "'Oscar Jacobsson'" , Sharon Boeyen
Cc: "'Stephen Kent'" , [email-masked]
Message-id:
MIME-version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-type: text/plain
Content-transfer-encoding: 7BIT

Oscar,

Just a quick response to your specific critique...

[Oscar] One issue I have with this is that it violates one of the central
premises of Sharon's "soapbox address" by placing the assumption on DNs
that they employ a specific naming scheme, in this case one with a
"C=xxx, O=xxx" root.

[Skip] Actually, this was not where I was coming from at all. As I see it,
we currently have two documented approaches to naming, neither of which is
mandatory, both of which are in use: (1) RFC 2377, which recommends the use
of dc-style naming, and (2) the X.521 informative annex that recommends the
use of C=xx, O=xxx -style naming. What I was doing was acknowledging that
both name styles exist and will probably continue to exist indefinitely.
Based on that recognition, I was proposing that a relatively simple
modification to DNS could conceivably (with some more work, of course) help
resolve the latter type of names to a point where pkixrep can take over and
get us to the repository.

-- Skip

-----Original Message-----
From: Oscar Jacobsson [mailto:[email-masked]]
Sent: Tuesday, January 16, 2001 5:18 AM
To: Sharon Boeyen
Cc: 'Slone, Skip'; 'Stephen Kent'; [email-masked]
Subject: Re: Basic Cert-2-Directory mapping question

All,

this thread has progressed a bit since last I checked, so I hope you'll
forgive me for skipping to the front.

Regarding our precious screwdriver, the primary functional requirement
for said tool, to paraphrase Sharon, would then appear to be:

"The screwdriver shall identify and locate PKIX repositories for
Distinguished Names."

Or is it important that this method only be used failing derivation or
a-priori knowledge of the repository location?

Is it also important that the DN be "geopolitically" structured, or can
I interpret that as "non-domainComponent" structured?

Skip has already proposed a solution, which I'd like to address:

"What I'm proposing is the development of a new DNS RR type that allows
the registration of arbitrary attribute value assertions (such as
"o=Something" or "ou=Something Else"). These new RRs (let's call them
AVA RRs) would resolve to a domain name that could subsequently be used
to construct the right hand portion of a PKIXREP query (or some other
SRV-seeking query). A remaining critical piece is the specification of
c=XX as equivalent to a corresponding ccTLD. As an example, when
resolving a DN ending in o=Entrust, c=CA, one would first query .ca for
an AVA record matching "o=Entrust", and would get a response such as
"entrust.com" which would then be used to generate a query along the
line of _PKIXREP._LDAP.entrust.com."

One issue I have with this is that it violates one of the central
premises of Sharon's "soapbox address" by placing the assumption on DNs
that they employ a specific naming scheme, in this case one with a
"C=xxx, O=xxx" root.

Regards,

//oscar

Sharon Boyen wrote:
> Hi Skip,
>
> What I meant by the tools was that the SRV records are populated by
> CAs, some of which use the geopolitical DN style and others that use
> the dc style. Regardless of what style of DN they use, all queries
> for SRV records are based on a domain name. If that domain name is
> known, or can be derived (e.g. by the email application from the
> email address), then the SRV records can direct you to the right PKI
> repository.
>
> The need for a screwdriver is when you don't know the domain name
> and can't derive it, but need to identify and locate the PKI
> repository for a geopolitically structured DN that you do know.
>
> Cheers,
> Sharon

Received: from mailgw2a.lmco.com (mailgw2a.lmco.com [192.91.147.7]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA00477 for ; Tue, 16 Jan 2001 06:13:27 -0800 (PST)
Received: from emss03g01.ems.lmco.com (emss03g01.ems.lmco.com [141.240.4.144]) by mailgw2a.lmco.com (8.8.8/8.8.8) with ESMTP id JAA08821; Tue, 16 Jan 2001 09:17:37 -0500 (EST)
Received: from CONVERSION-DAEMON by lmco.com (PMDF V5.2-32 #38888) id <[email-masked]>; Tue, 16 Jan 2001 09:16:36 -0500 (EST)
Received: from emss03i00.ems.lmco.com ([141.240.31.211]) by lmco.com (PMDF V5.2-32 #38888) with ESMTP id <[email-masked]>; Tue, 16 Jan 2001 09:16:25 -0500 (EST)
Received: by emss03i00.orl.lmco.com with Internet Mail Service (5.5.2650.21) id ; Tue, 16 Jan 2001 09:17:34 -0500
Content-return: allowed
Date: Tue, 16 Jan 2001 09:17:33 -0500
From: "Slone, Skip"
Subject: RE: Basic Cert-2-Directory mapping question
To: "'Sharon Boeyen'" , "'Stephen Kent'"
Cc: [email-masked]
Message-id:
MIME-version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-type: MULTIPART/ALTERNATIVE; BOUNDARY="Boundary_(ID_RhMO2EhoBq/gdMVgtiZc4g)"

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

--Boundary_(ID_RhMO2EhoBq/gdMVgtiZc4g)
Content-type: text/plain
Content-transfer-encoding: 7BIT

Sharon, I think I can say that we're on the same page at this point. See my
recently posted note to Bob for my thoughts on what we can do in those
instances when we need a screwdriver.

-- Skip

-----Original Message-----
From: Sharon Boeyen [mailto:[email-masked]]
Sent: Monday, January 15, 2001 3:13 PM
To: 'Slone, Skip'; 'Stephen Kent'
Cc: [email-masked]
Subject: RE: Basic Cert-2-Directory mapping question

Hi Skip,

What I meant by the tools was that the SRV records are populated by CAs,
some of which use the geopolitical DN style and others that use the dc
style. Regardless of what style of DN they use, all queries for SRV records
are based on a domain name. If that domain name is known, or can be derived
(e.g. by the email application from the email address), then the SRV records
can direct you to the right PKI repository.

The need for a screwdriver is when you don't know the domain name and can't
derive it, but need to identify and locate the PKI repository for a
geopolitically structured DN that you do know.

Cheers,
Sharon

-----Original Message-----
From: Slone, Skip [mailto:[email-masked]]
Sent: Monday, January 15, 2001 12:54 PM
To: 'Sharon Boeyen'; 'Stephen Kent'
Cc: [email-masked]
Subject: RE: Basic Cert-2-Directory mapping question

[Sharon] It seems that we are basically in agreement that both the 'civil
attributes' type of DNs and the domain
component attributes for DNS structured DNs are currently being used and
will likely continue to be used.

[Skip] Agreed.

[Sharon] We also seem to be in agreement that both are hierarchical name
structures.

[Skip] Agreed.

[Sharon] I think it is also fairly safe to say that the extensions we
already have in certificates, combined with the PKI repository locator
service seem adequate for identifying and locating the PKI repository of
interest in most cases for both types of DN structures.

[Skip] I'm not sure I understand what you mean by "the [tools] we already
have ... seem adequate ... for both types of DN structures." Maybe I'm
overlooking the obvious, but I don't see support structures for
civil-attribute-based DNs.

[Sharon] The single exception to this is, as pointed out by Skip, the one
where all the following conditions are met: I guess typically this
would be an environment where there is more than one internediary
certificate in a path because if two domains directly cross-certify with
one-another they would provide repository access information to each other,
otherwise the cross-certification makes no sense.

[Skip] I see this need most acutely in those instances that occur near the
boundaries of a business relationship. That is, when a relationship is in
the early stages of being formed, or if some break has occured in a business
relationship (due to mergers, acquisitions, etc.), there is a sharp drop in
the likelihood that the requisite knowledge is already in place. Once a
relationship has been established, the whole repository locator issue
becomes a moot point. Until then, it can be a big deal. The "problem certs"
are not the ones that are commercially issued; the problem arises when
certificates are issued by a private CA that is certified (directly or
indirectly) by a commercial CA that I happen to trust.

[Sharon] While I don't disagree with Skip's assertion that the mapping of
civil DNs to DNS names might be useful in the general directory sense,

[Skip] In the absence of a well-connected DIT (complete with globally
accessible first-level DSAs, a functional c=US, etc.) distributed X.500/LDAP
name resolution has been, and will continue to be an unmitigated failure.
By leveraging an existing, global, ubiquitous infrastructure, the mapping
I've suggested is intended to solve a big portion of this name resolution
problem.

[Sharon] I agree with Steve that this directory issue is not one that PKIX
needs to tackle in general.

[Skip] While I completely agree that the charter of PKIX is NOT to solve
general directory issues, it seems to me that it is within the charter of
PKIX to consider problems that users report with PKIX as currently defined,
and to give due consideration to whether any proposed solution does indeed
solve the reported problem. If the solution is then deemed to be too
general, the work can, of course, be moved elsewhere.

[Sharon] However, if the scenario above is one that PKIX needs to find a
solution to (as opposed to determining that its not relevant since Internet
applications will generally have domain names and can therefore use PKI
repository locator service regardless of the DN structures in the certs or
the directory entries), then we have some work to do.

[Skip] Agreed. I can offer some cycles to do some of this work.

[Sharon] Otherwise, we already have all the tools we need to satisfy the PKI
information retrieval problem.

[Skip] I'm still looking for something other than a hammer :-)

-- Skip

-----Original Message-----
From: Sharon Boeyen [mailto:[email-masked]]
Sent: Friday, January 12, 2001 9:19 AM
To: 'Stephen Kent'; Slone, Skip
Cc: [email-masked]
Subject: RE: Basic Cert-2-Directory mapping question

OK now we're getting to the 'focal' point I was hoping we would.

It seems that we are basically in agreement that both the 'civil attributes'
type of DNs and the domain
component attributes for DNS structured DNs are currently being used and
will likely continue to be used. We also seem to be in agreement that both
are hierarchical name structures. I think it is also fairly safe to say that
the extensions we already have in certificates, combined with the PKI
repository locator service seem adequate for identifying and locating the
PKI repository of interest in most cases for both types of DN structures.
The single exception to this is, as pointed out by Skip, the one where all
the following conditions are met: A relying party needs to obtain an
end-entity certificate for which it does not know the domain name and it
cannot be easily derived from information the relying party does have (and
therefore the PKI repository locator service won't provide the required
information) and the relying party's local environment does not have a
priori knowledge of the remote domain's repository. I guess typically this
would be an environment where there is more than one internediary
certificate in a path because if two domains directly cross-certify with
one-another they would provide repository access information to each other,
otherwise the cross-certification makes no sense.

While I don't disagree with Skip's assertion that the mapping of civil DNs
to DNS names might be useful in the general directory sense, I agree with
Steve that this directory issue is not one that PKIX needs to tackle in
general. However, if the scenario above is one that PKIX needs to find a
solution to (as opposed to determining that its not relevant since Internet
applications will generally have domain names and can therefore use PKI
repository locator service regardless of the DN structures in the certs or
the directory entries), then we have some work to do. Otherwise, we already
have all the tools we need to satisfy the PKI information retrieval problem.

Sharon

-----Original Message-----
From: Stephen Kent [mailto:[email-masked]]
Sent: Thursday, January 11, 2001 4:56 PM
To: Slone, Skip
Cc: [email-masked]
Subject: RE: Basic Cert-2-Directory mapping question

Skip,

I would just like to add that, in addition to X.521 and some LDAP specs, the
ability to recognize civil naming attributes in the issuer and subject
fields of an X.509v3 cert is mandated in RFC 2459 (ref section 4.1.2.4) and
in son-of-2459.

Ironically, the requirement for support for Issuer names (DNs) vs. allowing
an Issuer alname in lieu of a DN, arose because the S/MIME WG was relying on
the presence of an Issuer DN in their design, and I believe the motivation
for it (Russ can confirm or correct this notion) was to facilitate directory
lookup for certs in S/MIME!

Steve

--Boundary_(ID_RhMO2EhoBq/gdMVgtiZc4g)
Content-type: text/html
Content-transfer-encoding: 7BIT

Sharon, I think I can say that we're on the same page
at this point.  See my recently posted note to Bob for my thoughts on what
we can do in those instances when we need a screwdriver.

-- Skip

-----Original Message-----
From: Sharon Boeyen
[mailto:[email-masked]]
Sent: Monday, January 15, 2001
3:13 PM
To: 'Slone, Skip'; 'Stephen Kent'
Cc:
[email-masked]
Subject: RE: Basic Cert-2-Directory mapping
question

Hi
Skip,

What
I meant by the tools was that the SRV records are populated by CAs, some of
which use the geopolitical DN style and others that use the dc style.
Regardless of what style of DN they use, all queries for SRV records are based
on a domain name. If that domain name is known, or can be derived (e.g. by the
email application from the email address), then the SRV records can direct you
to the right PKI repository.

The
need for a screwdriver is when you don't know the domain name and can't derive
it, but need to identify and locate the PKI repository for a geopolitically
structured DN that you do know.

Cheers,

Sharon

-----Original Message-----
From: Slone, Skip
[mailto:[email-masked]]
Sent: Monday, January 15, 2001 12:54
PM
To: 'Sharon Boeyen'; 'Stephen Kent'
Cc:
[email-masked]
Subject: RE: Basic Cert-2-Directory mapping
question

[Sharon]  It seems that we are basically in
agreement that both the 'civil attributes' type of DNs and the domain

component
attributes for DNS structured DNs are currently being used and will likely
continue to be used.

[Skip]  Agreed.

[Sharon]  We
also seem to be in agreement that both are hierarchical name structures.

[Skip]  Agreed.

[Sharon]  I think it is also fairly safe to say
that the extensions we already have in certificates, combined with the PKI
repository locator service seem adequate for identifying and locating the
PKI repository of interest in most cases for both types of DN
structures.

[Skip]  I'm not sure I
understand what you mean by
"the [tools] we already have ... seem adequate ... for both types of DN
structures."  Maybe I'm
overlooking the obvious, but I don't see support structures
for civil-attribute-based DNs.

[Sharon]  The single exception to this is, as
pointed out by Skip, the one where all the following conditions are
met:  <snip> I guess typically this would be
an environment where there is more than one internediary certificate in a
path because if two domains directly cross-certify with
one-another they would provide repository access information to each
other, otherwise the cross-certification makes no
sense.

[Skip] I see this need most acutely in those
instances that occur near the boundaries of a business relationship. That
is, when a relationship is in the early stages of being formed, or if some
break has occured in a business relationship (due to mergers, acquisitions,
etc.), there is a sharp drop in the likelihood that the requisite knowledge
is already in place.  Once a relationship has been established,
the whole repository locator issue becomes a moot point. Until then, it
can be a big deal.  The "problem certs" are not the ones that are
commercially issued; the problem arises when certificates are
issued by a private CA that is certified (directly or indirectly) by a
commercial CA that I happen to trust.

[Sharon] While I don't disagree with Skip's
assertion that the mapping of civil DNs to DNS names might be useful in the
general directory sense,

[Skip] In the absence of a well-connected DIT
(complete with globally accessible first-level DSAs, a functional c=US,
etc.) distributed X.500/LDAP name resolution has been, and will
continue to be an unmitigated failure.  By leveraging an existing,
global, ubiquitous infrastructure, the mapping I've suggested is intended to
solve a big portion of this name resolution
problem.

[Sharon]  I agree with Steve that this
directory issue is not one that PKIX needs to tackle in general.

[Skip] While I completely agree that the charter of
PKIX is NOT to solve general directory issues, it seems to me that it is
within the charter of PKIX to consider problems that users report with PKIX
as currently defined, and to give due consideration to whether any proposed
solution does indeed solve the reported problem.  If the solution is
then deemed to be too general, the work can, of course, be moved
elsewhere.

[Sharon]
However, if the scenario above is one that PKIX needs to find a
solution to (as opposed to determining that its not relevant since Internet
applications will generally have domain names and can therefore use PKI
repository locator service regardless of the DN structures in the certs or
the directory entries), then we have some work to do.

[Skip] Agreed.  I can offer some cycles to do
some of this work.

[Sharon] Otherwise, we already have all the
tools we need to satisfy the PKI information retrieval
problem.

[Skip] I'm still looking for something other
than a hammer :-)

--
Skip

-----Original Message-----
From: Sharon Boeyen
[mailto:[email-masked]]
Sent: Friday, January 12,
2001 9:19 AM
To: 'Stephen Kent'; Slone, Skip
Cc:
[email-masked]
Subject: RE: Basic Cert-2-Directory mapping
question

OK now we're getting to the 'focal' point I was hoping we
would.

It seems that we are basically in agreement that both the 'civil
attributes' type of DNs and the domain

component attributes for DNS structured DNs are currently being
used and will likely continue to be used. We also seem to be in agreement
that both are hierarchical name structures. I think it is also fairly safe
to say that the extensions we already have in certificates, combined with
the PKI repository locator service seem adequate for identifying and
locating the PKI repository of interest in most cases for both types
of DN structures. The single exception to this is, as pointed out by
Skip, the one where all the following conditions are met: A relying party
needs to obtain an end-entity certificate for which it does not know the
domain name and it cannot be easily derived from information the
relying party does have (and therefore the PKI repository
locator service won't provide the required information) and the relying
party's local environment does not have a priori knowledge of the remote
domain's repository. I guess typically this would be an environment where
there is more than one internediary certificate in a path because if two
domains directly cross-certify with one-another they would provide
repository access information to each other, otherwise the
cross-certification makes no
sense.

While I don't disagree with Skip's assertion that
the mapping of civil DNs to DNS names might be useful in the general
directory sense, I agree with Steve that this directory issue is not one
that PKIX needs to tackle in general. However, if the scenario above is
one that PKIX needs to find a solution to (as opposed to determining that
its not relevant since Internet applications will generally have domain
names and can therefore use PKI repository locator service regardless of
the DN structures in the certs or the directory entries), then we have
some work to do. Otherwise, we already have all the tools we need to
satisfy the PKI information retrieval problem.

Sharon

-----Original
Message-----
From: Stephen Kent
[mailto:[email-masked]]
Sent: Thursday, January 11, 2001 4:56
PM
To: Slone, Skip
Cc:
[email-masked]
Subject: RE: Basic Cert-2-Directory mapping
question

Skip,

I would just like to add that, in
addition to X.521 and some LDAP specs, the ability to recognize civil
naming attributes in the issuer and subject fields of an X.509v3 cert is
mandated in RFC 2459 (ref section 4.1.2.4) and in son-of-2459.

Ironically, the requirement for support for Issuer names (DNs) vs.
allowing an Issuer alname in lieu of a DN, arose because the S/MIME WG
was relying on the presence of an Issuer DN in their design, and I
believe the motivation for it (Russ can confirm or correct this notion)
was to facilitate directory lookup for certs in S/MIME!

<snip>

Steve

--Boundary_(ID_RhMO2EhoBq/gdMVgtiZc4g)--

Received: from mailgw2a.lmco.com (mailgw2a.lmco.com [192.91.147.7]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA00300 for ; Tue, 16 Jan 2001 06:11:07 -0800 (PST)
Received: from emss03g01.ems.lmco.com (emss03g01.ems.lmco.com [141.240.4.144]) by mailgw2a.lmco.com (8.8.8/8.8.8) with ESMTP id JAA14880; Tue, 16 Jan 2001 09:16:38 -0500 (EST)
Received: from CONVERSION-DAEMON by lmco.com (PMDF V5.2-32 #38888) id <[email-masked]>; Tue, 16 Jan 2001 09:15:20 -0500 (EST)
Received: from emss03i00.ems.lmco.com ([141.240.31.211]) by lmco.com (PMDF V5.2-32 #38888) with ESMTP id <[email-masked]>; Tue, 16 Jan 2001 09:15:08 -0500 (EST)
Received: by emss03i00.orl.lmco.com with Internet Mail Service (5.5.2650.21) id ; Tue, 16 Jan 2001 09:16:14 -0500
Content-return: allowed
Date: Tue, 16 Jan 2001 09:16:13 -0500
From: "Slone, Skip"
Subject: RE: Basic Cert-2-Directory mapping question
To: "'Bob Jueneman'"
Cc: [email-masked]
Message-id:
MIME-version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-type: text/plain
Content-transfer-encoding: 7BIT

Bob,

I'm glad to hear we agree on the nature of the problem. From that point of
agreement, we can move the discussion to one of "what do we do about it?"

In abstract terms, it appears to me that "what we can do about it" falls
into two broad categories:
1) we can create a mechanism for explicitly identifying the appropriate
directory, or
2) we can remove the barriers that currently prevent the directory from
being discovered implicitly based upon existing information

I would say that your approach fits in category 1, while my approach fits in
category 2. Either approach has validity IMHO and is worthy of
consideration.

As I read your suggestion, you want to add an element to the DN that directs
the user to the appropriate directory. The new element is syntactically an
RDN, but semantically is something different. The resulting new-style DN
appears to me to semantically comparable to an LDAP URL.

Assuming we're on the same page up to this point, I'll say that my concern
with this approach is that it changes the semantics of DN, potentially
causing interoperability problems in that both clients and servers that
understand the semantics as currently defined would have problems when
encountering the new-style name. If we were to go with a "category 1" fix
to the problem, I would rather see a new mechanism employed, such as a new
PKIX-defined certificate extension that explicitly gives repository location
information. As a new construct, we would be free to define whatever
semantics we want, and could readily use existing concepts such as URLs.

Now, in defense of my approach, I think we can all probably agree that *IF*
the original concept of X.500-style distributed, global name resolution were
a practical reality, we would be able to plug into the nearest DSA and find
the named entry regardless of where it resides physically. Of course I
emphasized the word "if" to imply that we can also probably agree that that
original X.500 concept is not going to occur anytime soon, if ever. What I
was proposing instead, was a "category 2" fix -- a way of removing that
barrier by providing an alternative way of doing distributed name
resolution. The alternative mechanism I proposed was one which builds upon
an existing, working, global infrastructure that already has the requisite
registration infrastructure in place. Without digging into the specifics, I
would like to know if you or others believe that this *concept* has merit.

-- Skip

-----Original Message-----
From: Bob Jueneman [mailto:[email-masked]]
Sent: Monday, January 15, 2001 2:11 PM
To: [email-masked]
Cc: [email-masked]
Subject: RE: Basic Cert-2-Directory mapping question

Skip,

I don't particularly like the mechanism you've proposed, at least as
I understand it. But I absolutely and completely agree with you
as to the nature of the problem that has to be solved.

Civil attribute type names will always be with us, and hence must be
dealt with, for at least two fundamental reasons:

1. An address is not a name, although it may be a pseudonym. I
don't want to be forced to change my identity, or to an extent
my basis "self-hood," every time I change my ISP. And I especially
don't want some system administrator telling me that my name
must be limited to 8 characters, or that I have to change my name
because someone else has already used that same name within
that same system administrator's ill-conceived naming scheme.

2. E-mail address and other cyberspace identifiers fail to provide the
essence of PKI from a nonrepudiation standpoint, i.e., what I call the
"where do you send the sheriff" question.

Granted, not all uses of PKI will or should involve legal nonrepudiation.
But to the extent that at least some uses WILL have legal consequences,
then the establishment of a globally unique and credible identity that is
grounded in "meat-space" rather then cyberspace is absolutely essential.

For those legally binding transaction to be worth anything at all, they
have to be enforceable. And that means that a judgement may have
to be enforced upon someone, either by seizing the assets or putting
them in jail. And only in science fiction does the sheriff ride off into
cyberspace to arrest someone.

If I as a relying party wish to trade with someone, then I either want to
charge her credit card (in which case PKI is demonstrably not necessary)
or I want to know that she is the Mary Smith who resides at 123 Anywhere St,
Metropolis, NY.

The inclusion of that civil address not only servers to distinguish her
from the other Mary Smiths, but more importantly it establishes a nexus
or link between her identity and her probable whereabouts, and
probably valuable real property as well.

So civil addresses, both corporate or "organizationalPerson", or the
harder-to-deal-with residentialPerson type will presumably always
be with us, and will have to be dealt with.

And unfortunately, perhaps, here int he US the simple and inescapable
fact of the matter is that neither the federal nor the state governments
operate the type of presumptively authoritative name registration
authorities that are relatively common in other countries. I am perfectly
free to move from one city to another, or from address to another in
the same city, and to never notify anyone in authority at all, including
the tax authorities. No one will ever say, "Papers, please."

(Granted, if I choose to do that I may not be able to register to vote,
but over half the population doesn't vote anyway. And the last time
I registered, no one checked to see that I actually lived there -- that
one of the problems we have with our voting system, even outside
of the State of Florida.. And I may not be able to get a driver's license
in order to legally drive a car, but a lot of illegal immigrants don't have
driver's licenses either, although that doesn't keep them from driving.)

So merely trying to ignore the problem of civil addressing schemes
won't solve that problem. And neither will various approaches that
make certain assumptions about monopoly name registration
authorities, or try to divine or impute where a directory containing
a particular name might be found based on some kind of a Karnak
mentalist act.

The primary issue is not the question of whether the name space
is flat or hierarchical, or how hierarchical, much less what the
"approved" schema is. What will be, will be, for reasons that
are beyond our scope and power to influence, even if we wanted
to.

So.

We cannot force a person to deposit his certificate or other useful
information into a specific directory, even if we wanted to. Nor can
we reliably impute a likely directory where such information might
be found, at least in the absence of a monopoly or governmental
mandate.

The best we can do is to ASK the user where he has deposited
such information, if anywhere, and to include that information
EXPLICITLY in any directory or pseudo-directory reference, such
as a DN.

Although at one time I liked the notion of prefixing the DN with a
URL, I have come to believe that John Wray's suggestion is the
better way forward.

He said:
>
>Bob,
>
>Accepting the fact that the X.500 dream of a single global directory is not
>going to happen any time soon, DNs can still be turned into globally
>significant pointers into a federation of directories in the way you
>suggest, but it doesn't require altering the DN syntax (and therefore
>doesn't have to break existing implementations). All that's needed is a DN
>attribute that names the particular directory within which the name
>resides. e.g. instead of "c=us;..;cn=My Name" you'd have "dir=My
>Directory;c=us;...;cn=My Name", where "My Directory" is the URL of a
>directory access point.

By including an explicit directory qualifier of the form dir="directory URL"
at the root (top) of the RDN chain, we have implicitly qualified all of the
rest
of the RDN, which is a Good Thing.

By defining the syntax of the "dir" attribute appropriately, we could
include
both the access type (LDAP, http, etc.) and port number appropriately,
either a default or explicitly indicated.

And by making the dir component multivalued, we could accommodate
a choice of multiple directories and multiple directory types.

Once again -- the essence of the problem is not the format of the directory
name but where a directory containing that name can be found.
Including that information as a top-level qualifying component solves that
problem (and potentially several others, such as name scope qualification)
very neatly.

Bob

Robert R. Jueneman
'Security Architect
Novell, Inc. -- the leading provider of Net services software
>
>
>
>
>
>
>
>>>> "Slone, Skip" 01/15/01 09:08AM >>>
>Oscar,
>
>No offense taken, thus no apology needed.
>
>My comments from the soapbox last week were actually intended for the
>community at large, and were meant to convey frustration at the apparent
>unwillingness of solution providers in general to hear about -- and solve
--
>real world problems that are faced by users like myself in large, complex
>environments.
>
>When I say "my environment is not so simple," the response I hear is "let's
>not talk about the complexity; let's make some simplifying assumptions
>instead."
>
>When I say "I have a nail AND a screw and need to put them both in the
>wall," the response I hear is "we have provided you with a perfectly
>adequate hammer, therefore you don't have a screw."
>
>As I was using the nail/hammer analogy, dc-based names are the nails;
>civil-attribute-based names are the screws. No matter how good a job my
>company does of using nails and nails alone, we still have tens of
thousands
>of trading partners, many of whom prefer screws to nails and will continue
>to use them indefinitely. Without a screwdriver, it's hard to do business
>with them.
>
>I don't really care what the screwdriver looks like. I've suggested a
>fairly simple design that I think will work. So far, no one has commented
on
>the design. What I've heard instead is a chorus of "we still don't like
>screws." Well, I don't like them either, but I still have to deal with
>them. If I'm simply overlooking a screwdriver that we have lying around
>somewhere, I would appreciate someone pointing it out to me.
>
> -- Skip
>
>
>-----Original Message-----
>From: Oscar Jacobsson [mailto:[email-masked]]
>Sent: Thursday, January 11, 2001 5:16 PM
>To: Slone, Skip
>Cc: 'Sharon Boeyen'; [email-masked]
>Subject: RE: Basic Cert-2-Directory mapping question
>
>
>> From: Slone, Skip [mailto:[email-masked]]
>> In response to this, I'm inclined to join Sharon on Marshall's soapbox
and
>> echo her words:
>>
>> "... I believe a more constructive approach is to accept the fact that
>> different parts of the world and different environments will use a
variety
>> of nameforms ... We are not the global naming police either and should
not
>> try to impose the rules that anyone uses to name entities to which they
>> issue certificates."
>
>I'm sorry if I came across as clamouring for rules be imposed. I know that
>this working group has a tendency to be wary of suggestions that don't
cater
>for distinguished names containing cat MPEGs, so I should probably have
been
>more careful. The requirements I suggested were for a possible naming
>standards document, conformance to which need not be enforced.
>
>The case at hand is not, IMHO, one of dictating that "all distinguished
>names must be according to our will, or you shall feel our wrath". A
>document however, outlining a naming strategy that would require of the
>users of certificates named accordingly no a-priori knowledge of their
>issuer (save for eventually having to reach something explicitly trusted in
>the chain) in order to perform path validation, is something I would
>personally consider very valuable indeed. I'm reasonably confident that
>organizations intending to act as certification authorities or trusted
third
>parties would agree.
>
>> And to quote someone Sharon and I both know, "If all you have is a
hammer,
>> every problem looks like a nail."
>
>It seems I was less than clear here as well. :-(
>
>My intention was to point out that there are actually two separate problems
>here (one nail, if you will, and one screw) each looking for its own
>solution:
>
>1. Defining a repository, and subsequently entry, discovery process for
>arbitrarily named entries.
>
>2. Defining a naming scheme that _if applied_ would automate this
repository
>and entry discovery process.
>
>I am only trying to address the second of these problems. The first is only
>an issue because nobody seems to have properly addressed the second before
>deploying certificates on the Internet en masse. The further we wait before
>addressing number two, the more of a problem number one will become.
>
>I should probably make a habit of pointing out that the opinions stated
here
>are my very own, and not necessarily those of my employer.
>
>Cheers,
>
>//oscar

Received: from junker.ms.inka.de (pD901CD87.dip.t-dialin.net [217.1.205.135]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id CAA15084 for ; Tue, 16 Jan 2001 02:46:13 -0800 (PST)
Received: from stroeder.com (localhost [127.0.0.1]) by junker.ms.inka.de (Postfix) with ESMTP id 82A9B67C6C for ; Tue, 16 Jan 2001 11:27:24 +0100 (CET)
Sender: [email-masked]
Message-ID: <[email-masked]>
Date: Tue, 16 Jan 2001 11:27:23 +0100
From: Michael =?iso-8859-1?Q?Str=F6der?=
Organization: stroeder.com
X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.18 i686)
X-Accept-Language: de-DE, de, en
MIME-Version: 1.0
To: [email-masked]
Subject: Re: Basic Cert-2-Directory mapping question
References: <[email-masked]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Steven Legg wrote:
>
> > Isn't a substantial part of this problem the question of how to
> > publish a certificate in a directory where it will be
> > searchable by a field
> > within SubjectAltName, most importantly the e-mail address
> > when that is
> > included?
>
> The refinement of the component
> matching rules in my last reply to David Chadwick would make it possible
> to search for entries containing certificates with a particular
> SubjectAltName regardless of whether the alternate name was reflected
> in any other attribute(s) in the entry.

1. Now I appreciate the I-D about certificate matching rules for
LDAP very much and I think this is a promising solution for part of
the problem.

2. If subjectAltName is an RFC822 mail address very likely the
directory admin will have no problem putting that attribute in the
entry itself => even applications/servers not implementing these
matching rules will be sufficient. (But this is not the issue here
and should not prevent anybody from adding the appropriate matching
rules for subjectAltName to the I-D).

3. As described in one of my former e-mails I believe that there's a
good chance to locate a person's entry by e-mail address (with SRV
records and doing searches on the located server).

The problem I see that up to now there's no common good practice
1. to add appropriate SRV records for at least the company's
top-level domain and
2. to make a directory-based certificate repository really
searchable.
Most directories I played with are either not public or public but
unbrowsable/limited regarding searches.

Now these problems are what we face most when deploying all this
PKIX stuff. We already have a lot of mechanisms at hand but nobody
is using them. What we need is not a new I-D for defining new
technical mechanisms. IMHO what we really need are I-Ds making clear
recommendations for tying all those relevant RFCs and I-Ds together.
Then we have a chance to get implementors doing it.

Ciao, Michael.

Received: from junker.ms.inka.de (pD901CD87.dip.t-dialin.net [217.1.205.135]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id CAA15085 for ; Tue, 16 Jan 2001 02:46:13 -0800 (PST)
Received: from stroeder.com (localhost [127.0.0.1]) by junker.ms.inka.de (Postfix) with ESMTP id A6C8367F3A for ; Tue, 16 Jan 2001 11:45:35 +0100 (CET)
Sender: [email-masked]
Message-ID: <[email-masked]>
Date: Tue, 16 Jan 2001 11:45:34 +0100
From: Michael =?iso-8859-1?Q?Str=F6der?=
Organization: stroeder.com
X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.18 i686)
X-Accept-Language: de-DE, de, en
MIME-Version: 1.0
To: ietf-pkix
Subject: Re: Basic Cert-2-Directory mapping question
References:
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Bob Jueneman wrote:
>
> Civil attribute type names will always be with us, and hence must be
> dealt with, for at least two fundamental reasons:
>
> 1. An address is not a name, although it may be a pseudonym. I
> don't want to be forced to change my identity, or to an extent
> my basis "self-hood," every time I change my ISP.

"Identity" is a very fundamental term. I would use it rather
carefully here. Identity can never ever be fully mapped to any sort
of name or address. Nor can it be represented by a public-key
certificate for this very reason.

> 2. E-mail address and other cyberspace identifiers fail to provide the
> essence of PKI from a nonrepudiation standpoint, i.e., what I call the
> "where do you send the sheriff" question.

I have no problems adding a mapping from a what you call "cyberspace
identifier" to a civil information record if this identifier is
unique.

And note that we have problems when dealing with "civil names"
anyway. Most times you can't derive from civil names (e.g. X.521
attributes) where to "send the sheriff".

Furthermore the CA already vouches for the mapping of the
certificate holder's "identity" (reduced to checking parts of the
identity specified in their CPS) to the subject DN. Whatever the
subject DN contains. If your business relys on a PKI you have to
trust a CA which enables you to "send the sheriff" to the
certificate holder. That's it.

Ciao, Michael.

Received: from junker.ms.inka.de (pD901CD87.dip.t-dialin.net [217.1.205.135]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id CAA15083 for ; Tue, 16 Jan 2001 02:46:13 -0800 (PST)
Received: from stroeder.com (localhost [127.0.0.1]) by junker.ms.inka.de (Postfix) with ESMTP id 0B1A767FEE for ; Tue, 16 Jan 2001 11:50:00 +0100 (CET)
Sender: [email-masked]
Message-ID: <[email-masked]>
Date: Tue, 16 Jan 2001 11:49:58 +0100
From: Michael =?iso-8859-1?Q?Str=F6der?=
Organization: stroeder.com
X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.18 i686)
X-Accept-Language: de-DE, de, en
MIME-Version: 1.0
To: ietf-pkix
Subject: Re: Basic Cert-2-Directory mapping question
References:
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Tom Gindin wrote:
>
> wouldn't it be reasonable to define a search
> syntax for them which uses keywords to identify fields, rather than the
> generic ASN.1 facility you proposed? I cannot believe that it is really
> appropriate to require LDAP queries for known ASN.1 types to specify
> matching rules within the query.

As far as I understand this I-D the LDAP client will just construct
LDAP filter strings as usual. The LDAP server deals with the ugly
stuff as it deals with ASN.1 structures when doing searches anyway.

Steve, David, correct me if I'm wrong.

Ciao, Michael.

Received: from ns.celocom.se ([email-masked] [212.209.40.66]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id CAA12587 for ; Tue, 16 Jan 2001 02:13:49 -0800 (PST)
Received: by ns.celocom.se; id LAA15720; Tue, 16 Jan 2001 11:19:19 +0100 (CET)
Received: from unknown(10.10.10.1) by ns.celocom.se via smap (V5.0) id xma015710; Tue, 16 Jan 01 11:18:34 +0100
Received: from celocom.com (stan.celocom.se [10.10.10.129]) by zap.celocom.se (8.8.7/8.8.7) with ESMTP id LAA13486; Tue, 16 Jan 2001 11:18:32 +0100
Message-ID: <[email-masked]>
Date: Tue, 16 Jan 2001 11:18:29 +0100
From: Oscar Jacobsson
Organization: Celo Communications
X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Sharon Boeyen
CC: "'Slone, Skip'" , "'Stephen Kent'" , [email-masked]
Subject: Re: Basic Cert-2-Directory mapping question
References:
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

All,

this thread has progressed a bit since last I checked, so I hope you'll
forgive me for skipping to the front.

Regarding our precious screwdriver, the primary functional requirement
for said tool, to paraphrase Sharon, would then appear to be:

"The screwdriver shall identify and locate PKIX repositories for
Distinguished Names."

Or is it important that this method only be used failing derivation or
a-priori knowledge of the repository location?

Is it also important that the DN be "geopolitically" structured, or can
I interpret that as "non-domainComponent" structured?

Skip has already proposed a solution, which I'd like to address:

"What I'm proposing is the development of a new DNS RR type that allows
the registration of arbitrary attribute value assertions (such as
"o=Something" or "ou=Something Else"). These new RRs (let's call them
AVA RRs) would resolve to a domain name that could subsequently be used
to construct the right hand portion of a PKIXREP query (or some other
SRV-seeking query). A remaining critical piece is the specification of
c=XX as equivalent to a corresponding ccTLD. As an example, when
resolving a DN ending in o=Entrust, c=CA, one would first query .ca for
an AVA record matching "o=Entrust", and would get a response such as
"entrust.com" which would then be used to generate a query along the
line of _PKIXREP._LDAP.entrust.com."

One issue I have with this is that it violates one of the central
premises of Sharon's "soapbox address" by placing the assumption on DNs
that they employ a specific naming scheme, in this case one with a
"C=xxx, O=xxx" root.

Regards,

//oscar

Sharon Boyen wrote:
> Hi Skip,
>
> What I meant by the tools was that the SRV records are populated by
> CAs, some of which use the geopolitical DN style and others that use
> the dc style. Regardless of what style of DN they use, all queries
> for SRV records are based on a domain name. If that domain name is
> known, or can be derived (e.g. by the email application from the
> email address), then the SRV records can direct you to the right PKI
> repository.
>
> The need for a screwdriver is when you don't know the domain name
> and can't derive it, but need to identify and locate the PKI
> repository for a geopolitically structured DN that you do know.
>
> Cheers,
> Sharon

Received: from ext-mail.valicert.com (ns1.valicert.com [63.65.221.10]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id WAA10846; Mon, 15 Jan 2001 22:12:18 -0800 (PST)
Received: from CONVERSION-DAEMON by ext-mail.valicert.com (PMDF V5.2-33 #46613) id <[email-masked]>; Mon, 15 Jan 2001 22:17: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 <[email-masked]>; Mon, 15 Jan 2001 22:17:47 -0800 (PST)
Received: by exchange.valicert.com with Internet Mail Service (5.5.2650.21) id ; Mon, 15 Jan 2001 22:13:34 -0800
Content-return: allowed
Date: Mon, 15 Jan 2001 22:13:32 -0800
From: Ambarish Malpani
Subject: RE: DPD & DPV Basics
To: "'Steve Hanna'" , Paul Hoffman / IMC
Cc: PKIX List
Message-id: <[email-masked]>
MIME-version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-type: text/plain; charset="iso-8859-1"

Hi Steve,
I agree with both this mail and the one you sent to Carlin
earlier - I would fully expect the client to send the server
the kind of use it wants to use the certificate for (IPSec, S/MIME,
SSL) and the appropriate information that would depend on the
protocol (the e-mail address of the sender/recipient, the address
it thinks it is connecting to, etc).

The DPV server needs to figure out what the right key usage/
extended key usage bits are, how to do validation, etc. I would
expect servers to support commonly known protocols and be expandable
for other/future protocols.

Regards,
Ambarish

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

> -----Original Message-----
> From: Steve Hanna [mailto:[email-masked]]
> Sent: Monday, January 15, 2001 2:32 PM
> To: Paul Hoffman / IMC
> Cc: PKIX List
> Subject: Re: DPD & DPV Basics
>
>
> Paul Hoffman / IMC wrote:
> > At 2:09 PM -0500 1/15/01, Steve Hanna wrote:
> > > >From this message and several others, I gather that the
> basic motivation
> > >for having a DPV server is to provide services to simple,
> "PKI-ignorant"
> > >clients. Could someone please supply some examples of such
> clients? What
> > >protocols will they be speaking (other than the DPV protocol)? This
> > >would be very useful in determining the proper
> requirements for the DPV
> > >protocol.
> >
> > Well, the one that started me on SCVP a few years ago was IPsec
> > implementations. All they really care about is "is the party that
> > just presented me with credentials someone for whom I have
> a security
> > policy?". They use PKI to get that information, but they actually
> > don't care about what the identity is after they have a) verified
> > that they trust the identity and then b) found a match for it in
> > their security policy set.
> >
> > Another example would be non-human S/MIME clients, such as a secure
> > automated order-processing that uses CMS messages over email. If the
> > recipient of the message can establish trust in the identity in the
> > cert and knows what to do with messages from that identity, that
> > recipient doesn't really care about the identity itself.
> >
> > In both cases, the details of what the path to the root is,
> who is in
> > that path, and why they are in that path, are irrelevant. "Is this
> > the signing/encrypting key for someone with whom I have an automated
> > security policy: yes or no?"
>
> I'm afraid that, as with TLS/SSL, the situation is not as simple as it
> might appear. I am certainly not an expert with IPsec or
> S/MIME, so feel
> free to correct me as necessary (as if IETFers would be shy
> about doing
> so!).
>
> Let's start with IPsec. During an IKE or ISAKMP exchange, one party
> (Alice) receives a certificate payload from another party (Bob) (or
> perhaps Alice receives a hash of a certificate that she already has or
> can easily get). Alice needs to decide whether she trusts this
> certificate. If so, she must check that the identification
> payload sent
> by Bob is included in the certificate and the public key
> included in the
> certificate can be used to verify the signature payload sent
> by Bob. And
> she must look up Bob's identity (as specified in the identification
> payload) in her security policy database to decide how to treat him.
>
> With a DPV server, Alice could send the certificate to the DPV server.
> The DPV server would decide whether Alice should trust it, by
> trying to
> build a valid path from one of her trust anchors to the
> certificate and
> checking revocation along the way. Once the DPV server had completed
> this validation, it could inform Alice of the result (Valid
> or Invalid).
>
> In order to make Alice's life as easy as possible, the DPV
> server would
> probably be preconfigured with Alice's trust anchors and other
> validation parameters. Alice and the DPV server would need mutual
> authentication with replay protection for their conversation and
> probably confidentiality, too.
>
> A few tricky bits, though. The DPV server should check that the
> certificate in question does not have key usage and extended key usage
> extensions inconsistent with the use that Alice is planning.
> This could
> be preconfigured along with the rest of Alice's validation parameters.
>
> A trickier bit is that Alice needs to check that the identification
> payload sent by Bob is included in the certificate. I suppose
> that Alice
> could send the identification payload to the DPV server in her initial
> request. But there are many Identification Types listed in RFC 2407. I
> guess the DPV server would have to know about all of those.
> How can they
> be listed in certificates, etc. Maybe only a few are used today
> (ID_IPV4_ADDR), but we would need to design the protocol so that it
> could support all of them in the future. Or the DPV would need to send
> all of the subject names and subject alternative names back
> to Alice and
> she could check for herself. So much for keeping Alice PKI-ignorant!
>
> Another tricky bit is that Alice must check that the public
> key included
> in the certificate can be used to verify the signature payload sent by
> Bob. The DPV server should send her the public key in its
> result, along
> with any DSA parameters and such. Then Alice can use it to verify the
> signature payload.
>
> Please correct me if I have made any mistakes with the IPsec part of
> this. I really know very little about IPsec and it seems to be quite
> complicated. I just want to make sure we understand all of the
> requirements that are implied for the DPV protocol and server.
>
> With respect to S/MIME, several others have said that S/MIME
> agents must
> be able to parse CMS and ASN.1. Therefore, it is reasonable to expect
> them to be PKI-aware. This seems sensible to me.
>
> But if you *did* want to use a DPV server for verifying signatures on
> S/MIME messages, it seems to me that you would need to deal
> with issues
> similar to the ones raised above and in the previous message regarding
> TLS/SSL: ensuring that the subject name or subject alternative name
> matches the From line, checking that the appropriate key usage and
> extended key usage bits are set, and getting the public key with
> parameters from the DPV server. There's also the separate issue of how
> (or whether) to send CRLs included with the message to the
> DPV server. A
> full-fledged S/MIME implementation would raise lots of more
> interesting
> issues: discovering a path to a previously unknown party in order to
> send them an encrypted email, determine which certificates and CRLs to
> send with a signed email (based on the intended recipients), etc. But
> that's clearly out of scope for DPV.
>
> Please feel free to correct my analysis. I just want to make sure we
> have thought about what DPV will be used for before we decide what the
> requirements should be.
>
> Thanks,
>
> Steve
>

Received: from ext-mail.valicert.com (ns1.valicert.com [63.65.221.10]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id VAA10358 for ; Mon, 15 Jan 2001 21:54:13 -0800 (PST)
Received: from CONVERSION-DAEMON by ext-mail.valicert.com (PMDF V5.2-33 #46613) id <[email-masked]> for [email-masked]; Mon, 15 Jan 2001 21:59:38 -0800 (PST)
Received: from polaris.valicert.com ([192.168.2.34]) by ext-mail.valicert.com (PMDF V5.2-33 #46613) with ESMTP id <[email-masked]>; Mon, 15 Jan 2001 21:59:38 -0800 (PST)
Received: by exchange.valicert.com with Internet Mail Service (5.5.2650.21) id ; Mon, 15 Jan 2001 21:55:25 -0800
Content-return: allowed
Date: Mon, 15 Jan 2001 21:55:24 -0800
From: Frank Balluffi
Subject: RE: DPD & DPV requirements
To: "'Michael Myers'"
Cc: [email-masked]
Message-id: <[email-masked]>
MIME-version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-type: text/plain; charset="iso-8859-1"

Mike Myers said:

> The ReqCert syntax of OCSPv2 imports Certificate syntax from
> X.509, yielding
> a single X.509 certificate in a request. At this stage, I
> have no objection
> to amending ReqCert to use CertificateSet syntax defined in
> RFC 2630 (i.e.
> CMS) to enable a "certificate lump" since the syntax of CertificateSet
> enables specification of a single certificate (although
> prefaced then by a
> SET OF, but otherwise we're looking at a SEQ OF anyway).
> OCSPv2 is already
> requiring linkage to 2630 via import of IssuerAndSerialNumber for
> certificate identification purposes.

I'm confused. Are people saying that the certificate whose path the client
would like to discover or validate is in the unordered lump of certificates
or that a separate lump of certificates may be sent to assist the server? I
thought the latter.

Frank

Received: from e4.ny.us.ibm.com (e4.ny.us.ibm.com [32.97.182.104]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id UAA08949 for ; Mon, 15 Jan 2001 20:24:23 -0800 (PST)
Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.117.200.22]) by e4.ny.us.ibm.com (8.9.3/8.9.3) with ESMTP id XAA159200; Mon, 15 Jan 2001 23:28:58 -0500
Received: from d02ml237.somers.hqregion.ibm.com (d02ml237.sby.ibm.com [9.45.4.171]) by northrelay02.pok.ibm.com (8.8.8m3/NCO v4.95) with ESMTP id XAA29098; Mon, 15 Jan 2001 23:27:01 -0500
Importance: Normal
Subject: RE: Basic Cert-2-Directory mapping question
To:
Cc: "'Stephen Kent'" ,
X-Mailer: Lotus Notes Release 5.0.3 (Intl) 21 March 2000
Message-ID:
From: "Tom Gindin"
Date: Mon, 15 Jan 2001 23:29:45 -0500
X-MIMETrack: Serialize by Router on D02ML237/02/M/IBM(Release 5.0.6 |December 14, 2000) at 01/15/2001 11:29:51 PM
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii

The technique you documented has some effects equivalent to the
alternative 1 I proposed, although with a syntax which requires
considerable knowledge of ASN.1 to formulate an LDAP query and with no
ability to index on the component field (as opposed to searching on it).
This does not mean that I disapprove of the idea of component filtering in
LDAP searches, which IMHO will solve a number of important problems.
However, in view of the very high proportion of ASN.1 usage within
directory attributes actually accounted for by the small number of
PKI-based data structures, wouldn't it be reasonable to define a search
syntax for them which uses keywords to identify fields, rather than the
generic ASN.1 facility you proposed? I cannot believe that it is really
appropriate to require LDAP queries for known ASN.1 types to specify
matching rules within the query.

Tom Gindin

"Steven Legg" on 01/15/2001 10:56:28 PM

Please respond to

To: Tom Gindin/Watson/IBM@IBMUS, "'Stephen Kent'"
cc:
Subject: RE: Basic Cert-2-Directory mapping question

Tom,

> -----Original Message-----
> From: Tom Gindin [mailto:[email-masked]]
> Sent: Saturday, 13 January 2001 18:48
> To: Stephen Kent
> Cc: [email-masked]
> Subject: Re: Basic Cert-2-Directory mapping question
>
>
>
> Steve:
>
> Isn't a substantial part of this problem the question of how to
> publish a certificate in a directory where it will be
> searchable by a field
> within SubjectAltName, most importantly the e-mail address
> when that is
> included? Most of the arguments which I have ever heard for including
> e-mail address in the subject DN were actually searchability
> arguments.
> The names in SubjectAltName are typically hierarchically assigned, of
> course, but they aren't X.500-based.
> Assuming that an EE wants their certificate published
> under the e-mail
> address, IMHO they should be able to request the RA or CA to
> perform one of
> the following actions on a successful certificate issuance (using the
> publication info control or a similar mechanism):
> 1 Add a directory attribute for e-mail address whose value
> is the e-mail
> address in the SubjectAltName to the directory entry named by
> the Subject
> DN. Very often, the RA or CA has the privilege and the
> knowledge to do
> this and the EE has only one or neither.
> 2 Send a certificate announcement to the domain of the
> e-mail address,
> in the hope and (reasonable) expectation that the certificate will be
> published there.
>
> Similar, but less practically important, considerations
> apply to other
> addresses in SubjectAltName. IMHO we also need to profile
> which directory
> attributes should normally be used when indexing a
> certificate under fields
> within SubjectAltName, especially since there are at least two fairly
> common attributes for e-mail address.

Rather than using other attributes as surrogates for searching for
certificates with particular fields (of subjectAltName or any other
component) I think it is more appropriate to have the capability to
search for those certificates directly. The refinement of the component
matching rules in my last reply to David Chadwick would make it possible
to search for entries containing certificates with a particular
SubjectAltName regardless of whether the alternate name was reflected
in any other attribute(s) in the entry. Such a solution avoids questions
about which other attributes to search, and doesn't require RAs or CAs to
populate said attributes.

Regards,
Steven

>
> Tom Gindin
>
> P.S. - The opinions above are my own, and not necessarily
> those of my
> employer.
>
>
>

Received: from arnie.adacel.com.au (arnie.adacel.com.au [203.36.26.147]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id TAA08372 for ; Mon, 15 Jan 2001 19:50:03 -0800 (PST)
Received: (qmail 7563 invoked from network); 16 Jan 2001 04:04:42 -0000
Received: from unknown (HELO osmium) (203.8.85.176) by arnie.adacel.com.au with SMTP; 16 Jan 2001 04:04:42 -0000
Reply-To:
From: "Steven Legg"
To: "'Tom Gindin'" , "'Stephen Kent'"
Cc:
Subject: RE: Basic Cert-2-Directory mapping question
Date: Tue, 16 Jan 2001 14:56:28 +1100
Message-ID: <[email-masked]>
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 8.5, Build 4.71.2377.0
In-Reply-To:
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2120.0
Importance: Normal

Tom,

> -----Original Message-----
> From: Tom Gindin [mailto:[email-masked]]
> Sent: Saturday, 13 January 2001 18:48
> To: Stephen Kent
> Cc: [email-masked]
> Subject: Re: Basic Cert-2-Directory mapping question
>
>
>
> Steve:
>
> Isn't a substantial part of this problem the question of how to
> publish a certificate in a directory where it will be
> searchable by a field
> within SubjectAltName, most importantly the e-mail address
> when that is
> included? Most of the arguments which I have ever heard for including
> e-mail address in the subject DN were actually searchability
> arguments.
> The names in SubjectAltName are typically hierarchically assigned, of
> course, but they aren't X.500-based.
> Assuming that an EE wants their certificate published
> under the e-mail
> address, IMHO they should be able to request the RA or CA to
> perform one of
> the following actions on a successful certificate issuance (using the
> publication info control or a similar mechanism):
> 1 Add a directory attribute for e-mail address whose value
> is the e-mail
> address in the SubjectAltName to the directory entry named by
> the Subject
> DN. Very often, the RA or CA has the privilege and the
> knowledge to do
> this and the EE has only one or neither.
> 2 Send a certificate announcement to the domain of the
> e-mail address,
> in the hope and (reasonable) expectation that the certificate will be
> published there.
>
> Similar, but less practically important, considerations
> apply to other
> addresses in SubjectAltName. IMHO we also need to profile
> which directory
> attributes should normally be used when indexing a
> certificate under fields
> within SubjectAltName, especially since there are at least two fairly
> common attributes for e-mail address.

Rather than using other attributes as surrogates for searching for
certificates with particular fields (of subjectAltName or any other
component) I think it is more appropriate to have the capability to
search for those certificates directly. The refinement of the component
matching rules in my last reply to David Chadwick would make it possible
to search for entries containing certificates with a particular
SubjectAltName regardless of whether the alternate name was reflected
in any other attribute(s) in the entry. Such a solution avoids questions
about which other attributes to search, and doesn't require RAs or CAs to
populate said attributes.

Regards,
Steven

>
> Tom Gindin
>
> P.S. - The opinions above are my own, and not necessarily
> those of my
> employer.
>
>
>

Received: from po1.bbn.com (PO1.BBN.COM [192.1.50.38]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id TAA08087 for ; Mon, 15 Jan 2001 19:44:35 -0800 (PST)
Received: from [128.33.238.101] (TC101.BBN.COM [128.33.238.101]) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id WAA23131; Mon, 15 Jan 2001 22:49:59 -0500 (EST)
Mime-Version: 1.0
X-Sender: [email-masked]
Message-Id:
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Date: Mon, 15 Jan 2001 22:40:42 -0500
To: Peter Williams
From: Stephen Kent
Subject: RE: DPD & DPV requirements - to nonce or not to nonce?
Cc: [email-masked]
Content-Type: multipart/alternative; boundary="============_-1232505458==_ma============"

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

Peter,

>X.511 enables signed requests and signed responses to be linked by
>nonce values. X.500 however had no
>clear statements about nonce handling. I implemented an online
>responder for certificates status
>values using X.511 signed request/response pairs several years ago.
>I maintained at the server a
>hash-tree of nonce values provided to, and generated by the server,
>and checked that a nonce value
>was not repeated in a certain period. As X.500 operations are rather
>more complex than simple OCSP, requiring support for multicasting,
>result reconstruction/resigning and n-level chaining of operations
>between master and slave servers, the issues of nonces seemed
>important beyond merely the issue of linking one request to the
>initiating servers response to thwart replay. The party who generates
>the information element in the response may not be the party that
>provides it (once resigned) to the
>relying party. The nonce value says nothing about the timeliness of
>the information, only the issuing
>time of the signed response PDU; the source of response data, under
>X.500 reconstruction rules
>may be cached data held by the server as a slave or replicate of a
>master DSA responsible
>for the status-data DIB. (*)
>
>Today, for NR reasons, Id use a hash-tree (just like CRTs!) that is
>persistent and stored as part
>of the NR records showing the proper conduct of the server when
>acting for the relying party. The thing
>that has changed in 10 years is the realization that the server is
>really the agent of the
>relying party: its not a frontend of the CA. The server now needs to
>ensure that it
>can show it fulfilled its obligations under the relying party
>agreement/policy.
>
>(*) Careful configuration of multi-mastering replication, to assure
>the relying-party that cache
>attacks are not in place, is used to address this in modern X.500
>versions, btw)

Not sure I see the need for the nonce hash tree you described, though
it is a clever approach, but it also might run afoul of the time
stamp patents of some folks.

It's up to a client to produce an example of a signed response from a
sever which it maintains provided a "wring" answer, if I understand
the context of your example. What is needed here is an ability to
verify the context of the request and response, to ensure that later
examination of response can be put into the proper time frame and
parameter setting. If we allow reference to validation policies by
reference, we'll have to make sure the reference includes a hash of
the policy, to avoid problems. But, I bet we have several options
ways to ensure that the client and server can later verify what the
parameter set was, and we have a time stamping protocol to nail down
the time context, as Denis has reminded us.

Steve

--============_-1232505458==_ma============
Content-Type: text/enriched; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Peter,

Arial0000,0000,FFFFX.511
enables signed requests and signed responses to be linked by nonce
values. X.500 however had no

clear statements about nonce handling. I implemented an online
responder for certificates status

values using X.511 signed request/response pairs several years ago. I
maintained at the server a

hash-tree of nonce values provided to, and generated by the server, and
checked that a nonce value

was not repeated in a certain period. As X.500 operations are rather
more complex than simple OCSP, requiring support for multicasting,
result reconstruction/resigning and n-level chaining of operations

between master and slave servers, the issues of nonces seemed important
beyond merely the issue of linking one request to the initiating
servers response to thwart replay. The party who generates

the information element in the response may not be the party that
provides it (once resigned) to the

relying party. The nonce value says nothing about the timeliness of the
information, only the issuing

time of the signed response PDU; the source of response data, under
X.500 reconstruction rules

may be cached data held by the server as a slave or replicate of a
master DSA responsible

for the status-data DIB. (*)

=20

Today, for NR reasons, Id use a hash-tree (just like CRTs!) that is
persistent and stored as part

of the NR records showing the proper conduct of the server when acting
for the relying party. The thing

that has changed in 10 years is the realization that the server is
really the agent of the

relying party: its not a frontend of the CA. The server now needs to
ensure that it

can show it fulfilled its obligations under the relying party
agreement/policy.

=20

(*) Careful configuration of multi-mastering replication, to assure
the relying-party that cache

attacks are not in place, is used to address this in modern X.500
versions, btw)

Arial0000,0000,FFFF

Not sure I see the need for the nonce hash tree
you described, though it is a clever approach, but it also might run
afoul of the time stamp patents of some folks.

It's up to a client to produce an example of a signed response from a
sever which it maintains provided a "wring" answer, if I understand the
context of your example. What is needed here is an ability to verify
the context of the request and response, to ensure that later
examination of response can be put into the proper time frame and
parameter setting. If we allow reference to validation policies by
reference, we'll have to make sure the reference includes a hash of the
policy, to avoid problems. But, I bet we have several options ways to
ensure that the client and server can later verify what the parameter
set was, and we have a time stamping protocol to nail down the time
context, as Denis has reminded us.

Steve =20

--============_-1232505458==_ma============--

Received: from po1.bbn.com (PO1.BBN.COM [192.1.50.38]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id TAA07508 for ; Mon, 15 Jan 2001 19:33:08 -0800 (PST)
Received: from [128.33.238.101] (TC101.BBN.COM [128.33.238.101]) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id WAA22547; Mon, 15 Jan 2001 22:38:14 -0500 (EST)
Mime-Version: 1.0
X-Sender: [email-masked] (Unverified)
Message-Id:
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Date: Mon, 15 Jan 2001 22:01:38 -0500
To: Peter Sylvester
From: Stephen Kent
Subject: Re: DPD & DPV Basics
Cc: [email-masked]
Content-Type: text/plain; charset="us-ascii" ; format="flowed"

Peter,

> > > Here's my take on the basic concepts of DPD and DPV:
> > >
> > > The basic job of a DPV server is to validate a certification path.
> >
> > I disagree. The basic job of a DPV server is to say whether a given
> > certificate is valid according to some validation policy. The
>client may not
> > provide any certification path.
>
>I second that. The server should/may provide a trustworthy
>certification path but even this may be considered as not necessary
>by the policy or application context.

Agreed, i.e., a compliant server must be prepared to return the path
and the revocation status data, but a client may not require the
return of such data, e.g., to reduce the bandwidth devoted to the
response.

> > > 2) Validate the supplied certification path using the supplied inputs
> >
> > No. He will have to fetch information (certs and revocation data).
>
>A server creates a valid/non-valid response acoording whatever information
>is available. IF the server returns a certification path, this path
>must be a path that can be validated even by the client or a client of
>the client.

I would like the spec to require the servers (DPD and DPV) to be
capable of retrieving certs and CRLs via LDAP (at a minimum), and to
be able to interact with OCSP servers. Local configuration may vary
...

>One question is if the client provides one intermediate CA
>cert (maybe expired), and the server knows that this intermediate
>CA cert is bad but has a good one, I think it is better to
>let the server decide whether to honour the input CA cert.

The spec already says that the revocation status data provided by the
client is advisory, but not mandatory. Presumably we could make the
same statement for certs supplied by the client, other than trust
anchors, or we can let the client indicate whether the supplied data
is advisory or mandatory.

> > > 3) Send a response containing the results of the validation (at least,
> > > an indication of success or failure)
> >
> > Yes, and as an option the data used for the assertion.
>
>Note that the certification path is part of these data.
>
>All data returned should be part of the signed structure.

Agreed.

> >
> > > Many refinements to this are possible: the client supplying only a
> > > subset of the necessary inputs (by referring to an established policy),
> >
> > .. or no subset at all.
> >
> > > the server returning supporting evidence such as CRLs and OCSP
> > > responses,
> >
> > No. The server returning a blob. The fact that the blob contains certs,
> > CRLs, delta CRLs, OSCP or whatever, is not visible.
>If it is not VISIBLE, then it doesn't make sense. It is not necessary
>for the client to know the complete interpretation of the 'blob'.

The client need not know it, but some ASN.1-aware and PKI-aware
software, not just DPV servers, should be able to parse it.

> >
> > > the client supplying CRLs or OCSP responses that may be
> > > useful to the server, etc. But I think it may be useful to reach
> > > agreement on the basic model described above before discussing these
> > > refinements (however worthy).
> >
> > > The basic job of a DPD server is to discover a certification path.
> >
> > No. The basic job of a DPD server is to help the PKI-aware client to perfom
> > the validation itself.
>
>In current PKI a validation always results in having a certification
>path, thus
>I do not see what else a DPD can provide to a client other than a
>certification path or some part of it.

A cert path AND matching revocation status data.

> > Certification paths or/and revocation information may be
>returned. More than
> > one certification path and one than one revocation information (e. g. both
> > CRLs and OCSP responses) may be returned.
>
> > > In its most basic form, it will perform the following steps:
> > >
> > > 1) Receive a request containing a target certificate and inputs to the
> > > validation algorithm (trust anchors, etc.)
> >
> > Yes.
> >
> > > 2) Attempt to discover a certification path ending in the target
> > > certificate that will validate properly given the supplied inputs
> >
> > One or more paths.
>See below. The server does not know which of many path the client likes.
>
> >
> > > 3) Send a response containing the results of the discovery process
> > > (at least an indication of success or failure and, in the success
> > > case, the discovered certification path)
> >
> > Succes or failure of finding the requested elements (i.e. certification
> > paths or/and revocation information)
>
>Is a DPD successful when it finds at least one path or some part of it?

A path returned by a DPD server must meet the criteria established by
the client, which must include reference (explicit or implicit) to
one or more trust points. So, a partial path does not meet that
criteria. I think returning one path suffices.

> >
> > > Most of the refinements listed above with respect to the DPV server can
> > > also be applied to the DPD server.
> >
> > No. See above.
>
> >
> > > In addition, other refinements might
> > > include having the client supply additional certificates that may be
> > > useful to the server (such as certificates received with an S/MIME email
> > > message).
> >
> > Yes.
>
>The structure for sending in additional certs together with the certs
>for which you ask a service, should be well defined. Both for DPV and DPD.\

Agreed. Russ has proposed the structure from S/MIME for the added
certs, vs. the target cert. Carlin (I think) suggested that we keep
the request simple (er?) and have just one target cert per request.

>For DPD there is the question about *how* does the server know when
>to stop filling up all possible cert chains that may be considered
>valid by the client. (That's why there is an interative approach
>in OSCP-DPD).

I think we answered this. One chain (with associated revocation
status data) is sufficient, IF it matches the validation criteria
supplied by the client. It's an open question whether we want to
provide a facility for a DPD server to return multiple chains (and
associated ...) as an option.

> >
> > > I look forward to seeing a discussion on this topic. If no discussion
> > > results, I suppose that I will conclude that there is general agreement
> > > about these basic concepts. However, simple affirmative messages
> > > agreeing with these basic concepts would be useful in judging rough
> > > consensus.
> >
> > Sorry, my message is going in the reverse direction. :-(
>
>The direction of consensus is not necessarily defined by the chairman :-)

It is determined by the chair, but not defined by the chair, as you note :-)

Steve

Received: from po1.bbn.com (PO1.BBN.COM [192.1.50.38]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id TAA07497 for ; Mon, 15 Jan 2001 19:33:06 -0800 (PST)
Received: from [128.33.238.101] (TC101.BBN.COM [128.33.238.101]) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id WAA22553; Mon, 15 Jan 2001 22:38:24 -0500 (EST)
Mime-Version: 1.0
X-Sender: [email-masked] (Unverified)
Message-Id:
In-Reply-To:
References:
Date: Mon, 15 Jan 2001 22:26:20 -0500
To: "Slone, Skip"
From: Stephen Kent
Subject: RE: DPD & DPV requirements
Cc: PKIX-List
Content-Type: text/plain; charset="us-ascii" ; format="flowed"

Skip,

>Steve,
>
>Thanks for your response. You've raised some good points that have caused
>me to reflect a little deeper on how this subject would play out. In my
>reflection, I reread the requirements message that prompted all this
>discussion. The question now in my mind is whether we should take another
>look at the differences between the DPV and DPD services. As of this moment
>in time, it seems to me that perhaps we should consider the two to be
>distinctly different animals, and that we should modify the requirements
>document accordingly. I know this is bordering on radical, so I ask you to
>bear with me for a few minutes while I explain my thinking...
>
>Specifically, if we consider a DPV server to be nothing more than a special
>case of a DPD client, we can keep the DPV client/server protocol extremely
>simple. At the same time, we can allow the DPD client/server protocol to
>represent the complex, signed, nested data structures necessary to convey
>the various scenarios discussed on this thread over the last several days.
>This separation also provides the restrictions necessary to accommodate the
>concerns expressed regarding concepts like transitive trust.

I think you have already lost me. Maybe this is because I have not
seen strong arguments that result in the need for recursive call
support, but I'l read on ...

>If we go down this path of cleanly separating DPV and DPD services, a DPV
>client could request service using an extremely simple query. For example,
>(other than the PDU headers) the query could contain as little as a
>certificate, and the result could be as simple as a boolean.

The client must specify validation parameters, either directly or via
reference to a policy, so no, the query cannot be as simple as you
suggest.

>The client
>might also express something like a required policy along with the
>certificate, but a default scenario would allow this part to be omitted,
>catering to highly constrained and/or "PKI-ignorant clients" (to quote you
>and Denis).

PKI-ignorant clients are candidates for using the reference approach
to specifying the validation parameters.

>Alternatively, the response might express a slightly more
>complex thought like "valid under policy X."

I think this is the minimum, simple query, and even here we need a
strong reference to the policy, e.g., a hash to go along with the URL.

>The DPV server would be a
>highly capable PKI-aware entity, responsible for obtaining the primitive
>elements (certs and certificate validity status information) from whatever
>sources are available, and for making a determination as to whether the
>presented certificate is valid under some given policy at some given point
>in time.

The "some policy" must be well defined, by the client.

>The determination of validity could be determined, in part, by the
>sources of the primitive elements. For example, if a blob of certs and
>status information is obtained within a signed structure, the validity of
>the enclosing signature would be taken into account.

You're loosing me again. Is the suggestion that receipt of a signed
blob of certs from some source relieves the DPV server from needing
to verify these certs? One could imagine that, if we allow recursive
calls among DPV servers, but this makes for a more complex system and
syntax, and I'd want to see good arguments about the benefits before
we head down that path.

>By contrast, DPD would be a vehicle for gathering the primitive elements
>needed to perform path validation, but would not necessarily make any
>judgements on the validity of those elements.

If a DPD server returns junk as an acceptable response I don't think
that's especially useful, and it makes verification of "correct
operation" either very hard or trivial :-).

> The DPD protocol would be
>sufficiently flexible to allow the DPD client to express a variety of
>starting elements (e.g., certs, CRLDPs, etc.) and/or path-related
>constraints (name constraints, policy constraints, policy mapping
>constraints, etc., as well as any new DPD-specific constraints). A service
>control in the protocol could allow the specification of whether the client
>requires complete paths in the response or if partial paths are acceptible.
>The DPD server could be permitted to gather its data from any available
>source (LDAP server, web server, FTP server, OCSP server, or DPD server), as
>long as that source is consistent with the constraints specified by the DPD
>client. The response PDU, which could (should?) itself be a signed
>structure, can contain any primitive elements gathered by this DPD server,
>as well as any nested, signed structures that resolve to primitive elements
>at some arbitrary, yet pragmatically constrained level of depth. I know it
>sounds complicated, but I suspect a fairly straightforward, recursive data
>structure could be specified to convey such a PDU.

Yes, it sounds complicated, and it is not clear what problem we're
solving by allow this complexity. The proposed requirement for a DPD
server is a simple one to understand, i.e., the server performs the
function of collecting a complete cert path and associated revocation
status data controlled by the same set of parameters that the client
will use to validate the path. That means that the answer returned to
a client will be useful for verifying the target cert, which is the
goal for the client in the first place. You don't include details to
motivate what the client does with the potentially piecemeal data
returned by a DPD server as suggested above. I think you need to
provide that, not just the high level scenario that initiated this
threat, if we are to consider this alternative.

>In the scenario I previously described, companies A and B would provide DPD
>services at their boundaries. The RP inside company A would request either
>DPV or DPD services from a company A server. That server would then request
>DPD services from company B's server. The path validation elements would be
>collected at company A (either at the DPV server or the RP itself) where the
>determination of validity would take place. In this scenario, there is no
>need for DPV recursion, but DPV or DPD servers are permitted to act as DPD
>clients as necessary. Path validation itself takes place at one point, using
>all the essential elements gathered, and based in part on validating the
>signatures on DPD responses from non-controlled sources.
>
>Note that actual implementations could provide a combined DPV/DPD service
>without implementing the more complex DPD protocol by keeping the DPV/DPD
>interface internal to the system.

of course.

>Is this too radical a departure from the previously articulated
>requirements?

Well, it's not the radical part that bothers me; it's the lack of
explicit, detailed motivation. The scenario you described can be
satisfied by the previous proposal for DPD and DPV services, so the
challenge is to articulate why creating a more complex interface to a
DPD server, but allowing it to return possible junk, is desirable. I
just don't see the point, yet.

Steve

Received: from eagle.verisign.com (eagle.verisign.com [208.206.241.105]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id SAA05519 for ; Mon, 15 Jan 2001 18:16:51 -0800 (PST)
Received: from postal-gw2.verisign.com (verisign.com [63.104.27.102]) by eagle.verisign.com (8.9.3/BCH1.7.1) with ESMTP id SAA14945; Mon, 15 Jan 2001 18:24:08 -0800 (PST)
Received: by postal-gw.verisign.com with Internet Mail Service (5.5.2650.21) id ; Mon, 15 Jan 2001 18:22:16 -0800
Message-ID: <[email-masked]>
From: Michael Myers
To: Peter Sylvester , [email-masked]
Cc: [email-masked]
Subject: RE: DPD & DPV requirements - Recursion Issues
Date: Mon, 15 Jan 2001 18:22:08 -0800
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"

Peter,

One thought at this point:

> -----Original Message-----
> From: Peter Sylvester [mailto:[email-masked]]
> Sent: Sunday, January 14, 2001 4:43 AM
> To: [email-masked]; [email-masked]
> Cc: [email-masked]
> Subject: RE: DPD & DPV requirements - Recursion Issues
>
> . . .
>
>
> Hm,
>
> A DPV response has such an importance that it seems useful to keep
> it as is when used by a client, even if this client uses the
> content of the response to create some other statement or
> whatever to its type of client.
>
> There are at least two elements in the response of a DPV:
>
> - A authoritive statement about whether a cert is good or not.
> - And a list of reasons, starting with the cert chain, crls,
> Ocsp responses.

Section 2, "Delegated Path Validation", of draft-ietf-pkix-ocsp-valid-00.txt
specifies use of BasicOCSPResponse syntax. This syntax enables but does not
mandate inclusion of chains or CRLs.

Mike

Received: from pigeon.verisign.com (pigeon.verisign.com [208.206.241.106]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id SAA05497 for ; Mon, 15 Jan 2001 18:16:46 -0800 (PST)
Received: from postal-gw1.verisign.com (verisign.com [63.104.27.101]) by pigeon.verisign.com (8.9.3/BCH1.7.1) with ESMTP id SAA23847; Mon, 15 Jan 2001 18:17:33 -0800 (PST)
Received: by postal-gw.verisign.com with Internet Mail Service (5.5.2650.21) id ; Mon, 15 Jan 2001 18:22:11 -0800
Message-ID: <[email-masked]>
From: Michael Myers
To: Frank Balluffi , "'Stephen Kent'"
Cc: [email-masked]
Subject: RE: DPD & DPV requirements
Date: Mon, 15 Jan 2001 18:22:10 -0800
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"

Steve, Frank, all:

The ReqCert syntax of OCSPv2 imports Certificate syntax from X.509, yielding
a single X.509 certificate in a request. At this stage, I have no objection
to amending ReqCert to use CertificateSet syntax defined in RFC 2630 (i.e.
CMS) to enable a "certificate lump" since the syntax of CertificateSet
enables specification of a single certificate (although prefaced then by a
SET OF, but otherwise we're looking at a SEQ OF anyway). OCSPv2 is already
requiring linkage to 2630 via import of IssuerAndSerialNumber for
certificate identification purposes.

Mike

Received: from pigeon.verisign.com (pigeon.verisign.com [208.206.241.106]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id SAA05485 for ; Mon, 15 Jan 2001 18:16:43 -0800 (PST)
Received: from postal-gw1.verisign.com (verisign.com [63.104.27.101]) by pigeon.verisign.com (8.9.3/BCH1.7.1) with ESMTP id SAA23840; Mon, 15 Jan 2001 18:17:28 -0800 (PST)
Received: by postal-gw.verisign.com with Internet Mail Service (5.5.2650.21) id ; Mon, 15 Jan 2001 18:22:06 -0800
Message-ID: <[email-masked]>
From: Michael Myers
To: Stephen Kent , Michael Myers
Cc: PKIX-List
Subject: RE: DPD & DPV requirements - Recursion Issues
Date: Mon, 15 Jan 2001 18:22:05 -0800
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"

Steve,

> On Friday, January 12, 2001 3:19 PM you wrote:
> . . .
> the question I asked was whether the OCSP response carried data that
> tied it to a requestor, not a responder.

As Rick Salz noted, RFC 2560 enables such binding via the nonce mechanism.
Use of this mechanism is not however mandated. Also, Rich Akney was a
strong advocate of the OPTIONAL requestorName syntax in an OCSP request.
The definition of the production of response signature in RFC 2560 does not
include the contents of the request in its hash. We might wish to consider
amending this in the OCSPv2 I-D but it's not yet clear to me that we should
inhibit response transparency. A relying party might very well wish to know
who is ultimately standing behind a certificate.

Mike

Received: from arista.iris.com (arista.iris.com [198.112.211.42]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA02735 for ; Mon, 15 Jan 2001 15:21:25 -0800 (PST)
From: [email-masked]
Subject: NSPW 2001 CFP
To: [email-masked]
Cc: [email-masked], [email-masked]
X-Mailer: Lotus Notes Release 5.0.5 September 22, 2000
Message-ID:
Date: Mon, 15 Jan 2001 18:25:34 -0500
X-MIMETrack: Serialize by Router on Arista/Iris(Build V507_01082001 |January 8, 2001) at 01/15/2001 06:26:57 PM
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii

========================================================================
Call For Papers
New Security Paradigms Workshop 2001
An ACM/SIGSAC sponsored workshop
11 - 13 September 2001
Cloudcroft, New Mexico, USA
http://www.nspw.org
========================================================================

2001 is the tenth anniversary of the New Security Paradigms Workshop
(NSPW), which has provided a productive and highly interactive forum for
innovative new approaches to computer security. The workshop offers a
constructive environment where experienced researchers and practitioners
work alongside newer participants in the field. The result is a unique
opportunity to exchange ideas. NSPW 2001 will take place September 11 -
13, 2001 at the Cloudcroft Lodge, Cloudcroft, New Mexico, 20 miles from
Alamogordo/White Sands.

In order to preserve the small, focused nature of the workshop,
participation is limited to authors of accepted papers and conference
organizers. Because we expect new paradigms we accept wide-ranging
topics in information security. Any paper that presents a significant
shift in thinking about difficult security issues or builds on a
previous shift is welcomed.

NSPW is highly interactive in nature. Authors are encouraged to present
ideas that might be considered risky in some other forum. All
participants are charged with providing feedback in a constructive
manner. The resulting brainstorming environment has proven to be an
excellent medium for furthering the development of these ideas. Many
authors have mentioned that they received more useful feedback and ideas
than from any other conference. The proceedings, published after the
workshop, have consistently benefited from the inclusion of workshop
feedback.

What makes a paper acceptable for NSPW? While we reject plenty of
excellent papers that would do very well at other venues, our eclectic
program committee particularly looks for new paradigms, innovative
approaches to older problems, early thinking on new topics that are not
necessarily fully polished, and controversial issues that might not make
it into other conferences but deserve to have their try at shaking and
breaking the mold. Conversely, a great paper that does not have a new
paradigm, does not challenge the status quo, or does not critique an
older paradigm will almost certainly get rejected.

To participate, please submit your paper, justification, and attendance
statement, preferably via e-mail, to both Program Chairs -- Brenda
Timmerman and Darrell Kienzle
-- by Friday, March 30, 2001 (hardcopy submissions must be received by
Friday, March 23, 2001). Further details on the required format of
submissions follow.

1 - Your Paper
You should submit either a research paper, a 5 - 10 page position paper,
or a discussion topic proposal. Submissions of any type must not have
been published elsewhere. Discussion topic proposals should include an
in-depth description of the topic to be discussed, a convincing argument
that the topic will lead to a lively discussion, and any other
supporting materials.

Softcopy submissions should be in Postscript, PDF, Word/RTF or ASCII
format. Papers may be submitted as hardcopy. To submit hardcopy, please
mail 5 (five) copies to Program Co-chair Brenda Timmerman. Please allow
adequate time for delivery.

2 - Justification
You should describe, in one page or less, why your paper is appropriate
for the New Security Paradigms Workshop. A good justification will
describe the new paradigm being proposed, explain how it is a departure
from existing theory or practice, and identify those aspects of the
status quo it challenges or rejects.

3 - Attendance Statement
You should state how many authors wish to attend the workshop. Accepted
papers require the attendance of at least one author. In order to ensure
that all papers receive equally strong feedback, all attendees are
expected to stay for the entire duration of the workshop.

The program committee will referee the papers and notify the authors of
acceptance status by June 8, 2000. We expect to be able to offer a
limited amount of financial aid to those who require it. More
information will be provided on our web site as it
becomes available.

Workshop General and Vice Chairs

Steven J. Greenwald Cristina Serban
Independent Consultant AT&T Labs
2521 NE 135th Street 307 Middletown-Lincroft Rd.
North Miami, FL 33181 USA Lincroft, NJ 07748 USA
Email: [email-masked] Email: [email-masked]
Voice: +1 (305) 944-7842 Voice: +1 (732) 576-3279
Fax: +1 (305) 489-8129 Fax: +1 (732) 576-6406

Program Committee Co-Chairs

Brenda Timmerman Darrell Kienzle
California State University NAI Labs at Network Associates
18111 Nordhoff Street 8000 Westpark Dr. Suite 600
Northridge, CA 91330-8281 USA McLean, VA 22102 USA
Email: [email-masked] Email: [email-masked]
Voice: +1 (818) 677-7341 Voice: 703-356-4938
Fax: +1 (818) 677-2140 Fax: 703-821-8426

Program Committee

Bob Blakley, Tivoli Systems
Thomas E. Daniels, CERIAS/Purdue University
Heather Hinton, Tivoli Systems
Jun Li, University of California, Los Angeles
Carla Marceau, Odyssey Research Associates
Cathy Meadows, Naval Research Laboratory
Ira Moskowitz, Naval Research Laboratory
Susan Pancho, University of Cambridge
Kai Rannenberg, Microsoft Research, Cambridge
Emilia Rosti, Universita` degli Studi di Milano
Sami Saydjari, SRI International
Abe Singer, University of California, San Diego
John Michael Williams, USA
Bradley J. Wood, SRI International

Local Arrangements
John McHugh, SEI/CERT, +1 (412) 268-7737

Financial Aid
Hilary Hosmer, Data Security Inc., +1 (781) 275-8231

John McHugh, SEI/CERT, +1 (412) 268-7737,

Publicity
Crispin Cowan (WireX Communications, Inc.) +1 (503) 241-6575

ACM-SIGSAC Chair
Ravi Sandhu (George Mason University) +1 (703) 993-1659

Steering Committee
Bob Blakley, Steven J. Greenwald, Hilary Hosmer, Darrell Kienzle,
Catherine Meadows, Cristina Serban, Brenda Timmerman, Mary Ellen Zurko

Received: from [165.227.249.17] (ip17.proper.com [165.227.249.17]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA01858; Mon, 15 Jan 2001 14:47:53 -0800 (PST)
Mime-Version: 1.0
X-Sender: [email-masked]
Message-Id:
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Date: Mon, 15 Jan 2001 14:51:57 -0800
To: Steve Hanna
From: Paul Hoffman / IMC
Subject: Re: DPD & DPV Basics
Cc: PKIX List
Content-Type: text/plain; charset="us-ascii" ; format="flowed"

At 5:32 PM -0500 1/15/01, Steve Hanna wrote:
>I'm afraid that, as with TLS/SSL, the situation is not as simple as it
>might appear. I am certainly not an expert with IPsec or S/MIME, so feel
>free to correct me as necessary (as if IETFers would be shy about doing
>so!).

Done. :-)

Where you go wrong on both of your responses is to assume that an
application that can parse a cert is the same thing as one which is
PKI-aware. This is not the case. A program that can parse a cert just
fine might still want/need a DPV to do the path checking (which
includes the CA policy checking) and the validity checking.

For instance, you say:

>A few tricky bits, though. The DPV server should check that the
>certificate in question does not have key usage and extended key usage
>extensions inconsistent with the use that Alice is planning. This could
>be preconfigured along with the rest of Alice's validation parameters.

That is not needed in the examples I gave. Alice's IKE implementation
can parse the certificate from Bob and decide if the key usage bits
in the cert match her security policy. Yes, she might want to trust
the DPV system to do that, but she doesn't have to.

>A trickier bit is that Alice needs to check that the identification
>payload sent by Bob is included in the certificate.

Not tricky at all: parse the cert, find the SubjectAltName in it, and
compare it to the ID payload.

>With respect to S/MIME, several others have said that S/MIME agents must
>be able to parse CMS and ASN.1. Therefore, it is reasonable to expect
>them to be PKI-aware. This seems sensible to me.

Nope: you conflated to different possible attributes of the agents.

Does that make more sense?

FWIW, I got this wrong when I started the SCVP work. I wanted clients
to not need to be able to parse the cert, and for the SCVP server to
not only pass back a yes-no answer, but also the relevant parts of
the cert. It was pointed out to me that this was doable but not that
useful: parsing a cert for the ID, the key, and the key usage isn't
as hard as some people think.

--Paul Hoffman, Director
--Internet Mail Consortium

Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA00355; Mon, 15 Jan 2001 14:29:42 -0800 (PST)
Received: from eastmail1.East.Sun.COM ([129.148.1.240]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id OAA19194; Mon, 15 Jan 2001 14:35:10 -0800 (PST)
Received: from sunlabs.East.Sun.COM (sunlabs.East.Sun.COM [129.148.75.250]) by eastmail1.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id RAA21732; Mon, 15 Jan 2001 17:35:09 -0500 (EST)
Received: from sun.com (dhcp75-155 [129.148.75.155]) by sunlabs.East.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id RAA25502; Mon, 15 Jan 2001 17:35:08 -0500 (EST)
Message-ID: <[email-masked]>
Date: Mon, 15 Jan 2001 17:32:15 -0500
From: Steve Hanna
Organization: Sun Microsystems, Inc.
X-Mailer: Mozilla 4.75 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Paul Hoffman / IMC
CC: PKIX List
Subject: Re: DPD & DPV Basics
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Paul Hoffman / IMC wrote:
> At 2:09 PM -0500 1/15/01, Steve Hanna wrote:
> > >From this message and several others, I gather that the basic motivation
> >for having a DPV server is to provide services to simple, "PKI-ignorant"
> >clients. Could someone please supply some examples of such clients? What
> >protocols will they be speaking (other than the DPV protocol)? This
> >would be very useful in determining the proper requirements for the DPV
> >protocol.
>
> Well, the one that started me on SCVP a few years ago was IPsec
> implementations. All they really care about is "is the party that
> just presented me with credentials someone for whom I have a security
> policy?". They use PKI to get that information, but they actually
> don't care about what the identity is after they have a) verified
> that they trust the identity and then b) found a match for it in
> their security policy set.
>
> Another example would be non-human S/MIME clients, such as a secure
> automated order-processing that uses CMS messages over email. If the
> recipient of the message can establish trust in the identity in the
> cert and knows what to do with messages from that identity, that
> recipient doesn't really care about the identity itself.
>
> In both cases, the details of what the path to the root is, who is in
> that path, and why they are in that path, are irrelevant. "Is this
> the signing/encrypting key for someone with whom I have an automated
> security policy: yes or no?"

I'm afraid that, as with TLS/SSL, the situation is not as simple as it
might appear. I am certainly not an expert with IPsec or S/MIME, so feel
free to correct me as necessary (as if IETFers would be shy about doing
so!).

Let's start with IPsec. During an IKE or ISAKMP exchange, one party
(Alice) receives a certificate payload from another party (Bob) (or
perhaps Alice receives a hash of a certificate that she already has or
can easily get). Alice needs to decide whether she trusts this
certificate. If so, she must check that the identification payload sent
by Bob is included in the certificate and the public key included in the
certificate can be used to verify the signature payload sent by Bob. And
she must look up Bob's identity (as specified in the identification
payload) in her security policy database to decide how to treat him.

With a DPV server, Alice could send the certificate to the DPV server.
The DPV server would decide whether Alice should trust it, by trying to
build a valid path from one of her trust anchors to the certificate and
checking revocation along the way. Once the DPV server had completed
this validation, it could inform Alice of the result (Valid or Invalid).

In order to make Alice's life as easy as possible, the DPV server would
probably be preconfigured with Alice's trust anchors and other
validation parameters. Alice and the DPV server would need mutual
authentication with replay protection for their conversation and
probably confidentiality, too.

A few tricky bits, though. The DPV server should check that the
certificate in question does not have key usage and extended key usage
extensions inconsistent with the use that Alice is planning. This could
be preconfigured along with the rest of Alice's validation parameters.

A trickier bit is that Alice needs to check that the identification
payload sent by Bob is included in the certificate. I suppose that Alice
could send the identification payload to the DPV server in her initial
request. But there are many Identification Types listed in RFC 2407. I
guess the DPV server would have to know about all of those. How can they
be listed in certificates, etc. Maybe only a few are used today
(ID_IPV4_ADDR), but we would need to design the protocol so that it
could support all of them in the future. Or the DPV would need to send
all of the subject names and subject alternative names back to Alice and
she could check for herself. So much for keeping Alice PKI-ignorant!

Another tricky bit is that Alice must check that the public key included
in the certificate can be used to verify the signature payload sent by
Bob. The DPV server should send her the public key in its result, along
with any DSA parameters and such. Then Alice can use it to verify the
signature payload.

Please correct me if I have made any mistakes with the IPsec part of
this. I really know very little about IPsec and it seems to be quite
complicated. I just want to make sure we understand all of the
requirements that are implied for the DPV protocol and server.

With respect to S/MIME, several others have said that S/MIME agents must
be able to parse CMS and ASN.1. Therefore, it is reasonable to expect
them to be PKI-aware. This seems sensible to me.

But if you *did* want to use a DPV server for verifying signatures on
S/MIME messages, it seems to me that you would need to deal with issues
similar to the ones raised above and in the previous message regarding
TLS/SSL: ensuring that the subject name or subject alternative name
matches the From line, checking that the appropriate key usage and
extended key usage bits are set, and getting the public key with
parameters from the DPV server. There's also the separate issue of how
(or whether) to send CRLs included with the message to the DPV server. A
full-fledged S/MIME implementation would raise lots of more interesting
issues: discovering a path to a previously unknown party in order to
send them an encrypted email, determine which certificates and CRLs to
send with a signed email (based on the intended recipients), etc. But
that's clearly out of scope for DPV.

Please feel free to correct my analysis. I just want to make sure we
have thought about what DPV will be used for before we decide what the
requirements should be.

Thanks,

Steve

Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA29009 for ; Mon, 15 Jan 2001 14:08:09 -0800 (PST)
Received: from eastmail2.East.Sun.COM ([129.148.1.241]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA02855; Mon, 15 Jan 2001 14:13:36 -0800 (PST)
Received: from sunlabs.East.Sun.COM (sunlabs.East.Sun.COM [129.148.75.250]) by eastmail2.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id RAA07492; Mon, 15 Jan 2001 17:13:36 -0500 (EST)
Received: from sun.com (dhcp75-155 [129.148.75.155]) by sunlabs.East.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id RAA24635; Mon, 15 Jan 2001 17:13:34 -0500 (EST)
Message-ID: <[email-masked]>
Date: Mon, 15 Jan 2001 17:10:41 -0500
From: Steve Hanna
Organization: Sun Microsystems, Inc.
X-Mailer: Mozilla 4.75 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: "Covey, Carlin"
CC: PKIX List
Subject: Re: DPD & DPV Basics
References: <[email-masked]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

"Covey, Carlin" wrote:
> It seems to me that DPV would be very useful for devices that
> are bandwidth limited, such as cell phones, or are protocol-
> complexity-limited, such as VPN devices implemented in hardware.
> In both these cases the device would not be interested in the
> supporting evidence, just a good/not-good indication.

For cell phones, TLS/SSL would probably be the primary certificate-using
protocol that we would need to support. For VPN devices, it would
probably be IPsec. Please correct me if I'm wrong on this.

Let's take a look at what we would need to support a cell phone talking
TLS/SSL (server side authentication only, let's assume). For IPsec, see
my response to Paul Hoffman's email (coming out next).

When an TLS/SSL client receives a Server Certificate message, it needs
to decide whether it believes that the server's end-entity certificate
is valid. It also needs to make sure that this certificate includes a
subject name or subject alternative name that matches the expected host
name and that the appropriate key usage and extended key usage bits are
set (or that those extensions are absent). Finally, it needs to extract
the public key from the certificate (along with any public key
parameters), so that it can complete the handshake and authenticate the
server.

With a DPV server, the TLS/SSL client could send the TLS/SSL server's
end-entity certificate to the DPV server. The DPV server would decide
whether the TLS/SSL client should trust it, by trying to discover a
validated path from one of the client's trust anchors to the
certificate. Once the DPV server had completed this validation, it could
inform the TLS/SSL client of the result (Valid or Invalid).

In order to make the TLS/SSL client's life as easy as possible, the DPV
server could be preconfigured with its trust anchors and other
validation parameters. The TLS/SSL client and the DPV server would need
mutual authentication with replay protection for their conversation and
probably confidentiality, too.

But what about the TLS/SSL client's need to check that the TLS/SSL
server's end entity certificate includes a subject name or subject
alternative name that matches the expected host name? This task could be
handled by the DPV server, but we would need to include a way for the
DPV client to send the host name to the DPV server and the DPV server
would need to know about the special, legacy ways that host names may be
included in certificates. Or the DPV server could send the list of
subject names and subject alternative names to the DPV client, which
would could parse these items itself and decide whether they were
acceptable. Or we could just have the TLS/SSL client parse the
certificate, but now it's not PKI-ignorant any more.

The key usage and extended key usage checks can be handled by including
the desired values in the preconfigured validation parameters on the DPV
server. But the DPV server will definitely need to send the public key
value to the DPV client, since the end-entity certificate may have
inherited DSA parameters.

Note also that the TLS/SSL client should really send the other
certificates included in the Server Certificate message to the DPV
server. They may be essential to building the path.

I certainly don't think these requirements are impossible to meet.
However, they should be added to the requirements for DPV (which are
diverging quickly from the requirements for DPD).

-Steve

>
> Regards,
> Carlin
>
> ----------------------------
> - Carlin Covey
> Cylink Corp.
>
> -----Original Message-----
> From: Steve Hanna [mailto:[email-masked]]
> Sent: Monday, January 15, 2001 12:10 PM
> To: Stephen Kent
> Cc: PKIX List
> Subject: Re: DPD & DPV Basics
>
> Stephen Kent wrote:
> > Maybe the root of our disagreement is the assumption of what
> > the common requirement is for a DPV client. My strawman cites
> > PKI-ignorant (to use Denis' term) clients as a major motivation for
> > DPV, which seems incompatible with a DPV server that requires perfect
> > inputs.
>
> From this message and several others, I gather that the basic motivation
> for having a DPV server is to provide services to simple, "PKI-ignorant"
> clients. Could someone please supply some examples of such clients? What
> protocols will they be speaking (other than the DPV protocol)? This
> would be very useful in determining the proper requirements for the DPV
> protocol.
>
> Thanks,
>
> Steve

Received: from [165.227.249.17] (ip17.proper.com [165.227.249.17]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA28499 for ; Mon, 15 Jan 2001 13:52:30 -0800 (PST)
Mime-Version: 1.0
X-Sender: [email-masked]
Message-Id:
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Date: Mon, 15 Jan 2001 13:56:33 -0800
To: PKIX List
From: Paul Hoffman / IMC
Subject: Re: DPD & DPV Basics
Content-Type: text/plain; charset="us-ascii" ; format="flowed"

At 2:09 PM -0500 1/15/01, Steve Hanna wrote:
> >From this message and several others, I gather that the basic motivation
>for having a DPV server is to provide services to simple, "PKI-ignorant"
>clients. Could someone please supply some examples of such clients? What
>protocols will they be speaking (other than the DPV protocol)? This
>would be very useful in determining the proper requirements for the DPV
>protocol.

Well, the one that started me on SCVP a few years ago was IPsec
implementations. All they really care about is "is the party that
just presented me with credentials someone for whom I have a security
policy?". They use PKI to get that information, but they actually
don't care about what the identity is after they have a) verified
that they trust the identity and then b) found a match for it in
their security policy set.

Another example would be non-human S/MIME clients, such as a secure
automated order-processing that uses CMS messages over email. If the
recipient of the message can establish trust in the identity in the
cert and knows what to do with messages from that identity, that
recipient doesn't really care about the identity itself.

In both cases, the details of what the path to the root is, who is in
that path, and why they are in that path, are irrelevant. "Is this
the signing/encrypting key for someone with whom I have an automated
security policy: yes or no?"

--Paul Hoffman, Director
--Internet Mail Consortium

Received: from exchange.cylink.com (exchange.cylink.com [192.43.161.25]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA26759 for ; Mon, 15 Jan 2001 13:24:01 -0800 (PST)
Received: by exchange.cylink.com with Internet Mail Service (5.5.2650.21) id ; Mon, 15 Jan 2001 13:21:21 -0800
Message-ID: <[email-masked]>
From: "Covey, Carlin"
To: PKIX List
Subject: RE: DPD & DPV Basics
Date: Mon, 15 Jan 2001 13:21:20 -0800
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"

It seems to me that DPV would be very useful for devices that
are bandwidth limited, such as cell phones, or are protocol-
complexity-limited, such as VPN devices implemented in hardware.
In both these cases the device would not be interested in the
supporting evidence, just a good/not-good indication.

Regards,
Carlin

----------------------------
- Carlin Covey
Cylink Corp.

-----Original Message-----
From: Steve Hanna [mailto:[email-masked]]
Sent: Monday, January 15, 2001 12:10 PM
To: Stephen Kent
Cc: PKIX List
Subject: Re: DPD & DPV Basics

Stephen Kent wrote:
> Maybe the root of our disagreement is the assumption of what
> the common requirement is for a DPV client. My strawman cites
> PKI-ignorant (to use Denis' term) clients as a major motivation for
> DPV, which seems incompatible with a DPV server that requires perfect
> inputs.

>From this message and several others, I gather that the basic motivation
for having a DPV server is to provide services to simple, "PKI-ignorant"
clients. Could someone please supply some examples of such clients? What
protocols will they be speaking (other than the DPV protocol)? This
would be very useful in determining the proper requirements for the DPV
protocol.

Thanks,

Steve

Received: from mailgw2a.lmco.com (mailgw2a.lmco.com [192.91.147.7]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA26273 for ; Mon, 15 Jan 2001 13:20:14 -0800 (PST)
Received: from emss03g01.ems.lmco.com (emss03g01.ems.lmco.com [141.240.4.144]) by mailgw2a.lmco.com (8.8.8/8.8.8) with ESMTP id QAA07950; Mon, 15 Jan 2001 16:25:39 -0500 (EST)
Received: from CONVERSION-DAEMON by lmco.com (PMDF V5.2-32 #38888) id <[email-masked]>; Mon, 15 Jan 2001 16:24:18 -0500 (EST)
Received: from emss03i00.ems.lmco.com ([141.240.31.211]) by lmco.com (PMDF V5.2-32 #38888) with ESMTP id <[email-masked]>; Mon, 15 Jan 2001 16:24:10 -0500 (EST)
Received: by emss03i00.orl.lmco.com with Internet Mail Service (5.5.2650.21) id ; Mon, 15 Jan 2001 16:25:18 -0500
Content-return: allowed
Date: Mon, 15 Jan 2001 16:25:18 -0500
From: "Slone, Skip"
Subject: RE: DPD & DPV requirements
To: "'Stephen Kent'"
Cc: PKIX-List
Message-id:
MIME-version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-type: text/plain
Content-transfer-encoding: 7BIT

Steve,

Thanks for your response. You've raised some good points that have caused
me to reflect a little deeper on how this subject would play out. In my
reflection, I reread the requirements message that prompted all this
discussion. The question now in my mind is whether we should take another
look at the differences between the DPV and DPD services. As of this moment
in time, it seems to me that perhaps we should consider the two to be
distinctly different animals, and that we should modify the requirements
document accordingly. I know this is bordering on radical, so I ask you to
bear with me for a few minutes while I explain my thinking...

Specifically, if we consider a DPV server to be nothing more than a special
case of a DPD client, we can keep the DPV client/server protocol extremely
simple. At the same time, we can allow the DPD client/server protocol to
represent the complex, signed, nested data structures necessary to convey
the various scenarios discussed on this thread over the last several days.
This separation also provides the restrictions necessary to accommodate the
concerns expressed regarding concepts like transitive trust.

If we go down this path of cleanly separating DPV and DPD services, a DPV
client could request service using an extremely simple query. For example,
(other than the PDU headers) the query could contain as little as a
certificate, and the result could be as simple as a boolean. The client
might also express something like a required policy along with the
certificate, but a default scenario would allow this part to be omitted,
catering to highly constrained and/or "PKI-ignorant clients" (to quote you
and Denis). Alternatively, the response might express a slightly more
complex thought like "valid under policy X." The DPV server would be a
highly capable PKI-aware entity, responsible for obtaining the primitive
elements (certs and certificate validity status information) from whatever
sources are available, and for making a determination as to whether the
presented certificate is valid under some given policy at some given point
in time. The determination of validity could be determined, in part, by the
sources of the primitive elements. For example, if a blob of certs and
status information is obtained within a signed structure, the validity of
the enclosing signature would be taken into account.

By contrast, DPD would be a vehicle for gathering the primitive elements
needed to perform path validation, but would not necessarily make any
judgements on the validity of those elements. The DPD protocol would be
sufficiently flexible to allow the DPD client to express a variety of
starting elements (e.g., certs, CRLDPs, etc.) and/or path-related
constraints (name constraints, policy constraints, policy mapping
constraints, etc., as well as any new DPD-specific constraints). A service
control in the protocol could allow the specification of whether the client
requires complete paths in the response or if partial paths are acceptible.
The DPD server could be permitted to gather its data from any available
source (LDAP server, web server, FTP server, OCSP server, or DPD server), as
long as that source is consistent with the constraints specified by the DPD
client. The response PDU, which could (should?) itself be a signed
structure, can contain any primitive elements gathered by this DPD server,
as well as any nested, signed structures that resolve to primitive elements
at some arbitrary, yet pragmatically constrained level of depth. I know it
sounds complicated, but I suspect a fairly straightforward, recursive data
structure could be specified to convey such a PDU.

In the scenario I previously described, companies A and B would provide DPD
services at their boundaries. The RP inside company A would request either
DPV or DPD services from a company A server. That server would then request
DPD services from company B's server. The path validation elements would be
collected at company A (either at the DPV server or the RP itself) where the
determination of validity would take place. In this scenario, there is no
need for DPV recursion, but DPV or DPD servers are permitted to act as DPD
clients as necessary. Path validation itself takes place at one point, using
all the essential elements gathered, and based in part on validating the
signatures on DPD responses from non-controlled sources.

Note that actual implementations could provide a combined DPV/DPD service
without implementing the more complex DPD protocol by keeping the DPV/DPD
interface internal to the system.

Is this too radical a departure from the previously articulated
requirements?

-- Skip

-----Original Message-----
From: Stephen Kent [mailto:[email-masked]]
Sent: Friday, January 12, 2001 12:27 PM
To: Slone, Skip
Cc: PKIX-List
Subject: RE: DPD & DPV requirements

Skip,

Thanks for taking the time to supply an example scenario. Your text
was very readable and quite clear.

>Putting the two sides of this equation together and looking at a typical
B2B
>scenario, we find the following case in which a relying party in Company A
>needs to validate a Company B path: the RP delegates its request to the DPV
>server residing on Company A's boundary. Company A's DPV server (since it
>doesn't have direct access to Company B's network) will delegate to the DPV
>server residing on Company B's boundary. Company B's DPV server will then
>access the internal resources in Company B's network, perform all the
>necessary discovery and validation work and return the result back
upstream.

I agree that the RP in Company A would call the DPV server that
Company A makes available to it and that that DPV server needs to
contact a server at Company B to get the necessary info. However, I
don't agree that the DPV server at Company A would accept a DPV
response from Company B, at least not blindly. Company B really needs
to evaluate the response. It could do that by accessing a DPD server
at Company B, or it could access a DPV server, but insist on getting
back the data that supports the validation assertion by the Company B
DPV server. If so, then what is returned by the DPV server will
contain the same path and revocation status data as an equivalently
formulated DPD response. So, I can see a case for offering only a DPV
service to the outside world, but I might well choose to not accept
just a yes/no response, if I were running a DPV server at another
company. If that's the case, and if have to validate the returned
data, then I could repackage it for return to my client (the RP), and
the fact that there was a call to another DPV server is invisible to
the client.

>As for the need to constrain the number of relays (on further reflection,
>"relay" seems like a better fit than "recursion"), consider the following.
>In the scenario above, there is a need to relay the delegation exactly one
>time. Thus, the RP inside A needs to allow a one-hop relay, but it may wish
>to preclude paths longer than that, in order to prevent getting to Company
B
>by first going through Companies X, Y, and Z. On the other hand, it may be
>appropriate for a third party to be involved in the relay (industry
>consortium, bridge, TTP, etc.), which would make it appropriate to be able
>to specify two hops (or some other number as the situation warrants).

In your example, with clients inside of a corporate environment, it
seems more likely that it would be a corporate policy that addresses
the hop count issue, rather than a client parameter. also, I have to
admit that I have a very strong bias here: transitive trust is
generally a bad idea. It's OK for a client to rely on a DPV server in
a corporate environment, and under some circumstances in a public
environment. However, I'm very concerned about encouraging these
servers to rely on other DPV servers, vs. DPD servers. And I'm
especially concerned about the complexity that arises if such
reliance becomes visible to clients, e.g, in terms of nested response
syntax. I don't think the TTP or bridge CA example is a good analogy
here, since any DPV server can do it's own validation on data
returned by a DPD server for any other domain.

Steve

Received: from exchange.cylink.com (exchange.cylink.com [192.43.161.25]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA23624 for ; Mon, 15 Jan 2001 12:36:29 -0800 (PST)
Received: by exchange.cylink.com with Internet Mail Service (5.5.2650.21) id ; Mon, 15 Jan 2001 12:33:46 -0800
Message-ID: <[email-masked]>
From: "Covey, Carlin"
To: PKIX-List
Subject: RE: DPD & DPV requirements - to nonce or not to nonce?
Date: Mon, 15 Jan 2001 12:33:46 -0800
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C07F32.75A40630"

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_01C07F32.75A40630
Content-Type: text/plain;
charset="iso-8859-1"

Thanks Peter, that was very informative. I guess keeping track of used
nonces, while not fun,
can be fairly time-efficient.

If you are keeping track of nonces as supporting evidence for
non-repudiation, don't you have
to keep the requests around, as well as the responses? But these requests
would not be very
convincing evidence unless they were signed by the client. Would the server
refuse to reply to
unsigned requests? Would the server refuse to respond to a request that
included a reused
nonce?

If you had a choice, would nonces be your first choice for a replay
countermeasure?

Regards,
Carlin

_______________________
- Carlin Covey
Cylink Corp.

-----Original Message-----
From: Peter Williams [mailto:[email-masked]]
Sent: Monday, January 15, 2001 12:31 PM
To: Covey, Carlin
Cc: PKIX-List
Subject: RE: DPD & DPV requirements - to nonce or not to nonce?

X.511 enables signed requests and signed responses to be linked by nonce
values. X.500 however had no
clear statements about nonce handling. I implemented an online responder for
certificates status
values using X.511 signed request/response pairs several years ago. I
maintained at the server a
hash-tree of nonce values provided to, and generated by the server, and
checked that a nonce value
was not repeated in a certain period. As X.500 operations are rather more
complex than simple OCSP, requiring support for multicasting, result
reconstruction/resigning and n-level chaining of operations
between master and slave servers, the issues of nonces seemed important
beyond merely the issue of linking one request to the initiating servers
response to thwart replay. The party who generates
the information element in the response may not be the party that provides
it (once resigned) to the
relying party. The nonce value says nothing about the timeliness of the
information, only the issuing
time of the signed response PDU; the source of response data, under X.500
reconstruction rules
may be cached data held by the server as a slave or replicate of a master
DSA responsible
for the status-data DIB. (*)

Today, for NR reasons, Id use a hash-tree (just like CRTs!) that is
persistent and stored as part
of the NR records showing the proper conduct of the server when acting for
the relying party. The thing
that has changed in 10 years is the realization that the server is really
the agent of the
relying party: its not a frontend of the CA. The server now needs to ensure
that it
can show it fulfilled its obligations under the relying party
agreement/policy.

(*) Careful configuration of multi-mastering replication, to assure the
relying-party that cache
attacks are not in place, is used to address this in modern X.500 versions,
btw)

-----Original Message-----
From: Stephen Kent [mailto:[email-masked]]
Sent: Thursday, January 04, 2001 6:37 AM
To: Covey, Carlin
Cc: PKIX-List
Subject: RE: DPD & DPV requirements - to nonce or not to nonce?

At 5:21 PM -0800 1/3/01, Covey, Carlin wrote:

To thwart replay attacks, both OCSP and SCVP have provisions for the
optional inclusion of nonces in requests and responses .

The premise of this is that the requester picks a nonce that it hasn't used
before, and includes it in its request.

The server is obligated to return this same nonce, ensuring that the
response was prepared after the request.

I don't see a provision in the proposed DPD and DPV requirements for the
optional inclusion of a nonce.

Is this an intentional omission, or inadvertent? Do we want/need nonces in
the new DPD/DPV standards?

I didn't want to mandate the use of nonces per se. However, the security
requirement that nonces address is covered in 1.8:

1.8 Either the request/response protocol itself, or a specified lower
layer protocol to be employed for requests and responses, there must be a
provision for data origin authentication and connectionless integrity for
requests and responses, and responses must be matched to requests. Request
authentication & integrity is needed to support access control to the
server, a requirement for public servers. Responses must be authenticated
and integrity-protected to ensure that they are from the indicated server,
and matched to the request in question. Additional security services may be
offered optionally.

I won't venture an opinion, but I will make some observations. Since nonces
are permitted in OCSP v1 responses,

nonces may appear in OCSP responses embedded in the requests sent to the DPD
or DPV server.

"1.2 A client request can contain one or more revocation data items,

to assist the server in path validation." - from proposed DPD & DPV
requirements

The nonces in the OCSP responses will be of no use to the server, because
the server did not generate the OCSP

requests with the matching nonces.

Likewise, the responses that a DPD server returns may contain OCSP responses
with nonces. (To thwart replay attacks,

the DPD server may have put nonces in the requests that it made to OCSP
servers.)

"2.2 A server must be able to return one or more sets of certification paths
and associated

revocation data as a result of path discovery/validation. Each set shall
consist of an ordered

list of certificates and associated CRLs and/or OCSP responses." - from
proposed DPD &

DPV requirements

These nonces will be useful to the DPD server, but not to the DPD client,
since the client did not generate the matching

OCSP requests. UNLESS ....... the DPD server chooses the same nonce that it
received from the DPD client. (Contemplating

this makes me queasy.) Recall that the protection against replay attacks was
based upon the requester not using the same

nonce it had used before. This can be done cheaply by generating the nonces
as a sequence, or as a sizable random number.

But if the DPD server doesn't generate the nonce, then it must keep a record
of all the nonces that it has seen (well, perhaps

only those it has seen within some global time-ambiguity interval). Failing
to keep track of past nonces renders the DPD

server vulnerable to conspiracies between the DPD client and another agent
replaying older OCSP responses to the DPD server.

But why would a DPD client conspire against itself? It might undertake such
a conspiracy in order to fool the DPD server

into attesting to incorrect (or at least out-of-date) certificate status,
with a view toward later presenting this incorrect

attestation to someone else. (If the DPD response is timestamped, then all
the response data, including the incorrect revocation

data, will have been signed as part of the timestamp.)

An alternative would be for the DPD server to generate its own nonces, and
then simply attest to the DPD client that all the OCSP

responses returned in the DPD response are fresh. But this calls for some
amount of trust in the DPD server, and part of the

premise for DPD (as opposed to DPV) was that the client might not trust the
server.

Interesting point re a DPD server returning OCSPv1 responses. i didn't think
about that in detail! I'll have to think more about that case.

Steve

------_=_NextPart_001_01C07F32.75A40630
Content-Type: text/html;
charset="iso-8859-1"

Thanks
Peter, that was very informative.  I guess keeping track of used nonces,
while not fun,

can be fairly
time-efficient.

If you
are keeping track of nonces as supporting evidence for non-repudiation, don't
you have

to
keep the requests around, as well as the responses?  But these requests
would not be very

convincing evidence unless they were signed by the
client.  Would the server refuse to reply to

unsigned requests?  Would the server refuse to
respond to a request that included a reused

nonce?

If you
had a choice, would nonces be your first choice for a replay
countermeasure?

Regards,

Carlin

_______________________

-
Carlin Covey

Cylink Corp.

-----Original Message-----
From: Peter Williams
[mailto:[email-masked]]
Sent: Monday, January 15, 2001 12:31
PM
To: Covey, Carlin
Cc: PKIX-List
Subject: RE:
DPD & DPV requirements - to nonce or not to nonce?

X.511 enables signed requests and signed responses to
be linked by nonce values. X.500 however had no

clear statements about nonce handling. I implemented
an online responder for certificates status

values using X.511 signed request/response
pairs several years ago. I maintained at the server a

hash-tree of nonce values provided to, and
generated by the server, and checked that a nonce value

was
not repeated in a certain period. As X.500 operations are rather
more complex than simple OCSP, requiring support for
multicasting, result reconstruction/resigning and n-level chaining of
operations

between master and slave servers, the issues
of nonces seemed important beyond merely the issue of
linking one request to the initiating servers response to
thwart replay. The party who generates

the
information element in the response may not be the party that provides it
(once resigned) to the

relying party. The nonce value says nothing about the
timeliness of the information, only the issuing

time
of the signed response PDU; the source of response data, under X.500
reconstruction rules

may
be cached data held by the server as a slave or replicate of a master DSA
responsible

for
the status-data DIB. (*)

Today, for NR reasons, Id use a hash-tree (just like
CRTs!) that is persistent and stored as part

of
the NR records showing the proper conduct of the server when
acting for the relying party. The thing

that
has changed in 10 years is the realization that the server is really the agent
of the

relying party: its not a frontend of the CA. The
server now needs to ensure that it

can
show it fulfilled its obligations under the relying party
agreement/policy.

(*)
Careful configuration of multi-mastering replication, to assure
the relying-party that cache

attacks are not in
place, is used to address this in modern X.500
versions, btw)

-----Original Message-----
From: Stephen Kent
[mailto:[email-masked]]
Sent: Thursday, January 04, 2001 6:37
AM
To: Covey, Carlin
Cc: PKIX-List
Subject:
RE: DPD & DPV requirements - to nonce or not to
nonce?

At 5:21 PM -0800 1/3/01, Covey, Carlin wrote:

To thwart replay attacks, both OCSP and
SCVP have provisions for the optional inclusion of nonces in requests and
responses .

The premise of this is that the requester
picks a nonce that it hasn't used before, and includes it in its request.

The server is obligated to return this
same nonce, ensuring that the response was prepared after the request.

I don't see a provision in the proposed
DPD and DPV requirements for the optional inclusion of a nonce.

Is this an intentional omission, or
inadvertent? Do we want/need nonces in the new DPD/DPV standards?

I didn't want to mandate the use of nonces per se. However, the security
requirement that nonces address is covered in 1.8:

1.8     Either the
request/response protocol itself, or a specified lower layer protocol to be
employed for requests and responses, there must be a provision for data
origin authentication and connectionless integrity for requests and
responses, and responses must be matched to requests. Request
authentication & integrity is needed to support access control to the
server, a requirement for public servers. Responses must be authenticated
and integrity-protected to ensure that they are from the indicated server,
and matched to the request in question. Additional security services may be
offered optionally.

I won't venture an opinion, but I will
make some observations. Since nonces are permitted in OCSP v1 responses,

nonces may appear in OCSP responses
embedded in the requests sent to the DPD or DPV server.

"1.2 A client request can contain one or more revocation
data items,

to assist the server in path validation." - from
proposed DPD & DPV requirements

The nonces in the OCSP responses will be
of no use to the server, because the server did not generate the OCSP

requests with the matching nonces.

Likewise, the responses that a DPD server
returns may contain OCSP responses with nonces. (To thwart replay attacks,

the DPD server may have put nonces in the
requests that it made to OCSP servers.)

"2.2 A server must be able to return one or more sets of
certification paths and associated

revocation data as a result of path
discovery/validation. Each set shall consist of an ordered

list of certificates and associated CRLs and/or OCSP
responses." - from proposed DPD &

DPV requirements

These nonces will be useful to the DPD
server, but not to the DPD client, since the client did not generate the
matching

OCSP requests. UNLESS ....... the DPD
server chooses the same nonce that it received from the DPD client.
(Contemplating

this makes me queasy.) Recall that the
protection against replay attacks was based upon the requester not using the
same

nonce it had used before. This can be done
cheaply by generating the nonces as a sequence, or as a sizable random
number.

But if the DPD server doesn't generate the
nonce, then it must keep a record of all the nonces that it has seen (well,
perhaps

only those it has seen within some global
time-ambiguity interval). Failing to keep track of past nonces renders the
DPD

server vulnerable to conspiracies between
the DPD client and another agent replaying older OCSP responses to the DPD
server.

But why would a DPD client conspire
against itself? It might undertake such a conspiracy in order to fool the
DPD server

into attesting to incorrect (or at least
out-of-date) certificate status, with a view toward later presenting this
incorrect

attestation to someone else. (If the DPD
response is timestamped, then all the response data, including the incorrect
revocation

data, will have been signed as part of the
timestamp.)

An alternative would be for the DPD server
to generate its own nonces, and then simply attest to the DPD client that
all the OCSP

responses returned in the DPD response are
fresh. But this calls for some amount of trust in the DPD server, and part
of the

premise for DPD (as opposed to DPV) was
that the client might not trust the server.

Interesting point re a DPD server returning OCSPv1 responses. i didn't
think about that in detail! I'll have to think more about that case.

Steve

------_=_NextPart_001_01C07F32.75A40630--

Received: from sottmxs02.entrust.com (gatekeeper.entrust.com [204.101.128.170]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA22346 for ; Mon, 15 Jan 2001 12:11:50 -0800 (PST)
Received: by sottmxs02.entrust.com with Internet Mail Service (5.5.2650.21) id ; Mon, 15 Jan 2001 15:15:30 -0500
Message-ID:
From: Sharon Boeyen
To: "'Slone, Skip'" , "'Stephen Kent'"
Cc: [email-masked]
Subject: RE: Basic Cert-2-Directory mapping question
Date: Mon, 15 Jan 2001 15:13:27 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C07F2F.9F4D5610"

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_01C07F2F.9F4D5610
Content-Type: text/plain

Hi Skip,

What I meant by the tools was that the SRV records are populated by CAs,
some of which use the geopolitical DN style and others that use the dc
style. Regardless of what style of DN they use, all queries for SRV records
are based on a domain name. If that domain name is known, or can be derived
(e.g. by the email application from the email address), then the SRV records
can direct you to the right PKI repository.

The need for a screwdriver is when you don't know the domain name and can't
derive it, but need to identify and locate the PKI repository for a
geopolitically structured DN that you do know.

Cheers,
Sharon

-----Original Message-----
From: Slone, Skip [mailto:[email-masked]]
Sent: Monday, January 15, 2001 12:54 PM
To: 'Sharon Boeyen'; 'Stephen Kent'
Cc: [email-masked]
Subject: RE: Basic Cert-2-Directory mapping question

[Sharon] It seems that we are basically in agreement that both the 'civil
attributes' type of DNs and the domain
component attributes for DNS structured DNs are currently being used and
will likely continue to be used.

[Skip] Agreed.

[Sharon] We also seem to be in agreement that both are hierarchical name
structures.

[Skip] Agreed.

[Sharon] I think it is also fairly safe to say that the extensions we
already have in certificates, combined with the PKI repository locator
service seem adequate for identifying and locating the PKI repository of
interest in most cases for both types of DN structures.

[Skip] I'm not sure I understand what you mean by "the [tools] we already
have ... seem adequate ... for both types of DN structures." Maybe I'm
overlooking the obvious, but I don't see support structures for
civil-attribute-based DNs.

[Sharon] The single exception to this is, as pointed out by Skip, the one
where all the following conditions are met: I guess typically this
would be an environment where there is more than one internediary
certificate in a path because if two domains directly cross-certify with
one-another they would provide repository access information to each other,
otherwise the cross-certification makes no sense.

[Skip] I see this need most acutely in those instances that occur near the
boundaries of a business relationship. That is, when a relationship is in
the early stages of being formed, or if some break has occured in a business
relationship (due to mergers, acquisitions, etc.), there is a sharp drop in
the likelihood that the requisite knowledge is already in place. Once a
relationship has been established, the whole repository locator issue
becomes a moot point. Until then, it can be a big deal. The "problem certs"
are not the ones that are commercially issued; the problem arises when
certificates are issued by a private CA that is certified (directly or
indirectly) by a commercial CA that I happen to trust.

[Sharon] While I don't disagree with Skip's assertion that the mapping of
civil DNs to DNS names might be useful in the general directory sense,

[Skip] In the absence of a well-connected DIT (complete with globally
accessible first-level DSAs, a functional c=US, etc.) distributed X.500/LDAP
name resolution has been, and will continue to be an unmitigated failure.
By leveraging an existing, global, ubiquitous infrastructure, the mapping
I've suggested is intended to solve a big portion of this name resolution
problem.

[Sharon] I agree with Steve that this directory issue is not one that PKIX
needs to tackle in general.

[Skip] While I completely agree that the charter of PKIX is NOT to solve
general directory issues, it seems to me that it is within the charter of
PKIX to consider problems that users report with PKIX as currently defined,
and to give due consideration to whether any proposed solution does indeed
solve the reported problem. If the solution is then deemed to be too
general, the work can, of course, be moved elsewhere.

[Sharon] However, if the scenario above is one that PKIX needs to find a
solution to (as opposed to determining that its not relevant since Internet
applications will generally have domain names and can therefore use PKI
repository locator service regardless of the DN structures in the certs or
the directory entries), then we have some work to do.

[Skip] Agreed. I can offer some cycles to do some of this work.

[Sharon] Otherwise, we already have all the tools we need to satisfy the PKI
information retrieval problem.

[Skip] I'm still looking for something other than a hammer :-)

-- Skip

-----Original Message-----
From: Sharon Boeyen [mailto:[email-masked]]
Sent: Friday, January 12, 2001 9:19 AM
To: 'Stephen Kent'; Slone, Skip
Cc: [email-masked]
Subject: RE: Basic Cert-2-Directory mapping question

OK now we're getting to the 'focal' point I was hoping we would.

It seems that we are basically in agreement that both the 'civil attributes'
type of DNs and the domain
component attributes for DNS structured DNs are currently being used and
will likely continue to be used. We also seem to be in agreement that both
are hierarchical name structures. I think it is also fairly safe to say that
the extensions we already have in certificates, combined with the PKI
repository locator service seem adequate for identifying and locating the
PKI repository of interest in most cases for both types of DN structures.
The single exception to this is, as pointed out by Skip, the one where all
the following conditions are met: A relying party needs to obtain an
end-entity certificate for which it does not know the domain name and it
cannot be easily derived from information the relying party does have (and
therefore the PKI repository locator service won't provide the required
information) and the relying party's local environment does not have a
priori knowledge of the remote domain's repository. I guess typically this
would be an environment where there is more than one internediary
certificate in a path because if two domains directly cross-certify with
one-another they would provide repository access information to each other,
otherwise the cross-certification makes no sense.

While I don't disagree with Skip's assertion that the mapping of civil DNs
to DNS names might be useful in the general directory sense, I agree with
Steve that this directory issue is not one that PKIX needs to tackle in
general. However, if the scenario above is one that PKIX needs to find a
solution to (as opposed to determining that its not relevant since Internet
applications will generally have domain names and can therefore use PKI
repository locator service regardless of the DN structures in the certs or
the directory entries), then we have some work to do. Otherwise, we already
have all the tools we need to satisfy the PKI information retrieval problem.

Sharon

-----Original Message-----
From: Stephen Kent [mailto:[email-masked]]
Sent: Thursday, January 11, 2001 4:56 PM
To: Slone, Skip
Cc: [email-masked]
Subject: RE: Basic Cert-2-Directory mapping question

Skip,

I would just like to add that, in addition to X.521 and some LDAP specs, the
ability to recognize civil naming attributes in the issuer and subject
fields of an X.509v3 cert is mandated in RFC 2459 (ref section 4.1.2.4) and
in son-of-2459.

Ironically, the requirement for support for Issuer names (DNs) vs. allowing
an Issuer alname in lieu of a DN, arose because the S/MIME WG was relying on
the presence of an Issuer DN in their design, and I believe the motivation
for it (Russ can confirm or correct this notion) was to facilitate directory
lookup for certs in S/MIME!

Steve

------_=_NextPart_001_01C07F2F.9F4D5610
Content-Type: text/html

Hi
Skip,

What I
meant by the tools was that the SRV records are populated by CAs, some of which
use the geopolitical DN style and others that use the dc style. Regardless of
what style of DN they use, all queries for SRV records are based on a domain
name. If that domain name is known, or can be derived (e.g. by the email
application from the email address), then the SRV records can direct you to the
right PKI repository.

The
need for a screwdriver is when you don't know the domain name and can't derive
it, but need to identify and locate the PKI repository for a geopolitically
structured DN that you do know.

Cheers,

Sharon

-----Original Message-----
From: Slone, Skip
[mailto:[email-masked]]
Sent: Monday, January 15, 2001 12:54
PM
To: 'Sharon Boeyen'; 'Stephen Kent'
Cc:
[email-masked]
Subject: RE: Basic Cert-2-Directory mapping
question

[Sharon]  It seems that we are basically in
agreement that both the 'civil attributes' type of DNs and the domain

component
attributes for DNS structured DNs are currently being used and will likely
continue to be used.

[Skip]  Agreed.

[Sharon]  We also
seem to be in agreement that both are hierarchical name structures.

[Skip]  Agreed.

[Sharon]  I think it is also fairly safe to say
that the extensions we already have in certificates, combined with the PKI
repository locator service seem adequate for identifying and locating the PKI
repository of interest in most cases for both types of DN structures.

[Skip]  I'm not sure I
understand what you mean by
"the [tools] we already have ... seem adequate ... for both types of DN
structures."  Maybe I'm
overlooking the obvious, but I don't see support structures
for civil-attribute-based DNs.

[Sharon]
The single exception to this is, as pointed out by Skip, the one
where all the following conditions are met:  <snip> I guess typically this would be
an environment where there is more than one internediary certificate in a path
because if two domains directly cross-certify with one-another they would
provide repository access information to each other, otherwise the
cross-certification makes no sense.

[Skip] I see this need most acutely in those
instances that occur near the boundaries of a business relationship. That is,
when a relationship is in the early stages of being formed, or if some break
has occured in a business relationship (due to mergers, acquisitions, etc.),
there is a sharp drop in the likelihood that the requisite knowledge is
already in place.  Once a relationship has been established, the
whole repository locator issue becomes a moot point. Until then, it can
be a big deal.  The "problem certs" are not the ones that are
commercially issued; the problem arises when certificates are issued
by a private CA that is certified (directly or indirectly) by a commercial CA
that I happen to trust.

[Sharon] While I don't
disagree with Skip's assertion that the mapping of civil DNs to DNS names
might be useful in the general directory sense,

[Skip] In the absence of a well-connected DIT
(complete with globally accessible first-level DSAs, a functional c=US, etc.)
distributed X.500/LDAP name resolution has been, and will continue to be
an unmitigated failure.  By leveraging an existing, global,
ubiquitous infrastructure, the mapping I've suggested is intended to solve a
big portion of this name resolution problem.

[Sharon]  I agree with Steve that this
directory issue is not one that PKIX needs to tackle in general.

[Skip] While I completely agree that the charter of
PKIX is NOT to solve general directory issues, it seems to me that it is
within the charter of PKIX to consider problems that users report with PKIX as
currently defined, and to give due consideration to whether any proposed
solution does indeed solve the reported problem.  If the solution is then
deemed to be too general, the work can, of course, be moved
elsewhere.

[Sharon]
However, if the scenario above is one that PKIX needs to find a
solution to (as opposed to determining that its not relevant since Internet
applications will generally have domain names and can therefore use PKI
repository locator service regardless of the DN structures in the certs or the
directory entries), then we have some work to do.

[Skip] Agreed.  I can offer some cycles to do
some of this work.

[Sharon] Otherwise, we already have all the
tools we need to satisfy the PKI information retrieval
problem.

[Skip] I'm still looking for something other
than a hammer :-)

-- Skip

-----Original Message-----
From: Sharon Boeyen
[mailto:[email-masked]]
Sent: Friday, January 12, 2001
9:19 AM
To: 'Stephen Kent'; Slone, Skip
Cc:
[email-masked]
Subject: RE: Basic Cert-2-Directory mapping
question

OK
now we're getting to the 'focal' point I was hoping we
would.

It
seems that we are basically in agreement that both the 'civil attributes'
type of DNs and the domain

component attributes for DNS structured DNs are currently
being used and will likely continue to be used. We also seem to be in
agreement that both are hierarchical name structures. I think it is also
fairly safe to say that the extensions we already have in certificates,
combined with the PKI repository locator service seem adequate for
identifying and locating the PKI repository of interest in most cases for
both types of DN structures. The single exception to this is, as
pointed out by Skip, the one where all the following conditions are
met: A relying party needs to obtain an end-entity certificate for which it
does not know the domain name and it cannot be easily derived from
information the relying party does have (and therefore the PKI
repository locator service won't provide the required information) and the
relying party's local environment does not have a priori knowledge of the
remote domain's repository. I guess typically this would be an environment
where there is more than one internediary certificate in a path because if
two domains directly cross-certify with one-another they would provide
repository access information to each other, otherwise the
cross-certification makes no sense.

While I don't disagree with Skip's assertion that
the mapping of civil DNs to DNS names might be useful in the general
directory sense, I agree with Steve that this directory issue is not one
that PKIX needs to tackle in general. However, if the scenario above is one
that PKIX needs to find a solution to (as opposed to determining that its
not relevant since Internet applications will generally have domain names
and can therefore use PKI repository locator service regardless of the DN
structures in the certs or the directory entries), then we have some work to
do. Otherwise, we already have all the tools we need to satisfy the PKI
information retrieval problem.

Sharon

-----Original
Message-----
From: Stephen Kent
[mailto:[email-masked]]
Sent: Thursday, January 11, 2001 4:56
PM
To: Slone, Skip
Cc:
[email-masked]
Subject: RE: Basic Cert-2-Directory mapping
question

Skip,

I would just like to add that, in
addition to X.521 and some LDAP specs, the ability to recognize civil
naming attributes in the issuer and subject fields of an X.509v3 cert is
mandated in RFC 2459 (ref section 4.1.2.4) and in son-of-2459.

Ironically, the requirement for support for Issuer names (DNs) vs.
allowing an Issuer alname in lieu of a DN, arose because the S/MIME WG was
relying on the presence of an Issuer DN in their design, and I believe the
motivation for it (Russ can confirm or correct this notion) was to
facilitate directory lookup for certs in S/MIME!

<snip>

Steve

------_=_NextPart_001_01C07F2F.9F4D5610--

Received: from ext-mail.valicert.com (ns1.valicert.com [63.65.221.10]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA19492 for ; Mon, 15 Jan 2001 11:29:31 -0800 (PST)
Received: from CONVERSION-DAEMON by ext-mail.valicert.com (PMDF V5.2-33 #46613) id <[email-masked]> for [email-masked]; Mon, 15 Jan 2001 11:34:59 -0800 (PST)
Received: from polaris.valicert.com ([192.168.2.34]) by ext-mail.valicert.com (PMDF V5.2-33 #46613) with ESMTP id <[email-masked]>; Mon, 15 Jan 2001 11:34:58 -0800 (PST)
Received: by exchange.valicert.com with Internet Mail Service (5.5.2650.21) id ; Mon, 15 Jan 2001 11:30:46 -0800
Content-return: allowed
Date: Mon, 15 Jan 2001 11:30:45 -0800
From: Peter Williams
Subject: RE: DPD & DPV requirements - to nonce or not to nonce?
To: "Covey, Carlin"
Cc: PKIX-List
Message-id: <[email-masked]>
MIME-version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-type: multipart/alternative; boundary="Boundary_(ID_1hnHg1QAzU4m52F9KlyuTw)"

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

--Boundary_(ID_1hnHg1QAzU4m52F9KlyuTw)
Content-type: text/plain; charset="iso-8859-1"

X.511 enables signed requests and signed responses to be linked by nonce
values. X.500 however had no
clear statements about nonce handling. I implemented an online responder for
certificates status
values using X.511 signed request/response pairs several years ago. I
maintained at the server a
hash-tree of nonce values provided to, and generated by the server, and
checked that a nonce value
was not repeated in a certain period. As X.500 operations are rather more
complex than simple OCSP, requiring support for multicasting, result
reconstruction/resigning and n-level chaining of operations
between master and slave servers, the issues of nonces seemed important
beyond merely the issue of linking one request to the initiating servers
response to thwart replay. The party who generates
the information element in the response may not be the party that provides
it (once resigned) to the
relying party. The nonce value says nothing about the timeliness of the
information, only the issuing
time of the signed response PDU; the source of response data, under X.500
reconstruction rules
may be cached data held by the server as a slave or replicate of a master
DSA responsible
for the status-data DIB. (*)

Today, for NR reasons, Id use a hash-tree (just like CRTs!) that is
persistent and stored as part
of the NR records showing the proper conduct of the server when acting for
the relying party. The thing
that has changed in 10 years is the realization that the server is really
the agent of the
relying party: its not a frontend of the CA. The server now needs to ensure
that it
can show it fulfilled its obligations under the relying party
agreement/policy.

(*) Careful configuration of multi-mastering replication, to assure the
relying-party that cache
attacks are not in place, is used to address this in modern X.500 versions,
btw)

-----Original Message-----
From: Stephen Kent [mailto:[email-masked]]
Sent: Thursday, January 04, 2001 6:37 AM
To: Covey, Carlin
Cc: PKIX-List
Subject: RE: DPD & DPV requirements - to nonce or not to nonce?

At 5:21 PM -0800 1/3/01, Covey, Carlin wrote:

To thwart replay attacks, both OCSP and SCVP have provisions for the
optional inclusion of nonces in requests and responses .

The premise of this is that the requester picks a nonce that it hasn't used
before, and includes it in its request.

The server is obligated to return this same nonce, ensuring that the
response was prepared after the request.

I don't see a provision in the proposed DPD and DPV requirements for the
optional inclusion of a nonce.

Is this an intentional omission, or inadvertent? Do we want/need nonces in
the new DPD/DPV standards?

I didn't want to mandate the use of nonces per se. However, the security
requirement that nonces address is covered in 1.8:

1.8 Either the request/response protocol itself, or a specified lower
layer protocol to be employed for requests and responses, there must be a
provision for data origin authentication and connectionless integrity for
requests and responses, and responses must be matched to requests. Request
authentication & integrity is needed to support access control to the
server, a requirement for public servers. Responses must be authenticated
and integrity-protected to ensure that they are from the indicated server,
and matched to the request in question. Additional security services may be
offered optionally.

I won't venture an opinion, but I will make some observations. Since nonces
are permitted in OCSP v1 responses,

nonces may appear in OCSP responses embedded in the requests sent to the DPD
or DPV server.

"1.2 A client request can contain one or more revocation data items,

to assist the server in path validation." - from proposed DPD & DPV
requirements

The nonces in the OCSP responses will be of no use to the server, because
the server did not generate the OCSP

requests with the matching nonces.

Likewise, the responses that a DPD server returns may contain OCSP responses
with nonces. (To thwart replay attacks,

the DPD server may have put nonces in the requests that it made to OCSP
servers.)

"2.2 A server must be able to return one or more sets of certification paths
and associated

revocation data as a result of path discovery/validation. Each set shall
consist of an ordered

list of certificates and associated CRLs and/or OCSP responses." - from
proposed DPD &

DPV requirements

These nonces will be useful to the DPD server, but not to the DPD client,
since the client did not generate the matching

OCSP requests. UNLESS ....... the DPD server chooses the same nonce that it
received from the DPD client. (Contemplating

this makes me queasy.) Recall that the protection against replay attacks was
based upon the requester not using the same

nonce it had used before. This can be done cheaply by generating the nonces
as a sequence, or as a sizable random number.

But if the DPD server doesn't generate the nonce, then it must keep a record
of all the nonces that it has seen (well, perhaps

only those it has seen within some global time-ambiguity interval). Failing
to keep track of past nonces renders the DPD

server vulnerable to conspiracies between the DPD client and another agent
replaying older OCSP responses to the DPD server.

But why would a DPD client conspire against itself? It might undertake such
a conspiracy in order to fool the DPD server

into attesting to incorrect (or at least out-of-date) certificate status,
with a view toward later presenting this incorrect

attestation to someone else. (If the DPD response is timestamped, then all
the response data, including the incorrect revocation

data, will have been signed as part of the timestamp.)

An alternative would be for the DPD server to generate its own nonces, and
then simply attest to the DPD client that all the OCSP

responses returned in the DPD response are fresh. But this calls for some
amount of trust in the DPD server, and part of the

premise for DPD (as opposed to DPV) was that the client might not trust the
server.

Interesting point re a DPD server returning OCSPv1 responses. i didn't think
about that in detail! I'll have to think more about that case.

Steve

--Boundary_(ID_1hnHg1QAzU4m52F9KlyuTw)
Content-type: text/html; charset="iso-8859-1"

X.511
enables signed requests and signed responses to be linked by nonce values. X.500
however had no

clear
statements about nonce handling. I implemented an online responder for
certificates status

values
using X.511 signed request/response pairs several years ago. I maintained
at the server a

hash-tree of nonce values provided to,
and generated by the server, and checked that a nonce value

was
not repeated in a certain period. As X.500 operations are rather
more complex than simple OCSP, requiring support for multicasting, result
reconstruction/resigning and n-level chaining of operations

between master and slave servers, the issues
of nonces seemed important beyond merely the issue of
linking one request to the initiating servers response to
thwart replay. The party who generates

the
information element in the response may not be the party that provides it (once
resigned) to the

relying party. The nonce value says nothing about the
timeliness of the information, only the issuing

time
of the signed response PDU; the source of response data, under X.500
reconstruction rules

may be
cached data held by the server as a slave or replicate of a master DSA
responsible

for
the status-data DIB. (*)

Today,
for NR reasons, Id use a hash-tree (just like CRTs!) that is persistent and
stored as part

of the
NR records showing the proper conduct of the server when
acting for the relying party. The thing

that
has changed in 10 years is the realization that the server is really the agent
of the

relying party: its not a frontend of the CA. The server
now needs to ensure that it

can
show it fulfilled its obligations under the relying party
agreement/policy.

(*)
Careful configuration of multi-mastering replication, to assure
the relying-party that cache

attacks are not in
place, is used to address this in modern X.500
versions, btw)

-----Original Message-----
From: Stephen Kent
[mailto:[email-masked]]
Sent: Thursday, January 04, 2001 6:37
AM
To: Covey, Carlin
Cc: PKIX-List
Subject: RE:
DPD & DPV requirements - to nonce or not to nonce?

At 5:21 PM -0800 1/3/01, Covey, Carlin wrote:

To thwart replay attacks, both OCSP and SCVP
have provisions for the optional inclusion of nonces in requests and responses
.

The premise of this is that the requester
picks a nonce that it hasn't used before, and includes it in its request.

The server is obligated to return this same
nonce, ensuring that the response was prepared after the request.

I don't see a provision in the proposed DPD
and DPV requirements for the optional inclusion of a nonce.

Is this an intentional omission, or
inadvertent? Do we want/need nonces in the new DPD/DPV standards?

I didn't want to mandate the use of nonces per se. However, the security
requirement that nonces address is covered in 1.8:

1.8     Either the
request/response protocol itself, or a specified lower layer protocol to be
employed for requests and responses, there must be a provision for data origin
authentication and connectionless integrity for requests and responses, and
responses must be matched to requests. Request authentication &
integrity is needed to support access control to the server, a requirement for
public servers. Responses must be authenticated and integrity-protected to
ensure that they are from the indicated server, and matched to the request in
question. Additional security services may be offered optionally.

I won't venture an opinion, but I will make
some observations. Since nonces are permitted in OCSP v1 responses,

nonces may appear in OCSP responses embedded
in the requests sent to the DPD or DPV server.

"1.2 A client request can contain one or more revocation
data items,

to assist the server in path validation." - from proposed
DPD & DPV requirements

The nonces in the OCSP responses will be of
no use to the server, because the server did not generate the OCSP

requests with the matching nonces.

Likewise, the responses that a DPD server
returns may contain OCSP responses with nonces. (To thwart replay attacks,

the DPD server may have put nonces in the
requests that it made to OCSP servers.)

"2.2 A server must be able to return one or more sets of
certification paths and associated

revocation data as a result of path discovery/validation.
Each set shall consist of an ordered

list of certificates and associated CRLs and/or OCSP
responses." - from proposed DPD &

DPV requirements

These nonces will be useful to the DPD
server, but not to the DPD client, since the client did not generate the
matching

OCSP requests. UNLESS ....... the DPD server
chooses the same nonce that it received from the DPD client. (Contemplating

this makes me queasy.) Recall that the
protection against replay attacks was based upon the requester not using the
same

nonce it had used before. This can be done
cheaply by generating the nonces as a sequence, or as a sizable random number.

But if the DPD server doesn't generate the
nonce, then it must keep a record of all the nonces that it has seen (well,
perhaps

only those it has seen within some global
time-ambiguity interval). Failing to keep track of past nonces renders the DPD

server vulnerable to conspiracies between
the DPD client and another agent replaying older OCSP responses to the DPD
server.

But why would a DPD client conspire against
itself? It might undertake such a conspiracy in order to fool the DPD server

into attesting to incorrect (or at least
out-of-date) certificate status, with a view toward later presenting this
incorrect

attestation to someone else. (If the DPD
response is timestamped, then all the response data, including the incorrect
revocation

data, will have been signed as part of the
timestamp.)

An alternative would be for the DPD server
to generate its own nonces, and then simply attest to the DPD client that all
the OCSP

responses returned in the DPD response are
fresh. But this calls for some amount of trust in the DPD server, and part of
the

premise for DPD (as opposed to DPV) was that
the client might not trust the server.

Interesting point re a DPD server returning OCSPv1 responses. i didn't
think about that in detail! I'll have to think more about that case.

Steve

--Boundary_(ID_1hnHg1QAzU4m52F9KlyuTw)--

Received: from mail.spyrus.com (mail.spyrus.com [207.212.34.20]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA19150 for ; Mon, 15 Jan 2001 11:27:42 -0800 (PST)
Received: from RHOUSLEY-PC.spyrus.com ([209.172.119.210]) by mail.spyrus.com (8.9.3/8.9.3) with ESMTP id LAA16452; Mon, 15 Jan 2001 11:32:03 -0800 (PST)
Message-Id: <[email-masked]>
X-Sender: [email-masked]
X-Mailer: QUALCOMM Windows Eudora Version 5.0.1
Date: Mon, 15 Jan 2001 14:20:41 -0500
To:
From: Russ Housley
Subject: RE: Basic Cert-2-Directory mapping question
Cc: "'Stephen Kent'" ,
In-Reply-To: <[email-masked]>
References:
Mime-Version: 1.0
Content-Type: text/html; charset="us-ascii"

Jim:

There is an issue with S/MIME.  It was ONE of the reasons that we
require a non-empty issuer distinguished name in RFC 249.  In RFC
2315 (and in RFC 2630 for backward compatibility), SignerInfo structure
includes IssuerAndSerialNumber to specify the certificate that contains
the public key needed to validate the signature.  If an empty issuer
name were permitted, this match would be impossible.  Similarly, the
RecipientInfo field in the EnvelopedData uses IssuerAndSerialNumber to
specify the certificate of the intended recipient.  Again, an empty
issuer name would be counter productive.

Russ

At 02:31 PM 1/12/2001 -0800, Jim Schaad wrote:

This
does not match my memory of what was going on at the time.  My
memory said that the Issuer DN was made required to simplify the chaining
issues for building names.  I do not remember this as being pushed
from the S/MIME working group although several of us from the S/MIME
working group probably gave comments on this issue.

jim

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

From: Stephen Kent
[mailto:[email-masked]]

Sent: Thursday, January 11, 2001 1:56 PM

To: Slone, Skip

Cc: [email-masked]

Subject: RE: Basic Cert-2-Directory mapping question

Skip,

<?fontfamily><?param Arial><?color><?param
0000,0000,FFFF>I would just like to add that, in addition to X.521 and
some LDAP specs, the ability to recognize civil naming attributes in the
issuer and subject fields of an X.509v3 cert is mandated in RFC 2459 (ref
section 4.1.2.4) and in son-of-2459.

<?/color><?/fontfamily>

<?fontfamily><?param Arial><?color><?param
0000,0000,FFFF>

<?/color><?/fontfamily>Ironically, the requirement for
support for Issuer names (DNs) vs. allowing an Issuer alname in lieu of a
DN, arose because the S/MIME WG was relying on the presence of an Issuer
DN in their design, and I believe the motivation for it (Russ can confirm
or correct this notion) was to facilitate directory lookup for certs in
S/MIME!

<?paraindent><?param right,left><snip>

<?/paraindent>

Steve

Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA17667 for ; Mon, 15 Jan 2001 11:07:27 -0800 (PST)
Received: from eastmail2.East.Sun.COM ([129.148.1.241]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA21029; Mon, 15 Jan 2001 11:12:52 -0800 (PST)
Received: from sunlabs.East.Sun.COM (sunlabs.East.Sun.COM [129.148.75.250]) by eastmail2.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id OAA22484; Mon, 15 Jan 2001 14:12:51 -0500 (EST)
Received: from sun.com (dhcp75-155 [129.148.75.155]) by sunlabs.East.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id OAA21371; Mon, 15 Jan 2001 14:12:50 -0500 (EST)
Message-ID: <[email-masked]>
Date: Mon, 15 Jan 2001 14:09:57 -0500
From: Steve Hanna
Organization: Sun Microsystems, Inc.
X-Mailer: Mozilla 4.75 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Stephen Kent
CC: PKIX List
Subject: Re: DPD & DPV Basics
References: <[email-masked]> <[email-masked]> <[email-masked]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Stephen Kent wrote:
> Maybe the root of our disagreement is the assumption of what
> the common requirement is for a DPV client. My strawman cites
> PKI-ignorant (to use Denis' term) clients as a major motivation for
> DPV, which seems incompatible with a DPV server that requires perfect
> inputs.

>From this message and several others, I gather that the basic motivation
for having a DPV server is to provide services to simple, "PKI-ignorant"
clients. Could someone please supply some examples of such clients? What
protocols will they be speaking (other than the DPV protocol)? This
would be very useful in determining the proper requirements for the DPV
protocol.

Thanks,

Steve

Received: from prv-mail20.provo.novell.com (prv-mail20.provo.novell.com [137.65.81.122]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id LAA17381 for ; Mon, 15 Jan 2001 11:06:40 -0800 (PST)
Received: from INET-PRV-Message_Server by prv-mail20.provo.novell.com with Novell_GroupWise; Mon, 15 Jan 2001 12:11:26 -0700
Message-Id:
X-Mailer: Novell GroupWise Internet Agent 5.5.5.1
Date: Mon, 15 Jan 2001 12:11:20 -0700
From: "Bob Jueneman"
To:
Cc:
Subject: RE: Basic Cert-2-Directory mapping question
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id LAA17383

Skip,

I don't particularly like the mechanism you've proposed, at least as
I understand it. But I absolutely and completely agree with you
as to the nature of the problem that has to be solved.

Civil attribute type names will always be with us, and hence must be
dealt with, for at least two fundamental reasons:

1. An address is not a name, although it may be a pseudonym. I
don't want to be forced to change my identity, or to an extent
my basis "self-hood," every time I change my ISP. And I especially
don't want some system administrator telling me that my name
must be limited to 8 characters, or that I have to change my name
because someone else has already used that same name within
that same system administrator's ill-conceived naming scheme.

2. E-mail address and other cyberspace identifiers fail to provide the
essence of PKI from a nonrepudiation standpoint, i.e., what I call the
"where do you send the sheriff" question.

Granted, not all uses of PKI will or should involve legal nonrepudiation.
But to the extent that at least some uses WILL have legal consequences,
then the establishment of a globally unique and credible identity that is
grounded in "meat-space" rather then cyberspace is absolutely essential.

For those legally binding transaction to be worth anything at all, they
have to be enforceable. And that means that a judgement may have
to be enforced upon someone, either by seizing the assets or putting
them in jail. And only in science fiction does the sheriff ride off into
cyberspace to arrest someone.

If I as a relying party wish to trade with someone, then I either want to
charge her credit card (in which case PKI is demonstrably not necessary)
or I want to know that she is the Mary Smith who resides at 123 Anywhere St,
Metropolis, NY.

The inclusion of that civil address not only servers to distinguish her
from the other Mary Smiths, but more importantly it establishes a nexus
or link between her identity and her probable whereabouts, and
probably valuable real property as well.

So civil addresses, both corporate or "organizationalPerson", or the
harder-to-deal-with residentialPerson type will presumably always
be with us, and will have to be dealt with.

And unfortunately, perhaps, here int he US the simple and inescapable
fact of the matter is that neither the federal nor the state governments
operate the type of presumptively authoritative name registration
authorities that are relatively common in other countries. I am perfectly
free to move from one city to another, or from address to another in
the same city, and to never notify anyone in authority at all, including
the tax authorities. No one will ever say, "Papers, please."

(Granted, if I choose to do that I may not be able to register to vote,
but over half the population doesn't vote anyway. And the last time
I registered, no one checked to see that I actually lived there -- that
one of the problems we have with our voting system, even outside
of the State of Florida.. And I may not be able to get a driver's license
in order to legally drive a car, but a lot of illegal immigrants don't have
driver's licenses either, although that doesn't keep them from driving.)

So merely trying to ignore the problem of civil addressing schemes
won't solve that problem. And neither will various approaches that
make certain assumptions about monopoly name registration
authorities, or try to divine or impute where a directory containing
a particular name might be found based on some kind of a Karnak
mentalist act.

The primary issue is not the question of whether the name space
is flat or hierarchical, or how hierarchical, much less what the
"approved" schema is. What will be, will be, for reasons that
are beyond our scope and power to influence, even if we wanted
to.

So.

We cannot force a person to deposit his certificate or other useful
information into a specific directory, even if we wanted to. Nor can
we reliably impute a likely directory where such information might
be found, at least in the absence of a monopoly or governmental
mandate.

The best we can do is to ASK the user where he has deposited
such information, if anywhere, and to include that information
EXPLICITLY in any directory or pseudo-directory reference, such
as a DN.

Although at one time I liked the notion of prefixing the DN with a
URL, I have come to believe that John Wray's suggestion is the
better way forward.

He said:
>
>Bob,
>
>Accepting the fact that the X.500 dream of a single global directory is not
>going to happen any time soon, DNs can still be turned into globally
>significant pointers into a federation of directories in the way you
>suggest, but it doesn't require altering the DN syntax (and therefore
>doesn't have to break existing implementations). All that's needed is a DN
>attribute that names the particular directory within which the name
>resides. e.g. instead of "c=us;..;cn=My Name" you'd have "dir=My
>Directory;c=us;...;cn=My Name", where "My Directory" is the URL of a
>directory access point.

By including an explicit directory qualifier of the form dir="directory URL"
at the root (top) of the RDN chain, we have implicitly qualified all of the rest
of the RDN, which is a Good Thing.

By defining the syntax of the "dir" attribute appropriately, we could include
both the access type (LDAP, http, etc.) and port number appropriately,
either a default or explicitly indicated.

And by making the dir component multivalued, we could accommodate
a choice of multiple directories and multiple directory types.

Once again -- the essence of the problem is not the format of the directory
name but where a directory containing that name can be found.
Including that information as a top-level qualifying component solves that
problem (and potentially several others, such as name scope qualification)
very neatly.

Bob

Robert R. Jueneman
'Security Architect
Novell, Inc. -- the leading provider of Net services software
>
>
>
>
>
>
>
>>>> "Slone, Skip" 01/15/01 09:08AM >>>
>Oscar,
>
>No offense taken, thus no apology needed.
>
>My comments from the soapbox last week were actually intended for the
>community at large, and were meant to convey frustration at the apparent
>unwillingness of solution providers in general to hear about -- and solve --
>real world problems that are faced by users like myself in large, complex
>environments.
>
>When I say "my environment is not so simple," the response I hear is "let's
>not talk about the complexity; let's make some simplifying assumptions
>instead."
>
>When I say "I have a nail AND a screw and need to put them both in the
>wall," the response I hear is "we have provided you with a perfectly
>adequate hammer, therefore you don't have a screw."
>
>As I was using the nail/hammer analogy, dc-based names are the nails;
>civil-attribute-based names are the screws. No matter how good a job my
>company does of using nails and nails alone, we still have tens of thousands
>of trading partners, many of whom prefer screws to nails and will continue
>to use them indefinitely. Without a screwdriver, it's hard to do business
>with them.
>
>I don't really care what the screwdriver looks like. I've suggested a
>fairly simple design that I think will work. So far, no one has commented on
>the design. What I've heard instead is a chorus of "we still don't like
>screws." Well, I don't like them either, but I still have to deal with
>them. If I'm simply overlooking a screwdriver that we have lying around
>somewhere, I would appreciate someone pointing it out to me.
>
> -- Skip
>
>
>-----Original Message-----
>From: Oscar Jacobsson [mailto:[email-masked]]
>Sent: Thursday, January 11, 2001 5:16 PM
>To: Slone, Skip
>Cc: 'Sharon Boeyen'; [email-masked]
>Subject: RE: Basic Cert-2-Directory mapping question
>
>
>> From: Slone, Skip [mailto:[email-masked]]
>> In response to this, I'm inclined to join Sharon on Marshall's soapbox and
>> echo her words:
>>
>> "... I believe a more constructive approach is to accept the fact that
>> different parts of the world and different environments will use a variety
>> of nameforms ... We are not the global naming police either and should not
>> try to impose the rules that anyone uses to name entities to which they
>> issue certificates."
>
>I'm sorry if I came across as clamouring for rules be imposed. I know that
>this working group has a tendency to be wary of suggestions that don't cater
>for distinguished names containing cat MPEGs, so I should probably have been
>more careful. The requirements I suggested were for a possible naming
>standards document, conformance to which need not be enforced.
>
>The case at hand is not, IMHO, one of dictating that "all distinguished
>names must be according to our will, or you shall feel our wrath". A
>document however, outlining a naming strategy that would require of the
>users of certificates named accordingly no a-priori knowledge of their
>issuer (save for eventually having to reach something explicitly trusted in
>the chain) in order to perform path validation, is something I would
>personally consider very valuable indeed. I'm reasonably confident that
>organizations intending to act as certification authorities or trusted third
>parties would agree.
>
>> And to quote someone Sharon and I both know, "If all you have is a hammer,
>> every problem looks like a nail."
>
>It seems I was less than clear here as well. :-(
>
>My intention was to point out that there are actually two separate problems
>here (one nail, if you will, and one screw) each looking for its own
>solution:
>
>1. Defining a repository, and subsequently entry, discovery process for
>arbitrarily named entries.
>
>2. Defining a naming scheme that _if applied_ would automate this repository
>and entry discovery process.
>
>I am only trying to address the second of these problems. The first is only
>an issue because nobody seems to have properly addressed the second before
>deploying certificates on the Internet en masse. The further we wait before
>addressing number two, the more of a problem number one will become.
>
>I should probably make a habit of pointing out that the opinions stated here
>are my very own, and not necessarily those of my employer.
>
>Cheers,
>
>//oscar

Received: from edelweb.fr (edelweb.fr [212.234.46.16]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA16484 for ; Mon, 15 Jan 2001 11:00:20 -0800 (PST)
Received: from champagne.edelweb.fr (localhost.edelweb.fr [127.0.0.1]) by edelweb.fr with ESMTP id UAA21823; Mon, 15 Jan 2001 20:05:37 +0100 (MET)
Received: from champagne.edelweb.fr (champagne.edelweb.fr [193.51.14.161]) by edelweb.fr (nospam/1.3); Mon, 15 Jan 2001 20:05:37 +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 UAA17200; Mon, 15 Jan 2001 20:05:36 +0100 (MET)
From: Peter Sylvester
Received: (sylvest@localhost) by emeriau.edelweb.fr (8.7.6/8.6.6) id UAA19354; Mon, 15 Jan 2001 20:05:35 +0100 (MET)
Date: Mon, 15 Jan 2001 20:05:35 +0100 (MET)
Message-Id: <[email-masked]>
To: [email-masked], [email-masked]
Subject: RE: question to time stamp draft: case of error
Cc: [email-masked], [email-masked]

> > bill for hardware failure.
>
> Denis, will you be adding systemFailure(25) to the PKIFailureInfo in the RFC
> version of the Time Stamping Protocol?

With the new text of rfc2510bis one could also have
systemUnavail(24) as a more general error case then
timeNotavailable(14) which in fact is somewhat detailed,
a user doesn't really care about the difference between them.

What is not said in TSP and also not in rfc 2510bis is
the supposed treatment. can a tsp client just retry,
or is this out of scope of the document?

> I agree with Jean-Marc and Ari that it would be very useful to add this
> additional value to the PKIFailureInfo since the latest time stamping draft
> currently indicates that:
>
> "These are the only values of PKIFailureInfo that are supported. Compliant
> servers MUST NOT produce any other values. Compliant clients MAY ignore any
> other values."
>
> By not adding systemFailure(25) during the final editing of the RFC version,
> this useful value could not ever be used to indicate this type of error.
>
Not quite true, because this can be changed in the next round of
the standards process.

PS

Received: from edelweb.fr (edelweb.fr [212.234.46.16]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA14499 for ; Mon, 15 Jan 2001 10:41:11 -0800 (PST)
Received: from champagne.edelweb.fr (localhost.edelweb.fr [127.0.0.1]) by edelweb.fr with ESMTP id TAA21705; Mon, 15 Jan 2001 19:46:34 +0100 (MET)
Received: from champagne.edelweb.fr (champagne.edelweb.fr [193.51.14.161]) by edelweb.fr (nospam/1.3); Mon, 15 Jan 2001 19:46: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 TAA17152; Mon, 15 Jan 2001 19:46:33 +0100 (MET)
From: Peter Sylvester
Received: (sylvest@localhost) by emeriau.edelweb.fr (8.7.6/8.6.6) id TAA19333; Mon, 15 Jan 2001 19:46:32 +0100 (MET)
Date: Mon, 15 Jan 2001 19:46:32 +0100 (MET)
Message-Id: <[email-masked]>
To: [email-masked], [email-masked]
Subject: Re: DPD & DPV Basics
Cc: [email-masked]

> > Here's my take on the basic concepts of DPD and DPV:
> >
> > The basic job of a DPV server is to validate a certification path.
>
> I disagree. The basic job of a DPV server is to say whether a given
> certificate is valid according to some validation policy. The client may not
> provide any certification path.

I second that. The server should/may provide a trustworthy
certification path but even this may be considered as not necessary
by the policy or application context.

> > 2) Validate the supplied certification path using the supplied inputs
>
> No. He will have to fetch information (certs and revocation data).

A server creates a valid/non-valid response acoording whatever information
is available. IF the server returns a certification path, this path
must be a path that can be validated even by the client or a client of
the client.

One question is if the client provides one intermediate CA
cert (maybe expired), and the server knows that this intermediate
CA cert is bad but has a good one, I think it is better to
let the server decide whether to honour the input CA cert.

> > 3) Send a response containing the results of the validation (at least,
> > an indication of success or failure)
>
> Yes, and as an option the data used for the assertion.

Note that the certification path is part of these data.

All data returned should be part of the signed structure.

>
> > Many refinements to this are possible: the client supplying only a
> > subset of the necessary inputs (by referring to an established policy),
>
> .. or no subset at all.
>
> > the server returning supporting evidence such as CRLs and OCSP
> > responses,
>
> No. The server returning a blob. The fact that the blob contains certs,
> CRLs, delta CRLs, OSCP or whatever, is not visible.
If it is not VISIBLE, then it doesn't make sense. It is not necessary
for the client to know the complete interpretation of the 'blob'.

>
> > the client supplying CRLs or OCSP responses that may be
> > useful to the server, etc. But I think it may be useful to reach
> > agreement on the basic model described above before discussing these
> > refinements (however worthy).
>
> > The basic job of a DPD server is to discover a certification path.
>
> No. The basic job of a DPD server is to help the PKI-aware client to perfom
> the validation itself.

In current PKI a validation always results in having a certification path, thus
I do not see what else a DPD can provide to a client other than a
certification path or some part of it.

> Certification paths or/and revocation information may be returned. More than
> one certification path and one than one revocation information (e. g. both
> CRLs and OCSP responses) may be returned.

> > In its most basic form, it will perform the following steps:
> >
> > 1) Receive a request containing a target certificate and inputs to the
> > validation algorithm (trust anchors, etc.)
>
> Yes.
>
> > 2) Attempt to discover a certification path ending in the target
> > certificate that will validate properly given the supplied inputs
>
> One or more paths.
See below. The server does not know which of many path the client likes.

>
> > 3) Send a response containing the results of the discovery process
> > (at least an indication of success or failure and, in the success
> > case, the discovered certification path)
>
> Succes or failure of finding the requested elements (i.e. certification
> paths or/and revocation information)

Is a DPD successful when it finds at least one path or some part of it?

>
> > Most of the refinements listed above with respect to the DPV server can
> > also be applied to the DPD server.
>
> No. See above.

>
> > In addition, other refinements might
> > include having the client supply additional certificates that may be
> > useful to the server (such as certificates received with an S/MIME email
> > message).
>
> Yes.

The structure for sending in additional certs together with the certs
for which you ask a service, should be well defined. Both for DPV and DPD.

For DPD there is the question about *how* does the server know when
to stop filling up all possible cert chains that may be considered
valid by the client. (That's why there is an interative approach
in OSCP-DPD).

>
> > I look forward to seeing a discussion on this topic. If no discussion
> > results, I suppose that I will conclude that there is general agreement
> > about these basic concepts. However, simple affirmative messages
> > agreeing with these basic concepts would be useful in judging rough
> > consensus.
>
> Sorry, my message is going in the reverse direction. :-(

The direction of consensus is not necessarily defined by the chairman :-)

Peter

Received: from mail.spyrus.com (mail.spyrus.com [207.212.34.20]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA13301 for ; Mon, 15 Jan 2001 09:58:34 -0800 (PST)
Received: from RHOUSLEY-PC.spyrus.com ([209.172.119.210]) by mail.spyrus.com (8.9.3/8.9.3) with ESMTP id KAA14381; Mon, 15 Jan 2001 10:03:27 -0800 (PST)
Message-Id: <[email-masked]>
X-Sender: [email-masked]
X-Mailer: QUALCOMM Windows Eudora Version 5.0.1
Date: Mon, 15 Jan 2001 12:20:39 -0500
To: "'Stephen Kent'"
From: Russ Housley
Subject: RE: DPD & DPV requirements
Cc: [email-masked]
In-Reply-To: <[email-masked] om>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed

Steve:

S/MIME has such a construct. From RFC 2630:

10.2.2 CertificateChoices

The CertificateChoices type gives either a PKCS #6 extended
certificate [PKCS#6], an X.509 certificate, or an X.509 attribute
certificate [X.509-97]. The PKCS #6 extended certificate is
obsolete. PKCS #6 certificates are included for backward
compatibility, and their use should be avoided. The Internet profile
of X.509 certificates is specified in the "Internet X.509 Public Key
Infrastructure: Certificate and CRL Profile" [PROFILE].

The definitions of Certificate and AttributeCertificate are imported
from X.509.

CertificateChoices ::= CHOICE {
certificate Certificate, -- See X.509
extendedCertificate [0] IMPLICIT ExtendedCertificate,
-- Obsolete
attrCert [1] IMPLICIT AttributeCertificate }
-- See X.509 and X9.57

10.2.3 CertificateSet

The CertificateSet type provides a set of certificates. It is
intended that the set be sufficient to contain chains from a
recognized "root" or "top-level certification authority" to all of
the sender certificates with which the set is associated. However,
there may be more certificates than necessary, or there may be fewer
than necessary.

The precise meaning of a "chain" is outside the scope of this
document. Some applications may impose upper limits on the length of
a chain; others may enforce certain relationships between the
subjects and issuers of certificates within a chain.

CertificateSet ::= SET OF CertificateChoices

Russ

At 07:02 AM 1/15/2001 -0800, Frank Balluffi wrote:
>Steve Kent said:
> > OK, that's a good argument! The argument to the server then would be
> > a lump (a new ASN.1 construct) of certs, with no implied ordering,
> > and the server if left to sort it out. If a partial or complete
> > chain is sent, it is a valid example of the lump of certs model,
> > which happens to be ordered already. I could live with that.

Received: from mailgw2a.lmco.com (mailgw2a.lmco.com [192.91.147.7]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA12810 for ; Mon, 15 Jan 2001 09:49:27 -0800 (PST)
Received: from emss03g01.ems.lmco.com (emss03g01.ems.lmco.com [141.240.4.144]) by mailgw2a.lmco.com (8.8.8/8.8.8) with ESMTP id MAA13305; Mon, 15 Jan 2001 12:54:40 -0500 (EST)
Received: from CONVERSION-DAEMON by lmco.com (PMDF V5.2-32 #38888) id <[email-masked]>; Mon, 15 Jan 2001 12:53:28 -0500 (EST)
Received: from emss03i00.ems.lmco.com ([141.240.31.211]) by lmco.com (PMDF V5.2-32 #38888) with ESMTP id <[email-masked]>; Mon, 15 Jan 2001 12:53:20 -0500 (EST)
Received: by emss03i00.orl.lmco.com with Internet Mail Service (5.5.2650.21) id ; Mon, 15 Jan 2001 12:54:28 -0500
Content-return: allowed
Date: Mon, 15 Jan 2001 12:54:26 -0500
From: "Slone, Skip"
Subject: RE: Basic Cert-2-Directory mapping question
To: "'Sharon Boeyen'" , "'Stephen Kent'"
Cc: [email-masked]
Message-id:
MIME-version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-type: MULTIPART/ALTERNATIVE; BOUNDARY="Boundary_(ID_0CCXUD13R8PfMnEM4h9dmw)"

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

--Boundary_(ID_0CCXUD13R8PfMnEM4h9dmw)
Content-type: text/plain
Content-transfer-encoding: 7BIT

[Sharon] It seems that we are basically in agreement that both the 'civil
attributes' type of DNs and the domain
component attributes for DNS structured DNs are currently being used and
will likely continue to be used.

[Skip] Agreed.

[Sharon] We also seem to be in agreement that both are hierarchical name
structures.

[Skip] Agreed.

[Sharon] I think it is also fairly safe to say that the extensions we
already have in certificates, combined with the PKI repository locator
service seem adequate for identifying and locating the PKI repository of
interest in most cases for both types of DN structures.

[Skip] I'm not sure I understand what you mean by "the [tools] we already
have ... seem adequate ... for both types of DN structures." Maybe I'm
overlooking the obvious, but I don't see support structures for
civil-attribute-based DNs.

[Sharon] The single exception to this is, as pointed out by Skip, the one
where all the following conditions are met: I guess typically this
would be an environment where there is more than one internediary
certificate in a path because if two domains directly cross-certify with
one-another they would provide repository access information to each other,
otherwise the cross-certification makes no sense.

[Skip] I see this need most acutely in those instances that occur near the
boundaries of a business relationship. That is, when a relationship is in
the early stages of being formed, or if some break has occured in a business
relationship (due to mergers, acquisitions, etc.), there is a sharp drop in
the likelihood that the requisite knowledge is already in place. Once a
relationship has been established, the whole repository locator issue
becomes a moot point. Until then, it can be a big deal. The "problem certs"
are not the ones that are commercially issued; the problem arises when
certificates are issued by a private CA that is certified (directly or
indirectly) by a commercial CA that I happen to trust.

[Sharon] While I don't disagree with Skip's assertion that the mapping of
civil DNs to DNS names might be useful in the general directory sense,

[Skip] In the absence of a well-connected DIT (complete with globally
accessible first-level DSAs, a functional c=US, etc.) distributed X.500/LDAP
name resolution has been, and will continue to be an unmitigated failure.
By leveraging an existing, global, ubiquitous infrastructure, the mapping
I've suggested is intended to solve a big portion of this name resolution
problem.

[Sharon] I agree with Steve that this directory issue is not one that PKIX
needs to tackle in general.

[Skip] While I completely agree that the charter of PKIX is NOT to solve
general directory issues, it seems to me that it is within the charter of
PKIX to consider problems that users report with PKIX as currently defined,
and to give due consideration to whether any proposed solution does indeed
solve the reported problem. If the solution is then deemed to be too
general, the work can, of course, be moved elsewhere.

[Sharon] However, if the scenario above is one that PKIX needs to find a
solution to (as opposed to determining that its not relevant since Internet
applications will generally have domain names and can therefore use PKI
repository locator service regardless of the DN structures in the certs or
the directory entries), then we have some work to do.

[Skip] Agreed. I can offer some cycles to do some of this work.

[Sharon] Otherwise, we already have all the tools we need to satisfy the PKI
information retrieval problem.

[Skip] I'm still looking for something other than a hammer :-)

-- Skip

-----Original Message-----
From: Sharon Boeyen [mailto:[email-masked]]
Sent: Friday, January 12, 2001 9:19 AM
To: 'Stephen Kent'; Slone, Skip
Cc: [email-masked]
Subject: RE: Basic Cert-2-Directory mapping question

OK now we're getting to the 'focal' point I was hoping we would.

It seems that we are basically in agreement that both the 'civil attributes'
type of DNs and the domain
component attributes for DNS structured DNs are currently being used and
will likely continue to be used. We also seem to be in agreement that both
are hierarchical name structures. I think it is also fairly safe to say that
the extensions we already have in certificates, combined with the PKI
repository locator service seem adequate for identifying and locating the
PKI repository of interest in most cases for both types of DN structures.
The single exception to this is, as pointed out by Skip, the one where all
the following conditions are met: A relying party needs to obtain an
end-entity certificate for which it does not know the domain name and it
cannot be easily derived from information the relying party does have (and
therefore the PKI repository locator service won't provide the required
information) and the relying party's local environment does not have a
priori knowledge of the remote domain's repository. I guess typically this
would be an environment where there is more than one internediary
certificate in a path because if two domains directly cross-certify with
one-another they would provide repository access information to each other,
otherwise the cross-certification makes no sense.

While I don't disagree with Skip's assertion that the mapping of civil DNs
to DNS names might be useful in the general directory sense, I agree with
Steve that this directory issue is not one that PKIX needs to tackle in
general. However, if the scenario above is one that PKIX needs to find a
solution to (as opposed to determining that its not relevant since Internet
applications will generally have domain names and can therefore use PKI
repository locator service regardless of the DN structures in the certs or
the directory entries), then we have some work to do. Otherwise, we already
have all the tools we need to satisfy the PKI information retrieval problem.

Sharon

-----Original Message-----
From: Stephen Kent [mailto:[email-masked]]
Sent: Thursday, January 11, 2001 4:56 PM
To: Slone, Skip
Cc: [email-masked]
Subject: RE: Basic Cert-2-Directory mapping question

Skip,

I would just like to add that, in addition to X.521 and some LDAP specs, the
ability to recognize civil naming attributes in the issuer and subject
fields of an X.509v3 cert is mandated in RFC 2459 (ref section 4.1.2.4) and
in son-of-2459.

Ironically, the requirement for support for Issuer names (DNs) vs. allowing
an Issuer alname in lieu of a DN, arose because the S/MIME WG was relying on
the presence of an Issuer DN in their design, and I believe the motivation
for it (Russ can confirm or correct this notion) was to facilitate directory
lookup for certs in S/MIME!

Steve

--Boundary_(ID_0CCXUD13R8PfMnEM4h9dmw)
Content-type: text/html
Content-transfer-encoding: 7BIT

[Sharon]  It seems
that we are basically in agreement that both the 'civil attributes' type of DNs
and the domain

component
attributes for DNS structured DNs are currently being used and will likely
continue to be used.

[Skip]  Agreed.

[Sharon]  We also
seem to be in agreement that both are hierarchical name structures.

[Skip]  Agreed.

[Sharon]  I think it is also fairly safe to say
that the extensions we already have in certificates, combined with the PKI
repository locator service seem adequate for identifying and locating the PKI
repository of interest in most cases for both types of DN structures.

[Skip]  I'm not sure I
understand what you mean by
"the [tools] we already have ... seem adequate ... for both types of DN
structures."  Maybe I'm
overlooking the obvious, but I don't see support structures
for civil-attribute-based DNs.

[Sharon]  The single exception to this is, as
pointed out by Skip, the one where all the following conditions are
met:  <snip> I guess typically this would be an
environment where there is more than one internediary certificate in a path
because if two domains directly cross-certify with one-another they would
provide repository access information to each other, otherwise the
cross-certification makes no sense.

[Skip] I see this need most acutely in those instances
that occur near the boundaries of a business relationship. That is, when a
relationship is in the early stages of being formed, or if some break has
occured in a business relationship (due to mergers, acquisitions, etc.), there
is a sharp drop in the likelihood that the requisite knowledge is already in
place.  Once a relationship has been established, the whole repository
locator issue becomes a moot point. Until then, it can be a big deal.
The "problem certs" are not the ones that are commercially issued; the problem
arises when certificates are issued by a private CA that is certified
(directly or indirectly) by a commercial CA that I happen to trust.

[Sharon] While I don't
disagree with Skip's assertion that the mapping of civil DNs to DNS names might
be useful in the general directory sense,

[Skip] In the absence of a well-connected DIT (complete
with globally accessible first-level DSAs, a functional c=US, etc.) distributed
X.500/LDAP name resolution has been, and will continue to be an unmitigated
failure.  By leveraging an existing, global, ubiquitous
infrastructure, the mapping I've suggested is intended to solve a big portion of
this name resolution problem.

[Sharon]  I agree with Steve that this
directory issue is not one that PKIX needs to tackle in general.

[Skip] While I completely agree that the charter of
PKIX is NOT to solve general directory issues, it seems to me that it is within
the charter of PKIX to consider problems that users report with PKIX as
currently defined, and to give due consideration to whether any proposed
solution does indeed solve the reported problem.  If the solution is then
deemed to be too general, the work can, of course, be moved
elsewhere.

[Sharon] However, if the scenario above is one
that PKIX needs to find a solution to (as opposed to determining that its not
relevant since Internet applications will generally have domain names and can
therefore use PKI repository locator service regardless of the DN structures in
the certs or the directory entries), then we have some work to do.

[Skip] Agreed.  I can offer some cycles to do some
of this work.

[Sharon] Otherwise, we already have all the
tools we need to satisfy the PKI information retrieval
problem.

[Skip] I'm still looking for something other than
a hammer :-)

-- Skip

-----Original Message-----
From: Sharon Boeyen
[mailto:[email-masked]]
Sent: Friday, January 12, 2001
9:19 AM
To: 'Stephen Kent'; Slone, Skip
Cc:
[email-masked]
Subject: RE: Basic Cert-2-Directory mapping
question

OK
now we're getting to the 'focal' point I was hoping we
would.

It
seems that we are basically in agreement that both the 'civil attributes' type
of DNs and the domain

component
attributes for DNS structured DNs are currently being used and will likely
continue to be used. We also seem to be in agreement that both are
hierarchical name structures. I think it is also fairly safe to say that the
extensions we already have in certificates, combined with the PKI repository
locator service seem adequate for identifying and locating the PKI repository
of interest in most cases for both types of DN structures. The single
exception to this is, as pointed out by Skip, the one where all the
following conditions are met: A relying party needs to obtain an end-entity
certificate for which it does not know the domain name and it cannot be
easily derived from information the relying party does have (and
therefore the PKI repository locator service won't provide the required
information) and the relying party's local environment does not have a priori
knowledge of the remote domain's repository. I guess typically this would be
an environment where there is more than one internediary certificate in a path
because if two domains directly cross-certify with one-another they would
provide repository access information to each other, otherwise the
cross-certification makes no sense.

While I don't disagree with Skip's assertion that the
mapping of civil DNs to DNS names might be useful in the general directory
sense, I agree with Steve that this directory issue is not one that PKIX needs
to tackle in general. However, if the scenario above is one that PKIX needs to
find a solution to (as opposed to determining that its not relevant since
Internet applications will generally have domain names and can therefore use
PKI repository locator service regardless of the DN structures in the certs or
the directory entries), then we have some work to do. Otherwise, we already
have all the tools we need to satisfy the PKI information retrieval
problem.

Sharon

-----Original
Message-----
From: Stephen Kent
[mailto:[email-masked]]
Sent: Thursday, January 11, 2001 4:56
PM
To: Slone, Skip
Cc:
[email-masked]
Subject: RE: Basic Cert-2-Directory mapping
question

Skip,

I would just like to add that, in addition
to X.521 and some LDAP specs, the ability to recognize civil naming
attributes in the issuer and subject fields of an X.509v3 cert is mandated
in RFC 2459 (ref section 4.1.2.4) and in son-of-2459.

Ironically, the requirement for support for Issuer names (DNs) vs.
allowing an Issuer alname in lieu of a DN, arose because the S/MIME WG was
relying on the presence of an Issuer DN in their design, and I believe the
motivation for it (Russ can confirm or correct this notion) was to
facilitate directory lookup for certs in S/MIME!

<snip>

Steve

--Boundary_(ID_0CCXUD13R8PfMnEM4h9dmw)--

Received: from ntserver2.chrysalis-its.com ([209.47.245.163]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA11373 for ; Mon, 15 Jan 2001 09:25:53 -0800 (PST)
From: [email-masked]
Received: by NTSERVER2 with Internet Mail Service (5.5.2650.21) id ; Mon, 15 Jan 2001 12:31:19 -0500
Message-ID: <[email-masked]>
To: [email-masked]
Cc: [email-masked], [email-masked]
Subject: RE: question to time stamp draft: case of error
Date: Mon, 15 Jan 2001 12:31:17 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C07F18.F87E4E86"

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_01C07F18.F87E4E86
Content-Type: text/plain;
charset="iso-8859-1"

Jean-Marc Desperrier ([email-masked]) asked a similar
question in December and Ari Kermaier ([email-masked]) wrote:

> The PKIFailureInfo structure described in draft-ietf-pkix-rfc2510bis-02
> includes systemFailure(25) which, while not very descriptive, might fit
the
> bill for hardware failure.

Denis, will you be adding systemFailure(25) to the PKIFailureInfo in the RFC
version of the Time Stamping Protocol?

I agree with Jean-Marc and Ari that it would be very useful to add this
additional value to the PKIFailureInfo since the latest time stamping draft
currently indicates that:

"These are the only values of PKIFailureInfo that are supported. Compliant
servers MUST NOT produce any other values. Compliant clients MAY ignore any
other values."

By not adding systemFailure(25) during the final editing of the RFC version,
this useful value could not ever be used to indicate this type of error.

Cheers,

Francois
___________________________________
Francois Rousseau
Director of Standards and Conformance
Chrysalis-ITS
1688 Woodward Drive
Ottawa, Ontario, CANADA, K2C 3R7
[email-masked] Tel. (613) 723-5076 ext. 419
http://www.chrysalis-its.com Fax. (613) 723-5078

-----Original Message-----
From: Bernd Matthes [mailto:[email-masked]]
Sent: Monday, January 15, 2001 7:33 AM
To: ietf pkix
Subject: question to time stamp draft: case of error

Hi to all!

If a time stamp token (TimeStampToken) can not produced by a server
due to an internal error, i.e. malloc() failed, which value of PKIStatus
and/or PKIFailureInfo is appropriate to send back to the client?
Or should the client get a profane "Server Error"?

Thanks in advance.
--
Mors certa, hora incerta. In dubio pro mille.
--------------------------------------------------------------------
Bernd Matthes Celo Communications GmbH
Senior Software Engineer Weissenfelser Strasse 46a
Nachrichtentechniker D 06217 Merseburg
Dipl.-Ing.(FH) http://www.celocom.com
f. technische Informatik mailto:[email-masked]
http://www.worldbug.de Tel.: +49 3461/3318-0
mailto:[email-masked] Fax: +49 3461/415072
--------------------------------------------------------------------
"When in doubt, use brute force." (Ken Thompson)

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

RE: question to time stamp draft: case of error

Jean-Marc Desperrier =
([email-masked]) asked a similar question in =
December and Ari Kermaier ([email-masked]) wrote:

> The PKIFailureInfo structure described in =
draft-ietf-pkix-rfc2510bis-02

> includes systemFailure(25) which, while not =
very descriptive, might fit the

> bill for hardware failure.

Denis, will you be adding systemFailure(25) to the =
PKIFailureInfo in the RFC version of the Time Stamping Protocol?

I agree with Jean-Marc and Ari that it would be very =
useful to add this additional value to the PKIFailureInfo since the =
latest time stamping draft currently indicates that:

"These are the only values of PKIFailureInfo =
that are supported. Compliant servers MUST NOT produce any other =
values. Compliant clients MAY ignore any other values."

By not adding systemFailure(25) during the final =
editing of the RFC version, this useful value could not ever be used to =
indicate this type of error.

Cheers,

Francois

___________________________________

Francois Rousseau

Director of Standards and Conformance

Chrysalis-ITS

1688 Woodward Drive

Ottawa, Ontario, CANADA, K2C 3R7

[email-masked]      Tel. =
(613) 723-5076 ext. 419

http://www.chrysalis-its.com   &nbs=
p; Fax. (613) 723-5078

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

From: Bernd Matthes [mailto:[email-masked]]=

Sent: Monday, January 15, 2001 7:33 AM

To: ietf pkix

Subject: question to time stamp draft: case of =
error

Hi to all!

If a time stamp token (TimeStampToken) can not =
produced by a server

due to an internal error, i.e. malloc() failed, =
which value of PKIStatus

and/or PKIFailureInfo is appropriate to send back to =
the client?

Or should the client get a profane "Server =
Error"?

Thanks in advance.

--

Mors certa, hora incerta. In dubio pro mille.

---------------------------------------------------------------=
-----

Bernd =
Matthes           =
;        Celo Communications =
GmbH

Senior Software Engineer    =
Weissenfelser Strasse 46a

Nachrichtentechniker       &=
nbsp;    D 06217 =
Merseburg           =

Dipl.-Ing.(FH)        &=
nbsp;         http://www.celocom.com    &nbs=
p;

f. technische =
Informatik      mailto:[email-masked] &n=
bsp;

http://www.worldbug.de    &nbs=
p;     Tel.: +49 =
3461/3318-0

mailto:[email-masked] =
Fax:  +49 3461/415072

---------------------------------------------------------------=
-----

"When in doubt, use brute force." (Ken =
Thompson)

------_=_NextPart_001_01C07F18.F87E4E86--

Received: from mailgw2a.lmco.com (mailgw2a.lmco.com [192.91.147.7]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA05728 for ; Mon, 15 Jan 2001 08:03:34 -0800 (PST)
Received: from emss03g01.ems.lmco.com (emss03g01.ems.lmco.com [141.240.4.144]) by mailgw2a.lmco.com (8.8.8/8.8.8) with ESMTP id LAA31355; Mon, 15 Jan 2001 11:08:51 -0500 (EST)
Received: from CONVERSION-DAEMON by lmco.com (PMDF V5.2-32 #38888) id <[email-masked]>; Mon, 15 Jan 2001 11:07:50 -0500 (EST)
Received: from emss03i00.ems.lmco.com ([141.240.31.211]) by lmco.com (PMDF V5.2-32 #38888) with ESMTP id <[email-masked]>; Mon, 15 Jan 2001 11:07:42 -0500 (EST)
Received: by emss03i00.orl.lmco.com with Internet Mail Service (5.5.2650.21) id ; Mon, 15 Jan 2001 11:08:51 -0500
Content-return: allowed
Date: Mon, 15 Jan 2001 11:08:50 -0500
From: "Slone, Skip"
Subject: RE: Basic Cert-2-Directory mapping question
To: "'Oscar Jacobsson'"
Cc: "'Sharon Boeyen'" , [email-masked]
Message-id:
MIME-version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-type: text/plain; charset=iso-8859-1
Content-transfer-encoding: 7BIT

Oscar,

No offense taken, thus no apology needed.

My comments from the soapbox last week were actually intended for the
community at large, and were meant to convey frustration at the apparent
unwillingness of solution providers in general to hear about -- and solve --
real world problems that are faced by users like myself in large, complex
environments.

When I say "my environment is not so simple," the response I hear is "let's
not talk about the complexity; let's make some simplifying assumptions
instead."

When I say "I have a nail AND a screw and need to put them both in the
wall," the response I hear is "we have provided you with a perfectly
adequate hammer, therefore you don't have a screw."

As I was using the nail/hammer analogy, dc-based names are the nails;
civil-attribute-based names are the screws. No matter how good a job my
company does of using nails and nails alone, we still have tens of thousands
of trading partners, many of whom prefer screws to nails and will continue
to use them indefinitely. Without a screwdriver, it's hard to do business
with them.

I don't really care what the screwdriver looks like. I've suggested a
fairly simple design that I think will work. So far, no one has commented on
the design. What I've heard instead is a chorus of "we still don't like
screws." Well, I don't like them either, but I still have to deal with
them. If I'm simply overlooking a screwdriver that we have lying around
somewhere, I would appreciate someone pointing it out to me.

-- Skip

-----Original Message-----
From: Oscar Jacobsson [mailto:[email-masked]]
Sent: Thursday, January 11, 2001 5:16 PM
To: Slone, Skip
Cc: 'Sharon Boeyen'; [email-masked]
Subject: RE: Basic Cert-2-Directory mapping question

> From: Slone, Skip [mailto:[email-masked]]
> In response to this, I'm inclined to join Sharon on Marshall's soapbox and
> echo her words:
>
> "... I believe a more constructive approach is to accept the fact that
> different parts of the world and different environments will use a variety
> of nameforms ... We are not the global naming police either and should not
> try to impose the rules that anyone uses to name entities to which they
> issue certificates."

I'm sorry if I came across as clamouring for rules be imposed. I know that
this working group has a tendency to be wary of suggestions that don't cater
for distinguished names containing cat MPEGs, so I should probably have been
more careful. The requirements I suggested were for a possible naming
standards document, conformance to which need not be enforced.

The case at hand is not, IMHO, one of dictating that "all distinguished
names must be according to our will, or you shall feel our wrath". A
document however, outlining a naming strategy that would require of the
users of certificates named accordingly no a-priori knowledge of their
issuer (save for eventually having to reach something explicitly trusted in
the chain) in order to perform path validation, is something I would
personally consider very valuable indeed. I'm reasonably confident that
organizations intending to act as certification authorities or trusted third
parties would agree.

> And to quote someone Sharon and I both know, "If all you have is a hammer,
> every problem looks like a nail."

It seems I was less than clear here as well. :-(

My intention was to point out that there are actually two separate problems
here (one nail, if you will, and one screw) each looking for its own
solution:

1. Defining a repository, and subsequently entry, discovery process for
arbitrarily named entries.

2. Defining a naming scheme that _if applied_ would automate this repository
and entry discovery process.

I am only trying to address the second of these problems. The first is only
an issue because nobody seems to have properly addressed the second before
deploying certificates on the Internet en masse. The further we wait before
addressing number two, the more of a problem number one will become.

I should probably make a habit of pointing out that the opinions stated here
are my very own, and not necessarily those of my employer.

Cheers,

//oscar

Received: from ext-mail.valicert.com (ns1.valicert.com [63.65.221.10]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA28331 for ; Mon, 15 Jan 2001 07:01:25 -0800 (PST)
Received: from CONVERSION-DAEMON by ext-mail.valicert.com (PMDF V5.2-33 #46613) id <[email-masked]> for [email-masked]; Mon, 15 Jan 2001 07:06:48 -0800 (PST)
Received: from polaris.valicert.com ([192.168.2.34]) by ext-mail.valicert.com (PMDF V5.2-33 #46613) with ESMTP id <[email-masked]>; Mon, 15 Jan 2001 07:06:47 -0800 (PST)
Received: by exchange.valicert.com with Internet Mail Service (5.5.2650.21) id ; Mon, 15 Jan 2001 07:02:36 -0800
Content-return: allowed
Date: Mon, 15 Jan 2001 07:02:35 -0800
From: Frank Balluffi
Subject: RE: DPD & DPV requirements
To: "'Stephen Kent'"
Cc: [email-masked]
Message-id: <[email-masked]>
MIME-version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-type: text/plain; charset="iso-8859-1"

Frank Balluffi said:

>Would it be valuable for a client to be able to supply the end-entity
>certificate and the trusted certificate in the path?

Steve Kent said:

> What if we say that the chain could be partial?
>
> A trust point (anchor) is a root and the client can specify one or
> more of these as part of the path validation parameter set,
> explicitly or via reference.

Steve Hanna said:

> One good reason to allow the client to supply to a DPD server an
> arbitrary collection of certificates is that this is exactly what's
> delivered in a signed S/MIME message: a bunch of certificates that may
> be useful in building a path from a trust anchor to the
> sender. Multiple
> intermediate certificates are explicitly allowed.

Steve Kent said:

> OK, that's a good argument! The argument to the server then would be
> a lump (a new ASN.1 construct) of certs, with no implied ordering,
> and the server if left to sort it out. If a partial or complete
> chain is sent, it is a valid example of the lump of certs model,
> which happens to be ordered already. I could live with that.

A lump of certs makes sense to me.

Frank

Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA27350 for ; Mon, 15 Jan 2001 06:20: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 PAA24940; Mon, 15 Jan 2001 15:32:31 +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 PAA45540; Mon, 15 Jan 2001 15:24:59 +0100
Message-ID: <[email-masked]>
Date: Mon, 15 Jan 2001 15:24:59 +0100
From: Denis Pinkas
Organization: Bull
X-Mailer: Mozilla 4.7 [fr] (Win98; I)
X-Accept-Language: fr
MIME-Version: 1.0
To: Steve Hanna
CC: PKIX List
Subject: Re: DPD & DPV Basics
References: <[email-masked]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Steve,

> It seems that at least some members of the working group have not yet
> agreed upon certain basic concepts. Perhaps it would be useful for me to
> articulate these concepts so that they can be discussed separately from
> the detailed requirements supplied by Steve. Discussion of those
> detailed requirements can proceed simultaneously, but it would be good
> if we could reach agreement on these basic concepts or at least
> understand why we don't agree on them. I suspect that we already have
> rough consensus on these concepts, but it would be good to get any
> debate on them out into the open so that we can understand the technical
> foundations from which that debate arises.
>
> Here's my take on the basic concepts of DPD and DPV:
>
> The basic job of a DPV server is to validate a certification path.

I disagree. The basic job of a DPV server is to say whether a given
certificate is valid according to some validation policy. The client may not
provide any certification path.

> In its most basic form, it will perform the following steps:
>
> 1) Receive a request containing a certification path

No. See above.

> and other inputs
> to the validation algorithm (trust anchors, required certificate
> policies, etc.)

Yes.

> 2) Validate the supplied certification path using the supplied inputs

No. He will have to fetch information (certs and revocation data).

> 3) Send a response containing the results of the validation (at least,
> an indication of success or failure)

Yes, and as an option the data used for the assertion.

> Many refinements to this are possible: the client supplying only a
> subset of the necessary inputs (by referring to an established policy),

.. or no subset at all.

> the server returning supporting evidence such as CRLs and OCSP
> responses,

No. The server returning a blob. The fact that the blob contains certs,
CRLs, delta CRLs, OSCP or whatever, is not visible.

> the client supplying CRLs or OCSP responses that may be
> useful to the server, etc. But I think it may be useful to reach
> agreement on the basic model described above before discussing these
> refinements (however worthy).

> The basic job of a DPD server is to discover a certification path.

No. The basic job of a DPD server is to help the PKI-aware client to perfom
the validation itself.
Certification paths or/and revocation information may be returned. More than
one certification path and one than one revocation information (e. g. both
CRLs and OCSP responses) may be returned.

> In its most basic form, it will perform the following steps:
>
> 1) Receive a request containing a target certificate and inputs to the
> validation algorithm (trust anchors, etc.)

Yes.

> 2) Attempt to discover a certification path ending in the target
> certificate that will validate properly given the supplied inputs

One or more paths.

> 3) Send a response containing the results of the discovery process
> (at least an indication of success or failure and, in the success
> case, the discovered certification path)

Succes or failure of finding the requested elements (i.e. certification
paths or/and revocation information)

> Most of the refinements listed above with respect to the DPV server can
> also be applied to the DPD server.

No. See above.

> In addition, other refinements might
> include having the client supply additional certificates that may be
> useful to the server (such as certificates received with an S/MIME email
> message).

Yes.

> I look forward to seeing a discussion on this topic. If no discussion
> results, I suppose that I will conclude that there is general agreement
> about these basic concepts. However, simple affirmative messages
> agreeing with these basic concepts would be useful in judging rough
> consensus.

Sorry, my message is going in the reverse direction. :-(

Regards,

Denis

> Thanks,
>
> Steve
>
> P.S. Due to the short timeline, I will submit more detailed comments on
> Steve's requirements soon.

Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA26005 for ; Mon, 15 Jan 2001 06:00:20 -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 PAA67566; Mon, 15 Jan 2001 15:12: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 PAA14798; Mon, 15 Jan 2001 15:05:12 +0100
Message-ID: <[email-masked]>
Date: Mon, 15 Jan 2001 15:05:13 +0100
From: Denis Pinkas
Organization: Bull
X-Mailer: Mozilla 4.7 [fr] (Win98; I)
X-Accept-Language: fr
MIME-Version: 1.0
To: Stephen Kent
CC: PKIX-List
Subject: Re: DPD & DPV requirements
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id GAA26006

Steve,

I have seen an avalanche of messages on that topic, but let me reply to your
message which is not that old.

> Denis,
>
> Steve,
>
> See my responses embbeded with your comments.
>
> > Denis,
> >
> > Steve,
> >
> > First of all, many thanks for posting this long document.
> >
> > I will not respond using directly your text, since my arguments
> > are fairly different. I will however re-use some of your arguments.
> >
> > Let us use the concept of "validation policy", that you introduce, which is
> > all the set of rules to be followed when validating a certificate. It will
> > usually not simply be the rules mentioned in RFC 2459, but these rules with
> > additional conditions. Note that in the context of electronic signatures, a
> > "signature policy" is a specific example of a "validation policy".
> >
>
> [Steve]
>
> We need to be explicit about what are the parameters that control path
> validation. The 2459 validation algorithm has a well-defined set, but if
> there are others, we need to have them specified and agreed upon. One
> conversation that took place in San Diego noted that one could imagine a lot
> of parameters that a user might want to express re path validation, but
> which have not been standardized, and for which we do not have general
> agreement. A very rich list of this sort, and the associated complexity that
> would accompany an enhanced validation algorithm that used thise parameters,
> was thought to be out of scope for now, more an R&D topic vs. a topic for
> standardization. So we have to be careful here.
>
> [Denis]
>
> The current validation algorithm described in RFC 2459 is fine but too
> restritive. It works fine with a single root key in the case where there are
> no naming constraints nor Certification Policy constraints, or in the case
> where there are are included in the (root) self-signed certificates. I have
> worked with Tim Polk so that in the "son-of-RFC2459" we will have the
> description of an enhanced path validation algorithm that will take care of
> multiple roots, each one associated with different naming constraints or
> Certification Policy constraints - which will not necessarilly be included
> in the root self-signed certificates.
>

[Steve]

Self-signed certs are not the only way to deal with multiple roots, and it
often seems to me that they are a poor way, when we want to make use of
features like naming constraints. Why not just have cross certs issued to
other "roots" by a local CA and embed the naming (and policy?) constraints
into those cross certs?

[Denis]

This would be quite an artificial way to do this, and more complex than
simply adding the elements to define the policy and naming constraints. The
proposal is simply to define the policy constraints and the name
constraints. Take a look at the document being progressed in the S/MIME WG
which defines a validation policy format for non repudiation: Electronic
Signature Policies

> So we would need to support two options, which are not mutually exclusive:
>
> 1) define with a great level of accuracy each of the parameters, or
> 2) provide an OID which is a global reference to all these parameters.
>
> > DPV
> > ===
> >
> > Let us start with DPV first. A DPV client will not necessarily be either
> > PKI-aware, nor ASN.1 aware. I thus see two flavors for a DPV protocol:
> >
> > 1) one not using ASN.1 (e.g. using XML),
> > 2) one using ASN.1.
> >
> > In both cases the client only supplies an unambiguous reference of the
> > certificate (CA name, serial number and a hash of the certificate) or the
> > certificate itself and specifies the rules to be followed to validate the
> > certificate: an identification of a pre-defined "validation policy" (e.g. an
> > OID and/or a URL to find the policy and a hash of that validation policy).
> >
>
> [Steve]
>
> Given the problems we have had in OCSP (v1) re referring to a target cert, I
> am not comfortable specifying a target cert other than by providing a copy
> of that cert to the server.
>
> [Denis]
>
> In a signed CMS message, you may only have the EESCertID, without the
> certificate itself.
>
> ESSCertID ::= SEQUENCE {
> certHash Hash,
> issuerSerial IssuerSerial OPTIONAL
> }
>
> Hash ::= OCTET STRING -- SHA1 hash of entire certificate
>
> IssuerSerial ::= SEQUENCE {
> issuer GeneralNames,
> serialNumber CertificateSerialNumber
> }
>
> The idea is to be able to use ESSCertID without the need to fetch the
> certificate itself.
>

[Steve]

I see your example, but I also stand by my observation that providing
anything other than the target cert per se has potential problems and adds
complexity to the server. We'll have to decide whether we want to impose
such adde complexity on servers, and whether we can provide clean,
algorithmic means of dealing with this complexity.

[Denis]

You say "that providing anything other than the target cert per se has
potential problems and adds complexity to the server". However, you do not
provide arguments to support this statement. Let us take one example of use:
someone wants to checks whether a CMS structure is well signed. Such a
client is certainly ASN.1 aware since the CMS structure is described in
ASN1, but is not necessarily PKI aware.

Fortunately, the CMS structure contains two important data structures and
some "useful" attributes. The client may be able to collect the content of
these data structures or attributes. He may then pass each content *as a
blob* to the server.

The CMS structure is the following:

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

Candidate data structures to be passed as *optional* parameters are:

1. the CertificateSet,
2. the CertificateRevocationLists.

Candidate useful unsigned attributes to be passed as parameter are:

1. the Other Signing Certificate attribute
[defined in ],
2. the Complete Certificate Refs attribute
[defined in ],
3. the Complete Revocation Refs attribute
[defined in ],

As a summary:

A. When providing either a reference to a certificate or a list of
certificates that *might* be useful for the server, we have four options:

1. the Other Signing Certificate attribute
[defined in ],
2. the CertificateSet,
3. the Complete Certificate Refs attribute
[defined in ],

B. When providing revocation information that *might* be useful for the
server, we have two options:

1. the CertificateRevocationLists,
2. the Complete Revocation Refs attribute
[defined in ]

If we address the problem this way, then I can agree that a DPV client may
pass these parameters while still being PKI-ignorant. You will notice that
this is a move from my initial position.

> > As a result, the client expects a signed response which reproduces the
> > requested parameters and includes a status. The status is not simply:
> > "passed validation", "failed validation", or "don't' know" but can also be
> > "incomplete validation", meaning that some revocation status information is
> > not yet available at the time of processing and a later attempt might
> > succeed.
> >
>
> [Steve]
>
> Incomplete validation is a reasonable response.
>
> Yes, it will have to be one of the responses, hopefully with an explanation of what caused the response to be incomplete.
>
> [Denis]
>
> :-)
>
> [Steve]
>
> maybe we should include the
> set of parameters used for the validation, including ones not supplied by
> the client, e.g., defaults, or overrides imposed by the server, or the
> values bound to a policy that was specified.
>
> [Denis]
>
> We are not on the same track here. I am assuming that a DPV client is PKI
> ignorant. You are making the assumption that the client MAY simply some
> elements of the certification path, where I make the assumption that the
> single element that MAY be supplied in a DPV request is the leaf
> certificate. For all the other elements of a certification path, the server
> is supposed to have access to the various repositories. The response
> contains a blob of what has been used, that can be blinding copied and
> stored.
>

[Steve]

A DPV client MAY be not PKI-aware, but that is not the only case we agreed
to address. I'll need to see more comments from WG members to persuade me
that we wish to restrict DPV interactions to clients that are presumed to be
PKI-ignorant, to use your term.

[Denis]

I would rephrase your wording as :" Make sure that a DPV client can be used
by a PKI-ignorant client".

> > The response must include the time at which the validation has been
> > performed. Allowing to test a certificate "in the past", would place some
> > requirements that cannot always be accomplished by a standard PKI: currently
> > we do not mandate CAs to maintain revocation information beyond the end of
> > the validity period of a certificate. We should not change that rule. So I
> > am very reluctant to autorise validation in the past, e.g. 10 years later.
> >
>
> [Steve]
>
> Good points; we should include the time of the response. I added the "in the
> past" requirement based on its inclusion in SCVP, but there clearly limits
> to one's ability to support that feature. However, if the server is uable to
> verify a cert relative to a prior time, based on unavailability of some
> revocation data, it can always state that in a response. One might add a
> requirement to allow the server to be configured to reject requests for
> validation that cite a time/date prior to some confugured value.
>
> [Denis]
>
> Since archiving of recocation information is not mandated to the CAs, such a
> function would need to be provided by some other trusted service provider.
> We should be very careful before allowing the provision of such a new
> service. I believe that the PKI is already sufficiently complex so that we
> make our best efforts not to introduced additional Trusted Service Providers
> (that could be avoided). The only case to be supported should be the
> "current time" and some time "soon after the end of validity of a
> certificate" (i.e. a few weeks, in case someone being on holidays would like
> to check, when coming back from holidays, if a received message, was signed
> by a revoked certificate or not).
>

[Steve]

There was some sentiment for having the "was it valid then" function as
provided in SCVP, but if there is not continued support we could delete it.
I want to get more feedback on this issue.

[Denis]

So, let us wait and see ...

> > If a client is interested in a later proof, then it should obtain that
> > information from the server at the time the information is still available.
> > This means that a client should have the possibility to ask the server to
> > optionally return an opaque blob that contains all what has been used to
> > validate the certificate (i.e. a certification path and all the CRLs or
> > OCSPs needed for each certificate from the path).
> >
>
> [Steve]
>
> We have this requirement already, with a time stamp option.
>
> [Denis]
>
> We should remove the time stamp option.
>
> Yes, we could.
>
> > A question arises from the requirements 1.5 and 1.6 that you listed: should
> > that opaque blob be time-stamped ? If there is a fear that some of the
> > issuing keys used in the certification path might later on be compromised,
> > then this can be useful. This case should be very seldom and hence this
> > service would not always be required. In addition, why should that service
> > be embedded in this protocol ? This could be obtained using directly the
> > TSP, leaving more possibilities: free choice of the TSAs, time stamp of the
> > full blob, time stamp of the certification chain only, time stamp on both
> > the certification chain and the revocation information. Thus I do not favor
> > to piggy-back the two services.
> >
>
> [Steve]
>
> Yes, one could keep the services separate. I am not hard over on this, and
> can be persuaded to remove the requirement, or to make server support for it
> optional.
>
> [Denis]
>
> If you are not hard on this issue, let us remove the time stamping option.
>
> :-)

[Steve]

I'll remove it if I hear from a few more people who agree that it is best
provided as a separate call to a TSA.

[Denis]

Up to now, there has been one other message posted to the list, asking for
the TSA removal.

> > In order to simplify the protocol and allow for PKI-ignorant clients, the
> > client should NOT be allowed to provide any other element than the
> > certificate, that might help to construct the path or the revocation
> > information.
> >
>
> [Steve]
>
> I don't see the rationale for this. We already have application protocols
> where a client that is not PKI-aware might acquire cert paths and/or
> revocation data that it could pass on to a DPV server. So, I don't think you
> have made a good argument here for not allowing such data to be transmitted.
> Also, I don't think we have agreement yet that we are supporting clients
> that are not PKI-aware. I merely noted that IF we choose to support such
> clients, then there are implications for the syntax used for the protocol,
> and for the semantics of what is transmitted. I don't think we have made the
> next step to agree to support such clients.
>
> [Denis]
>
> I have difficulties to understand how a client that would NOT be "PKI-aware
> might acquire cert paths and/or revocation data" :-)
>
> Once again, I am advocating a simple protocol for DPV to be used by PKI
> ignorant clients.
>

[Steve]

As I noted, a client might acquire cert paths and CRLs via a protocol like
SSL or IKE. Such clients could be ASN.1 capable but want to offload
validation for the reasons cited earlier.

[Denis]

I agree with you that "we already have application protocols where a client
that is not PKI-aware might acquire cert paths and/or revocation data that
he could pass on to a DPV server." The S/MIME example I provided is one such
example. However, this would mean that each blob able to contain such cert
paths and/or revocation data would have to be passed "as it is", i.e.
without being opened by the application. I made the list of such data
structures for three documents from the S/MIME working group. If we proceed
in that direction, then we should ask the other working groups (e.g. IPSEC,
TLS) to provide us with a list of the data structures that are relevant. If
this list is not too large, then it could make sense to support all of them,
otherwise, we would have to consider that this is not practical.

If you agree with this idea, it could be interesting that we raise the
question to the other working groups.

> > This means that, not only I do not agree with a common list of requirements
> > for both DPV and DPD, but also that I do not agree with many of the
> > requirements that you listed:
> >
> > For a DPV client:
> >
> > 1.1. Only a single certificate should be allowed.
> > 1.2. No revocation items should be allowed.
> > 1.3. No request in the past should be allowed.
> > 1.4. Imposing constraints for CRLs or OCSP responses should be hidden
> > under the "validation policy" that is selected.
> > 1.5. and 1.6. Time stamped responses, if needed, should not be part of the
> > service.
> > 1.7. Validation policies are not necessarily "configured at the server",
> > but can simply be pre-defined, outside the server. I any case, the
> > rules that has been followed - i.e. "validation policy" - must be
> > indicated in the response.
> > 1.8. For DPV, responses must be signed.
> > 1.9. The policy ID format can/will be specified in the protocol.
> >
> > For a DPV server:
> >
> > 2.1. A DPV server, will have to do more than RFC 2459, hence why the use
> > of a validation policy is needed.
> > 2.2. An opaque blob MAY be returned.
> > 2.3. Time stamping is not needed.
> > 2.4. The concept of policy overriding is too complex: a reference to
> > a validation policy is sufficient.
> > 2.5. No comment.
> > 2.6. A server must support LDAP for certificate fetching, and EITHER CRL
> > fetching OR OSCP (OCSP should not be mandatory).
> > 2.7. No comment.
> >
>
> [Steve]
>
> Given that we no longer agree on the underlying assumptions, it probably is
> not worthwhile discussing each of your proposed changes above.
>
> [Denis]
>
> Yes and no. We clearly have different assumptions, but we need to find an
> agreement. I am first advocating to separate the requirements for DPV from
> the requirements for DPD. Then we need to discuss the requirements for each
> of them. So we need to come with separate lists of requirements. This is
> what I did in my response.
>

[Steve]

If we don't agree on whether a DPV client might still pass on certs and CRLs
acquired via a protocol exchange, we can't proceed along these lines. Such a
DPV client looks a lot like a DPD client in terms of what it might pass to
the server in a request. In any case the servers do much the same function,
with the primary differences being the form in which validation parameters
are specified by the client, and the form of the answers returned by the
server. The vast majority of the processing performed by the servers for DPD
and DPV is the same, even for a PKI-ignorant client.

[Denis]

The resolution on that point is pending the result of the number of "blob"
data structures that would need to be supported for:

a) certificate(s) or certificate references that *might* be useful for the
server,
b) revocation information that *might* be useful for the server.

> > DPD
> > ===
> >
> > Let us continue with DPD. I agree in general with many of the requirements
> > that you listed in that case. In particular, since a DPD client must be both
> > PKI-aware and ASN.1 aware, the protocol should only be described in ASN.1.
> >
> > The major difference with the previous protocol is that no evaluation of the
> > returned chain needs to be done, since the client is supposed to be able to
> > perform all the checks himself. Therefor no validation status is returned by
> > the server.
> >
>
> [Steve]
>
> I don't think I agree with both of the statements above. No explicit
> validation status is returned, but I do think the server is performing
> validation so that only valid chains are returned.
>
> [Denis]
>
> Since these chains may not be complete, I would not consider such chains to
> be "valid". These chains will comply with the request, but some elements
> (more probably revovation information, but also certificates ?) may be
> missing.
>

[Steve]

I don't think I have seen anyone suggest that DPD return partial path info,
but maybe I have overlooked this. We obviously have different models here.

[Denis]

If the request parameters are "coarse" (e.g. no naming constraints or no
certification policy constraints), nothing would prevent the server to find
more than one acceptable certification path.

> > The service is more a single place for shopping all (?) the needed
> > certificates and revocation status information.
> >
> > In the request, the client could either specify a validation policy or the
> > trusted points with, for each level of the chain, the indication whether
> > CRLs or OCSP responses are requested.
> >
> > One or more chains, corresponding to the request may be obtained.
> >
> > The response does not need to be signed, but only protected by a combined
> > integrity and data origin authentication service.
> >
> > CONCLUSION
> > ==========
> >
> > We could support three protocols:
> >
> > 1° DPV in XML,
> > 2° DPV in ASN.1,
> > 3° DPD in ASN.1.
> >
> [Steve]
>
> The operative term here is "could." Also, DPV in XML and DPV in ASN.1 need
> not be the same protocol, because of different assumptions about the
> clients. So I think of it three protocols where 2 & 3 may be very similar,
> but 1 is quite different.
>
> [Denis]
>
> Two remarks:
>
> 1) What kind of different assumptions are you making on:
>
> 1) DPV in XML and
> 2) DPV in ASN.1 ?
>
> 2) You think that protocols 2 & 3 may be very similar, but you do not
> provide arguments. On the contrary, I do not think the same and I have have
> provided arguments to explain why they are pretty different.
>

[Steve]

Protocols 2 & 3 are quite similar because I assume that a DPV client using
ASN.1 will be able to supply cert path and revocation status data in cases
such as the ones I noted, e.g., when the protocols allow clients to pass
this info around even if they do not understand it. We have examples of such
protocols now. It's a reasonable design approach, allowing a mix of
PKI-aware and PKI-ignorant implementations for the same protocol.

[Denis]

A DPD client is supposed to be both ASN.1-aware and PKI-aware, so he may
format the cerths and the revocation data that he already got from the
application protocols in any desired way. The same assumption does not
necessarily stand for a DPV client that might be ASN.1-aware but would be
PKI-ignorant.

> > ADDITIONAL QUESTION
> > ===================
> >
> > For the two protocols in ASN.1, should these two protocols be piggy-back on
> > OCSP ?
> >
>
> [Steve]
>
> That's one of the proposals, but the answer should be the result of analysis
> of a revised proposal consistent with the requirements that we adopt.
>
> [Denis]
>
> Agreed.
>
> > Before going at the technical details, it is important to raise the
> > following question: which combination(s) of the three basic requests (OCSP,
> > DPV and DPD) could make sense ?
> >
> > If a client requests DPV, then it does not care about OCSP and neither on
> > DPD (multiple certification chains to be tested).
> >
> > For a PKI-aware client, only OCSP + DPD makes sense.
> >
> > This means that :
> >
> > 1) DPV does not need to be supported by OCSP.
> > 2) The only protocol to be piggy-backed to OCSP would be DPD.
> >
>
> [Steve]
>
> I don't understand these comments. You need to provide more substantiation.
>
> [Denis]
>
> OK. Let me try to explain more:
>
> " If a client requests DPV, then it does not care about OCSP and neither on
> DPD (multiple certification chains to be tested)."
>
> If a client requests DPV, it would normally like to get the response "passed
> validation", and will ask whether or not it wants back the single proof (as
> a blob) that lead to that conclusion. In that case, it does not care about
> the OCSP response which has been used in the validation algorithm and is
> part from the blob. A single chain is returned in that case.
>

[Steve]

I begin to see the differences in our perspectives here. Yes, return of a
single path and associated revocation status data would seem to suffice for
DPV, but I don't think that DPD necessarily returns multiple paths, and I
certainly don't think of it doing so in most cases. Also, why would a DPV
server not return OSCP responses as part of its revocation status data, in
an opaque blob? I would assume that either type of server might return
either CRLs or OCSP responses, unless otherwise directed by the client (or
by locally configured parameters).

[Denis]

It is what I said. So we strongly agree. :-) If the OCSP response is part of
the blob, then it is no more directly visible. To this respect the
individual OCSP response that is indeed returned is of no interest anymore
since it is part of the revocation data blob.

>
> "For a PKI-aware client, only OCSP + DPD makes sense.
> This means that :
>
> 1) DPV does not need to be supported by OCSP.
> 2) The only protocol to be piggy-backed to OCSP would be DPD."
>
> DPV is NOT designed for a PKI-aware client, but of course can be used by a
> PKI aware client, that will behave as if it were PKI ignorant.
>
> So the single combination that remains is between the two remaining
> protocols for PKI-aware clients (i.e. OCSP and DPD). In that sense, DPD
> could be piggy-backed on top of OCSP.
>

[Steve]

The wording here may be confusing me. Are you saying that DPD could be
implemented as an extension to OCSP (as has been proposed), because an OCSP
client must be PKI-aware, whereas a DPV client is nominally PKI-ignorant and
thus would never use OCSP in the first place?

[Denis]

Yes, I mean this.

[Steve]

I agree with that analysis, although it only suggests that the DPD/OCSP
combination is plausible, not necessarily preferable, and that a DPV/OCSP
combination is less plausible. though not impossible.

[Denis]

Good ! Since the later combination is, using your terminology, "less
plausible", I do not see why we should support it, taking into consideration
one further argument: the caller may be ASN1-ignorant (and XML-aware). In
such case it is not possible to piggy back the DPV protocol on top on an
ASN.1 protocol.

This means that there is no need to piggy back the two protocols (i.e. OCSP
and DPV) ... unless more information than simply revocation status data is
returned. OCSP *theoretically* allows to carry extensions. We have observed,
by experience, that different people had different interpretations on how
such extensions would work. :-(

At this point of time, I would imagine that DPV would also be able to carry
some extensions, e.g. to ask some additional information on the account of
the leaf certificate holder. We should take great care on how such
extensions would be supported.

> Steve

Received: from brot.celocom.de (brot.celocom.de [212.78.104.200]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id EAA19174 for ; Mon, 15 Jan 2001 04:27:51 -0800 (PST)
Received: from frolic.celocom.de (frolic.celocom.de [212.78.104.90]) by brot.celocom.de (Postfix) with ESMTP id 86C7C2FD6 for ; Mon, 15 Jan 2001 13:33:17 +0100 (CET)
Received: from celocom.de (bernd.celocom.de [212.78.104.41]) by frolic.celocom.de (Postfix) with ESMTP id 8CADE108003 for ; Mon, 15 Jan 2001 13:33:17 +0100 (CET)
Message-ID: <[email-masked]>
Date: Mon, 15 Jan 2001 13:33:15 +0100
From: Bernd Matthes
Reply-To: [email-masked]
Organization: Celo Communications -- http://www.celocom.com
X-Mailer: Mozilla 4.75 [en] (WinNT; U)
X-Accept-Language: de,en
MIME-Version: 1.0
To: ietf pkix
Subject: question to time stamp draft: case of error
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms6386F5F0A06A6D3D57BD1037"

This is a cryptographically signed message in MIME format.

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

Hi to all!

If a time stamp token (TimeStampToken) can not produced by a server
due to an internal error, i.e. malloc() failed, which value of PKIStatus
and/or PKIFailureInfo is appropriate to send back to the client?
Or should the client get a profane "Server Error"?

Thanks in advance.
--
Mors certa, hora incerta. In dubio pro mille.
--------------------------------------------------------------------
Bernd Matthes Celo Communications GmbH
Senior Software Engineer Weissenfelser Strasse 46a
Nachrichtentechniker D 06217 Merseburg
Dipl.-Ing.(FH) http://www.celocom.com
f. technische Informatik mailto:[email-masked]
http://www.worldbug.de Tel.: +49 3461/3318-0
mailto:[email-masked] Fax: +49 3461/415072
--------------------------------------------------------------------
"When in doubt, use brute force." (Ken Thompson)
--------------ms6386F5F0A06A6D3D57BD1037
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

MIIKSgYJKoZIhvcNAQcCoIIKOzCCCjcCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC
B9YwggSgMIIECaADAgECAhBsOnTzXfzOOQkJistWSC3oMA0GCSqGSIb3DQEBBAUAMIHMMRcw
FQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y
azFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5
IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRp
dmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTAwMDEyNzAwMDAw
MFoXDTAxMDIwOTIzNTk1OVowggESMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UE
CxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9y
ZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMV
UGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBO
ZXRzY2FwZSBGdWxsIFNlcnZpY2UxFjAUBgNVBAMUDUJlcm5kIE1hdHRoZXMxITAfBgkqhkiG
9w0BCQEWEm1haW5idWdAY2Vsb2NvbS5kZTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA
5XDGxWjDOe+gHZygtVsNACVkbiY27ug06wI9DGzn4+ibdyEoqNnMlqe7dHSHsLG5f9Fl8gBa
ZgwOUnNClgnjCbqoByj4In82wWwUG97DndueKQhN78pYDRBWhGXKo/YSGI2l5rw7fjYnlTlw
6QQF0OGpFNBXzkNCBC4muSaI2YUCAwEAAaOCATgwggE0MAkGA1UdEwQCMAAwgawGA1UdIASB
pDCBoTCBngYLYIZIAYb4RQEHAQEwgY4wKAYIKwYBBQUHAgEWHGh0dHBzOi8vd3d3LnZlcmlz
aWduLmNvbS9DUFMwYgYIKwYBBQUHAgIwVjAVFg5WZXJpU2lnbiwgSW5jLjADAgEBGj1WZXJp
U2lnbidzIENQUyBpbmNvcnAuIGJ5IHJlZmVyZW5jZSBsaWFiLiBsdGQuIChjKTk3IFZlcmlT
aWduMBEGCWCGSAGG+EIBAQQEAwIHgDAwBgpghkgBhvhFAQYHBCIWIDFjNzhjMGNiYWZjMzg2
YzQzYzFmMWFjYTY5NzY4Nzk3MDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNp
Z24uY29tL2NsYXNzMS5jcmwwDQYJKoZIhvcNAQEEBQADgYEAsvJl1q8TirOQUfjbbyZKmVdi
k+2YQmQr64uvnEGf0Vp/laotPE49SR5Vu9GwGA2cPY/CPrb9v/bc3mOnCBlJ2m/xQIITJRxv
A66enfch2KSRLjl+VyU5BeIkq3UZekTAy76DPozOEwd6Azf4fLJy6AIh/DRS0GS9w/l2sLYQ
FAAwggMuMIICl6ADAgECAhEA0nYujRQMPX2yqCVdr+4NdTANBgkqhkiG9w0BAQIFADBfMQsw
CQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xNzA1BgNVBAsTLkNsYXNzIDEg
UHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkwHhcNOTgwNTEyMDAwMDAw
WhcNMDgwNTEyMjM1OTU5WjCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsT
FlZlcmlTaWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVw
b3NpdG9yeS9SUEEgSW5jb3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1Zl
cmlTaWduIENsYXNzIDEgQ0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZh
bGlkYXRlZDCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAu1pEigQWu1X9A3qKLZRPFXg2
uA1Ksm+cVL+86HcqnbnwaLuV2TFBcHqBS7lIE1YtxwjhhEKrwKKSq0RcqkLwgg4C6S/7wju7
vsknCl22sDZCM7VuVIhPh0q/Gdr5FegPh7Yc48zGmo5/aiSS4/zgZbqnsX7vyds3ashKyAkG
5JkCAwEAAaN8MHowEQYJYIZIAYb4QgEBBAQDAgEGMEcGA1UdIARAMD4wPAYLYIZIAYb4RQEH
AQEwLTArBggrBgEFBQcCARYfd3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQTAPBgNV
HRMECDAGAQH/AgEAMAsGA1UdDwQEAwIBBjANBgkqhkiG9w0BAQIFAAOBgQCIuDc73dqUNwCt
qp/hgQFxHpJqbS/28Z3TymQ43BuYDAeGW4UVag+5SYWklfEXfWe0fy0s3ZpCnsM+tI6q5QsG
3vJWKvozx74Z11NMw73I4xe1pElCY+zCphcPXVgaSTyQXFWjZSAA/Rgg5V+CprGoksVYasGN
Azzrw80FopCubjGCAjwwggI4AgEBMIHhMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEf
MB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWdu
LmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYG
A1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29u
YSBOb3QgVmFsaWRhdGVkAhBsOnTzXfzOOQkJistWSC3oMAkGBSsOAwIaBQCggbEwGAYJKoZI
hvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDEwMTE1MTIzMzE3WjAjBgkq
hkiG9w0BCQQxFgQUlLNjLuWDJ+yzhnN2qSCpk57iGDEwUgYJKoZIhvcNAQkPMUUwQzAKBggq
hkiG9w0DBzAOBggqhkiG9w0DAgICAIAwBwYFKw4DAgcwDQYIKoZIhvcNAwICAUAwDQYIKoZI
hvcNAwICASgwDQYJKoZIhvcNAQEBBQAEgYCPeKRbUnoVsP3bN5AFtWFL+XpA7WTX02SA0ac9
dxRAeHmXSxQtI5seIzTOFPxo0wdHG8lpiWK9i7CZ2KLRTZCwxzy+HNzdUD1XwPIZud3pFZgB
MWAZ1HELvGmMK4EpfwgGdYwTZcwHAm6/8FdiAHE3ka6cfCoospaUeP/cGKtrRA==
--------------ms6386F5F0A06A6D3D57BD1037--

Received: from edelweb.fr (edelweb.fr [212.234.46.16]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id EAA01221 for ; Sun, 14 Jan 2001 04:38:22 -0800 (PST)
Received: from champagne.edelweb.fr (localhost.edelweb.fr [127.0.0.1]) by edelweb.fr with ESMTP id NAA15684; Sun, 14 Jan 2001 13:43:28 +0100 (MET)
Received: from champagne.edelweb.fr (champagne.edelweb.fr [193.51.14.161]) by edelweb.fr (nospam/1.3); Sun, 14 Jan 2001 13:43:28 +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 NAA13936; Sun, 14 Jan 2001 13:43:27 +0100 (MET)
From: Peter Sylvester
Received: (sylvest@localhost) by emeriau.edelweb.fr (8.7.6/8.6.6) id NAA18872; Sun, 14 Jan 2001 13:43:26 +0100 (MET)
Date: Sun, 14 Jan 2001 13:43:26 +0100 (MET)
Message-Id: <[email-masked]>
To: [email-masked], [email-masked]
Subject: RE: DPD & DPV requirements - Recursion Issues
Cc: [email-masked]

> >
> >I am not the best candidate to answer questions about DPD. I am mainly
> >interested in DPV (as some might imagine).
> >
> >Anyway, if I understand Mike Myers remark correctly, if a DPD server
> >is essentially untrusted, then it could basically just rewrite a relayed
> >response.
>
> Yes, but that will be caught by the client of a DPD server, even a
> DPV server that acts as a DPD client in performing it's function, as
> Steve Hanna suggests.
>
> >A DPD server might have performed an OCSP check or a DPV check (for example
> >to validate a CA cert.) The response should be sent back to the DPD
> >client, this can be used by the client to make a decision about the
> >acceptablity of the path.
>
> An OCSP response if fair game. but I'm not sure I want the DPV
> response to be used recursively, yet.

Hm,

A DPV response has such an importance that it seems useful to keep
it as is when used by a client, even if this client uses the
content of the response to create some other statement or
whatever to its type of client.

There are at least two elements in the response of a DPV:

- A authoritive statement about whether a cert is good or not.
- And a list of reasons, starting with the cert chain, crls,
Ocsp responses.

If a DPV server has acted as a DPV client either in delegation to
validate the same initial certificate, or to validate for
example the first CA cert in chain not just by using OCSP but by
using DPV, then not allowing it, *MUST NOT* be included,
in a response means what?

CA certs, CRLs, OCSP reponses are statement about the validity,
they already have a different nature, a DPV response doesn't
seem to be that far.

Again, if an OCSP responder policy explains that
the actual status doesn't just say 'not revoked' but
'good and existing', then this statement is essentially
the response of a DPV.

Peter

Received: from e4.ny.us.ibm.com (e4.ny.us.ibm.com [32.97.182.104]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id XAA19771 for ; Fri, 12 Jan 2001 23:43:28 -0800 (PST)
Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.117.200.22]) by e4.ny.us.ibm.com (8.9.3/8.9.3) with ESMTP id CAA307282; Sat, 13 Jan 2001 02:47:39 -0500
Received: from d02ml237.somers.hqregion.ibm.com (d02ml237.sby.ibm.com [9.45.4.171]) by northrelay02.pok.ibm.com (8.8.8m3/NCO v4.95) with ESMTP id CAA99470; Sat, 13 Jan 2001 02:45:46 -0500
Importance: Normal
Subject: Re: Basic Cert-2-Directory mapping question
To: Stephen Kent
Cc: [email-masked]
X-Mailer: Lotus Notes Release 5.0.3 (Intl) 21 March 2000
Message-ID:
From: "Tom Gindin"
Date: Sat, 13 Jan 2001 02:48:23 -0500
X-MIMETrack: Serialize by Router on D02ML237/02/M/IBM(Release 5.0.6 |December 14, 2000) at 01/13/2001 02:48:32 AM
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii

Steve:

Isn't a substantial part of this problem the question of how to
publish a certificate in a directory where it will be searchable by a field
within SubjectAltName, most importantly the e-mail address when that is
included? Most of the arguments which I have ever heard for including
e-mail address in the subject DN were actually searchability arguments.
The names in SubjectAltName are typically hierarchically assigned, of
course, but they aren't X.500-based.
Assuming that an EE wants their certificate published under the e-mail
address, IMHO they should be able to request the RA or CA to perform one of
the following actions on a successful certificate issuance (using the
publication info control or a similar mechanism):
1 Add a directory attribute for e-mail address whose value is the e-mail
address in the SubjectAltName to the directory entry named by the Subject
DN. Very often, the RA or CA has the privilege and the knowledge to do
this and the EE has only one or neither.
2 Send a certificate announcement to the domain of the e-mail address,
in the hope and (reasonable) expectation that the certificate will be
published there.

Similar, but less practically important, considerations apply to other
addresses in SubjectAltName. IMHO we also need to profile which directory
attributes should normally be used when indexing a certificate under fields
within SubjectAltName, especially since there are at least two fairly
common attributes for e-mail address.

Tom Gindin

P.S. - The opinions above are my own, and not necessarily those of my
employer.

Received: from venus.initech.com ([203.238.37.132]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id RAA03121 for ; Fri, 12 Jan 2001 17:29:50 -0800 (PST)
Received: from sigma (sigma.initech.com [203.238.37.133]) by venus.initech.com (8.11.0/8.11.0) with SMTP id f0D1U9K21834; Sat, 13 Jan 2001 10:30:09 +0900 (KST)
From: "Kwon, YongChul"
To: "'Andrea Piras'"
Cc:
Subject: RE: Certificate with ECDSA public key
Date: Sat, 13 Jan 2001 10:35:33 +0900
Message-ID: <[email-masked]>
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 CWS, Build 9.0.2416 (9.0.2910.0)
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.3018.1300
Importance: Normal
In-Reply-To: <004f01c07c9e$4a23efc0$5e02949c@yoda>

> And about the ECDSA public key? Do any drafts or standards
> exist about to certificate ECDSA public key?

please refer PKIX internet draft page.
http://www.ietf.org/ids.by.wg/pkix.html

"Algorithms and Identifiers for the Internet X.509 Public Key Infrastructure
Certificate and CRI Profile"
, Russ Housley, Lawrence Bassham, William Polk, 11/21/2000. (52952 bytes)

is exactly what you want.

Received: from mail-fwd.verio-web.com ([161.58.16.59]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id QAA02253 for ; Fri, 12 Jan 2001 16:46:42 -0800 (PST)
Received: from 161.58.117.181 (161.58.117.181) by mail11b.verio-web.com (RS ver 1.0.57s) with SMTP id 018909229; Fri, 12 Jan 2001 19:51:42 -0500 (EST)
Received: from caveosystems.com (adsl-141-154-29-43.bostma.adsl.bellatlantic.net [141.154.29.43]) by os390.caveosystems.com (8.9.3/8.9.3) with ESMTP id TAA05779; Fri, 12 Jan 2001 19:53:18 -0500
Message-ID: <[email-masked]>
Date: Fri, 12 Jan 2001 19:56:33 -0500
From: Rich Salz
X-Mailer: Mozilla 4.73 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Stephen Kent
CC: Michael Myers , PKIX-List
Subject: Re: DPD & DPV requirements - Recursion Issues
References:
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Loop-Detect: 1

> the question I asked was whether the OCSP response carried data that
> tied it to a requestor, not a responder.

Only if the requestor uses a nonce.
/r$

Received: from etrn.xmission.com (etrn.xmission.com [198.60.22.17]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id QAA01521 for ; Fri, 12 Jan 2001 16:11:30 -0800 (PST)
Received: from [166.70.104.49] (helo=reed.oncalldba.com) by etrn.xmission.com with smtp (Exim 2.12 #1) id 14HEN9-0005Pa-00 for [email-masked]; Fri, 12 Jan 2001 17:16:44 -0700
Received: from RMINC_DOM-Message_Server by reed.oncalldba.com with Novell_GroupWise; Fri, 12 Jan 2001 17:16:40 -0700
Message-Id:
X-Mailer: Novell GroupWise Internet Agent 5.5.2.1
Date: Fri, 12 Jan 2001 17:16:16 -0700
From: "Ed Reed"
To: ,
Cc:
Subject: Re: Basic Cert-2-Directory mapping question
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="=_EBB08378.492844FD"

--=_EBB08378.492844FD
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

As a case in point, nobody really needed those
32 bit ip addresses with all that subnetting and such...

48 bit mac addresses (flat addressing, with hierarchical
subregistration for manufacturers) are surely sufficient...

And if not, then the 128 bit UUIDs of IDL/IIOP/msRPC
will certainly do, right?

Yes, flat works within a context.

Yes, directory weenies like me tend to create too many
contexts, and stack them hierarchically to support delegation.

Interestingly, what the world keeps returning to is a roughly
4 level stack:

some naming scheme (dns, joint-iso-ccitt, broadcast SMB or SAP)
some top level thing (o, .com or .co.uk, c=3Dus, whatever)
some organizational association (aol.com, Visa, ietf.org)
some individual name (eer@, skip.slone@, etc).

Commerce has a similar hierarchy:

earth or government
industry or other community of interest
company
individual

But flat don't work when you want to ask "earth" what "Ed's" email address
is, and repeated attempts to make it work shouldn't be suffered to =
survive.

E

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Ed Reed
Reed-Matthews, Inc.
+1 801 796 7065
http://www.Reed-Matthews.COMd
>>> Stephen Kent 01/10/01 02:55PM >>>
At 9:08 AM +0100 1/10/01, Michael Str=F6der wrote:
>
>
>
>=3D> People are used to flat name spaces. X.500 DNs does not work.

Flat name spaces scale poorly, lead to confusion, and are thus not=20
attractive in various ways. People do like flat name spaces, until=20
they trip over the limitations they embody, then they complain and=20
look for magic solutions. I've seen no appropriate magic for this=20
problem.

Steve

--=_EBB08378.492844FD
Content-Type: TEXT/HTML
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="TEXT.htm"

PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv
L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu
dD0idGV4dC9odG1sOyBjaGFyc2V0PWlzby04ODU5LTEiPg0KPE1FVEEgY29udGVudD0iTVNIVE1M
IDUuNTAuNDEzNC42MDAiIG5hbWU9R0VORVJBVE9SPjwvSEVBRD4NCjxCT0RZIHN0eWxlPSJNQVJH
SU4tVE9QOiAycHg7IEZPTlQ6IDEwcHQgQXJpYWw7IE1BUkdJTi1MRUZUOiAycHgiIA0KYmdDb2xv
cj0jZmZmZmZmPg0KPERJVj5BcyBhIGNhc2UgaW4gcG9pbnQsIG5vYm9keSByZWFsbHkgbmVlZGVk
IHRob3NlPC9ESVY+DQo8RElWPjMyIGJpdCBpcCBhZGRyZXNzZXMgd2l0aCBhbGwgdGhhdCBzdWJu
ZXR0aW5nIGFuZCBzdWNoLi4uPC9ESVY+DQo8RElWPiZuYnNwOzwvRElWPg0KPERJVj40OCBiaXQg
bWFjIGFkZHJlc3NlcyAoZmxhdCBhZGRyZXNzaW5nLCB3aXRoIGhpZXJhcmNoaWNhbDwvRElWPg0K
PERJVj5zdWJyZWdpc3RyYXRpb24gZm9yIG1hbnVmYWN0dXJlcnMpIGFyZSBzdXJlbHkgc3VmZmlj
aWVudC4uLjwvRElWPg0KPERJVj4mbmJzcDs8L0RJVj4NCjxESVY+QW5kIGlmIG5vdCwgdGhlbiB0
aGUgMTI4IGJpdCBVVUlEcyBvZiBJREwvSUlPUC9tc1JQQzwvRElWPg0KPERJVj53aWxsIGNlcnRh
aW5seSBkbywgcmlnaHQ/PC9ESVY+DQo8RElWPiZuYnNwOzwvRElWPg0KPERJVj5ZZXMsIGZsYXQg
d29ya3Mgd2l0aGluIGEgY29udGV4dC48L0RJVj4NCjxESVY+Jm5ic3A7PC9ESVY+DQo8RElWPlll
cywgZGlyZWN0b3J5IHdlZW5pZXMgbGlrZSBtZSB0ZW5kIHRvIGNyZWF0ZSB0b28gbWFueTwvRElW
Pg0KPERJVj5jb250ZXh0cywgYW5kIHN0YWNrIHRoZW0gaGllcmFyY2hpY2FsbHkgdG8gc3VwcG9y
dCBkZWxlZ2F0aW9uLjwvRElWPg0KPERJVj4mbmJzcDs8L0RJVj4NCjxESVY+SW50ZXJlc3Rpbmds
eSwgd2hhdCB0aGUgd29ybGQga2VlcHMgcmV0dXJuaW5nIHRvIGlzIGEgcm91Z2hseTwvRElWPg0K
PERJVj40IGxldmVsIHN0YWNrOjwvRElWPg0KPERJVj4mbmJzcDs8L0RJVj4NCjxESVY+c29tZSBu
YW1pbmcgc2NoZW1lIChkbnMsIGpvaW50LWlzby1jY2l0dCwgYnJvYWRjYXN0IFNNQiBvciBTQVAp
PC9ESVY+DQo8RElWPnNvbWUgdG9wIGxldmVsIHRoaW5nIChvLCAuY29tIG9yIC5jby51aywgYz11
cywgd2hhdGV2ZXIpPC9ESVY+DQo8RElWPnNvbWUgb3JnYW5pemF0aW9uYWwgYXNzb2NpYXRpb24g
KGFvbC5jb20sIFZpc2EsIGlldGYub3JnKTwvRElWPg0KPERJVj5zb21lIGluZGl2aWR1YWwgbmFt
ZSAoZWVyQCwgc2tpcC5zbG9uZUAsIGV0YykuPC9ESVY+DQo8RElWPiZuYnNwOzwvRElWPg0KPERJ
Vj5Db21tZXJjZSBoYXMgYSBzaW1pbGFyIGhpZXJhcmNoeTo8L0RJVj4NCjxESVY+Jm5ic3A7PC9E
SVY+DQo8RElWPmVhcnRoIG9yIGdvdmVybm1lbnQ8L0RJVj4NCjxESVY+aW5kdXN0cnkgb3Igb3Ro
ZXIgY29tbXVuaXR5IG9mIGludGVyZXN0PEJSPmNvbXBhbnk8L0RJVj4NCjxESVY+aW5kaXZpZHVh
bDwvRElWPg0KPERJVj4mbmJzcDs8L0RJVj4NCjxESVY+QnV0IGZsYXQgZG9uJ3Qgd29yayB3aGVu
IHlvdSB3YW50IHRvIGFzayAiZWFydGgiIHdoYXQgIkVkJ3MiIGVtYWlsIA0KYWRkcmVzczwvRElW
Pg0KPERJVj5pcywgYW5kJm5ic3A7cmVwZWF0ZWQgYXR0ZW1wdHMgdG8gbWFrZSBpdCB3b3JrJm5i
c3A7c2hvdWxkbid0IGJlIHN1ZmZlcmVkIA0KdG8gc3Vydml2ZS48L0RJVj4NCjxESVY+Jm5ic3A7
PC9ESVY+DQo8RElWPkU8L0RJVj4NCjxESVY+Jm5ic3A7PC9ESVY+DQo8RElWPj09PT09PT09PT09
PT09PT09PEJSPkVkIFJlZWQ8QlI+UmVlZC1NYXR0aGV3cywgSW5jLjxCUj4rMSA4MDEgNzk2IA0K
NzA2NTxCUj48QSANCmhyZWY9Imh0dHA6Ly93d3cuUmVlZC1NYXR0aGV3cy5DT00iPmh0dHA6Ly93
d3cuUmVlZC1NYXR0aGV3cy5DT008L0E+ZDxCUj4mZ3Q7Jmd0OyZndDsgDQpTdGVwaGVuIEtlbnQg
Jmx0O2tlbnRAYmJuLmNvbSZndDsgMDEvMTAvMDEgMDI6NTVQTSAmZ3Q7Jmd0OyZndDs8QlI+QXQg
OTowOCBBTSANCiswMTAwIDEvMTAvMDEsIE1pY2hhZWwgU3Ry9mRlciANCndyb3RlOjxCUj4mZ3Q7
PEJSPiZndDsmbHQ7c25pcCZndDs8QlI+Jmd0OzxCUj4mZ3Q7PSZndDsgUGVvcGxlIGFyZSB1c2Vk
IHRvIGZsYXQgDQpuYW1lIHNwYWNlcy4gWC41MDAgRE5zIGRvZXMgbm90IHdvcmsuPEJSPjxCUj48
QlI+RmxhdCBuYW1lIHNwYWNlcyBzY2FsZSBwb29ybHksIA0KbGVhZCB0byBjb25mdXNpb24sIGFu
ZCBhcmUgdGh1cyBub3QgPEJSPmF0dHJhY3RpdmUgaW4gdmFyaW91cyB3YXlzLiZuYnNwOyBQZW9w
bGUgDQpkbyBsaWtlIGZsYXQgbmFtZSBzcGFjZXMsIHVudGlsIDxCUj50aGV5IHRyaXAgb3ZlciB0
aGUgbGltaXRhdGlvbnMgdGhleSBlbWJvZHksIA0KdGhlbiB0aGV5IGNvbXBsYWluIGFuZCA8QlI+
bG9vayBmb3IgbWFnaWMgc29sdXRpb25zLiBJJ3ZlIHNlZW4gbm8gYXBwcm9wcmlhdGUgDQptYWdp
YyBmb3IgdGhpcyA8QlI+cHJvYmxlbS48QlI+PEJSPlN0ZXZlPEJSPjxCUj48L0RJVj48L0JPRFk+
PC9IVE1MPg0K

--=_EBB08378.492844FD--

Received: from po1.bbn.com (PO1.BBN.COM [192.1.50.38]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA00599 for ; Fri, 12 Jan 2001 15:14:03 -0800 (PST)
Received: from [171.78.30.107] (comsec.bbn.com [171.78.30.107]) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id SAA03420; Fri, 12 Jan 2001 18:19:09 -0500 (EST)
Mime-Version: 1.0
X-Sender: [email-masked]
Message-Id:
In-Reply-To:
References:
Date: Fri, 12 Jan 2001 18:18:34 -0500
To: "Michael Myers"
From: Stephen Kent
Subject: RE: DPD & DPV requirements - Recursion Issues
Cc: "PKIX-List"
Content-Type: text/plain; charset="us-ascii" ; format="flowed"

Mike,

>Steve,
>
> > On Thursday, January 11, 2001 1:35 PM you wrote
> >
> > Since we don't trust DPD servers per se, the only issue I see here is
> > whether the DPD server to which a request was made can return OCSP
> > responses that were gathered by other DPD servers, without making
> > that obvious to the client. I'll rely on Ambarish or Mike to answer
> > that question, since I don't recall the format details well enough.
>
>Given that OCSP may in the long run wholly replace CRLs in some environments
>it does see prudent that the DPD response structure enable this option.
>
>With regard to client notification of a DPD server's response content, note
>that BasicOCSPREsponse syntax requires inclusion of ResponderID, either by
>name or key hash. Either would enable a client to identify the source(s) of
>information accumulated by a DPD server in its interaction with secondary,
>tertiary, etc. DPD servers.

the question I asked was whether the OCSP response carried data that
tied it to a requestor, not a responder. If not, then OCSP responses
acquired by other DPD or DPV servers can be passed through
transparently to the client. if so, then to make use of these
responses we need to preserve more of the structure of the processing
activities that otherwise could be opaque to the client.

Steve

Received: from po1.bbn.com (PO1.BBN.COM [192.1.50.38]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA00107 for ; Fri, 12 Jan 2001 15:03:58 -0800 (PST)
Received: from [171.78.30.107] (comsec.bbn.com [171.78.30.107]) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id SAA02775; Fri, 12 Jan 2001 18:09:10 -0500 (EST)
Mime-Version: 1.0
X-Sender: [email-masked]
Message-Id:
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]>
Date: Fri, 12 Jan 2001 18:10:24 -0500
To: Steve Hanna
From: Stephen Kent
Subject: Re: DPD & DPV requirements
Cc: [email-masked]
Content-Type: text/plain; charset="us-ascii" ; format="flowed"

Steve,

>Stephen Kent wrote:
> > >Frank Balluffi said:
> > >
> > > > >The client should supply some subset of each requested path
> > > > which must
> > > > >include the least significant certificate and optionally:
> > > > >
> > > > >- one or more intermediate certificates
> > > > >- one or more trusted certificates
> > >
> > >Steve Kent said:
> > >
> > > > An intermediate cert that is not trusted, but is not the end of a
> > > > partial path? Why? This is getting complicated.
>
>One good reason to allow the client to supply to a DPD server an
>arbitrary collection of certificates is that this is exactly what's
>delivered in a signed S/MIME message: a bunch of certificates that may
>be useful in building a path from a trust anchor to the sender. Multiple
>intermediate certificates are explicitly allowed.
>
>For instance, I might have an EE cert from Sun, which has CA certs from
>Thawte and the Federal Bridge CA. When sending an email, I might include
>all of these certs with the message. The DPD server can use these in
>conjunction with the client's trust anchors (perhaps a self-signed
>Thawte cert) to build a path.

OK, that's a good argument! The argument to the server then would be
a lump (a new ASN.1 construct) of certs, with no implied ordering,
and the server if left to sort it out. If a partial or complete
chain is sent, it is a valid example of the lump of certs model,
which happens to be ordered already. I could live with that.

Steve

Received: from po1.bbn.com (PO1.BBN.COM [192.1.50.38]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA00101 for ; Fri, 12 Jan 2001 15:03:57 -0800 (PST)
Received: from [171.78.30.107] (comsec.bbn.com [171.78.30.107]) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id SAA02772; Fri, 12 Jan 2001 18:09:09 -0500 (EST)
Mime-Version: 1.0
X-Sender: [email-masked]
Message-Id:
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]>
Date: Fri, 12 Jan 2001 18:06:36 -0500
To: Steve Hanna
From: Stephen Kent
Subject: Re: DPD & DPV Basics
Cc: PKIX List
Content-Type: text/plain; charset="us-ascii" ; format="flowed"

Steve,

>Stephen Kent wrote:
> > The strawman already calls for a DPD server to perform validation.
> > You're suggesting that a DPV server should not have to perform
> > discovery. That would imply that either:
> > (1) the client passed in a complete path, and matching
> > revocation status data,
> > (2) the client called the DPD server first, then passed on
> > the result to the DPV server
> > (3) or that a DPV server called a DPD server in support
>of discovery.
>
>As I see it, a DPV client would provide a complete path and other inputs
>required by RFC 2459 (such as acceptable certificate policies). The
>client could supply some revocation status information, but I would not
>expect this to be common. The DPV server would be responsible for
>performing the validation algorithm described in RFC 2459 (or its
>successors), including checking revocation. This could involve
>consulting CRLs or OCSP servers.

If a DPV client is not PKI aware, then I don't expect it to be able
to have a complete path in many cases, and I would rarely ex[ect it
to have all the relevant revocation status info. In S/MIME or in
IPsec, where there is a good chance that the peers have different
CAs, it is not necessarily feasible to send a complete path to the
other party, because you may not know enough about that party's PKI
context.

> > What simplifications to the overall architecture arise if we split
> > responsibility this way? Certainly if we expect one server to do
> > both, i.e., to have DPV piggyback on DPD but with slightly different
> > interfaces, this isn't all that helpful. I'm not rejecting this
> > approach, but I want to understand it's benefits in more detail.
>
>One benefit of this definition is that such a DPV server would be
>substantially easier than a DPD server (which may have to try many
>possible paths). In many cases, such a DPV server will be sufficient.

Yes, it would be simplier, but I worry that in making it simple, we
have over burdened the client. A PKI-ignorant client can't even go to
a DPD server to get the data to pass on to a DPV server.

>Here's an analysis of use cases for S/MIME and TLS/SSL:
>
> A TLS/SSL client could pass the certification path supplied
> by a TLS/SSL server to its trusted DPV server (along with any
> necessary parameters, such as the client's list of trust anchors) and
> the DPV server would determine whether the path was valid. If mutual
> authentication is in use, a TLS/SSL server could do the same thing to
> validate a certification path supplied by the TLS/SSL client. A DPD
> server could also be used in either of these cases. It would increase
> the probability of finding a successful path, but with a considerably
> higher cost.

For a client, given the common multi-root CA mode of operation for
browsers, none of this seems applicable, so I'm having trouble seeing
the utility for clients here. In either case you cite above, the apps
are PKI aware already and thus capable of calling a DPD sever, as you
noted. Maybe the root of our disagreement is the assumption of what
the common requirement is for a DPV client. My strawman cites
PKI-ignorant (to use Denis' term) clients as a major motivation for
DPV, which seems incompatible with a DPV server that requires perfect
inputs.

> With S/MIME, a DPD server will probably be required, in general. A
> signed email comes with a bag of certificates. In order to form a
> chain from one of the recipient's trust anchors to the signer,
> certificates must be selected from this bag (and perhaps from other
> sources). Simple validation is not usually sufficient. When attempting
> to determine the public key of a previously unknown party in order to
> send them an encrypted email, discovery is also required.
>
>To summarize, DPV (as I defined it) is a subset of DPD. In some
>circumstances, DPV is sufficient. But not always. We could simplify the
>model by eliminating DPV and adding a flag so the client can say "don't
>add any certs to this chain".
>
>---

See comments above re client capability assumptions.

>It seems to me that others on this list consider it perfectly OK for a
>DPV server to add or remove intermediate certificates to/from the
>certification path supplied by the client. In that case, the only
>distinction between a DPV server and a DPD server is that the DPD server
>is expected to return the validated certification path to the client.

My proposal requires the DPV server to be able to do the same, though
as an opaque blob.

>Is that what you had in mind, Steve? Mike? If so, I agree with Steve
>that there's little distinction between a DPV server and a DPD server
>(as so defined). Let's just add a few flags to say "don't add any certs
>to this chain" and "return the completed path to me" and call the whole
>thing a DPD server (or whatever we want to call it).

I think the request/response formats for both servers could be almost
identical, and with the right control flags one could cause the
relevant subset of operations to occur, yes.

Steve

Received: from po1.bbn.com (PO1.BBN.COM [192.1.50.38]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA28889 for ; Fri, 12 Jan 2001 14:54:04 -0800 (PST)
Received: from [171.78.30.107] (comsec.bbn.com [171.78.30.107]) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id RAA02186; Fri, 12 Jan 2001 17:59:10 -0500 (EST)
Mime-Version: 1.0
X-Sender: [email-masked]
Message-Id:
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Date: Fri, 12 Jan 2001 17:52:34 -0500
To: Peter Sylvester
From: Stephen Kent
Subject: RE: DPD & DPV requirements - Recursion Issues
Cc: [email-masked]
Content-Type: text/plain; charset="us-ascii" ; format="flowed"

Peter,

> > Whatever is contained in a response, it is left untouched.
> >
> > [Carlin's latest response] OK, but what if there is no
>provision in the
> > DPD response syntax for including an embedded DPD response?
>The good news
> > is that the timestamp on the embedded DPD response is
>untouched. The bad
> > news is that you can't include an embedded DPD response.
>Catch vingt-deux.
>
>I am not the best candidate to answer questions about DPD. I am mainly
>interested in DPV (as some might imagine).
>
>Anyway, if I understand Mike Myers remark correctly, if a DPD server
>is essentially untrusted, then it could basically just rewrite a relayed
>response.

Yes, but that will be caught by the client of a DPD server, even a
DPV server that acts as a DPD client in performing it's function, as
Steve Hanna suggests.

>A DPD server might have performed an OCSP check or a DPV check (for example
>to validate a CA cert.) The response should be sent back to the DPD
>client, this can be used by the client to make a decision about the
>acceptablity of the path.

An OCSP response if fair game. but I'm not sure I want the DPV
response to be used recursively, yet.

Steve

Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA28428 for ; Fri, 12 Jan 2001 14:49:39 -0800 (PST)
Received: from eastmail1.East.Sun.COM ([129.148.1.240]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id OAA09446; Fri, 12 Jan 2001 14:54:34 -0800 (PST)
Received: from sunlabs.East.Sun.COM (sunlabs.East.Sun.COM [129.148.75.250]) by eastmail1.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id RAA02983; Fri, 12 Jan 2001 17:54:34 -0500 (EST)
Received: from sun.com (dhcp75-155 [129.148.75.155]) by sunlabs.East.Sun.COM (8.9.3+Sun/8.9.1) with ESMTP id RAA18839; Fri, 12 Jan 2001 17:53:47 -0500 (EST)
Message-ID: <[email-masked]>
Date: Fri, 12 Jan 2001 17:51:42 -0500
From: Steve Hanna
Organization: Sun Microsystems, Inc.
X-Mailer: Mozilla 4.75 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Stephen Kent
CC: Frank Balluffi , [email-masked]
Subject: Re: DPD & DPV requirements
References: <[email-masked]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Stephen Kent wrote:
> >Frank Balluffi said:
> >
> > > >The client should supply some subset of each requested path
> > > which must
> > > >include the least significant certificate and optionally:
> > > >
> > > >- one or more intermediate certificates
> > > >- one or more trusted certificates
> >
> >Steve Kent said:
> >
> > > An intermediate cert that is not trusted, but is not the end of a
> > > partial path? Why? This is getting complicated.

One good reason to allow the client to supply to a DPD server an
arbitrary collection of certificates is that this is exactly what's
delivered in a signed S/MIME message: a bunch of certificates that may
be useful in building a path from a trust anchor to the sender. Multiple
intermediate certificates are explicitly allowed.

For instance, I might have an EE cert from Sun, which has CA certs from
Thawte and the Federal Bridge CA. When sending an email, I might include
all of these certs with the message. The DPD server can use these in
conjunction with the client's trust anchors (perhaps a self-signed
Thawte cert) to build a path.

-Steve

Received: from po1.bbn.com (PO1.BBN.COM [192.1.50.38]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA27364 for ; Fri, 12 Jan 2001 14:34:04 -0800 (PST)
Received: from [171.78.30.107] (comsec.bbn.com [171.78.30.107]) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id RAA00900; Fri, 12 Jan 2001 17:39:13 -0500 (EST)
Mime-Version: 1.0
X-Sender: [email-masked]
Message-Id:
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Date: Fri, 12 Jan 2001 17:38:47 -0500
To: Frank Balluffi
From: Stephen Kent
Subject: RE: DPD & DPV requirements
Cc: [email-masked]
Content-Type: text/plain; charset="us-ascii" ; format="flowed"

Frank,

>Frank Balluffi said:
>
> > >The client should supply some subset of each requested path
> > which must
> > >include the least significant certificate and optionally:
> > >
> > >- one or more intermediate certificates
> > >- one or more trusted certificates
>
>Steve Kent said:
>
> > An intermediate cert that is not trusted, but is not the end of a
> > partial path? Why? This is getting complicated.
>
>OK. It is difficult for me to imagine a client supplying intermediate
>certificates. But requirement 1.1 only supports a single certificate or a
>chain:
>
>1.1 A client request can contain a single certificate or a certificate
>chain terminating in the "target" certificate, to assist the server in path
>construction.
>
>Would it be valuable for a client to be able to supply the end-entity
>certificate and the trusted certificate in the path?

What if we say that the chain could be partial?

A trust point (anchor) is a root and the client can specify one or
more of these as part of the path validation parameter set,
explicitly or via reference.

Steve

Received: from femail4.sdc1.sfba.home.com (femail4.sdc1.sfba.home.com [24.0.95.84]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA27020 for ; Fri, 12 Jan 2001 14:24:56 -0800 (PST)
Received: from revelation ([65.4.166.11]) by femail4.sdc1.sfba.home.com (InterMail vM.4.01.03.00 201-229-121) with SMTP id <20010112222805.CQYL12962.femail4.sdc1.sfba.home.com@revelation>; Fri, 12 Jan 2001 14:28:05 -0800
Reply-To:
From: "Jim Schaad"
To: "'Stephen Kent'"
Cc:
Subject: RE: Basic Cert-2-Directory mapping question
Date: Fri, 12 Jan 2001 14:31:04 -0800
Message-ID: <[email-masked]>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_000E_01C07CA4.4C478450"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0)
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Importance: Normal
In-Reply-To:

This is a multi-part message in MIME format.

------=_NextPart_000_000E_01C07CA4.4C478450
Content-Type: text/plain;
charset="us-ascii"
Content-Transfer-Encoding: 7bit

This does not match my memory of what was going on at the time. My memory
said that the Issuer DN was made required to simplify the chaining issues
for building names. I do not remember this as being pushed from the S/MIME
working group although several of us from the S/MIME working group probably
gave comments on this issue.

jim
-----Original Message-----
From: Stephen Kent [mailto:[email-masked]]
Sent: Thursday, January 11, 2001 1:56 PM
To: Slone, Skip
Cc: [email-masked]
Subject: RE: Basic Cert-2-Directory mapping question

Skip,

I would just like to add that, in addition to X.521 and some LDAP specs,
the ability to recognize civil naming attributes in the issuer and subject
fields of an X.509v3 cert is mandated in RFC 2459 (ref section 4.1.2.4) and
in son-of-2459.

Ironically, the requirement for support for Issuer names (DNs) vs.
allowing an Issuer alname in lieu of a DN, arose because the S/MIME WG was
relying on the presence of an Issuer DN in their design, and I believe the
motivation for it (Russ can confirm or correct this notion) was to
facilitate directory lookup for certs in S/MIME!

Steve

------=_NextPart_000_000E_01C07CA4.4C478450
Content-Type: text/html;
charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

This=20
does not match my memory of what was going on at the time.  My =
memory said=20
that the Issuer DN was made required to simplify the chaining issues for =

building names.  I do not remember this as being pushed from the =
S/MIME=20
working group although several of us from the S/MIME working group =
probably gave=20
comments on this issue.

jim

-----Original Message-----
From: Stephen Kent=20
[mailto:[email-masked]]
Sent: Thursday, January 11, 2001 1:56=20
PM
To: Slone, Skip
Cc:=20
[email-masked]
Subject: RE: Basic Cert-2-Directory =
mapping=20
question

Skip,

I=20
would just like to add that, in addition to X.521 and some LDAP =
specs, the=20
ability to recognize civil naming attributes in the issuer and =
subject=20
fields of an X.509v3 cert is mandated in RFC 2459 (ref section =
4.1.2.4) and=20
in son-of-2459. =

Ironically,=20
the requirement for support for Issuer names (DNs) vs. allowing an =
Issuer=20
alname in lieu of a DN, arose because the S/MIME WG was relying on the =

presence of an Issuer DN in their design, and I believe the motivation =
for it=20
(Russ can confirm or correct this notion) was to facilitate directory =
lookup=20
for certs in S/MIME!

<snip>

Steve=20

------=_NextPart_000_000E_01C07CA4.4C478450--

Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA24137 for ; Fri, 12 Jan 2001 13:29:37 -0800 (PST)
Received: from eastmail2.East.Sun.COM ([129.148.1.241]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA00514; Fri, 12 Jan 2001 13:34:42 -0800 (PST)
Received: from sunlabs.East.Sun.COM (sunlabs.East.Sun.COM [129.148.75.250]) by eastmail2.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id QAA08915; Fri, 12 Jan 2001 16:34:42 -0500 (EST)
Received: from sun.com (dhcp75-155 [129.148.75.155]) by sunlabs.East.Sun.COM (8.9.3+Sun/8.9.1) with ESMTP id QAA06207; Fri, 12 Jan 2001 16:33:55 -0500 (EST)
Message-ID: <[email-masked]>
Date: Fri, 12 Jan 2001 16:31:50 -0500
From: Steve Hanna
Organization: Sun Microsystems, Inc.
X-Mailer: Mozilla 4.75 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Stephen Kent
CC: PKIX List
Subject: Re: DPD & DPV Basics
References: <[email-masked]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Stephen Kent wrote:
> >Here's my take on the basic concepts of DPD and DPV:
> >
> >The basic job of a DPV server is to validate a certification path. In
> >its most basic form, it will perform the following steps:
> >
> >1) Receive a request containing a certification path and other inputs
> > to the validation algorithm (trust anchors, required certificate
> > policies, etc.)
> >2) Validate the supplied certification path using the supplied inputs
> >3) Send a response containing the results of the validation (at least,
> > an indication of success or failure)
> >
> >Many refinements to this are possible: the client supplying only a
> >subset of the necessary inputs (by referring to an established policy),
> >the server returning supporting evidence such as CRLs and OCSP
> >responses, the client supplying CRLs or OCSP responses that may be
> >useful to the server, etc. But I think it may be useful to reach
> >agreement on the basic model described above before discussing these
> >refinements (however worthy).
>
> I think the "refinement" re completeness of input is a basic issue,
> not just a refinement. Also, the control inputs (non-cert and
> non-revocation status data) for validation may be explicit or
> references. I think the strawman motivated the need for both forms of
> specification, based on client capabilities, and the desire for
> centralized control of validation in some environments. Also, the
> need for the DPV server to return data that supports NR seems like an
> important feature, for some set of apps, though not all.

Several people seem to have interpreted "refinement" as "not required".
I didn't mean that. I just wanted to focus on the most basic function of
a DPV or DPD server to make sure we had agreement on what that is.

> >I look forward to seeing a discussion on this topic. If no discussion
> >results, I suppose that I will conclude that there is general agreement
> >about these basic concepts. However, simple affirmative messages
> >agreeing with these basic concepts would be useful in judging rough
> >consensus.
>
> I agree with the basic notions here, as qualified above.

Thanks for your prompt response.

-Steve

Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA19254 for ; Fri, 12 Jan 2001 11:49:03 -0800 (PST)
Received: from eastmail2.East.Sun.COM ([129.148.1.241]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA15281; Fri, 12 Jan 2001 11:53:55 -0800 (PST)
Received: from sunlabs.East.Sun.COM (sunlabs.East.Sun.COM [129.148.75.250]) by eastmail2.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id OAA14950; Fri, 12 Jan 2001 14:53:54 -0500 (EST)
Received: from sun.com (dhcp75-155 [129.148.75.155]) by sunlabs.East.Sun.COM (8.9.3+Sun/8.9.1) with ESMTP id OAA15534; Fri, 12 Jan 2001 14:53:07 -0500 (EST)
Message-ID: <[email-masked]>
Date: Fri, 12 Jan 2001 14:51:02 -0500
From: Steve Hanna
Organization: Sun Microsystems, Inc.
X-Mailer: Mozilla 4.75 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Michael Myers
CC: PKIX List
Subject: Re: DPD & DPV Basics
References:
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Michael Myers wrote:
> > On Thursday, January 11, 2001 12:34 PM you wrote:
> > The basic job of a DPD server is to discover a certification path. In
> > its most basic form, it will perform the following steps:
> >
> > 1) Receive a request containing a target certificate and inputs to the
> > validation algorithm (trust anchors, etc.)
> > 2) Attempt to discover a certification path ending in the target
> > certificate that will validate properly given the supplied inputs
> > 3) Send a response containing the results of the discovery process
> > (at least an indication of success or failure and, in the success
> > case, the discovered certification path)
> >
>
> The current DPD I-D also defines a fourth area of functionality. It enables
> a client to iteratively discover a path acceptable to the client in the case
> where a given certificate may be subject to multiple valid paths.

I'd say that's a refinement on the basic form listed above. It's
interesting, though. As I read your I-D, the RetryReference (which I
think is what you're referring to) allows the client to say "try again,
I didn't like that path". If there are many possible paths (as there
would be in a mesh topology), this probably won't work well. It would be
more efficient for the client to say what it's looking for in a path.

What things do you think a client might be looking for that couldn't be
expressed in the parameters supplied to the DPD server? And why? If
there is a short list with good reasons for each, we could provide a
standard way for the client to request those. But we should probably
provide this mechanism to handle the cases we missed. Of course, the
client could just refer to a validation policy OID that the server and
client both understand. But this won't handle the case where the server
and client haven't agreed on such a policy. Or where the client's
requirement is variable (all certs must contain a custom extension whose
contents match the project name I'm working on, or some such).

-Steve

Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA17955 for ; Fri, 12 Jan 2001 11:29:06 -0800 (PST)
Received: from eastmail2.East.Sun.COM ([129.148.1.241]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA15021; Fri, 12 Jan 2001 11:34:18 -0800 (PST)
Received: from sunlabs.East.Sun.COM (sunlabs.East.Sun.COM [129.148.75.250]) by eastmail2.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id OAA09972; Fri, 12 Jan 2001 14:34:18 -0500 (EST)
Received: from sun.com (dhcp75-155 [129.148.75.155]) by sunlabs.East.Sun.COM (8.9.3+Sun/8.9.1) with ESMTP id OAA13746; Fri, 12 Jan 2001 14:33:31 -0500 (EST)
Message-ID: <[email-masked]>
Date: Fri, 12 Jan 2001 14:31:26 -0500
From: Steve Hanna
Organization: Sun Microsystems, Inc.
X-Mailer: Mozilla 4.75 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: "Covey, Carlin"
CC: PKIX List
Subject: Re: DPD & DPV Basics
References: <[email-masked]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Thank you, Carlin, for pointing out several cases where it might be
useful for a DPD server to return an invalid or unvalidated path.

I'm glad to see that you and Steve Kent have agreed that these cases
should not be addressed at this time. They can be addressed later by
adding parameters that the client could use to describe what sort of
invalid or unvalidated paths it is willing to accept.

-Steve

"Covey, Carlin" wrote:
>
> Frank,
>
> See comments below.
>
> -----Original Message-----
> From: Frank Balluffi [mailto:[email-masked]]
> Sent: Thursday, January 11, 2001 2:31 PM
> To: 'Steve Hanna'; PKIX List
> Subject: RE: DPD & DPV Basics
>
>
>
> 1. Can someone explain the value of a DPD server returning a path that may
> not be valid?
>
>
>
> [Carlin]
> I agree that returning a path that may not be valid would not be the normal
> case.
> However, I can think of some circumstances in which it would be useful.
>
> The returned certificate path might include a certificate that has expired,
> or which is currently suspended. The DPD client may be willing to accept
> such an invalid chain for certain purposes.
>
> Another case is a valid chain that traces to a root that is not one of the
> client's trust anchors. The DPD client might be willing to add that root to
>
> its set of trust anchors.
>
> A third case is a chain that the DPD client can validate, but the DPD server
> cannot.
> (For instance, the client may be able validate a certificate signed with
> ECDSA,
> whereas the server may have no means to do so.)
>
> Regards,
>
> Carlin
>
> --------------------------------------
> - Carlin Covey
> Cylink Corp.

Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA17847 for ; Fri, 12 Jan 2001 11:28:53 -0800 (PST)
Received: from eastmail2.East.Sun.COM ([129.148.1.241]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA14755; Fri, 12 Jan 2001 11:34:02 -0800 (PST)
Received: from sunlabs.East.Sun.COM (sunlabs.East.Sun.COM [129.148.75.250]) by eastmail2.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id OAA09887; Fri, 12 Jan 2001 14:34:01 -0500 (EST)
Received: from sun.com (dhcp75-155 [129.148.75.155]) by sunlabs.East.Sun.COM (8.9.3+Sun/8.9.1) with ESMTP id OAA13715; Fri, 12 Jan 2001 14:33:14 -0500 (EST)
Message-ID: <[email-masked]>
Date: Fri, 12 Jan 2001 14:31:09 -0500
From: Steve Hanna
Organization: Sun Microsystems, Inc.
X-Mailer: Mozilla 4.75 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Stephen Kent
CC: Frank Balluffi , PKIX List
Subject: Re: DPD & DPV Basics
References: <[email-masked]> <[email-masked]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Stephen Kent wrote:
> The strawman already calls for a DPD server to perform validation.
> You're suggesting that a DPV server should not have to perform
> discovery. That would imply that either:
> (1) the client passed in a complete path, and matching
> revocation status data,
> (2) the client called the DPD server first, then passed on
> the result to the DPV server
> (3) or that a DPV server called a DPD server in support of discovery.

As I see it, a DPV client would provide a complete path and other inputs
required by RFC 2459 (such as acceptable certificate policies). The
client could supply some revocation status information, but I would not
expect this to be common. The DPV server would be responsible for
performing the validation algorithm described in RFC 2459 (or its
successors), including checking revocation. This could involve
consulting CRLs or OCSP servers.

> What simplifications to the overall architecture arise if we split
> responsibility this way? Certainly if we expect one server to do
> both, i.e., to have DPV piggyback on DPD but with slightly different
> interfaces, this isn't all that helpful. I'm not rejecting this
> approach, but I want to understand it's benefits in more detail.

One benefit of this definition is that such a DPV server would be
substantially easier than a DPD server (which may have to try many
possible paths). In many cases, such a DPV server will be sufficient.

Here's an analysis of use cases for S/MIME and TLS/SSL:

A TLS/SSL client could pass the certification path supplied
by a TLS/SSL server to its trusted DPV server (along with any
necessary parameters, such as the client's list of trust anchors) and
the DPV server would determine whether the path was valid. If mutual
authentication is in use, a TLS/SSL server could do the same thing to
validate a certification path supplied by the TLS/SSL client. A DPD
server could also be used in either of these cases. It would increase
the probability of finding a successful path, but with a considerably
higher cost.

With S/MIME, a DPD server will probably be required, in general. A
signed email comes with a bag of certificates. In order to form a
chain from one of the recipient's trust anchors to the signer,
certificates must be selected from this bag (and perhaps from other
sources). Simple validation is not usually sufficient. When attempting
to determine the public key of a previously unknown party in order to
send them an encrypted email, discovery is also required.

To summarize, DPV (as I defined it) is a subset of DPD. In some
circumstances, DPV is sufficient. But not always. We could simplify the
model by eliminating DPV and adding a flag so the client can say "don't
add any certs to this chain".

---

It seems to me that others on this list consider it perfectly OK for a
DPV server to add or remove intermediate certificates to/from the
certification path supplied by the client. In that case, the only
distinction between a DPV server and a DPD server is that the DPD server
is expected to return the validated certification path to the client.

Is that what you had in mind, Steve? Mike? If so, I agree with Steve
that there's little distinction between a DPV server and a DPD server
(as so defined). Let's just add a few flags to say "don't add any certs
to this chain" and "return the completed path to me" and call the whole
thing a DPD server (or whatever we want to call it).

> >My team has also implemented path discovery and validation (although not
> >yet delegated discovery and validation). Validation is a fairly simple
> >matter of running the PKIX validation algorithm using certain
> >parameters. Discovery is *much* more complicated, involving heuristics
> >for guessing which certificates might lead to the target certificate (or
> >to the trust anchor, if building forward), partial validation to
> >discover when a partial path is futile, and loop detection. I would
> >argue that DPD is substantially harder than DPV and DPV is often
> >sufficient. So it is definitely worthwhile to define DPV as a separate
> >operation. Many servers may only want to support that operation.
>
> No argument that discovery is harder, and it subsumes validation.
> But, what is the basis for arguing that validation, based on
> supplying complete cert chains and revocation status data, will be
> the more common case and thus we should optimize for it? Several
> protocols allow for transmission of certs and CRLs, but some allow
> transmission only for certs, perhaps because that it static data that
> is easier to configure into the client.

As I described above, I agree that clients will rarely have revocation
status data. Providing a DPV function that can validate a certification
path without including the extra complexity of path discovery would be
nice. But since path discovery is also important and usually more
desirable, perhaps we should just focus on that.

-Steve

Received: from edelweb.fr (edelweb.fr [212.234.46.16]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA16409 for ; Fri, 12 Jan 2001 11:04:14 -0800 (PST)
Received: from champagne.edelweb.fr (localhost.edelweb.fr [127.0.0.1]) by edelweb.fr with ESMTP id UAA09494; Fri, 12 Jan 2001 20:09:26 +0100 (MET)
Received: from champagne.edelweb.fr (champagne.edelweb.fr [193.51.14.161]) by edelweb.fr (nospam/1.3); Fri, 12 Jan 2001 20:09: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 UAA10310; Fri, 12 Jan 2001 20:09:25 +0100 (MET)
From: Peter Sylvester
Received: (sylvest@localhost) by emeriau.edelweb.fr (8.7.6/8.6.6) id UAA18217; Fri, 12 Jan 2001 20:09:24 +0100 (MET)
Date: Fri, 12 Jan 2001 20:09:24 +0100 (MET)
Message-Id: <[email-masked]>
To: [email-masked], [email-masked]
Subject: RE: DPD & DPV requirements - Recursion Issues

> Whatever is contained in a response, it is left untouched.
>
> [Carlin's latest response] OK, but what if there is no provision in the
> DPD response syntax for including an embedded DPD response? The good news
> is that the timestamp on the embedded DPD response is untouched. The bad
> news is that you can't include an embedded DPD response. Catch vingt-deux.

I am not the best candidate to answer questions about DPD. I am mainly
interested in DPV (as some might imagine).

Anyway, if I understand Mike Myers remark correctly, if a DPD server
is essentially untrusted, then it could basically just rewrite a relayed
response.

A DPD server might have performed an OCSP check or a DPV check (for example
to validate a CA cert.) The response should be sent back to the DPD
client, this can be used by the client to make a decision about the
acceptablity of the path.

Received: from po1.bbn.com (PO1.BBN.COM [192.1.50.38]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA13422 for ; Fri, 12 Jan 2001 10:24:59 -0800 (PST)
Received: from [171.78.30.107] (comsec.bbn.com [171.78.30.107]) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id NAA29116; Fri, 12 Jan 2001 13:30:01 -0500 (EST)
Mime-Version: 1.0
X-Sender: [email-masked]
Message-Id:
In-Reply-To:
References:
Date: Fri, 12 Jan 2001 13:26:08 -0500
To: "Michael Myers"
From: Stephen Kent
Subject: RE: DPD & DPV Basics
Cc: "PKIX List"
Content-Type: text/plain; charset="us-ascii" ; format="flowed"

Mike,

>Steve,
>
> > On Thursday, January 11, 2001, 3:05 PM you wrote:
> >
> > The strawman already calls for a DPD server to perform validation.
>
>While I await WG consensus on the requirements, in Pittsburg the DPD I-D
>authors observed that a DPD server need not be subject to ITSEC/Common
>Criteria/whatever certification due to its untrusted role. Suggesting that
>a DPD server must perform validation seems to refute this objective. A DPD
>client certainly has every reason to expect that the information it receives
>from a DPD server is well structured against the subject certificate. Any
>thoughts on how we can or should balance these two?

There is no conflict here. As the strawman already notes, a DPD
client is PKI-aware and is expected to validate the returned data. so
any failure by the DPD server has no adverse security implications
for the client, other than denial of service. A DPD server is still
untrusted.

Steve

Received: from geos.coastside.net (geos.coastside.net [207.213.212.4]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA13065 for ; Fri, 12 Jan 2001 10:14:24 -0800 (PST)
Received: from heatherdale (dsl-63-194-153-52.coastside.net [63.194.153.52]) by geos.coastside.net (8.11.0/8.11.1) with SMTP id f0CIJXk11165; Fri, 12 Jan 2001 10:19:33 -0800 (PST)
From: "Michael Myers"
To: "Stephen Kent" , "Frank Balluffi"
Cc: "PKIX-List"
Subject: RE: DPD & DPV requirements - Recursion Issues
Date: Fri, 12 Jan 2001 10:23:27 -0800
Message-ID:
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.00.2314.1300
Importance: Normal
In-Reply-To:

Steve,

> On Thursday, January 11, 2001 1:35 PM you wrote
>
> Since we don't trust DPD servers per se, the only issue I see here is
> whether the DPD server to which a request was made can return OCSP
> responses that were gathered by other DPD servers, without making
> that obvious to the client. I'll rely on Ambarish or Mike to answer
> that question, since I don't recall the format details well enough.

Given that OCSP may in the long run wholly replace CRLs in some environments
it does see prudent that the DPD response structure enable this option.

With regard to client notification of a DPD server's response content, note
that BasicOCSPREsponse syntax requires inclusion of ResponderID, either by
name or key hash. Either would enable a client to identify the source(s) of
information accumulated by a DPD server in its interaction with secondary,
tertiary, etc. DPD servers.

Mike

Received: from geos.coastside.net (geos.coastside.net [207.213.212.4]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA12746 for ; Fri, 12 Jan 2001 10:08:10 -0800 (PST)
Received: from heatherdale (dsl-63-194-153-52.coastside.net [63.194.153.52]) by geos.coastside.net (8.11.0/8.11.1) with SMTP id f0CID0k10682; Fri, 12 Jan 2001 10:13:04 -0800 (PST)
From: "Michael Myers"
To: "Stephen Kent" , "Steve Hanna"
Cc: "Frank Balluffi" , "PKIX List"
Subject: RE: DPD & DPV Basics
Date: Fri, 12 Jan 2001 10:16:55 -0800
Message-ID:
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.00.2314.1300
Importance: Normal
In-Reply-To:

Steve,

> On Thursday, January 11, 2001, 3:05 PM you wrote:
>
> The strawman already calls for a DPD server to perform validation.

While I await WG consensus on the requirements, in Pittsburg the DPD I-D
authors observed that a DPD server need not be subject to ITSEC/Common
Criteria/whatever certification due to its untrusted role. Suggesting that
a DPD server must perform validation seems to refute this objective. A DPD
client certainly has every reason to expect that the information it receives
from a DPD server is well structured against the subject certificate. Any
thoughts on how we can or should balance these two?

Mike

Received: from geos.coastside.net (geos.coastside.net [207.213.212.4]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA12419 for ; Fri, 12 Jan 2001 09:59:41 -0800 (PST)
Received: from heatherdale (dsl-63-194-153-52.coastside.net [63.194.153.52]) by geos.coastside.net (8.11.0/8.11.1) with SMTP id f0CI4qk10125; Fri, 12 Jan 2001 10:04:52 -0800 (PST)
From: "Michael Myers"
To: "Steve Hanna" , "PKIX List"
Subject: RE: DPD & DPV Basics
Date: Fri, 12 Jan 2001 10:08:46 -0800
Message-ID:
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.00.2314.1300
Importance: Normal
In-Reply-To: <[email-masked]>

Steve,

> On Thursday, January 11, 2001 12:34 PM you wrote:
>
> The basic job of a DPD server is to discover a certification path. In
> its most basic form, it will perform the following steps:
>
> 1) Receive a request containing a target certificate and inputs to the
> validation algorithm (trust anchors, etc.)
> 2) Attempt to discover a certification path ending in the target
> certificate that will validate properly given the supplied inputs
> 3) Send a response containing the results of the discovery process
> (at least an indication of success or failure and, in the success
> case, the discovered certification path)
>

The current DPD I-D also defines a fourth area of functionality. It enables
a client to iteratively discover a path acceptable to the client in the case
where a given certificate may be subject to multiple valid paths.

Mike

Received: from po1.bbn.com (PO1.BBN.COM [192.1.50.38]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA10928 for ; Fri, 12 Jan 2001 09:24:57 -0800 (PST)
Received: from [171.78.30.107] (comsec.bbn.com [171.78.30.107]) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id MAA20882; Fri, 12 Jan 2001 12:30:03 -0500 (EST)
Mime-Version: 1.0
X-Sender: [email-masked]
Message-Id:
In-Reply-To:
References:
Date: Fri, 12 Jan 2001 12:26:34 -0500
To: "Slone, Skip"
From: Stephen Kent
Subject: RE: DPD & DPV requirements
Cc: PKIX-List
Content-Type: text/plain; charset="us-ascii" ; format="flowed"

Skip,

Thanks for taking the time to supply an example scenario. Your text
was very readable and quite clear.

>Putting the two sides of this equation together and looking at a typical B2B
>scenario, we find the following case in which a relying party in Company A
>needs to validate a Company B path: the RP delegates its request to the DPV
>server residing on Company A's boundary. Company A's DPV server (since it
>doesn't have direct access to Company B's network) will delegate to the DPV
>server residing on Company B's boundary. Company B's DPV server will then
>access the internal resources in Company B's network, perform all the
>necessary discovery and validation work and return the result back upstream.

I agree that the RP in Company A would call the DPV server that
Company A makes available to it and that that DPV server needs to
contact a server at Company B to get the necessary info. However, I
don't agree that the DPV server at Company A would accept a DPV
response from Company B, at least not blindly. Company B really needs
to evaluate the response. It could do that by accessing a DPD server
at Company B, or it could access a DPV server, but insist on getting
back the data that supports the validation assertion by the Company B
DPV server. If so, then what is returned by the DPV server will
contain the same path and revocation status data as an equivalently
formulated DPD response. So, I can see a case for offering only a DPV
service to the outside world, but I might well choose to not accept
just a yes/no response, if I were running a DPV server at another
company. If that's the case, and if have to validate the returned
data, then I could repackage it for return to my client (the RP), and
the fact that there was a call to another DPV server is invisible to
the client.

>As for the need to constrain the number of relays (on further reflection,
>"relay" seems like a better fit than "recursion"), consider the following.
>In the scenario above, there is a need to relay the delegation exactly one
>time. Thus, the RP inside A needs to allow a one-hop relay, but it may wish
>to preclude paths longer than that, in order to prevent getting to Company B
>by first going through Companies X, Y, and Z. On the other hand, it may be
>appropriate for a third party to be involved in the relay (industry
>consortium, bridge, TTP, etc.), which would make it appropriate to be able
>to specify two hops (or some other number as the situation warrants).

In your example, with clients inside of a corporate environment, it
seems more likely that it would be a corporate policy that addresses
the hop count issue, rather than a client parameter. also, I have to
admit that I have a very strong bias here: transitive trust is
generally a bad idea. It's OK for a client to rely on a DPV server in
a corporate environment, and under some circumstances in a public
environment. However, I'm very concerned about encouraging these
servers to rely on other DPV servers, vs. DPD servers. And I'm
especially concerned about the complexity that arises if such
reliance becomes visible to clients, e.g, in terms of nested response
syntax. I don't think the TTP or bridge CA example is a good analogy
here, since any DPV server can do it's own validation on data
returned by a DPD server for any other domain.

Steve

Received: from exchange.cylink.com (exchange.cylink.com [192.43.161.25]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA09075 for ; Fri, 12 Jan 2001 08:55:08 -0800 (PST)
Received: by exchange.cylink.com with Internet Mail Service (5.5.2650.21) id ; Fri, 12 Jan 2001 08:52:22 -0800
Message-ID: <[email-masked]>
From: "Covey, Carlin"
To: [email-masked]
Subject: RE: DPD & DPV requirements - Recursion Issues
Date: Fri, 12 Jan 2001 08:52:21 -0800
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"

Peter,

See indented comment below.

-----Original Message-----
From: Peter Sylvester [mailto:[email-masked]]
Sent: Friday, January 12, 2001 2:58 AM
To: [email-masked]; [email-masked]
Subject: RE: DPD & DPV requirements - Recursion Issues

[from Carlin's previous email]
> As I mentioned in an earlier email, one advantage of the recursive data
> structure is that it allows the optional timestamp on the embedded DPD
> responses to be retained.

[from Peter's response]
Whatever is contained in a response, it is left untouched.

[Carlin's latest response] OK, but what if there is no provision in
the
DPD response syntax for including an embedded DPD response? The good
news
is that the timestamp on the embedded DPD response is untouched. The
bad
news is that you can't include an embedded DPD response. Catch
vingt-deux.

Regards, Carlin

------------------------------
- Carlin Covey
Cylink Corp.

Received: from janus.hosting4u.net (janus.hosting4u.net [209.15.2.37]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id IAA06816 for ; Fri, 12 Jan 2001 08:41:40 -0800 (PST)
Received: (qmail 9902 invoked from network); 12 Jan 2001 16:46:39 -0000
Received: from taurus.hosting4u.net (209.15.2.33) by mail-gate.hosting4u.net with SMTP; 12 Jan 2001 16:46:39 -0000
Received: from nma.com ([63.204.17.82]) by taurus.hosting4u.net ; Fri, 12 Jan 2001 10:46:36 -0600
Message-ID: <[email-masked]>
Date: Fri, 12 Jan 2001 08:46:19 -0800
From: Ed Gerck
X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; I)
X-Accept-Language: en
MIME-Version: 1.0
To: "[email-masked]"
Subject: Election Technology Expo -- Jan 16, 2001
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

List:

Applications of PKI technology and digital certificates will
be present at the Expo. The Expo was announced right before
Christmas by the Secretary of State. The Bell announced
it in the website www.thebell.net and in the December edition.
In case you missed it, the Expo is next week.

The California Secretary of State is sponsoring the Election
Technology Expo. The Expo will be at the Hyatt Regency in
Sacramento, January 16, from 9:00 to 3:00. It opens at 8:00 am
for registration. There will be also a series of panels in
the morning.

For information, contact

Bruce McDannold

Cheers,

Ed Gerck

Received: from exchange.cylink.com (exchange.cylink.com [192.43.161.25]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA06515 for ; Fri, 12 Jan 2001 08:38:23 -0800 (PST)
Received: by exchange.cylink.com with Internet Mail Service (5.5.2650.21) id ; Fri, 12 Jan 2001 08:35:36 -0800
Message-ID: <[email-masked]>
From: "Covey, Carlin"
To: [email-masked]
Subject: RE: DPD & DPV requirements - Recursion Issues
Date: Fri, 12 Jan 2001 08:35:35 -0800
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"

Vishal, Frank, Peter, et. al.

I agree with Vishal that this is a situation that can
appropriately be termed "transitive trust." "A" trusts
the information returned by "B" who trusts the information
returned by "C". I'm not making any claims about whether
this is a good thing or a bad thing. I'm sure the answer
would be different to different people and in different
circumstances. Many human and machine relationships are
built upon transitivity: "Any friend of yours is a friend
of mine." or more negatively, "Any enemy of yours is
a friend of mine."

In this case, one point of view is that the client trusts
server 1 to return a correct answer, and the client doesn't
know or care how server 1 obtained the information upon
which that answer is based.

Another point of view is that the client trusts the server
to not be malicious (e.g., it may be a server run by the
client's company), but the client doesn't trust
the server to not be stupid (the client has dealt with
the server administrator before). So the client may fear
that the server will not chose wisely when selecting other
servers to trust.

My preference is for server 1 to publicize the fact that
it trusts information obtained from certain other servers,
and the client can take that fact into account when deciding
whether to trust server 1.

Regards

Carlin

------------------------------------
- Carlin Covey
Cylink Corp.

-----Original Message-----
From: vishal jakhar [mailto:[email-masked]]
Sent: Friday, January 12, 2001 8:55 AM
To: Peter Sylvester; [email-masked]; [email-masked]
Subject: RE: DPD & DPV requirements - Recursion Issues

Dear Frank and Peter,
To my knowledge the term "Transitive trust" is definately there.
Since a client trusts server 1,any information that comes back from
it is treated as trusted, no matter what other parties are included
in the response. And since I trust server 1 really does not mean
that I should trust server 2,but since server 1 is trusting server 2
It forms a trust chain, in which I am trusting server 2 indirectly.
This indirect trust should be invisible to the client ,so that the
client thinks that he is trusting only the party he trusts.
It is better to repackage the response instead
of using a recursive approach, because the client should be unaware
of the recursion.
regards ,
Vishal .

Received: from sottmxs02.entrust.com (gatekeeper.entrust.com [204.101.128.170]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA27129 for ; Fri, 12 Jan 2001 06:17:04 -0800 (PST)
Received: by sottmxs02.entrust.com with Internet Mail Service (5.5.2650.21) id ; Fri, 12 Jan 2001 09:20:38 -0500
Message-ID:
From: Sharon Boeyen
To: "'Stephen Kent'" , "Slone, Skip"
Cc: [email-masked]
Subject: RE: Basic Cert-2-Directory mapping question
Date: Fri, 12 Jan 2001 09:18:43 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C07CA2.91727F00"

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_01C07CA2.91727F00
Content-Type: text/plain

OK now we're getting to the 'focal' point I was hoping we would.

It seems that we are basically in agreement that both the 'civil attributes'
type of DNs and the domain
component attributes for DNS structured DNs are currently being used and
will likely continue to be used. We also seem to be in agreement that both
are hierarchical name structures. I think it is also fairly safe to say that
the extensions we already have in certificates, combined with the PKI
repository locator service seem adequate for identifying and locating the
PKI repository of interest in most cases for both types of DN structures.
The single exception to this is, as pointed out by Skip, the one where all
the following conditions are met: A relying party needs to obtain an
end-entity certificate for which it does not know the domain name and it
cannot be easily derived from information the relying party does have (and
therefore the PKI repository locator service won't provide the required
information) and the relying party's local environment does not have a
priori knowledge of the remote domain's repository. I guess typically this
would be an environment where there is more than one internediary
certificate in a path because if two domains directly cross-certify with
one-another they would provide repository access information to each other,
otherwise the cross-certification makes no sense.

While I don't disagree with Skip's assertion that the mapping of civil DNs
to DNS names might be useful in the general directory sense, I agree with
Steve that this directory issue is not one that PKIX needs to tackle in
general. However, if the scenario above is one that PKIX needs to find a
solution to (as opposed to determining that its not relevant since Internet
applications will generally have domain names and can therefore use PKI
repository locator service regardless of the DN structures in the certs or
the directory entries), then we have some work to do. Otherwise, we already
have all the tools we need to satisfy the PKI information retrieval problem.

Sharon

-----Original Message-----
From: Stephen Kent [mailto:[email-masked]]
Sent: Thursday, January 11, 2001 4:56 PM
To: Slone, Skip
Cc: [email-masked]
Subject: RE: Basic Cert-2-Directory mapping question

Skip,

I would just like to add that, in addition to X.521 and some LDAP specs, the
ability to recognize civil naming attributes in the issuer and subject
fields of an X.509v3 cert is mandated in RFC 2459 (ref section 4.1.2.4) and
in son-of-2459.

Ironically, the requirement for support for Issuer names (DNs) vs. allowing
an Issuer alname in lieu of a DN, arose because the S/MIME WG was relying on
the presence of an Issuer DN in their design, and I believe the motivation
for it (Russ can confirm or correct this notion) was to facilitate directory
lookup for certs in S/MIME!

Steve

------_=_NextPart_001_01C07CA2.91727F00
Content-Type: text/html

OK now
we're getting to the 'focal' point I was hoping we would.

It
seems that we are basically in agreement that both the 'civil attributes' type
of DNs and the domain

component attributes for
DNS structured DNs are currently being used and will likely continue to be used.
We also seem to be in agreement that both are hierarchical name structures. I
think it is also fairly safe to say that the extensions we already have in
certificates, combined with the PKI repository locator service seem adequate for
identifying and locating the PKI repository of interest in most cases for
both types of DN structures. The single exception to this is, as pointed
out by Skip, the one where all the following conditions are met: A relying
party needs to obtain an end-entity certificate for which it does not know the
domain name and it cannot be easily derived from information the
relying party does have (and therefore the PKI repository locator
service won't provide the required information) and the relying party's local
environment does not have a priori knowledge of the remote domain's repository.
I guess typically this would be an environment where there is more than one
internediary certificate in a path because if two domains directly cross-certify
with one-another they would provide repository access information to each
other, otherwise the cross-certification makes no
sense.

While I don't disagree with Skip's assertion that the
mapping of civil DNs to DNS names might be useful in the general directory
sense, I agree with Steve that this directory issue is not one that PKIX needs
to tackle in general. However, if the scenario above is one that PKIX needs to
find a solution to (as opposed to determining that its not relevant since
Internet applications will generally have domain names and can therefore use PKI
repository locator service regardless of the DN structures in the certs or the
directory entries), then we have some work to do. Otherwise, we already have all
the tools we need to satisfy the PKI information retrieval
problem.

Sharon

-----Original Message-----
From:
Stephen Kent [mailto:[email-masked]]
Sent: Thursday, January 11, 2001
4:56 PM
To: Slone, Skip
Cc:
[email-masked]
Subject: RE: Basic Cert-2-Directory mapping
question

Skip,

I would just like to add that, in addition
to X.521 and some LDAP specs, the ability to recognize civil naming attributes
in the issuer and subject fields of an X.509v3 cert is mandated in RFC 2459
(ref section 4.1.2.4) and in son-of-2459.

Ironically, the requirement for support for Issuer names (DNs) vs. allowing
an Issuer alname in lieu of a DN, arose because the S/MIME WG was relying on
the presence of an Issuer DN in their design, and I believe the motivation for
it (Russ can confirm or correct this notion) was to facilitate directory
lookup for certs in S/MIME!

<snip>

Steve

------_=_NextPart_001_01C07CA2.91727F00--

Received: from mail.crs4.it (michelle.crs4.it [156.148.1.33]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id FAA25096 for ; Fri, 12 Jan 2001 05:38:07 -0800 (PST)
Received: from yoda (yoda.crs4.it [156.148.2.94]) by mail.crs4.it (Postfix) with SMTP id 6967510D2 for ; Fri, 12 Jan 2001 14:51:22 +0100 (MET)
Message-ID: <004f01c07c9e$4a23efc0$5e02949c@yoda>
From: "Andrea Piras"
To:
Subject: Certificate with ECDSA public key
Date: Fri, 12 Jan 2001 14:48:04 +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

Hi,
reading the RFC 2549, I saw that it's possible to certificate with the X509,
the public key derived from RSA, DSA and Diffie-Hellman algorithms.
And about the ECDSA public key? Do any drafts or standards exist about to
certificate ECDSA public key?
I don't find information on my question but I started to study certification
and cryptography few months ago.
Please, help me.
Thanks.

Andrea Piras

---------------------------------------
Andrea Piras
e-mail: [email-masked]
Junior Software Engineer - NDA Area
CRS4 - Center for Advanced Studies, Research and Development in Sardinia -
www.crs4.it

Received: from ietf.org (odin.ietf.org [132.151.1.176]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id EAA19559 for ; Fri, 12 Jan 2001 04:15:53 -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 HAA07358; Fri, 12 Jan 2001 07:21:04 -0500 (EST)
Message-Id: <[email-masked]>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-pkix-usergroup-00.txt
Date: Fri, 12 Jan 2001 07:21:04 -0500
Sender: [email-masked]

--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 : The PKIX UserGroupName GeneralName Type
Author(s) : M. StJohns
Filename : draft-ietf-pkix-usergroup-00.txt
Pages : 11
Date : 11-Jan-01

A number of systems which understand X.509 client certificates have
developed various ad-hoc mechanisms to map a certificate to a
userid/group value which can then be used for access control. The
mechanisms include peculiar name forms for the SubjectName field
such as encoding the userid as a CommonName and the group as an
OrganizationalUnit, or mapping the certificate against an entry in a
directory system. This document descibes an otherName extension of
the GeneralName type which can be used in the SubjectAltName
extension or IssuerAltName extension to directly encode userid and
group information.

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

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-ietf-pkix-usergroup-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:
[email-masked].
In the body type:
"FILE /internet-drafts/draft-ietf-pkix-usergroup-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="[email-masked]"

Content-Type: text/plain
Content-ID: <[email-masked]>

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

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

Content-Type: text/plain
Content-ID: <[email-masked]>

--OtherAccess--

--NextPart--

Received: from ngate.noida.hclt.com (IDENT:root@[204.160.254.4]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id CAA10817 for ; Fri, 12 Jan 2001 02:23:26 -0800 (PST)
Received: from titanium.noida.hclt.com (IDENT:root@titanium [204.160.252.2]) by ngate.noida.hclt.com (8.9.3/8.9.3) with ESMTP id PAA27839; Fri, 12 Jan 2001 15:56:51 +0530
Received: from vjakhar ([204.160.252.77]) by titanium.noida.hclt.com (8.9.3/8.9.3) with SMTP id QAA04597; Fri, 12 Jan 2001 16:04:15 +0530
From: "vishal jakhar"
To: "Peter Sylvester" , ,
Subject: RE: DPD & DPV requirements - Recursion Issues
Date: Fri, 12 Jan 2001 21:25:29 +0530
Message-ID:
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.00.2314.1300
Importance: Normal
In-Reply-To: <[email-masked]>

Dear Frank and Peter,
To my knowledge the term "Transitive trust" is definately there.
Since a client trusts server 1,any information that comes back from
it is treated as trusted, no matter what other parties are included
in the response. And since I trust server 1 really does not mean
that I should trust server 2,but since server 1 is trusting server 2
It forms a trust chain, in which I am trusting server 2 indirectly.
This indirect trust should be invisible to the client ,so that the
client thinks that he is trusting only the party he trusts.
It is better to repackage the response instead
of using a recursive approach, because the client should be unaware
of the recursion.
regards ,
Vishal .

-----Original Message-----
From: Peter Sylvester [mailto:[email-masked]]
Sent: Friday, January 12, 2001 3:28 PM
To: [email-masked]; [email-masked]
Subject: RE: DPD & DPV requirements - Recursion Issues

>
> Frank and Peter,
>
> I'd be happy for someone to define a set of terms for use in this
> context, if it would benefit the discussion.
Yes.

>
> The "transitive trust" issue that was referred to earlier arises in
> the context of "relaying" DPV status. The client asks server 1 to
> validate the status of a certificate, and server 1 "relays" some or
> all of the validation process to server 2. When the response comes
> back from server 2, server 1 then prepares a response to the client
> based wholly or in part on the information obtained from server 2.

Where do you have "transitive trust"? Client trusts server 1, and that's
all. Client may inspect server 1 response in order to inform its "client"
that server 1 came to whatever conclusion because he has reveived
an answer from 2, but that doen not mean that client has to trust server 2.

>
> When I originally used the term "recursion" I had in mind a recursive
> data structure, i.e. a DPD response that contains another DPD
> response that might in turn contain another DPD response. This is one
> method for returning the "relayed" status information to the client.

> This particular method raises the syntactic complexity issue that
> was mentioned in a previous email. This syntactic complexity is avoided
> if server 1 extracts information from server 2's response and repackages
> it into a nonrecursive data structure that it then sends to the client.

I have in mind that the server 1 always creates a new answer. This answer
is authoritive. As an additional information, OCSP responses, other servers
responses are added. A client does not need to look at them in order to
do this business.

> As I mentioned in an earlier email, one advantage of the recursive data
> structure is that it allows the optional timestamp on the embedded DPD
> responses to be retained.

Whatever is contained in a response, it is left untouched.

regards
peter

Received: from edelweb.fr (edelweb.fr [212.234.46.16]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id BAA08736 for ; Fri, 12 Jan 2001 01:52:46 -0800 (PST)
Received: from champagne.edelweb.fr (localhost.edelweb.fr [127.0.0.1]) by edelweb.fr with ESMTP id KAA05643; Fri, 12 Jan 2001 10:57:57 +0100 (MET)
Received: from champagne.edelweb.fr (champagne.edelweb.fr [193.51.14.161]) by edelweb.fr (nospam/1.3); Fri, 12 Jan 2001 10:57: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 KAA08595; Fri, 12 Jan 2001 10:57:55 +0100 (MET)
From: Peter Sylvester
Received: (sylvest@localhost) by emeriau.edelweb.fr (8.7.6/8.6.6) id KAA18105; Fri, 12 Jan 2001 10:57:54 +0100 (MET)
Date: Fri, 12 Jan 2001 10:57:54 +0100 (MET)
Message-Id: <[email-masked]>
To: [email-masked], [email-masked]
Subject: RE: DPD & DPV requirements - Recursion Issues

>
> Frank and Peter,
>
> I'd be happy for someone to define a set of terms for use in this
> context, if it would benefit the discussion.
Yes.

>
> The "transitive trust" issue that was referred to earlier arises in
> the context of "relaying" DPV status. The client asks server 1 to
> validate the status of a certificate, and server 1 "relays" some or
> all of the validation process to server 2. When the response comes
> back from server 2, server 1 then prepares a response to the client
> based wholly or in part on the information obtained from server 2.

Where do you have "transitive trust"? Client trusts server 1, and that's
all. Client may inspect server 1 response in order to inform its "client"
that server 1 came to whatever conclusion because he has reveived
an answer from 2, but that doen not mean that client has to trust server 2.

>
> When I originally used the term "recursion" I had in mind a recursive
> data structure, i.e. a DPD response that contains another DPD
> response that might in turn contain another DPD response. This is one
> method for returning the "relayed" status information to the client.

> This particular method raises the syntactic complexity issue that
> was mentioned in a previous email. This syntactic complexity is avoided
> if server 1 extracts information from server 2's response and repackages
> it into a nonrecursive data structure that it then sends to the client.

I have in mind that the server 1 always creates a new answer. This answer
is authoritive. As an additional information, OCSP responses, other servers
responses are added. A client does not need to look at them in order to
do this business.

> As I mentioned in an earlier email, one advantage of the recursive data
> structure is that it allows the optional timestamp on the embedded DPD
> responses to be retained.

Whatever is contained in a response, it is left untouched.

regards
peter

Received: from ext-mail.valicert.com (ns1.valicert.com [63.65.221.10]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id UAA11073 for ; Thu, 11 Jan 2001 20:44:31 -0800 (PST)
Received: from CONVERSION-DAEMON by ext-mail.valicert.com (PMDF V5.2-33 #46613) id <[email-masked]> for [email-masked]; Thu, 11 Jan 2001 20:49:42 -0800 (PST)
Received: from polaris.valicert.com ([192.168.2.34]) by ext-mail.valicert.com (PMDF V5.2-33 #46613) with ESMTP id <[email-masked]>; Thu, 11 Jan 2001 20:49:41 -0800 (PST)
Received: by exchange.valicert.com with Internet Mail Service (5.5.2650.21) id ; Thu, 11 Jan 2001 20:45:37 -0800
Content-return: allowed
Date: Thu, 11 Jan 2001 20:45:36 -0800
From: Frank Balluffi
Subject: RE: DPD & DPV requirements
To: Stephen Kent
Cc: [email-masked]
Message-id: <[email-masked]>
MIME-version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-type: text/plain; charset="iso-8859-1"

Frank Balluffi said:

> >The client should supply some subset of each requested path
> which must
> >include the least significant certificate and optionally:
> >
> >- one or more intermediate certificates
> >- one or more trusted certificates

Steve Kent said:

> An intermediate cert that is not trusted, but is not the end of a
> partial path? Why? This is getting complicated.

OK. It is difficult for me to imagine a client supplying intermediate
certificates. But requirement 1.1 only supports a single certificate or a
chain:

1.1 A client request can contain a single certificate or a certificate
chain terminating in the "target" certificate, to assist the server in path
construction.

Would it be valuable for a client to be able to supply the end-entity
certificate and the trusted certificate in the path?

Frank

Received: from exchange.cylink.com (exchange.cylink.com [192.43.161.25]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA06748 for ; Thu, 11 Jan 2001 15:33:19 -0800 (PST)
Received: by exchange.cylink.com with Internet Mail Service (5.5.2650.21) id ; Thu, 11 Jan 2001 15:30:28 -0800
Message-ID: <[email-masked]>
From: "Covey, Carlin"
To: PKIX List
Subject: RE: DPD & DPV Basics
Date: Thu, 11 Jan 2001 15:30:28 -0800
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"

I agree with you Steve.

- Carlin

-----Original Message-----
From: Stephen Kent [mailto:[email-masked]]
Sent: Thursday, January 11, 2001 4:22 PM
To: Covey, Carlin
Cc: PKIX List
Subject: RE: DPD & DPV Basics

Carlin,

The examples you cite of benefits from having cert chains returned by
a DPD server, even if not strictly valid, are examples of the R&D
problem area I alluded to in earlier messages. I don't think we have
a good set of parameters to express the "not quite valid, but maybe
close enough to be useful" notion you are describing. We would need
a specific set to be part of the spec, else we will not be able to
have a good spec for server operation, nor for client control of
server operation. So, I'd discourage heading down this path uless we
have such a set of parameters, and Wg agreement on their desirability
and completeness.

Steve

Received: from po1.bbn.com (PO1.BBN.COM [192.1.50.38]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA06158 for ; Thu, 11 Jan 2001 15:17:59 -0800 (PST)
Received: from [171.78.30.107] (comsec.bbn.com [171.78.30.107]) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id SAA10612; Thu, 11 Jan 2001 18:23:04 -0500 (EST)
Mime-Version: 1.0
X-Sender: [email-masked]
Message-Id:
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Date: Thu, 11 Jan 2001 18:22:12 -0500
To: "Covey, Carlin"
From: Stephen Kent
Subject: RE: DPD & DPV Basics
Cc: PKIX List
Content-Type: text/plain; charset="us-ascii" ; format="flowed"

Carlin,

The examples you cite of benefits from having cert chains returned by
a DPD server, even if not strictly valid, are examples of the R&D
problem area I alluded to in earlier messages. I don't think we have
a good set of parameters to express the "not quite valid, but maybe
close enough to be useful" notion you are describing. We would need
a specific set to be part of the spec, else we will not be able to
have a good spec for server operation, nor for client control of
server operation. So, I'd discourage heading down this path uless we
have such a set of parameters, and Wg agreement on their desirability
and completeness.

Steve

Received: from po1.bbn.com (PO1.BBN.COM [192.1.50.38]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA06126 for ; Thu, 11 Jan 2001 15:17:54 -0800 (PST)
Received: from [171.78.30.107] (comsec.bbn.com [171.78.30.107]) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id SAA10601; Thu, 11 Jan 2001 18:22:56 -0500 (EST)
Mime-Version: 1.0
X-Sender: [email-masked]
Message-Id:
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Date: Thu, 11 Jan 2001 18:17:51 -0500
To: Steve Hanna
From: Stephen Kent
Subject: Re: DPD & DPV Basics
Cc: PKIX List
Content-Type: text/plain; charset="us-ascii" ; format="flowed"

Steve,

>It seems that at least some members of the working group have not yet
>agreed upon certain basic concepts. Perhaps it would be useful for me to
>articulate these concepts so that they can be discussed separately from
>the detailed requirements supplied by Steve. Discussion of those
>detailed requirements can proceed simultaneously, but it would be good
>if we could reach agreement on these basic concepts or at least
>understand why we don't agree on them. I suspect that we already have
>rough consensus on these concepts, but it would be good to get any
>debate on them out into the open so that we can understand the technical
>foundations from which that debate arises.
>
>Here's my take on the basic concepts of DPD and DPV:
>
>The basic job of a DPV server is to validate a certification path. In
>its most basic form, it will perform the following steps:
>
>1) Receive a request containing a certification path and other inputs
> to the validation algorithm (trust anchors, required certificate
> policies, etc.)
>2) Validate the supplied certification path using the supplied inputs
>3) Send a response containing the results of the validation (at least,
> an indication of success or failure)
>
>Many refinements to this are possible: the client supplying only a
>subset of the necessary inputs (by referring to an established policy),
>the server returning supporting evidence such as CRLs and OCSP
>responses, the client supplying CRLs or OCSP responses that may be
>useful to the server, etc. But I think it may be useful to reach
>agreement on the basic model described above before discussing these
>refinements (however worthy).

I think the "refinement" re completeness of input is a basic issue,
not just a refinement. Also, the control inputs (non-cert and
non-revocation status data) for validation may be explicit or
references. I think the strawman motivated the need for both forms of
specification, based on client capabilities, and the desire for
centralized control of validation in some environments. Also, the
need for the DPV server to return data that supports NR seems like an
important feature, for some set of apps, though not all.

>The basic job of a DPD server is to discover a certification path. In
>its most basic form, it will perform the following steps:
>
>1) Receive a request containing a target certificate and inputs to the
> validation algorithm (trust anchors, etc.)
>2) Attempt to discover a certification path ending in the target
> certificate that will validate properly given the supplied inputs
>3) Send a response containing the results of the discovery process
> (at least an indication of success or failure and, in the success
> case, the discovered certification path)
>
>Most of the refinements listed above with respect to the DPV server can
>also be applied to the DPD server. In addition, other refinements might
>include having the client supply additional certificates that may be
>useful to the server (such as certificates received with an S/MIME email
>message).
>
>I look forward to seeing a discussion on this topic. If no discussion
>results, I suppose that I will conclude that there is general agreement
>about these basic concepts. However, simple affirmative messages
>agreeing with these basic concepts would be useful in judging rough
>consensus.

I agree with the basic notions here, as qualified above.

Steve

Received: from po1.bbn.com (PO1.BBN.COM [192.1.50.38]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA04844 for ; Thu, 11 Jan 2001 15:08:24 -0800 (PST)
Received: from [171.78.30.107] (comsec.bbn.com [171.78.30.107]) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id SAA10039; Thu, 11 Jan 2001 18:13:30 -0500 (EST)
Mime-Version: 1.0
X-Sender: [email-masked]
Message-Id:
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]>
Date: Thu, 11 Jan 2001 18:04:43 -0500
To: Steve Hanna
From: Stephen Kent
Subject: Re: DPD & DPV Basics
Cc: Frank Balluffi , PKIX List
Content-Type: text/plain; charset="us-ascii" ; format="flowed"

Steve,

>Frank Balluffi wrote:
> > 1. Can someone explain the value of a DPD server returning a path that may
> > not be valid? I would argue that path discovery should be an optional
> > internal operation performed by a DPV server. I say this as someone who has
> > implemented support for SCVP draft 4's path building types of check. To me
> > the operation should be implicit.
>
>I agree that there's not much utility in having a DPD server return an
>invalid (or unvalidated) path. However, I don't agree that path
>discovery should be part of a DPV server's job. Instead, I would argue
>that validation should be part of a DPD server's job.

The strawman already calls for a DPD server to perform validation.
You're suggesting that a DPV server should not have to perform
discovery. That would imply that either:
(1) the client passed in a complete path, and matching
revocation status data,
(2) the client called the DPD server first, then passed on
the result to the DPV server
(3) or that a DPV server called a DPD server in support of discovery.

What simplifications to the overall architecture arise if we split
responsibility this way? Certainly if we expect one server to do
both, i.e., to have DPV piggyback on DPD but with slightly different
interfaces, this isn't all that helpful. I'm not rejecting this
approach, but I want to understand it's benefits in more detail.

>My team has also implemented path discovery and validation (although not
>yet delegated discovery and validation). Validation is a fairly simple
>matter of running the PKIX validation algorithm using certain
>parameters. Discovery is *much* more complicated, involving heuristics
>for guessing which certificates might lead to the target certificate (or
>to the trust anchor, if building forward), partial validation to
>discover when a partial path is futile, and loop detection. I would
>argue that DPD is substantially harder than DPV and DPV is often
>sufficient. So it is definitely worthwhile to define DPV as a separate
>operation. Many servers may only want to support that operation.

No argument that discovery is harder, and it subsumes validation.
But, what is the basis for arguing that validation, based on
supplying complete cert chains and revocation status data, will be
the more common case and thus we should optimize for it? Several
protocols allow for transmission of certs and CRLs, but some allow
transmission only for certs, perhaps because that it static data that
is easier to configure into the client.

Steve

Received: from exchange.cylink.com (exchange.cylink.com [192.43.161.25]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA04105 for ; Thu, 11 Jan 2001 14:58:34 -0800 (PST)
Received: by exchange.cylink.com with Internet Mail Service (5.5.2650.21) id ; Thu, 11 Jan 2001 14:55:46 -0800
Message-ID: <[email-masked]>
From: "Covey, Carlin"
To: PKIX List
Subject: RE: DPD & DPV Basics
Date: Thu, 11 Jan 2001 14:55:46 -0800
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"

Frank,

See comments below.

-----Original Message-----
From: Frank Balluffi [mailto:[email-masked]]
Sent: Thursday, January 11, 2001 2:31 PM
To: 'Steve Hanna'; PKIX List
Subject: RE: DPD & DPV Basics

1. Can someone explain the value of a DPD server returning a path that may
not be valid?

[Carlin]
I agree that returning a path that may not be valid would not be the normal
case.
However, I can think of some circumstances in which it would be useful.

The returned certificate path might include a certificate that has expired,
or which is currently suspended. The DPD client may be willing to accept
such an invalid chain for certain purposes.

Another case is a valid chain that traces to a root that is not one of the
client's trust anchors. The DPD client might be willing to add that root to

its set of trust anchors.

A third case is a chain that the DPD client can validate, but the DPD server
cannot.
(For instance, the client may be able validate a certificate signed with
ECDSA,
whereas the server may have no means to do so.)

Regards,

Carlin

--------------------------------------
- Carlin Covey
Cylink Corp.

Received: from exchange.cylink.com (exchange.cylink.com [192.43.161.25]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA03473 for ; Thu, 11 Jan 2001 14:37:21 -0800 (PST)
Received: by exchange.cylink.com with Internet Mail Service (5.5.2650.21) id ; Thu, 11 Jan 2001 14:34:33 -0800
Message-ID: <[email-masked]>
From: "Covey, Carlin"
To: PKIX List
Subject: RE: DPD & DPV Basics
Date: Thu, 11 Jan 2001 14:34:32 -0800
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"

Steve Hanna,

Your take on the basic concepts of DPV and DPD services matches mine.
I think a bit of confusion was introduced during discussions of how
those services should be mapped to protocols. There was a suggestion
that a DPV-service protocol might also return a chain of evidence
supporting the validation status - thus providing a kind of DPD service
within the same protocol. It has also been observed that there is no point
in returning invalid (or unvalidated) paths in a DPD response -- thus
implying a sort of DPV service as part of the DPD protocol. I suppose
the distinguishing characteristic is whether or not the client trusts the
response, or will perform its own validation. This is out of the scope
of the protocol itself, unless we want to build in mechanisms for the client
to impose constraints on the path construction and validation process.

Regards,

Carlin

---------------------------------
- Carlin Covey
Cylink Corp.

-----Original Message-----
From: Steve Hanna [mailto:[email-masked]]
Sent: Thursday, January 11, 2001 1:34 PM
To: PKIX List
Subject: DPD & DPV Basics

It seems that at least some members of the working group have not yet
agreed upon certain basic concepts. Perhaps it would be useful for me to
articulate these concepts so that they can be discussed separately from
the detailed requirements supplied by Steve. Discussion of those
detailed requirements can proceed simultaneously, but it would be good
if we could reach agreement on these basic concepts or at least
understand why we don't agree on them. I suspect that we already have
rough consensus on these concepts, but it would be good to get any
debate on them out into the open so that we can understand the technical
foundations from which that debate arises.

Here's my take on the basic concepts of DPD and DPV:

The basic job of a DPV server is to validate a certification path. In
its most basic form, it will perform the following steps:

1) Receive a request containing a certification path and other inputs
to the validation algorithm (trust anchors, required certificate
policies, etc.)
2) Validate the supplied certification path using the supplied inputs
3) Send a response containing the results of the validation (at least,
an indication of success or failure)

Many refinements to this are possible: the client supplying only a
subset of the necessary inputs (by referring to an established policy),
the server returning supporting evidence such as CRLs and OCSP
responses, the client supplying CRLs or OCSP responses that may be
useful to the server, etc. But I think it may be useful to reach
agreement on the basic model described above before discussing these
refinements (however worthy).

The basic job of a DPD server is to discover a certification path. In
its most basic form, it will perform the following steps:

1) Receive a request containing a target certificate and inputs to the
validation algorithm (trust anchors, etc.)
2) Attempt to discover a certification path ending in the target
certificate that will validate properly given the supplied inputs
3) Send a response containing the results of the discovery process
(at least an indication of success or failure and, in the success
case, the discovered certification path)

Most of the refinements listed above with respect to the DPV server can
also be applied to the DPD server. In addition, other refinements might
include having the client supply additional certificates that may be
useful to the server (such as certificates received with an S/MIME email
message).

I look forward to seeing a discussion on this topic. If no discussion
results, I suppose that I will conclude that there is general agreement
about these basic concepts. However, simple affirmative messages
agreeing with these basic concepts would be useful in judging rough
consensus.

Thanks,

Steve

P.S. Due to the short timeline, I will submit more detailed comments on
Steve's requirements soon.

Received: from exchange.cylink.com (exchange.cylink.com [192.43.161.25]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA02769 for ; Thu, 11 Jan 2001 14:10:34 -0800 (PST)
Received: by exchange.cylink.com with Internet Mail Service (5.5.2650.21) id ; Thu, 11 Jan 2001 14:07:46 -0800
Message-ID: <[email-masked]>
From: "Covey, Carlin"
To: "'Stephen Kent'" , Peter Sylvester
Cc: [email-masked]
Subject: RE: DPD & DPV requirements - Let us Recurse
Date: Thu, 11 Jan 2001 14:07:45 -0800
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"

Peter,

I second Steve's thank you. But I question Steve's use of "IF"
in his reply below. Didn't a previous email mention that a DPV
server might make use of another DPV server without any evidence of
this in the response? (This was made in the context of a discussion of
transitive trust.) Does your use of "IF" here imply that outlawing such
"relays" from one DPV (or DPD) server to another might be a legitimate
way to manage the loop problem?

Regards,

Carlin

-------------------------------
- Carlin Covey
Cylink Corp.

-----Original Message-----
From: Stephen Kent [mailto:[email-masked]]
Sent: Thursday, January 11, 2001 2:37 PM
To: Peter Sylvester
Cc: [email-masked]
Subject: RE: DPD & DPV requirements - Let us Recurse

Peter,

Thanks for pointing out the loop detection requirement that needs to
be part of the protocol IF we allow these servers to call one another.

Steve

Received: from ns.celocom.se ([email-masked] [212.209.40.66]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA02377 for ; Thu, 11 Jan 2001 14:07:27 -0800 (PST)
Received: by ns.celocom.se; id XAA13559; Thu, 11 Jan 2001 23:12:35 +0100 (CET)
Received: from unknown(10.10.10.1) by ns.celocom.se via smap (V5.0) id xma013531; Thu, 11 Jan 01 23:11:35 +0100
Received: from oscar (root@localhost [127.0.0.1]) by zap.celocom.se (8.8.7/8.8.7) with SMTP id XAA05912; Thu, 11 Jan 2001 23:11:33 +0100
From: "Oscar Jacobsson"
To: "Slone, Skip"
Cc: "'Sharon Boeyen'" ,
Subject: RE: Basic Cert-2-Directory mapping question
Date: Thu, 11 Jan 2001 23:16:05 +0100
Message-ID:
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
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:
Importance: Normal
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id OAA02378

> From: Slone, Skip [mailto:[email-masked]]
> In response to this, I'm inclined to join Sharon on Marshall's soapbox and
> echo her words:
>
> "... I believe a more constructive approach is to accept the fact that
> different parts of the world and different environments will use a variety
> of nameforms ... We are not the global naming police either and should not
> try to impose the rules that anyone uses to name entities to which they
> issue certificates."

I'm sorry if I came across as clamouring for rules be imposed. I know that this working group has a tendency to be wary of suggestions that don't cater for distinguished names containing cat MPEGs, so I should probably have been more careful. The requirements I suggested were for a possible naming standards document, conformance to which need not be enforced.

The case at hand is not, IMHO, one of dictating that "all distinguished names must be according to our will, or you shall feel our wrath". A document however, outlining a naming strategy that would require of the users of certificates named accordingly no a-priori knowledge of their issuer (save for eventually having to reach something explicitly trusted in the chain) in order to perform path validation, is something I would personally consider very valuable indeed. I'm reasonably confident that organizations intending to act as certification authorities or trusted third parties would agree.

> And to quote someone Sharon and I both know, "If all you have is a hammer,
> every problem looks like a nail."

It seems I was less than clear here as well. :-(

My intention was to point out that there are actually two separate problems here (one nail, if you will, and one screw) each looking for its own solution:

1. Defining a repository, and subsequently entry, discovery process for arbitrarily named entries.

2. Defining a naming scheme that _if applied_ would automate this repository and entry discovery process.

I am only trying to address the second of these problems. The first is only an issue because nobody seems to have properly addressed the second before deploying certificates on the Internet en masse. The further we wait before addressing number two, the more of a problem number one will become.

I should probably make a habit of pointing out that the opinions stated here are my very own, and not necessarily those of my employer.

Cheers,

//oscar

Received: from po1.bbn.com (PO1.BBN.COM [192.1.50.38]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA01600 for ; Thu, 11 Jan 2001 13:58:01 -0800 (PST)
Received: from [171.78.30.107] (comsec.bbn.com [171.78.30.107]) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id RAA03923; Thu, 11 Jan 2001 17:03:04 -0500 (EST)
Mime-Version: 1.0
X-Sender: [email-masked]
Message-Id:
In-Reply-To:
References:
Date: Thu, 11 Jan 2001 16:55:31 -0500
To: "Slone, Skip"
From: Stephen Kent
Subject: RE: Basic Cert-2-Directory mapping question
Cc: [email-masked]
Content-Type: multipart/alternative; boundary="============_-1232871834==_ma============"

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

Skip,

>I would just like to add that, in addition to X.521 and some LDAP
>specs, the ability to recognize civil naming attributes in the
>issuer and subject fields of an X.509v3 cert is mandated in RFC 2459
>(ref section 4.1.2.4) and in son-of-2459.

Ironically, the requirement for support for Issuer names (DNs) vs.
allowing an Issuer alname in lieu of a DN, arose because the S/MIME
WG was relying on the presence of an Issuer DN in their design, and I
believe the motivation for it (Russ can confirm or correct this
notion) was to facilitate directory lookup for certs in S/MIME!

Steve

--============_-1232871834==_ma============
Content-Type: text/enriched; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Skip,

Arial0000,0000,FFFFI
would just like to add that, in addition to X.521 and some LDAP specs,
the ability to recognize civil naming attributes in the issuer and
subject fields of an X.509v3 cert is mandated in RFC 2459 (ref section
4.1.2.4) and in son-of-2459.=20

Arial0000,0000,FFFF

Ironically, the requirement for support for Issuer
names (DNs) vs. allowing an Issuer alname in lieu of a DN, arose
because the S/MIME WG was relying on the presence of an Issuer DN in
their design, and I believe the motivation for it (Russ can confirm or
correct this notion) was to facilitate directory lookup for certs in
S/MIME!

right,left<

Steve

--============_-1232871834==_ma============--

Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA01436 for ; Thu, 11 Jan 2001 13:57:19 -0800 (PST)
Received: from eastmail2.East.Sun.COM ([129.148.1.241]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id OAA09769; Thu, 11 Jan 2001 14:02:27 -0800 (PST)
Received: from sunlabs.East.Sun.COM (sunlabs.East.Sun.COM [129.148.75.250]) by eastmail2.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id RAA12756; Thu, 11 Jan 2001 17:02:26 -0500 (EST)
Received: from sun.com (dhcp75-155 [129.148.75.155]) by sunlabs.East.Sun.COM (8.9.3+Sun/8.9.1) with ESMTP id RAA01457; Thu, 11 Jan 2001 17:01:40 -0500 (EST)
Message-ID: <[email-masked]>
Date: Thu, 11 Jan 2001 16:59:35 -0500
From: Steve Hanna
Organization: Sun Microsystems, Inc.
X-Mailer: Mozilla 4.75 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Frank Balluffi
CC: PKIX List
Subject: Re: DPD & DPV Basics
References: <[email-masked]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Frank Balluffi wrote:
> 1. Can someone explain the value of a DPD server returning a path that may
> not be valid? I would argue that path discovery should be an optional
> internal operation performed by a DPV server. I say this as someone who has
> implemented support for SCVP draft 4's path building types of check. To me
> the operation should be implicit.

I agree that there's not much utility in having a DPD server return an
invalid (or unvalidated) path. However, I don't agree that path
discovery should be part of a DPV server's job. Instead, I would argue
that validation should be part of a DPD server's job.

My team has also implemented path discovery and validation (although not
yet delegated discovery and validation). Validation is a fairly simple
matter of running the PKIX validation algorithm using certain
parameters. Discovery is *much* more complicated, involving heuristics
for guessing which certificates might lead to the target certificate (or
to the trust anchor, if building forward), partial validation to
discover when a partial path is futile, and loop detection. I would
argue that DPD is substantially harder than DPV and DPV is often
sufficient. So it is definitely worthwhile to define DPV as a separate
operation. Many servers may only want to support that operation.

> 2. I would like to see the option of passing certificates and other input
> (e.g., CRLs) by reference for use by PKI-unaware (e.g., XML-enabled)
> applications.

I think this item really belongs in the discussion of Steve's detailed
requirements. It doesn't pertain to reaching agreement on the basic
concepts. It's definitely a good point to discuss, just not in this
thread.

Thanks,

Steve

>
> Frank
>
> > -----Original Message-----
> > From: Steve Hanna [mailto:[email-masked]]
> > Sent: Thursday, January 11, 2001 3:34 PM
> > To: PKIX List
> > Subject: DPD & DPV Basics
> >
> >
> > It seems that at least some members of the working group have not yet
> > agreed upon certain basic concepts. Perhaps it would be
> > useful for me to
> > articulate these concepts so that they can be discussed
> > separately from
> > the detailed requirements supplied by Steve. Discussion of those
> > detailed requirements can proceed simultaneously, but it would be good
> > if we could reach agreement on these basic concepts or at least
> > understand why we don't agree on them. I suspect that we already have
> > rough consensus on these concepts, but it would be good to get any
> > debate on them out into the open so that we can understand
> > the technical
> > foundations from which that debate arises.
> >
> > Here's my take on the basic concepts of DPD and DPV:
> >
> > The basic job of a DPV server is to validate a certification path. In
> > its most basic form, it will perform the following steps:
> >
> > 1) Receive a request containing a certification path and other inputs
> > to the validation algorithm (trust anchors, required certificate
> > policies, etc.)
> > 2) Validate the supplied certification path using the supplied inputs
> > 3) Send a response containing the results of the validation (at least,
> > an indication of success or failure)
> >
> > Many refinements to this are possible: the client supplying only a
> > subset of the necessary inputs (by referring to an
> > established policy),
> > the server returning supporting evidence such as CRLs and OCSP
> > responses, the client supplying CRLs or OCSP responses that may be
> > useful to the server, etc. But I think it may be useful to reach
> > agreement on the basic model described above before discussing these
> > refinements (however worthy).
> >
> > The basic job of a DPD server is to discover a certification path. In
> > its most basic form, it will perform the following steps:
> >
> > 1) Receive a request containing a target certificate and inputs to the
> > validation algorithm (trust anchors, etc.)
> > 2) Attempt to discover a certification path ending in the target
> > certificate that will validate properly given the supplied inputs
> > 3) Send a response containing the results of the discovery process
> > (at least an indication of success or failure and, in the success
> > case, the discovered certification path)
> >
> > Most of the refinements listed above with respect to the DPV
> > server can
> > also be applied to the DPD server. In addition, other
> > refinements might
> > include having the client supply additional certificates that may be
> > useful to the server (such as certificates received with an
> > S/MIME email
> > message).
> >
> > I look forward to seeing a discussion on this topic. If no discussion
> > results, I suppose that I will conclude that there is general
> > agreement
> > about these basic concepts. However, simple affirmative messages
> > agreeing with these basic concepts would be useful in judging rough
> > consensus.
> >
> > Thanks,
> >
> > Steve
> >
> > P.S. Due to the short timeline, I will submit more detailed
> > comments on
> > Steve's requirements soon.
> >

Received: from po1.bbn.com (PO1.BBN.COM [192.1.50.38]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA00719 for ; Thu, 11 Jan 2001 13:48:20 -0800 (PST)
Received: from [171.78.30.107] (comsec.bbn.com [171.78.30.107]) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id QAA02916; Thu, 11 Jan 2001 16:53:27 -0500 (EST)
Mime-Version: 1.0
X-Sender: [email-masked]
Message-Id:
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Date: Thu, 11 Jan 2001 16:51:55 -0500
To: Frank Balluffi
From: Stephen Kent
Subject: RE: DPD & DPV requirements
Cc: [email-masked]
Content-Type: text/plain; charset="us-ascii" ; format="flowed"

Frank,

>Some thoughts ...
>
>1. Purpose: Qualified Paths Only
>
>To me, DPD/DPV should be a protocol for requesting one or more qualified
>paths by value or by reference, period. By qualified path, I mean a path
>that satisfies some PKIX-defined standard (e.g., section 6 of RFC 2459). I
>do not see value in returning paths that the server can either not qualify
>or qualify in some other manner. Because PKIX does not define a standard for
>path discovery, I would argue that the only discovered paths allowable
>should be valid paths. What is the value of a server responding with, "Gee,
>I threw this path together, which might satisfy your needs."

Yes, that's what the requirements spec already says.

>2. Request
>
>The client should supply some subset of each requested path which must
>include the least significant certificate and optionally:
>
>- one or more intermediate certificates
>- one or more trusted certificates

An intermediate cert that is not trusted, but is not the end of a
partial path? Why? This is getting complicated.

>For ASN.1 applications, certificates should be passed by value. For XML (by
>which I mean PKI-unaware) applications, certificates should be passed by
>reference (e.g., issuer + serial number + ...). Optionally, an XML
>application could pass certificates as opaque elements.

I can see a PKI-ignorant app passing a cert as a blob, but passing
some other form of cert ID has to be motivated by the scenario that
would cause this info to become available to the app. We do have an
example that cited the issuer name and serial number for of cert
reference elsewhere, but that was an app that is already ASN.1 aware,
and so not a candidate for this discussion. I worry that once we move
into the realm of other, nominally equivalent forms of cert ID, that
we are entering a very iffy area, especially since we are talking
about accommodating a growing set of apps that are, by definition,
not ASN.1 aware.

>The client should have the ability to provide PKIX-defined path validation
>parameters by value or by reference (e.g., by OID). Since the only known
>parameters are those defined in RFC 2459, I do not see value in allowing the
>client to supply other parameters. By this, I am not implying that others do
>not have a need for custom parameters.

Since the spec already says this, why are you repeating it here? We
started down a path of suggesting charges to my strawman spec. I'd
like to continue in that fashion, to avoid duplicating existing text
and confusing the discussion. Please go back and cast you
suggestions in the form of changes to the current requirements spec,
so that where your suggestions agree with that spec there is no need
to comment.

Thanks,

Steve

Received: from po1.bbn.com (PO1.BBN.COM [192.1.50.38]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA29455 for ; Thu, 11 Jan 2001 13:38:24 -0800 (PST)
Received: from [171.78.30.107] (comsec.bbn.com [171.78.30.107]) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id QAA01722; Thu, 11 Jan 2001 16:43:23 -0500 (EST)
Mime-Version: 1.0
X-Sender: [email-masked]
Message-Id:
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Date: Thu, 11 Jan 2001 16:36:41 -0500
To: Peter Sylvester
From: Stephen Kent
Subject: RE: DPD & DPV requirements - Let us Recurse
Cc: [email-masked]
Content-Type: text/plain; charset="us-ascii" ; format="flowed"

Peter,

Thanks for pointing out the loop detection requirement that needs to
be part of the protocol IF we allow these servers to call one another.

Steve

Received: from po1.bbn.com (PO1.BBN.COM [192.1.50.38]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA29414 for ; Thu, 11 Jan 2001 13:38:16 -0800 (PST)
Received: from [171.78.30.107] (comsec.bbn.com [171.78.30.107]) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id QAA01718; Thu, 11 Jan 2001 16:43:23 -0500 (EST)
Mime-Version: 1.0
X-Sender: [email-masked]
Message-Id:
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Date: Thu, 11 Jan 2001 16:35:05 -0500
To: Frank Balluffi
From: Stephen Kent
Subject: RE: DPD & DPV requirements - Recursion Issues
Cc: PKIX-List
Content-Type: text/plain; charset="us-ascii" ; format="flowed"

Frank,

>Wouldn't a DPD/DPV server solely carry out the task of discovering and
>validating paths, and possibly use other protocols (e.g., LPAP, OCSP, etc.),
>which might be recursive, to assist in this process? So unless sub-DPD/DPV
>servers take part in path discovery or validation I would not describe
>DPD/DPV as recursive.

I think we're mostly in agreement. We expect an DPV or DPD server to
make use of other servers, e.g., LDAP and OCSP. If an LDAP server
makes a recursive call, the results can (should?) still be
"flattened" before returning to the user and have no security
implications, since LDAP is not trusted. So there's not necessarily
and evidence of this hidden recursion in the response, nor any
security implication. For OCSP, I didn't think recursion is
supported in the response structure, so the issue there is moot.
Finally, as I noted earlier, this is most importantly a DPV issue,
since no trust is vested in a DPD server. Still, we have to decide if
there is merit in allowing recursive syntax for DPD responses.

Since we don't trust DPD servers per se, the only issue I see here is
whether the DPD server to which a request was made can return OCSP
responses that were gathered by other DPD servers, without making
that obvious to the client. I'll rely on Ambarish or Mike to answer
that question, since I don't recall the format details well enough.

Steve

Received: from ext-mail.valicert.com (ns1.valicert.com [63.65.221.10]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA28592 for ; Thu, 11 Jan 2001 13:29:50 -0800 (PST)
Received: from CONVERSION-DAEMON by ext-mail.valicert.com (PMDF V5.2-33 #46613) id <[email-masked]> for [email-masked]; Thu, 11 Jan 2001 13:34: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 <[email-masked]>; Thu, 11 Jan 2001 13:34:57 -0800 (PST)
Received: by exchange.valicert.com with Internet Mail Service (5.5.2650.21) id ; Thu, 11 Jan 2001 13:30:54 -0800
Content-return: allowed
Date: Thu, 11 Jan 2001 13:30:53 -0800
From: Frank Balluffi
Subject: RE: DPD & DPV Basics
To: "'Steve Hanna'" , PKIX List
Message-id: <[email-masked]>
MIME-version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-type: text/plain; charset="iso-8859-1"

Steve,

I like your approach. Here goes ...

1. Can someone explain the value of a DPD server returning a path that may
not be valid? I would argue that path discovery should be an optional
internal operation performed by a DPV server. I say this as someone who has
implemented support for SCVP draft 4's path building types of check. To me
the operation should be implicit.

2. I would like to see the option of passing certificates and other input
(e.g., CRLs) by reference for use by PKI-unaware (e.g., XML-enabled)
applications.

Frank

> -----Original Message-----
> From: Steve Hanna [mailto:[email-masked]]
> Sent: Thursday, January 11, 2001 3:34 PM
> To: PKIX List
> Subject: DPD & DPV Basics
>
>
> It seems that at least some members of the working group have not yet
> agreed upon certain basic concepts. Perhaps it would be
> useful for me to
> articulate these concepts so that they can be discussed
> separately from
> the detailed requirements supplied by Steve. Discussion of those
> detailed requirements can proceed simultaneously, but it would be good
> if we could reach agreement on these basic concepts or at least
> understand why we don't agree on them. I suspect that we already have
> rough consensus on these concepts, but it would be good to get any
> debate on them out into the open so that we can understand
> the technical
> foundations from which that debate arises.
>
> Here's my take on the basic concepts of DPD and DPV:
>
> The basic job of a DPV server is to validate a certification path. In
> its most basic form, it will perform the following steps:
>
> 1) Receive a request containing a certification path and other inputs
> to the validation algorithm (trust anchors, required certificate
> policies, etc.)
> 2) Validate the supplied certification path using the supplied inputs
> 3) Send a response containing the results of the validation (at least,
> an indication of success or failure)
>
> Many refinements to this are possible: the client supplying only a
> subset of the necessary inputs (by referring to an
> established policy),
> the server returning supporting evidence such as CRLs and OCSP
> responses, the client supplying CRLs or OCSP responses that may be
> useful to the server, etc. But I think it may be useful to reach
> agreement on the basic model described above before discussing these
> refinements (however worthy).
>
> The basic job of a DPD server is to discover a certification path. In
> its most basic form, it will perform the following steps:
>
> 1) Receive a request containing a target certificate and inputs to the
> validation algorithm (trust anchors, etc.)
> 2) Attempt to discover a certification path ending in the target
> certificate that will validate properly given the supplied inputs
> 3) Send a response containing the results of the discovery process
> (at least an indication of success or failure and, in the success
> case, the discovered certification path)
>
> Most of the refinements listed above with respect to the DPV
> server can
> also be applied to the DPD server. In addition, other
> refinements might
> include having the client supply additional certificates that may be
> useful to the server (such as certificates received with an
> S/MIME email
> message).
>
> I look forward to seeing a discussion on this topic. If no discussion
> results, I suppose that I will conclude that there is general
> agreement
> about these basic concepts. However, simple affirmative messages
> agreeing with these basic concepts would be useful in judging rough
> consensus.
>
> Thanks,
>
> Steve
>
> P.S. Due to the short timeline, I will submit more detailed
> comments on
> Steve's requirements soon.
>

Received: from po1.bbn.com (PO1.BBN.COM [192.1.50.38]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA27724 for ; Thu, 11 Jan 2001 13:18:57 -0800 (PST)
Received: from [171.78.30.107] (comsec.bbn.com [171.78.30.107]) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id QAA29276; Thu, 11 Jan 2001 16:23:57 -0500 (EST)
Mime-Version: 1.0
X-Sender: [email-masked]
Message-Id:
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Date: Thu, 11 Jan 2001 16:20:50 -0500
To: [email-masked]
From: Stephen Kent
Subject: Re: Basic Cert-2-Directory mapping question
Cc: [email-masked]
Content-Type: text/plain; charset="us-ascii" ; format="flowed"

Peter,

>Stephen Kent writes:
> >At 9:08 AM +0100 1/10/01, Michael StrM-vder wrote:
> >>=> People are used to flat name spaces. X.500 DNs does not work.
> >
> >Flat name spaces scale poorly, lead to confusion, and are thus not
>attractive
> >in various ways. People do like flat name spaces, until they trip over the
> >limitations they embody, then they complain and look for magic solutions.
> >I've seen no appropriate magic for this problem.
>
>Have you actually seen the problem though? It's automatically assumed that
>there's some vast, unassailable problem which hierarchical names will solve,
>but I don't think I've ever seen it except as some special-case, often
>hypothetical situation which is used to justify the need for DNs (or
>whatever).

Well, hierarchic names do solve several problems, as I noted in an
earlier message today. DNS is a great example. X.500 is not so great
an example, for reasons I also allude to. LDAP is not a great
example for various reasons, including the fact that in making it "L"
folks threw out things they later realized that they needed. This
has several analogies to the history of e-mail systems. Internet
e-mail was basic but fairly solid and very widely implementable, like
DNS. Fancier e-mail system evolved, but were platform specific and
often were restricted to the set of users managed from a single
server or a small set of servers under single administrative control,
and thus didn't scale, like LDAP. Now that we have MIME, we have
most of the best of both worlds, i.e., a scalable system with
tremendous extent and the ability to handle arbitrary content. But,
I digress ...

>In the real world people have been using their flat, non-scalable name spaces
>for several decades without any sign that civilisation is about to collapse.
>Only yesterday I was talking to someone whose company is deploying a
>nationwide
>PKI based on HTTP (you tack the ID of the cert owner onto a URL and grab it
>from a server, revocation is handled by removing the cert). Since it's HTTP,
>it's guaranteed to work through firewalls, proxies, and other oddities, and is
>supported on every platform, I shudder to think what it would take to do the
>same thing with CRLs and directories and DNs and whatnot.

Not sure which "flat, non-scalable name spaces" you are alluding to
above. As for your example, I don't see how scaling works in your
HTTP PKI example. If the cert ID isn't structured, then does one
server (or server family) hold all the certs? That's not scaleable.
Also, revocation via removal from a directory is a questionable
notion, as it implies a need to always access the directory (not
supportive of many scenarios) and to place a lot of trust in the
directory (not a great security concept).

>In the real world we use flat IDs for practically everything where certs might
>at some stage be employed without any problems, for example:
>
> - Access to University account information (Uni. ID number)

That's not a flat ID if you have to specify the university ID; it's a
2 level hierarchy.

> - Access to/submission of tax info (taxpayer ID, SSN in the US I guess)

Not quite. Since SSNs are not unique, its the name and SSN that is
used, and the system. Still, for global applicability one would
prefix the ID with a country code, again making it a two tier scheme.

> - Email encryption (email address)

definitely NOT a flat space, because it is build on top of DNS, which
is already hierarchic.

> - Access to/update of frequent flyer info (frequent flyer number, living
> where I do you get handed one of these the first time you buy a
>ticket :-).

Airline specific, so a global system uses an implied airline ID.

> - Bank account access (account number)

Again, requires bank ID first to qualify the account number.

> - Access to patient medical records (from the discussion
>yesterday, this uses
> some doctor registration number which is centrally managed)

Can't comment here since the U.S. does not have a national, medical
care system, but I assume that here too we would need to qualify the
ID by country first.

>There isn't actually anything I do which needs a hierarchical DN or any of the
>accompanying paraphernalia and complexity (X.500/LDAP/whatever), in every case
>a simple "Get me the cert for "
>will do the job. What major, urgent real-world problem (apart from "Lack of
>revenue from selling X.500 services"), which couldn't be addressed much more
>simply with existing mechanisms, are DNs et al actually solving?

We have a very bad disconnect here, Peter. What I see above are
example of name spaces that are very much hierarchic, but usually
shallow hierarchies. What I think you have intended to say, but did
not until this paragraph, is that the DN structure based on
countries, and organizations or geographic locales seems richer than
one needs for most naming scenarios where we might want to issue
certs. I think that's true only if one assumes additional context, as
shown in each example above, and that context might be external to
the name, or it might be part of the name to make the name globally
unique.

Steve

Received: from ext-mail.valicert.com (ns1.valicert.com [63.65.221.10]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA26017 for ; Thu, 11 Jan 2001 13:02:18 -0800 (PST)
Received: from CONVERSION-DAEMON by ext-mail.valicert.com (PMDF V5.2-33 #46613) id <[email-masked]> for [email-masked]; Thu, 11 Jan 2001 13:07:26 -0800 (PST)
Received: from polaris.valicert.com ([192.168.2.34]) by ext-mail.valicert.com (PMDF V5.2-33 #46613) with ESMTP id <[email-masked]> for [email-masked]; Thu, 11 Jan 2001 13:07:26 -0800 (PST)
Received: by exchange.valicert.com with Internet Mail Service (5.5.2650.21) id ; Thu, 11 Jan 2001 13:03:22 -0800
Content-return: allowed
Date: Thu, 11 Jan 2001 13:03:22 -0800
From: Frank Balluffi
Subject: RE: DPD & DPV requirements
To: "[email-masked]'"
Message-id: <[email-masked]>
MIME-version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-type: text/plain; charset="iso-8859-1"

Earlier, I said:

> For XML applications, each valid path should be returned by
> reference (e.g.,
> as an ordered collection of issuer + serial number + ...) and
> optionally as
> an opaque element (e.g., base-64 encoded SEQUENCE OF
> Certificate).

In this case, each element in the path might include its subject and public
key (e.g., issuer + serial number + subject + public key).

Frank

Received: from po1.bbn.com (PO1.BBN.COM [192.1.50.38]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA24840 for ; Thu, 11 Jan 2001 12:38:08 -0800 (PST)
Received: from [171.78.30.107] (comsec.bbn.com [171.78.30.107]) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id PAA23931; Thu, 11 Jan 2001 15:43:14 -0500 (EST)
Mime-Version: 1.0
X-Sender: [email-masked]
Message-Id:
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Date: Thu, 11 Jan 2001 15:37:50 -0500
To: "Covey, Carlin"
From: Stephen Kent
Subject: RE: DPD & DPV requirements - Recursion Issues
Cc: PKIX-List
Content-Type: text/plain; charset="us-ascii" ; format="flowed"

Carlin,

>Steve,
>
>I'm sorry that this isn't much of an analysis, but I think
>that any such analysis should clearly separate the issues.
>Here are three issues that I can think of:
>
>1) One issue concerns the syntactic complexity of the protocol.
>If the protocol permits a DPV/DPD response to include embedded
>DPD/DPD responses from other servers, then the syntax will be a
>bit more complex than it might be otherwise.

Right.

>2) A second issue concerns transitive trust. This is an issue
>even if embedded responses aren't permitted in the protocol.
>A DPV/DPD server could contact another server and repackage
>the response that it receives. This issue might be addressed
>by providing hooks in the protocol to limit the extent of this
>transitive trust. On the other hand, the issue might be
>addressed by DPV/DPD server practice statements. "This is what
>I might do, trust me or not." Or the issue might be addressed
>by a combination of the two by using policy OIDs in the request
>to indicate which practice statement the client is willing
>to tolerate.

I disagree with part of this. If a DPV server makes use of other DPV
servers, but returns results that don't indicate such use, then it is
mostly outside the scope of the protocol, i.e., we could not tell
from examining the response. It might be stated in a published
policy, something I would expect for a public server, but not a
corporate (intranet) server. (Also, this discussion applies just to
DPV servers, I think; a DPD server returns paths and data for
ultimate evaluation by the client, so transitive trust is not an
issue.) It's only when the response to a client include a data
structure in which some part of the response is itself syntactically
identified as coming from another DPV server that I think the
discussion is applicable.

We already assume that a DPV server is making use of various other
servers, e.g., LDAP servers and OCSP servers. But an LDAP sever is
not a trusted repository, and a response from an OCSP server is
clearly marked as such and must be maintained in that fashion to be
valid. So the transitive trust aspect of simple DPV operation is
limited to the OCSP responders that it uses. If the DPV client is
not PKI-aware, I would not expect it to be able to meaningfully
influence transitive trust in this way, since such controls require
an understanding of PKI issues. Only the most basic sort of controls,
invoked symbolically, might make sense.

>3) A third issue is whether the benefits of recursion outweigh the
>difficulties presented by the first two issues. The authors of
>the SCVP and OCSP-DPV proposals, and the author of the proposed
>DPV/DPD requirements (someone well known to you, Steve) all chose
>to permit OCSP v1 responses to be embedded in the DPD responses,
>despite issues 1 and 2.

As noted above, the DPV and DPD cases are very separate here, and
only DPV is likely to be a legitimate focus of this discussion. Yes,
OCSP responses are included, and that introduces the transitive trust
issue, but unless OCSP allows for recursion itself, I think we have
an inherent limit in this case, i.e., it's not recursive, just
1-level delegation. Also, if one has a flag to say whether any OCSP
responses are considered legitimate, then this provides a level of
control that is simple to understand and exactly matches the
delegation.

Steve

Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA24312 for ; Thu, 11 Jan 2001 12:31:39 -0800 (PST)
Received: from eastmail1.East.Sun.COM ([129.148.1.240]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA11260 for ; Thu, 11 Jan 2001 12:36:47 -0800 (PST)
Received: from sunlabs.East.Sun.COM (sunlabs.East.Sun.COM [129.148.75.250]) by eastmail1.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id PAA05878 for ; Thu, 11 Jan 2001 15:36:46 -0500 (EST)
Received: from sun.com (dhcp75-155 [129.148.75.155]) by sunlabs.East.Sun.COM (8.9.3+Sun/8.9.1) with ESMTP id PAA24864 for ; Thu, 11 Jan 2001 15:36:00 -0500 (EST)
Message-ID: <[email-masked]>
Date: Thu, 11 Jan 2001 15:33:55 -0500
From: Steve Hanna
Organization: Sun Microsystems, Inc.
X-Mailer: Mozilla 4.75 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: PKIX List
Subject: DPD & DPV Basics
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

It seems that at least some members of the working group have not yet
agreed upon certain basic concepts. Perhaps it would be useful for me to
articulate these concepts so that they can be discussed separately from
the detailed requirements supplied by Steve. Discussion of those
detailed requirements can proceed simultaneously, but it would be good
if we could reach agreement on these basic concepts or at least
understand why we don't agree on them. I suspect that we already have
rough consensus on these concepts, but it would be good to get any
debate on them out into the open so that we can understand the technical
foundations from which that debate arises.

Here's my take on the basic concepts of DPD and DPV:

The basic job of a DPV server is to validate a certification path. In
its most basic form, it will perform the following steps:

1) Receive a request containing a certification path and other inputs
to the validation algorithm (trust anchors, required certificate
policies, etc.)
2) Validate the supplied certification path using the supplied inputs
3) Send a response containing the results of the validation (at least,
an indication of success or failure)

Many refinements to this are possible: the client supplying only a
subset of the necessary inputs (by referring to an established policy),
the server returning supporting evidence such as CRLs and OCSP
responses, the client supplying CRLs or OCSP responses that may be
useful to the server, etc. But I think it may be useful to reach
agreement on the basic model described above before discussing these
refinements (however worthy).

The basic job of a DPD server is to discover a certification path. In
its most basic form, it will perform the following steps:

1) Receive a request containing a target certificate and inputs to the
validation algorithm (trust anchors, etc.)
2) Attempt to discover a certification path ending in the target
certificate that will validate properly given the supplied inputs
3) Send a response containing the results of the discovery process
(at least an indication of success or failure and, in the success
case, the discovered certification path)

Most of the refinements listed above with respect to the DPV server can
also be applied to the DPD server. In addition, other refinements might
include having the client supply additional certificates that may be
useful to the server (such as certificates received with an S/MIME email
message).

I look forward to seeing a discussion on this topic. If no discussion
results, I suppose that I will conclude that there is general agreement
about these basic concepts. However, simple affirmative messages
agreeing with these basic concepts would be useful in judging rough
consensus.

Thanks,

Steve

P.S. Due to the short timeline, I will submit more detailed comments on
Steve's requirements soon.

Received: from mailgw2a.lmco.com (mailgw2a.lmco.com [192.91.147.7]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA15418 for ; Thu, 11 Jan 2001 10:24:39 -0800 (PST)
Received: from emss03g01.ems.lmco.com (emss03g01.ems.lmco.com [141.240.4.144]) by mailgw2a.lmco.com (8.8.8/8.8.8) with ESMTP id NAA19511; Thu, 11 Jan 2001 13:29:43 -0500 (EST)
Received: from CONVERSION-DAEMON by lmco.com (PMDF V5.2-32 #38888) id <[email-masked]>; Thu, 11 Jan 2001 13:28:42 -0500 (EST)
Received: from emss03i00.ems.lmco.com ([141.240.31.211]) by lmco.com (PMDF V5.2-32 #38888) with ESMTP id <[email-masked]>; Thu, 11 Jan 2001 13:28:20 -0500 (EST)
Received: by emss03i00.orl.lmco.com with Internet Mail Service (5.5.2650.21) id ; Thu, 11 Jan 2001 13:29:28 -0500
Content-return: allowed
Date: Thu, 11 Jan 2001 13:29:28 -0500
From: "Slone, Skip"
Subject: RE: Basic Cert-2-Directory mapping question
To: "'Oscar Jacobsson'"
Cc: "'Sharon Boeyen'" , [email-masked]
Message-id:
MIME-version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-type: text/plain
Content-transfer-encoding: 7BIT

In response to this, I'm inclined to join Sharon on Marshall's soapbox and
echo her words:

"... I believe a more constructive approach is to accept the fact that
different parts of the world and different environments will use a variety
of nameforms ... We are not the global naming police either and should not
try to impose the rules that anyone uses to name entities to which they
issue certificates."

And to quote someone Sharon and I both know, "If all you have is a hammer,
every problem looks like a nail."

-- Skip

-----Original Message-----
From: Oscar Jacobsson [mailto:[email-masked]]
Sent: Thursday, January 11, 2001 11:39 AM
To: Slone, Skip
Cc: 'Sharon Boeyen'; [email-masked]
Subject: Re: Basic Cert-2-Directory mapping question

"Slone, Skip" wrote:
> I would just like to add that, in addition to X.521 and some LDAP
> specs, the ability to recognize civil naming attributes in the issuer
> and subject fields of an X.509v3 cert is mandated in RFC 2459 (ref
> section 4.1.2.4) and in son-of-2459.

True, and I don't think "recognizing" them as certificates is the issue
here. More on this as we get to your proposed requirement.

> In terms of a requirement for this WG, as I see it, we have a
> requirement to be able to find the associated repository for any
> validly constructed PKIX-compliant certificate.

I would prefer this requirement restricted to apply only to those
certificates that were consciously created for deployment on the
Internet.

Come to think of it, maybe this would be better off split into two
separate discussions. One on creating/endorsing/applying a naming scheme
that will allow us to deploy PKIs over the Internet, for which I'd say
that repository discovery would be a must, and another on handling the
"legacy" (as in non-Internet based) X.521-style certificates already in
use, probably most importantly those shipped along with our web
browsers.

> I'm open to suggestions on HOW to resolve these domain-amiguous
> certs.

The problem here is in their very ambiguity. The subjects of these
certificates are not necessarily directory entries in the first place. I
know I've personally held a sizeable amount of certificates, the
subjects _and_ issuers of which have been completely fictitious. Or
maybe not fictitious, but completely arbitrary anyway. Of all the
certificates ever issued to me, no two have ever used the same DN.

Regards,

//oscar

Received: from email.nist.gov (email.nist.gov [129.6.2.7]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA14674 for ; Thu, 11 Jan 2001 10:06:09 -0800 (PST)
Received: from krdp2 (krdp2.ncsl.nist.gov [129.6.54.107]) by email.nist.gov (8.9.3/8.9.3) with ESMTP id NAA14467; Thu, 11 Jan 2001 13:11:14 -0500 (EST)
Message-Id: <[email-masked]>
X-Sender: [email-masked]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2
Date: Thu, 11 Jan 2001 13:10:49 -0500
To: Michael =?iso-8859-1?Q?Str=F6der?= , IETF-PXIX
From: "David A. Cooper"
Subject: Re: Two questions on delta-CRL
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]>
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 ns.secondary.com id KAA14675

Michael,

This is not correct. A delta CRL must (at least) provide information about every certificate whose status has changed since the previous full CRL was issued. Thus, one can always get up to date by obtaining the most recently issued full CRL and the most recently issued delta CRL (max. 2 accesses).

To put it another way, each delta CRL must specify a baseCRLNumber and must list every certificate whose status has changed since the CRL whose cRLNumber is baseCRLNumber was issued. Since the CRL whose cRLNumber is baseCRLNumber must have been issued as a full CRL, it is always sufficient to apply this one delta CRL to its corresponding base CRL to obtain up to date information.

Dave

At 06:54 PM 1/11/01 +0100, Michael Ströder wrote:
>E.g. if you issue a full CRL each day (24h) and delta-CRLs every
>hour the application will have to obtain the last full CRL and every
>delta CRL issued since then to get up to date (max. 24 accesses
>instead of one).
>
>If you want to relax the requirement of issuing full and delta CRLs
>at the same time you have to mandate
>1. that the CRL issuer stores all delta URLs from the last full CRL
>and
>2. you have to provide appropriate service access points to obtain
>all necessary delta CRLs.

Received: from exchange.cylink.com (exchange.cylink.com [192.43.161.25]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA13890 for ; Thu, 11 Jan 2001 09:58:25 -0800 (PST)
Received: by exchange.cylink.com with Internet Mail Service (5.5.2650.21) id ; Thu, 11 Jan 2001 09:55:36 -0800
Message-ID: <[email-masked]>
From: "Covey, Carlin"
To: PKIX-List
Subject: RE: DPD & DPV requirements
Date: Thu, 11 Jan 2001 09:55:32 -0800
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"

Skip,

Skip, thanks for posting this. This is clearly a valuable use case.

I agree that "relay" is a better term for this case than the term
"recursion," which I just meant to apply to one form of the data
structure in which the relayed data might be returned.

Regards,

Carlin

------------------------
- Carlin Covey
Cylink Corp.

-----Original Message-----
From: Slone, Skip [mailto:[email-masked]]
Sent: Thursday, January 11, 2001 10:39 AM
To: 'Stephen Kent'
Cc: PKIX-List
Subject: RE: DPD & DPV requirements

Steve,

The scenario I'm envisioning would be easiest to describe with the aid of a
whiteboard, cocktail napkin, or similar medium. But, alas, I'm restricted
to email at the moment, so I'll do the best I can to draw a good mental
picture...

What I'm envisioning is a typical scenario that companies will face in the
B2B space over the coming years. Imagine a diagram with an Intranet cloud
on one each side, with those two clouds each connected, via a firewall, to
the Internet, which is drawn in the middle. In that environment, any
traffic that goes from Intranet A to Intranet B must traverse two firewalls
to get to its destination.

Now, fast forward a few years and you'll see that what we now call firewalls
have morphed into full-fledged boundary service environments, complete with
inward and outward facing portals and a whole bunch of servers of various
sorts, servicing the needs of each enterprise at its respective boundary.
Glossing over a lot of details, I think it's reasonable to think that
DPV/DPD servers (mostly DPV) can play a huge role in this boundary service
environment.

Looking at the in-bound side, it's reasonable to assume that in the presence
of this capability, some companies will choose to provide DPV servers at
their boundaries and to prohibit direct in-bound traversal of their
boundaries for path discovery/validation purposes. Further, it is reasonable
to assume that companies that err of the side of paranoia will only service
DPV requests coming from known (i.e., preconfigured) sources, such as DPV
servers on the boundaries of known trading partners.

On the out-bound side, many companies currently restrict direct out-bound
access to nearly anything, requiring proxies and similar relay services
instead. As we move forward, I see this kind of restriction likely to
increase. Thus, relying parties inside a network who need to validate
external certificates may find very few paths available for the various
steps involved in path discovery and validation (most likely a combination
of not-so-basic-DNS, LDAP, HTTP, and FTP interactions). By making path
validation available on the boundary, companies will find an attractive
alternative. Internal RPs will be able to simply delegate the task to a
boundary-resident DPV server.

Putting the two sides of this equation together and looking at a typical B2B
scenario, we find the following case in which a relying party in Company A
needs to validate a Company B path: the RP delegates its request to the DPV
server residing on Company A's boundary. Company A's DPV server (since it
doesn't have direct access to Company B's network) will delegate to the DPV
server residing on Company B's boundary. Company B's DPV server will then
access the internal resources in Company B's network, perform all the
necessary discovery and validation work and return the result back upstream.

As for the need to constrain the number of relays (on further reflection,
"relay" seems like a better fit than "recursion"), consider the following.
In the scenario above, there is a need to relay the delegation exactly one
time. Thus, the RP inside A needs to allow a one-hop relay, but it may wish
to preclude paths longer than that, in order to prevent getting to Company B
by first going through Companies X, Y, and Z. On the other hand, it may be
appropriate for a third party to be involved in the relay (industry
consortium, bridge, TTP, etc.), which would make it appropriate to be able
to specify two hops (or some other number as the situation warrants).

That's it for now... thanks for listening.

-- Skip

Received: from mailgw2a.lmco.com (mailgw2a.lmco.com [192.91.147.7]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA13804 for ; Thu, 11 Jan 2001 09:57:35 -0800 (PST)
Received: from emss03g01.ems.lmco.com (emss03g01.ems.lmco.com [141.240.4.144]) by mailgw2a.lmco.com (8.8.8/8.8.8) with ESMTP id NAA11607; Thu, 11 Jan 2001 13:02:43 -0500 (EST)
Received: from CONVERSION-DAEMON by lmco.com (PMDF V5.2-32 #38888) id <[email-masked]>; Thu, 11 Jan 2001 13:01:48 -0500 (EST)
Received: from emss03i00.ems.lmco.com ([141.240.31.211]) by lmco.com (PMDF V5.2-32 #38888) with ESMTP id <[email-masked]>; Thu, 11 Jan 2001 13:01:31 -0500 (EST)
Received: by emss03i00.orl.lmco.com with Internet Mail Service (5.5.2650.21) id ; Thu, 11 Jan 2001 13:02:39 -0500
Content-return: allowed
Date: Thu, 11 Jan 2001 13:02:39 -0500
From: "Slone, Skip"
Subject: RE: Basic Cert-2-Directory mapping question
To: "'Robert Klerer'" , [email-masked]
Message-id:
MIME-version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id JAA13805

One example is to find associated attribute certs. See the following sample
paragraph taken from
ftp://ftp.ietf.org/internet-drafts/draft-ietf-pkix-ac509prof-06.txt:

In other cases, it is more suitable for a client simply to
authenticate to the server and for the server to request or "pull"
the client's AC from an AC issuer or a repository. <<<<------- !!

-- Skip

-----Original Message-----
From: Robert Klerer [mailto:[email-masked]]
Sent: Thursday, January 11, 2001 12:12 PM
To: [email-masked]
Subject: RE: Basic Cert-2-Directory mapping question

Please excuse my ignorance, but if I have the certificate why would I need a
repository where the certificate is stored? I need CRLs, but there is an
extension for that and has little to do with the subject DN in EE cert. The
only use I have for a repository is to find certificates if I know an EE's
name -- which brings up the real problem of mapping an EE name to a DN. The
"other attributes" is meaningless in this discussion since they would be
unsigned and I would have an apriori trust of the repository, thus I know
where to go beforehand.

From: Slone, Skip [mailto:[email-masked]]

Here's a use case that fits my scenario:

An RP needs to find a directory entry corresponding to a given certificate,
where:
- the certificate subject name uses civil-style naming,
- the RP's known directories have no knowledge (direct or indirect), and
- the subject's domain name is not known and cannot be derived.

With today's tools, this use case fails:
- LDAPv3 referrals fail due to the lack of knowledge,
- PKIXREP fails due to the lack of a domain name.

Am I overlooking some tool that can do the job?

-- Skip

-----Original Message-----
From: Michael Ströder [mailto:[email-masked]]
Sent: Thursday, January 11, 2001 10:31 AM
To: [email-masked]
Subject: Re: Basic Cert-2-Directory mapping question

"Slone, Skip" wrote:
>
> If LDAPv3 referrals were sufficient, we wouldn't be having this
> conversation.

Who said that LDAPv3 referrals are the overall solution without
prior configuration?

> LDAPv3 referrals WILL work in the following two cases:
>
> 1) where my server's administrator already knows how to
> find the target name
> space, or
> 2) where my server and the server holding the target name space
> participate in some fully-connected DIT
> [..]

Yes.

> What I'm discussing is a way to fill in the gap where (1) my server does
not
> already know how to find a certain name space, and (2) there's a knowledge
> disconnect between my server and the server holding the target. In this
> case, LDAPv3 referrals WILL NOT work.

Yes.

And RFC2377 does not work without SRV RRs. Yes. And I can't access
http://www.ietf.org without somebody having added the entry
www.ietf.org to DNS. Yes. And... Yes.

No doubt, if you do not know any service access point or you don't
have any rule how to derive the service access point from an
information at hand you can't access the service. Yes.

Now about which *use-case* are we talking here?

Ciao, Michael.

Received: from junker.ms.inka.de (p3EE0A972.dip.t-dialin.net [62.224.169.114]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA12905 for ; Thu, 11 Jan 2001 09:50:48 -0800 (PST)
Received: from stroeder.com (localhost [127.0.0.1]) by junker.ms.inka.de (Postfix) with ESMTP id E482D680EB for ; Thu, 11 Jan 2001 18:54:53 +0100 (CET)
Sender: [email-masked]
Message-ID: <[email-masked]>
Date: Thu, 11 Jan 2001 18:54:53 +0100
From: Michael =?iso-8859-1?Q?Str=F6der?=
Organization: stroeder.com
X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.18 i686)
X-Accept-Language: de-DE, de, en
MIME-Version: 1.0
To: IETF-PXIX
Subject: Re: Two questions on delta-CRL
References: <[email-masked]> <[email-masked]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Sam Schaen wrote:
>
> I believe the requirement for issuing a complete CRL when a delta CRL is
> released makes sense.
> [..]
> The availability of a current full CRL also allows an application to
> resynchronize at any point.

I think this is the most important argument. An application might
loose the stored CRL or the CRL got corrupt by e.g. a system crash.
The damage for the application is limited to the loss of some
network-bandwidth. Resynchronization is simple.

E.g. if you issue a full CRL each day (24h) and delta-CRLs every
hour the application will have to obtain the last full CRL and every
delta CRL issued since then to get up to date (max. 24 accesses
instead of one).

If you want to relax the requirement of issuing full and delta CRLs
at the same time you have to mandate
1. that the CRL issuer stores all delta URLs from the last full CRL
and
2. you have to provide appropriate service access points to obtain
all necessary delta CRLs.

The application logic gets more complicated though.

Ciao, Michael.

Received: from junker.ms.inka.de (p3EE0A972.dip.t-dialin.net [62.224.169.114]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA12904 for ; Thu, 11 Jan 2001 09:50:48 -0800 (PST)
Received: from stroeder.com (localhost [127.0.0.1]) by junker.ms.inka.de (Postfix) with ESMTP id 2F8B467D53 for ; Thu, 11 Jan 2001 18:45:05 +0100 (CET)
Sender: [email-masked]
Message-ID: <[email-masked]>
Date: Thu, 11 Jan 2001 18:45:03 +0100
From: Michael =?iso-8859-1?Q?Str=F6der?=
Organization: stroeder.com
X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.18 i686)
X-Accept-Language: de-DE, de, en
MIME-Version: 1.0
To: "[email-masked]"
Subject: Re: Two questions on delta-CRL
References: <[email-masked]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Ambarish Malpani wrote:
>
> I, too, would like to see the requirement relaxed to a full CRL
> SHOULD be published when a delta CRL is issued.

Why?

Ciao, Michael.

Received: from mailgw2a.lmco.com (mailgw2a.lmco.com [192.91.147.7]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA11875 for ; Thu, 11 Jan 2001 09:34:20 -0800 (PST)
Received: from emss03g01.ems.lmco.com (emss03g01.ems.lmco.com [141.240.4.144]) by mailgw2a.lmco.com (8.8.8/8.8.8) with ESMTP id MAA20421; Thu, 11 Jan 2001 12:39:24 -0500 (EST)
Received: from CONVERSION-DAEMON by lmco.com (PMDF V5.2-32 #38888) id <[email-masked]>; Thu, 11 Jan 2001 12:38:03 -0500 (EST)
Received: from emss03i00.ems.lmco.com ([141.240.31.211]) by lmco.com (PMDF V5.2-32 #38888) with ESMTP id <[email-masked]>; Thu, 11 Jan 2001 12:37:41 -0500 (EST)
Received: by emss03i00.orl.lmco.com with Internet Mail Service (5.5.2650.21) id ; Thu, 11 Jan 2001 12:38:44 -0500
Content-return: allowed
Date: Thu, 11 Jan 2001 12:38:44 -0500
From: "Slone, Skip"
Subject: RE: DPD & DPV requirements
To: "'Stephen Kent'"
Cc: PKIX-List
Message-id:
MIME-version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-type: text/plain
Content-transfer-encoding: 7BIT

Steve,

The scenario I'm envisioning would be easiest to describe with the aid of a
whiteboard, cocktail napkin, or similar medium. But, alas, I'm restricted
to email at the moment, so I'll do the best I can to draw a good mental
picture...

What I'm envisioning is a typical scenario that companies will face in the
B2B space over the coming years. Imagine a diagram with an Intranet cloud
on one each side, with those two clouds each connected, via a firewall, to
the Internet, which is drawn in the middle. In that environment, any
traffic that goes from Intranet A to Intranet B must traverse two firewalls
to get to its destination.

Now, fast forward a few years and you'll see that what we now call firewalls
have morphed into full-fledged boundary service environments, complete with
inward and outward facing portals and a whole bunch of servers of various
sorts, servicing the needs of each enterprise at its respective boundary.
Glossing over a lot of details, I think it's reasonable to think that
DPV/DPD servers (mostly DPV) can play a huge role in this boundary service
environment.

Looking at the in-bound side, it's reasonable to assume that in the presence
of this capability, some companies will choose to provide DPV servers at
their boundaries and to prohibit direct in-bound traversal of their
boundaries for path discovery/validation purposes. Further, it is reasonable
to assume that companies that err of the side of paranoia will only service
DPV requests coming from known (i.e., preconfigured) sources, such as DPV
servers on the boundaries of known trading partners.

On the out-bound side, many companies currently restrict direct out-bound
access to nearly anything, requiring proxies and similar relay services
instead. As we move forward, I see this kind of restriction likely to
increase. Thus, relying parties inside a network who need to validate
external certificates may find very few paths available for the various
steps involved in path discovery and validation (most likely a combination
of not-so-basic-DNS, LDAP, HTTP, and FTP interactions). By making path
validation available on the boundary, companies will find an attractive
alternative. Internal RPs will be able to simply delegate the task to a
boundary-resident DPV server.

Putting the two sides of this equation together and looking at a typical B2B
scenario, we find the following case in which a relying party in Company A
needs to validate a Company B path: the RP delegates its request to the DPV
server residing on Company A's boundary. Company A's DPV server (since it
doesn't have direct access to Company B's network) will delegate to the DPV
server residing on Company B's boundary. Company B's DPV server will then
access the internal resources in Company B's network, perform all the
necessary discovery and validation work and return the result back upstream.

As for the need to constrain the number of relays (on further reflection,
"relay" seems like a better fit than "recursion"), consider the following.
In the scenario above, there is a need to relay the delegation exactly one
time. Thus, the RP inside A needs to allow a one-hop relay, but it may wish
to preclude paths longer than that, in order to prevent getting to Company B
by first going through Companies X, Y, and Z. On the other hand, it may be
appropriate for a third party to be involved in the relay (industry
consortium, bridge, TTP, etc.), which would make it appropriate to be able
to specify two hops (or some other number as the situation warrants).

That's it for now... thanks for listening.

-- Skip

-----Original Message-----
From: Stephen Kent [mailto:[email-masked]]
Sent: Wednesday, January 10, 2001 5:10 PM
To: Slone, Skip
Cc: PKIX-List
Subject: RE: DPD & DPV requirements

Skip,

If we do agree to support DPV server recursion, then the suggested
changes are appropriate ones to consider.

First, though, on what basis would you propose that a client
enable/disable recursion or set a depth limit? Since a client is
completely dependent on a DPV server to answer a query, and has no
local means of validating any supporting data sent along with the
answer, what does recursion say about the trust that the client
places in the server? If one believes that trust is transitive,
recursion may well be fine, and a simple numerical limit on depth of
recursion would not seem to be a good way to express limits on the
transitivity (e.g., one bad choice of a DPV server for reliance is
enough to kill you). If you don't think trust is transitive, then
recursion is inappropriate, unless you operate in a closed
environment where the recursion is among servers operated by the same
org and is really just an internal decision on how to implement the
server.

Perhaps this is one reason why I am not yet comfortable with adding
recursion to servers. I'd like to see some analysis of why it makes
sense, whether it makes sense for both DPD and DPV, etc.

Steve

Received: from junker.ms.inka.de (pD901151F.dip.t-dialin.net [217.1.21.31]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA10944 for ; Thu, 11 Jan 2001 09:20:28 -0800 (PST)
Received: from stroeder.com (localhost [127.0.0.1]) by junker.ms.inka.de (Postfix) with ESMTP id DE52467D53 for ; Thu, 11 Jan 2001 18:25:16 +0100 (CET)
Sender: [email-masked]
Message-ID: <[email-masked]>
Date: Thu, 11 Jan 2001 18:25:15 +0100
From: Michael =?iso-8859-1?Q?Str=F6der?=
Organization: stroeder.com
X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.18 i686)
X-Accept-Language: de-DE, de, en
MIME-Version: 1.0
To: "[email-masked]"
Subject: Re: Basic Cert-2-Directory mapping question
References:
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id JAA10945

"Slone, Skip" wrote:
>
> Here's a use case that fits my scenario:
>
> An RP needs to find a directory entry corresponding to a given certificate,
> where:
> - the certificate subject name uses civil-style naming,
> - the RP's known directories have no knowledge (direct or indirect), and
> - the subject's domain name is not known and cannot be derived.

I repeat:

> Michael Ströder wrote:
> > No doubt, if you do not know any service access point or you don't
> > have any rule how to derive the service access point from an
> > information at hand you can't access the service. Yes.

Ciao, Michael.

Received: from mail4.registeredsite.com (IDENT:[email-masked] [64.224.9.13]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA09918 for ; Thu, 11 Jan 2001 09:06:53 -0800 (PST)
Received: from mail.xhair.com (mail.xhair.com [216.2.36.244]) by mail4.registeredsite.com (8.11.1/8.11.1) with ESMTP id f0BHC0d20927 for ; Thu, 11 Jan 2001 12:12:00 -0500
Received: from BOBT21 [63.146.136.63] by mail.xhair.com (SMTPD32-6.04) id A943745600CA; Thu, 11 Jan 2001 12:11:31 -0500
From: "Robert Klerer"
To:
Subject: RE: Basic Cert-2-Directory mapping question
Date: Thu, 11 Jan 2001 12:11:41 -0500
Message-ID:
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)
In-Reply-To:
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Importance: Normal

Please excuse my ignorance, but if I have the certificate why would I need a
repository where the certificate is stored? I need CRLs, but there is an
extension for that and has little to do with the subject DN in EE cert. The
only use I have for a repository is to find certificates if I know an EE's
name -- which brings up the real problem of mapping an EE name to a DN. The
"other attributes" is meaningless in this discussion since they would be
unsigned and I would have an apriori trust of the repository, thus I know
where to go beforehand.

From: Slone, Skip [mailto:[email-masked]]

Here's a use case that fits my scenario:

An RP needs to find a directory entry corresponding to a given certificate,
where:
- the certificate subject name uses civil-style naming,
- the RP's known directories have no knowledge (direct or indirect), and
- the subject's domain name is not known and cannot be derived.

With today's tools, this use case fails:
- LDAPv3 referrals fail due to the lack of knowledge,
- PKIXREP fails due to the lack of a domain name.

Am I overlooking some tool that can do the job?

-- Skip

-----Original Message-----
From: Michael Ströder [mailto:[email-masked]]
Sent: Thursday, January 11, 2001 10:31 AM
To: [email-masked]
Subject: Re: Basic Cert-2-Directory mapping question

"Slone, Skip" wrote:
>
> If LDAPv3 referrals were sufficient, we wouldn't be having this
> conversation.

Who said that LDAPv3 referrals are the overall solution without
prior configuration?

> LDAPv3 referrals WILL work in the following two cases:
>
> 1) where my server's administrator already knows how to
> find the target name
> space, or
> 2) where my server and the server holding the target name space
> participate in some fully-connected DIT
> [..]

Yes.

> What I'm discussing is a way to fill in the gap where (1) my server does
not
> already know how to find a certain name space, and (2) there's a knowledge
> disconnect between my server and the server holding the target. In this
> case, LDAPv3 referrals WILL NOT work.

Yes.

And RFC2377 does not work without SRV RRs. Yes. And I can't access
http://www.ietf.org without somebody having added the entry
www.ietf.org to DNS. Yes. And... Yes.

No doubt, if you do not know any service access point or you don't
have any rule how to derive the service access point from an
information at hand you can't access the service. Yes.

Now about which *use-case* are we talking here?

Ciao, Michael.

Received: from knightmare.the-dills.com (h002078cec9a7.ne.mediaone.net [24.91.47.157]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA09835 for ; Thu, 11 Jan 2001 09:04:43 -0800 (PST)
Received: by knightmare with Internet Mail Service (5.5.2650.21) id ; Thu, 11 Jan 2001 12:08:21 -0500
Message-ID:
From: Rick Dill
To: "[email-masked]'"
Subject:
Date: Thu, 11 Jan 2001 12:08:20 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"

Unsubscribe

Received: from ext-mail.valicert.com (ns1.valicert.com [63.65.221.10]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA08887 for ; Thu, 11 Jan 2001 08:59:07 -0800 (PST)
Received: from CONVERSION-DAEMON by ext-mail.valicert.com (PMDF V5.2-33 #46613) id <[email-masked]> for [email-masked]; Thu, 11 Jan 2001 09:04:14 -0800 (PST)
Received: from polaris.valicert.com ([192.168.2.34]) by ext-mail.valicert.com (PMDF V5.2-33 #46613) with ESMTP id <[email-masked]>; Thu, 11 Jan 2001 09:04:14 -0800 (PST)
Received: by exchange.valicert.com with Internet Mail Service (5.5.2650.21) id ; Thu, 11 Jan 2001 09:00:11 -0800
Content-return: allowed
Date: Thu, 11 Jan 2001 09:00:10 -0800
From: Frank Balluffi
Subject: RE: DPD & DPV requirements - Recursion Issues
To: "'Covey, Carlin'" , [email-masked]
Message-id: <[email-masked]>
MIME-version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-type: text/plain; charset="iso-8859-1"

Carlin Covey wrote:

> was mentioned in a previous email. This syntactic complexity
> is avoided
> if server 1 extracts information from server 2's response and
> repackages
> it into a nonrecursive data structure that it then sends to
> the client.

I agree. I like the following:

client
|
| (DPD/DPV)
|
server 1
|
| (supporting protocol (e.g., OCSP))
|
server 2
|
| (supporting protocol)
|
server 3

or

client
|
| (DPD/DPV)
|
server 1
| |
| |
| |
server 2 server 3

more than:

client
|
| (DPD/DPV)
|
server 1
|
| (DPD/DPV)
|
server 2

Frank

> -----Original Message-----
> From: Covey, Carlin [mailto:[email-masked]]
> Sent: Thursday, January 11, 2001 11:18 AM
> To: [email-masked]
> Subject: RE: DPD & DPV requirements - Recursion Issues
>
>
> Frank and Peter,
>
> I'd be happy for someone to define a set of terms for use in this
> context, if it would benefit the discussion.
>
> The "transitive trust" issue that was referred to earlier arises in
> the context of "relaying" DPV status. The client asks server 1 to
> validate the status of a certificate, and server 1 "relays" some or
> all of the validation process to server 2. When the response comes
> back from server 2, server 1 then prepares a response to the client
> based wholly or in part on the information obtained from server 2.
>
> When I originally used the term "recursion" I had in mind a recursive
> data structure, i.e. a DPD response that contains another DPD
> response that might in turn contain another DPD response. This is one
> method for returning the "relayed" status information to the client.
> This particular method raises the syntactic complexity issue that
> was mentioned in a previous email. This syntactic complexity
> is avoided
> if server 1 extracts information from server 2's response and
> repackages
> it into a nonrecursive data structure that it then sends to
> the client.
> As I mentioned in an earlier email, one advantage of the
> recursive data
> structure is that it allows the optional timestamp on the embedded DPD
> responses to be retained.
>
> Regards,
>
> Carlin
>
> ------------------------------
>
> - Carlin Covey
> Cylink Corp.
>
>
>
> -----Original Message-----
> From: Peter Sylvester [mailto:[email-masked]]
> Sent: Thursday, January 11, 2001 8:59 AM
> To: [email-masked]; [email-masked]; [email-masked]
> Subject: RE: DPD & DPV requirements - Recursion Issues
>
>
> > Content-Length: 3514
> >
> > Wouldn't a DPD/DPV server solely carry out the task of
> discovering and
> > validating paths, and possibly use other protocols (e.g.,
> LPAP, OCSP,
> etc.),
> > which might be recursive, to assist in this process? So
> unless sub-DPD/DPV
> > servers take part in path discovery or validation I would
> not describe
> > DPD/DPV as recursive.
> >
>
> 'Recursive' lay not be the right word, but you can have relaying
> or delegation or proxying.
>
> In the above, replace 'OCSP' by DPV': - instaed of asking
> for the revocation status, you ask for the validity status.
> This isn't that different, and even in OCSP you already have
> relaying.
>

Received: from po1.bbn.com (PO1.BBN.COM [192.1.50.38]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA08759 for ; Thu, 11 Jan 2001 08:58:41 -0800 (PST)
Received: from [171.78.30.107] (comsec.bbn.com [171.78.30.107]) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id MAA23253; Thu, 11 Jan 2001 12:03:47 -0500 (EST)
Mime-Version: 1.0
X-Sender: [email-masked]
Message-Id:
In-Reply-To:
References:
Date: Thu, 11 Jan 2001 12:01:48 -0500
To: Polar Humenn
From: Stephen Kent
Subject: Re: Basic Cert-2-Directory mapping question
Cc: [email-masked]
Content-Type: multipart/alternative; boundary="============_-1232889792==_ma============"

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

Polar,

>
>I'll jump on the band wagon as Peter, Anders, and a few others. DN's to
>me, have never been hierarchical. They are basically converted to strings,
>or hashed, and used, searched for, and compared, that way. I really enjoy
>the "flat" name space, Simple, and normal people, as well as "simple"
>programmers know how to deal with it. It's not really flat, but comes in
>two parts. 1. tell me where to find it, 2 and tell me how to find it from
>there. HTTP is just one good example illustrated by Peter, SDSI (SPKI?) is
>another. (And I for one, like that revocation scheme, much better then
>trying to find CRLs and calculate delta CRLs, what a waste of precious
>processing time!). The whole X.500 thing, in my mind is so bizzare. It's
>so complex, and with OSCP servers, and DPV and such, the whole thing is
>going to start looking like Kerberos pretty soon, which has one of these
>so called flat namespaces.

You're confused. DNs are hierarchical, by definition. That's not open
to debate; it is a function of the fact that they are directory
distinguished names, inherited from X.500, as Sharon has pointed out.
The fact that some people may have chosen to treat them in other ways
does not change the semantics of the name form, as specified by many
standards.

Kerberos may be good example of a flat name space, but only within a
single realm, i.e., to scale beyond one realm one must use a name
with a realm ID. That already makes it a two level, not flat, name
space. Only by imposing conventions on Kerberos names, tied to the
DNS (which, last time I looked, was hierarchical) does one manage to
ensure uniqueness, scaleability, and locatability for KDCs
(piggybacking on DNS).

All the criticisms re hierarchic name spaces apply not only to DNs
but to DNS names as well, a system that enables us to engage in this
debate via e-mail. The limitations of poor use of hierarchic names
spaces is also evident in the DNS, mostly in the form of the legacy
TLDs: .com, .net, .org, .mil, .gov, .edu. These flatten the space
considerably and overload the system, except where we have become
xenocentric and restricted use of U.S. entities (e.g., for gov and
mil). Whne Jon Postel managed name assignment, people could rely on
.org and .net being appropriately assigned, something that is no
longer true. The rush for every company and many individuals to be
listed under .com. vs. under country codes that then can have a .com
subdomain, has diminished the benefits that should result from this
structure, and places greater and greater demands on the server
infrastructure.

I already explained why hierarchic name spaces are desirable, so I
won't repeat the arguments. Despite all the fun that results from
this discussion, PKIX is not the right forum in which to have the
debate. We're not a directory WG. We support various options for
names, thanks to the generalname construct of v3 certs. It's useful
to discuss how to solve problems related to cert repository
discovery, but since we are not a directory WG, keep in mind the
limitations on our ability to influence the results of such
discussions.

Steve

--============_-1232889792==_ma============
Content-Type: text/enriched; charset="us-ascii"

Polar,

I'll jump on the band wagon as Peter, Anders, and a few others. DN's
to

me, have never been hierarchical. They are basically converted to
strings,

or hashed, and used, searched for, and compared, that way. I really
enjoy

the "flat" name space, Simple, and normal people, as well as "simple"

programmers know how to deal with it. It's not really flat, but comes
in

two parts. 1. tell me where to find it, 2 and tell me how to find it
from

there. HTTP is just one good example illustrated by Peter, SDSI (SPKI?)
is

another. (And I for one, like that revocation scheme, much better then

trying to find CRLs and calculate delta CRLs, what a waste of precious

processing time!). The whole X.500 thing, in my mind is so bizzare.
It's

so complex, and with OSCP servers, and DPV and such, the whole thing
is

going to start looking like Kerberos pretty soon, which has one of
these

so called flat namespaces.

You're confused. DNs are hierarchical, by definition. That's not open
to debate; it is a function of the fact that they are
directory distinguished names, inherited from
X.500, as Sharon has pointed out. The fact that some people may have
chosen to treat them in other ways does not change the semantics of the
name form, as specified by many standards.

Kerberos may be good example of a flat name space, but only within a
single realm, i.e., to scale beyond one realm one must use a name with
a realm ID. That already makes it a two level, not flat, name space.
Only by imposing conventions on Kerberos names, tied to the DNS (which,
last time I looked, was hierarchical) does one manage to ensure
uniqueness, scaleability, and locatability for KDCs (piggybacking on
DNS).

All the criticisms re hierarchic name spaces apply not only to DNs but
to DNS names as well, a system that enables us to engage in this debate
via e-mail. The limitations of poor use of hierarchic names spaces is
also evident in the DNS, mostly in the form of the legacy TLDs: .com,
.net, .org, .mil, .gov, .edu. These flatten the space considerably and
overload the system, except where we have become xenocentric and
restricted use of U.S. entities (e.g., for gov and mil). Whne Jon
Postel managed name assignment, people could rely on .org and .net
being appropriately assigned, something that is no longer true. The
rush for every company and many individuals to be listed under .com.
vs. under country codes that then can have a .com subdomain, has
diminished the benefits that should result from this structure, and
places greater and greater demands on the server infrastructure.

I already explained why hierarchic name spaces are desirable, so I
won't repeat the arguments. Despite all the fun that results from this
discussion, PKIX is not the right forum in which to have the debate.
We're not a directory WG. We support various options for names, thanks
to the generalname construct of v3 certs. It's useful to discuss how to
solve problems related to cert repository discovery, but since we are
not a directory WG, keep in mind the limitations on our ability to
influence the results of such discussions.

Steve

--============_-1232889792==_ma============--

Received: from edelweb.fr (edelweb.fr [212.234.46.16]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA07938 for ; Thu, 11 Jan 2001 08:54:23 -0800 (PST)
Received: from champagne.edelweb.fr (localhost.edelweb.fr [127.0.0.1]) by edelweb.fr with ESMTP id RAA29214; Thu, 11 Jan 2001 17:59:10 +0100 (MET)
Received: from champagne.edelweb.fr (champagne.edelweb.fr [193.51.14.161]) by edelweb.fr (nospam/1.3); Thu, 11 Jan 2001 17:59:10 +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 RAA04188; Thu, 11 Jan 2001 17:59:08 +0100 (MET)
From: Peter Sylvester
Received: (sylvest@localhost) by emeriau.edelweb.fr (8.7.6/8.6.6) id RAA17815; Thu, 11 Jan 2001 17:59:08 +0100 (MET)
Date: Thu, 11 Jan 2001 17:59:08 +0100 (MET)
Message-Id: <[email-masked]>
To: [email-masked]
Subject: RE: DPD & DPV requirements - Let us Recurse
Cc: [email-masked]

>
> Peter,
>
> I thinbk we are in agreement that the set of data returned by a DPD
> or DPV server will be limited in scope and well defined, i.e.,
> sequences of certs, CRLs, and OCSP responses are the initial set.

s/i.e./e.g./

> Whether we allow recursion and allow DPV responses is still an open
> question.

As you say there is 'recursion' and 'DPV responses'.

- If we allow an OCSP response as a statement about a cert status
I don't see whether why DPV status is not possible, in particular
if OCSP is the base protocol, one could consider that we already
a this available.

- Indeed, it remains the question whether we want these services
just relay the same request to another server, and what should
be the request and response format changes, in particular in
order to provide for loop detection.

For the second point another strawman requirement:

In some environment a DPV server may be operated as a relay/broker
to other services. In order to cover possible misconfiigurations
in such situations, the protocols must provide an efficient means
to detect request loops. hop counts or 'Received and relayed by XXX'
trace elements are possible means.

It is up to the relaying server how to interprete and transform
a response from another server. In any case a DPV must add apply
its own authentication mecanism, e;g. its own signature. Possible
reponses include an encapsulation of the initial reponse, or simple
replacement of the securiy envelope.

Received: from po1.bbn.com (PO1.BBN.COM [192.1.50.38]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA06745 for ; Thu, 11 Jan 2001 08:48:48 -0800 (PST)
Received: from [171.78.30.107] (comsec.bbn.com [171.78.30.107]) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id LAA21654; Thu, 11 Jan 2001 11:53:50 -0500 (EST)
Mime-Version: 1.0
X-Sender: [email-masked]
Message-Id:
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]>
Date: Thu, 11 Jan 2001 11:51:03 -0500
To: "Anders Rundgren"
From: Stephen Kent
Subject: Re: Basic Cert-2-Directory mapping question
Cc:
Content-Type: text/plain; charset="us-ascii" ; format="flowed"

Anders,

>Peter,
>
> > >Flat name spaces scale poorly, lead to confusion, and are thus
>not attractive
> > >in various ways. People do like flat name spaces, until they
>trip over the
> > >limitations they embody, then they complain and look for magic solutions.
> > >I've seen no appropriate magic for this problem.
> >
> > Have you actually seen the problem though? It's automatically assumed that
> > there's some vast, unassailable problem which hierarchical names
>will solve,
> > but I don't think I've ever seen it except as some special-case, often
> > hypothetical situation which is used to justify the need for DNs
>(or whatever).
> > In the real world people have been using their flat, non-scalable
>name spaces
> > for several decades without any sign that civilisation is about
>to collapse.
>
>I second that 100%. The only thing you gain by hierarchical cert
>names is rigidness
>(i.e. can only be used in a certain regime) and low trace ability
>(change position
>and then you become another identity). So even for closed PKI's we do have
>a serious mapping issue IMNSHO.

Hierarchic name spaces are desirable for many reasons irrespective of
the narrow focus of this discussion. (Note that DNS is an example of
such a name space.) They are attractive because they allow easy
distribution of name creation without fear of collision, and if one
aligns repositories with the name space, distribution of the database
is also facilitated. X.500 has not been widely successful, in part
because there is no authority to impose name space constraints,
mediate disputes, etc. DNS is successful because we have such
authorities and because folks are motivated to operate their parts of
the tree reliably, else Internet access is dramatically affected. So,
don't confuse X.500 problems with hierarchic name space problems.

Steve

Received: from po1.bbn.com (PO1.BBN.COM [192.1.50.38]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA06711 for ; Thu, 11 Jan 2001 08:48:45 -0800 (PST)
Received: from [171.78.30.107] (comsec.bbn.com [171.78.30.107]) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id LAA21658; Thu, 11 Jan 2001 11:53:50 -0500 (EST)
Mime-Version: 1.0
X-Sender: [email-masked]
Message-Id:
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]>
Date: Thu, 11 Jan 2001 11:53:34 -0500
To: Michael =?iso-8859-1?Q?Str=F6der?=
From: Stephen Kent
Subject: Re: Basic Cert-2-Directory mapping question
Cc: "[email-masked]"
Content-Type: text/plain; charset="us-ascii" ; format="flowed"

Michael,

>Stephen Kent wrote:
> >
> > >IMHO one of the main problems with
> > >PKIX is that there's so much X.500 in it. ;-)
> >
> > Perhaps thinking about the WG name will clarify why there's so much
> > X.500 in PKIX.
>
>I can also rephrase the sentence with having the same result by
>saying:
>The main problems with PKIX is that there's not much X.500 in
>current implementations any more.

That's a better statement.

Steve

Received: from ext-mail.valicert.com (ns1.valicert.com [63.65.221.10]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA06173 for ; Thu, 11 Jan 2001 08:46:37 -0800 (PST)
Received: from CONVERSION-DAEMON by ext-mail.valicert.com (PMDF V5.2-33 #46613) id <[email-masked]> for [email-masked]; Thu, 11 Jan 2001 08:51:45 -0800 (PST)
Received: from polaris.valicert.com ([192.168.2.34]) by ext-mail.valicert.com (PMDF V5.2-33 #46613) with ESMTP id <[email-masked]> for [email-masked]; Thu, 11 Jan 2001 08:51:45 -0800 (PST)
Received: by exchange.valicert.com with Internet Mail Service (5.5.2650.21) id ; Thu, 11 Jan 2001 08:47:42 -0800
Content-return: allowed
Date: Thu, 11 Jan 2001 08:47:41 -0800
From: Frank Balluffi
Subject: RE: DPD & DPV requirements
To: [email-masked]
Message-id: <[email-masked]>
MIME-version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-type: text/plain; charset="iso-8859-1"

Some thoughts ...

1. Purpose: Qualified Paths Only

To me, DPD/DPV should be a protocol for requesting one or more qualified
paths by value or by reference, period. By qualified path, I mean a path
that satisfies some PKIX-defined standard (e.g., section 6 of RFC 2459). I
do not see value in returning paths that the server can either not qualify
or qualify in some other manner. Because PKIX does not define a standard for
path discovery, I would argue that the only discovered paths allowable
should be valid paths. What is the value of a server responding with, "Gee,
I threw this path together, which might satisfy your needs."

2. Request

The client should supply some subset of each requested path which must
include the least significant certificate and optionally:

- one or more intermediate certificates
- one or more trusted certificates

For ASN.1 applications, certificates should be passed by value. For XML (by
which I mean PKI-unaware) applications, certificates should be passed by
reference (e.g., issuer + serial number + ...). Optionally, an XML
application could pass certificates as opaque elements.

The client should have the ability to provide PKIX-defined path validation
parameters by value or by reference (e.g., by OID). Since the only known
parameters are those defined in RFC 2459, I do not see value in allowing the
client to supply other parameters. By this, I am not implying that others do
not have a need for custom parameters.

Should the protocol allow a client to supply revocation information in its
request, the server should have the right to refuse using such information.
The server may not trust the supplier of the revocation information or in
the case of an OCSP response, the server may not trust the supposed nonce.

For ASN.1 applications, parameters and revocation information should be
passed by value or by reference. I do not see value in referring to an OCSP
response, but I do see value in referring to a CRL.

For XML applications, parameters and revocation information should be passed
by reference.

3. Response

Should the protocol allow a server to ignore the parameters in a request and
the server ignores the parameters, the server MUST return the parameters
that it used in its response. If the server does not return parameters in
its response, the client should be able to assume that the server used the
parameters in the request and the server should include a digest of the
request in its response.

I do not see a need to return parameters to an XML application unless it can
do so by reference, which I am having difficulty imagining.

For XML applications, each valid path should be returned by reference (e.g.,
as an ordered collection of issuer + serial number + ...) and optionally as
an opaque element (e.g., base-64 encoded SEQUENCE OF Certificate). As others
have pointed out, all paths should begin with the least-significant
certificate.

4. Time Stamping

Time stamping functionality should NOT be included in DPD/DPV. The client
should be free to send its own request to a TSA of its liking.

Received: from ns.celocom.se ([email-masked] [212.209.40.66]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA05271 for ; Thu, 11 Jan 2001 08:34:26 -0800 (PST)
Received: by ns.celocom.se; id RAA09552; Thu, 11 Jan 2001 17:39:33 +0100 (CET)
Received: from unknown(10.10.10.1) by ns.celocom.se via smap (V5.0) id xma009547; Thu, 11 Jan 01 17:38:38 +0100
Received: from celocom.com (stan.celocom.se [10.10.10.129]) by zap.celocom.se (8.8.7/8.8.7) with ESMTP id RAA01022; Thu, 11 Jan 2001 17:38:37 +0100
Message-ID: <[email-masked]>
Date: Thu, 11 Jan 2001 17:38:37 +0100
From: Oscar Jacobsson
Organization: Celo Communications
X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: "Slone, Skip"
CC: "'Sharon Boeyen'" , [email-masked]
Subject: Re: Basic Cert-2-Directory mapping question
References:
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

"Slone, Skip" wrote:
> I would just like to add that, in addition to X.521 and some LDAP
> specs, the ability to recognize civil naming attributes in the issuer
> and subject fields of an X.509v3 cert is mandated in RFC 2459 (ref
> section 4.1.2.4) and in son-of-2459.

True, and I don't think "recognizing" them as certificates is the issue
here. More on this as we get to your proposed requirement.

> In terms of a requirement for this WG, as I see it, we have a
> requirement to be able to find the associated repository for any
> validly constructed PKIX-compliant certificate.

I would prefer this requirement restricted to apply only to those
certificates that were consciously created for deployment on the
Internet.

Come to think of it, maybe this would be better off split into two
separate discussions. One on creating/endorsing/applying a naming scheme
that will allow us to deploy PKIs over the Internet, for which I'd say
that repository discovery would be a must, and another on handling the
"legacy" (as in non-Internet based) X.521-style certificates already in
use, probably most importantly those shipped along with our web
browsers.

> I'm open to suggestions on HOW to resolve these domain-amiguous
> certs.

The problem here is in their very ambiguity. The subjects of these
certificates are not necessarily directory entries in the first place. I
know I've personally held a sizeable amount of certificates, the
subjects _and_ issuers of which have been completely fictitious. Or
maybe not fictitious, but completely arbitrary anyway. Of all the
certificates ever issued to me, no two have ever used the same DN.

Regards,

//oscar

Received: from exchange.cylink.com (exchange.cylink.com [192.43.161.25]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA04311 for ; Thu, 11 Jan 2001 08:20:51 -0800 (PST)
Received: by exchange.cylink.com with Internet Mail Service (5.5.2650.21) id ; Thu, 11 Jan 2001 08:18:02 -0800
Message-ID: <[email-masked]>
From: "Covey, Carlin"
To: [email-masked]
Subject: RE: DPD & DPV requirements - Recursion Issues
Date: Thu, 11 Jan 2001 08:17:58 -0800
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"

Frank and Peter,

I'd be happy for someone to define a set of terms for use in this
context, if it would benefit the discussion.

The "transitive trust" issue that was referred to earlier arises in
the context of "relaying" DPV status. The client asks server 1 to
validate the status of a certificate, and server 1 "relays" some or
all of the validation process to server 2. When the response comes
back from server 2, server 1 then prepares a response to the client
based wholly or in part on the information obtained from server 2.

When I originally used the term "recursion" I had in mind a recursive
data structure, i.e. a DPD response that contains another DPD
response that might in turn contain another DPD response. This is one
method for returning the "relayed" status information to the client.
This particular method raises the syntactic complexity issue that
was mentioned in a previous email. This syntactic complexity is avoided
if server 1 extracts information from server 2's response and repackages
it into a nonrecursive data structure that it then sends to the client.
As I mentioned in an earlier email, one advantage of the recursive data
structure is that it allows the optional timestamp on the embedded DPD
responses to be retained.

Regards,

Carlin

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

- Carlin Covey
Cylink Corp.

-----Original Message-----
From: Peter Sylvester [mailto:[email-masked]]
Sent: Thursday, January 11, 2001 8:59 AM
To: [email-masked]; [email-masked]; [email-masked]
Subject: RE: DPD & DPV requirements - Recursion Issues

> Content-Length: 3514
>
> Wouldn't a DPD/DPV server solely carry out the task of discovering and
> validating paths, and possibly use other protocols (e.g., LPAP, OCSP,
etc.),
> which might be recursive, to assist in this process? So unless sub-DPD/DPV
> servers take part in path discovery or validation I would not describe
> DPD/DPV as recursive.
>

'Recursive' lay not be the right word, but you can have relaying
or delegation or proxying.

In the above, replace 'OCSP' by DPV': - instaed of asking
for the revocation status, you ask for the validity status.
This isn't that different, and even in OCSP you already have
relaying.

Received: from mailgw2a.lmco.com (mailgw2a.lmco.com [192.91.147.7]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA03116 for ; Thu, 11 Jan 2001 08:03:55 -0800 (PST)
Received: from emss03g01.ems.lmco.com (emss03g01.ems.lmco.com [141.240.4.144]) by mailgw2a.lmco.com (8.8.8/8.8.8) with ESMTP id LAA24117; Thu, 11 Jan 2001 11:09:02 -0500 (EST)
Received: from CONVERSION-DAEMON by lmco.com (PMDF V5.2-32 #38888) id <[email-masked]>; Thu, 11 Jan 2001 11:08:11 -0500 (EST)
Received: from emss03i00.ems.lmco.com ([141.240.31.211]) by lmco.com (PMDF V5.2-32 #38888) with ESMTP id <[email-masked]>; Thu, 11 Jan 2001 11:07:58 -0500 (EST)
Received: by emss03i00.orl.lmco.com with Internet Mail Service (5.5.2650.21) id ; Thu, 11 Jan 2001 11:09:06 -0500
Content-return: allowed
Date: Thu, 11 Jan 2001 11:09:05 -0500
From: "Slone, Skip"
Subject: RE: Basic Cert-2-Directory mapping question
To: =?ISO-8859-1?Q?=27Michael_Str=F6der=27?= , [email-masked]
Message-id:
MIME-version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id IAA03117

Here's a use case that fits my scenario:

An RP needs to find a directory entry corresponding to a given certificate,
where:
- the certificate subject name uses civil-style naming,
- the RP's known directories have no knowledge (direct or indirect), and
- the subject's domain name is not known and cannot be derived.

With today's tools, this use case fails:
- LDAPv3 referrals fail due to the lack of knowledge,
- PKIXREP fails due to the lack of a domain name.

Am I overlooking some tool that can do the job?

-- Skip

-----Original Message-----
From: Michael Ströder [mailto:[email-masked]]
Sent: Thursday, January 11, 2001 10:31 AM
To: [email-masked]
Subject: Re: Basic Cert-2-Directory mapping question

"Slone, Skip" wrote:
>
> If LDAPv3 referrals were sufficient, we wouldn't be having this
> conversation.

Who said that LDAPv3 referrals are the overall solution without
prior configuration?

> LDAPv3 referrals WILL work in the following two cases:
>
> 1) where my server's administrator already knows how to
> find the target name
> space, or
> 2) where my server and the server holding the target name space
> participate in some fully-connected DIT
> [..]

Yes.

> What I'm discussing is a way to fill in the gap where (1) my server does
not
> already know how to find a certain name space, and (2) there's a knowledge
> disconnect between my server and the server holding the target. In this
> case, LDAPv3 referrals WILL NOT work.

Yes.

And RFC2377 does not work without SRV RRs. Yes. And I can't access
http://www.ietf.org without somebody having added the entry
www.ietf.org to DNS. Yes. And... Yes.

No doubt, if you do not know any service access point or you don't
have any rule how to derive the service access point from an
information at hand you can't access the service. Yes.

Now about which *use-case* are we talking here?

Ciao, Michael.

Received: from edelweb.fr (edelweb.fr [212.234.46.16]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA02330 for ; Thu, 11 Jan 2001 07:53:43 -0800 (PST)
Received: from champagne.edelweb.fr (localhost.edelweb.fr [127.0.0.1]) by edelweb.fr with ESMTP id QAA28734; Thu, 11 Jan 2001 16:58:42 +0100 (MET)
Received: from champagne.edelweb.fr (champagne.edelweb.fr [193.51.14.161]) by edelweb.fr (nospam/1.3); Thu, 11 Jan 2001 16:58:43 +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 QAA03800; Thu, 11 Jan 2001 16:58:41 +0100 (MET)
From: Peter Sylvester
Received: (sylvest@localhost) by emeriau.edelweb.fr (8.7.6/8.6.6) id QAA17799; Thu, 11 Jan 2001 16:58:41 +0100 (MET)
Date: Thu, 11 Jan 2001 16:58:41 +0100 (MET)
Message-Id: <[email-masked]>
To: [email-masked], [email-masked], [email-masked]
Subject: RE: DPD & DPV requirements - Recursion Issues

> Content-Length: 3514
>
> Wouldn't a DPD/DPV server solely carry out the task of discovering and
> validating paths, and possibly use other protocols (e.g., LPAP, OCSP, etc.),
> which might be recursive, to assist in this process? So unless sub-DPD/DPV
> servers take part in path discovery or validation I would not describe
> DPD/DPV as recursive.
>

'Recursive' lay not be the right word, but you can have relaying
or delegation or proxying.

In the above, replace 'OCSP' by DPV': - instaed of asking
for the revocation status, you ask for the validity status.
This isn't that different, and even in OCSP you already have
relaying.

Received: from karon.dynas.se (karon.dynas.se [192.71.43.4]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id HAA02037 for ; Thu, 11 Jan 2001 07:50:40 -0800 (PST)
Received: (qmail 90871 invoked from network); 11 Jan 2001 15:55:46 -0000
Received: from spirit.sto.dynas.se (HELO spirit.dynas.se) (172.16.1.10) by karon.sto.dynas.se with SMTP; 11 Jan 2001 15:55:46 -0000
Received: (qmail 27676 invoked from network); 11 Jan 2001 15:55:46 -0000
Received: from unknown (HELO rsasecurity.com) (172.16.13.119) by spirit.dynas.se with SMTP; 11 Jan 2001 15:55:46 -0000
Sender: sjosefsson
Message-ID: <[email-masked]>
Date: Thu, 11 Jan 2001 16:55:33 +0100
From: Simon Josefsson
X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.12-20 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Michael =?iso-8859-1?Q?Str=F6der?=
CC: [email-masked]
Subject: Re: Basic Cert-2-Directory mapping question
References: <[email-masked]>
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit

Michael Ströder wrote:

> Example for 1.:
>
> a) Assuming you want to locate an entry for
> [email-masked] for retrieving the certificate and your
> client implementation is capable of searching the SRV RR in the DNS.
>
> 1. You search for SRV record _ldap._tcp.www.stroeder.com. -> no
> result
>
> 2. You search for SRV record _ldap._tcp.stroeder.com. -> RR points
> to LDAP server directory.adm.stroeder.com.
>
> 3. You're doing the LDAP search
> ldap://directory.adm.stroeder.com/dc=stroeder,dc=com??sub?(mail=[email-masked])

Another approach might be to retrieve the certificate from the DNS in
the first step, such as:

1. You search for CERT record webmaster.www.stroeder.com -> gets
certificate.

For an application that already implement "advanced" DNS features such
as SRV, this is a simpler and faster solution.

I believe uses of SRV records to locate LDAP servers to lookup a
certificate for a hostname or email address may be replaced with simply
looking up a CERT record. I also believe exactly this kind of operation
is quite common (mail clients). This solution is also less complicated.

Of course, CERT records would not help locating a certificate with a
"cn=foo, o=bar, c=US" kind of certificate, but then, SRV wouldn't
either. In most of these cases you'll probably have the LDAP server
pre-configured anyway.

(CERT records are documented in RFC 2538.)

/Simon

Received: from mailgw2a.lmco.com (mailgw2a.lmco.com [192.91.147.7]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA00960 for ; Thu, 11 Jan 2001 07:40:38 -0800 (PST)
Received: from emss03g01.ems.lmco.com (emss03g01.ems.lmco.com [141.240.4.144]) by mailgw2a.lmco.com (8.8.8/8.8.8) with ESMTP id KAA21513; Thu, 11 Jan 2001 10:45:42 -0500 (EST)
Received: from CONVERSION-DAEMON by lmco.com (PMDF V5.2-32 #38888) id <[email-masked]>; Thu, 11 Jan 2001 10:44:48 -0500 (EST)
Received: from emss03i00.ems.lmco.com ([141.240.31.211]) by lmco.com (PMDF V5.2-32 #38888) with ESMTP id <[email-masked]>; Thu, 11 Jan 2001 10:44:13 -0500 (EST)
Received: by emss03i00.orl.lmco.com with Internet Mail Service (5.5.2650.21) id ; Thu, 11 Jan 2001 10:45:21 -0500
Content-return: allowed
Date: Thu, 11 Jan 2001 10:45:19 -0500
From: "Slone, Skip"
Subject: RE: Basic Cert-2-Directory mapping question
To: "'Sharon Boeyen'" , "'Oscar Jacobsson'"
Cc: [email-masked]
Message-id:
MIME-version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-type: MULTIPART/ALTERNATIVE; BOUNDARY="Boundary_(ID_YoGC80SyjBHJbuOumsLDJw)"

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

--Boundary_(ID_YoGC80SyjBHJbuOumsLDJw)
Content-type: text/plain
Content-transfer-encoding: 7BIT

I would just like to add that, in addition to X.521 and some LDAP specs, the
ability to recognize civil naming attributes in the issuer and subject
fields of an X.509v3 cert is mandated in RFC 2459 (ref section 4.1.2.4) and
in son-of-2459.

In terms of a requirement for this WG, as I see it, we have a requirement to
be able to find the associated repository for any validly constructed
PKIX-compliant certificate. The pkixref draft solves the problem for certs
with names constructed according to 2377, but it doesn't solve the problem
for PKIX-compliant certs with names constructed otherwise. (As far as the
argument of plucking the domain name off the email containing the cert, I'm
not convinced that we will always and in all cases be able to make an
association between a cert and an email address.)

I'm open to suggestions on HOW to resolve these domain-amiguous certs. I've
outline one possible approach (using country-to-ccTLD mapping in conjunction
with a new type of DNS RR). An alternative approach might be to define a
new certificate extension containing a repository URL. Another suggestion
was made to include the repository URL information in the DN. (I personally
get squeamish every time someone suggests overloading the semantics of yet
another attribute, but I could probably live through it :-)

That's my two cents' worth for now...

-- Skip

-----Original Message-----
From: Sharon Boeyen [mailto:[email-masked]]
Sent: Thursday, January 11, 2001 8:28 AM
To: 'Oscar Jacobsson'; Slone, Skip
Cc: [email-masked]
Subject: RE: Basic Cert-2-Directory mapping question

The naming scheme (at least the higher levels of it) that is being
referenced is
originally outlined in an informative annex to X.521 and its also in some
LDAP specs.

In some countries this type of naming is being more readily adopted than in
others. It
is my VERY strong belief that trying to impose a single naming structure or
a single naming
hierarchy for all applications and all environments simply is a recipe for
disaster. The US
has historically been the absolute most difficult place to do this in the
past (reference
the North American Directory Forum effort that Bob references). Regulatory
differences and
differing business models and operating environments lead to different
naming structures.

Borrowing from Marshall Rose's writing style, let me step on my soapbox for
a minute:

Rather than try to name the world and every object in it, I believe a more
constructive approach
is to accept the fact that different parts of the world and different
environments will have
use a variety of nameforms and work within that context to make the best use
of the tools we have
at our disposal to find the information that is needed. We should not be
trying to solve the "global
directory problem", we are the PKIX WG. We should ensure that appropriate
PKIX information can be located and
retrieved. We are not the global naming police either and should not try to
impose the rules that
anyone uses to name entities to which they issue certificates. Finding a
particular certificate is
one problem and determining whether or not to 'trust' and make use of it is
another. Repository
locator discussions should be restricted to the former.

Step off soapbox.

I do agree that 2377 and the PKIX repository locator document are a nice fit
and will satisfy a
lot of the requirement for many environments. Those that use the
geographical, DNS or other style
of DNs for the certs and directories can all be supported for applications
where the domain name is
known. There may however be some additional support tools that can defined
to ease the 'knowledge'
gathering process as Skip suggests. One that was raised earlier on the list
and for which we don't yet
have an answer is the provision of search base data for LDAP SRV records for
PKI repositories. If there
is a way to add additional information to DNS that will help resolve these
types of issues then I'm
all for it. Another option that might be worth exploring is piggybacking
repository locator information
in certificate management protocols (e.g. when one CA sends a cert request
to another CA it could provide
the details of how to access its repository in that cert requests - it is
relying parties from the issuer's
domain that will need that access). Again that won't satisfy every case,
since strict hierarchies that
don't cross-certify with other domains wouldn't be covered). Skip, I'm not
necessarily objecting to the
mapping you are proposing, but am trying to understand within the context of
PKI requirements and I'm not
quite there yet :-)

However, I really would like to see us work from a focused 'requirements'
standpoint rather
than from the abstract level that a lot of this thread seems to have.

Sharon

> -----Original Message-----
> From: Oscar Jacobsson [ mailto:[email-masked]
]
> Sent: Thursday, January 11, 2001 4:47 AM
> To: Slone, Skip
> Cc: [email-masked]
> Subject: Re: Basic Cert-2-Directory mapping question
>
>
> "Slone, Skip" wrote:
> > Since civil-to-DNS name mapping typically fails to yield to a
> > character string transliteration algorithm (e.g., "o=Joe's Bar and
> > Grill" does not readily translate to are-you-hungry.com),
> this leaves
> > us with a choice of either registering the translations or
> > complaining that it can't be done.
>
> Pardon my ignorance of these matters, but where exactly is this civil
> naming scheme outlined?
>
> IMHO the DNS-based naming scheme for in RFC 2377 has been around for a
> couple years now, and when combined with the repository locator
> documents I'd say it provides the information necessary for an RP to
> locate the relevant repository.
>
> //oscar
>

--Boundary_(ID_YoGC80SyjBHJbuOumsLDJw)
Content-type: text/html
Content-transfer-encoding: 7BIT

RE: Basic Cert-2-Directory mapping question

I
would just like to add that, in addition to X.521 and some LDAP specs, the
ability to recognize civil naming attributes in the issuer and subject fields of
an X.509v3 cert is mandated in RFC 2459 (ref section 4.1.2.4) and in
son-of-2459.

In
terms of a requirement for this WG, as I see it, we have a requirement to be
able to find the associated repository for any validly constructed
PKIX-compliant certificate. The pkixref draft solves the problem for certs with
names constructed according to 2377, but it doesn't solve the problem for
PKIX-compliant certs with names constructed otherwise.  (As far as the
argument of plucking the domain name off the email containing the cert, I'm not
convinced that we will always and in all cases be able to make an association
between a cert and an email address.)

I'm
open to suggestions on HOW to resolve these domain-amiguous certs.  I've
outline one possible approach (using country-to-ccTLD mapping in conjunction
with a new type of DNS RR).  An alternative approach might be to define a
new certificate extension containing a repository URL.  Another suggestion
was made to include the repository URL information in the DN.  (I
personally get squeamish every time someone suggests overloading the semantics
of yet another attribute, but I could probably live through it
:-)

That's
my two cents' worth for now...

-- Skip

-----Original Message-----
From: Sharon Boeyen
[mailto:[email-masked]]
Sent: Thursday, January 11, 2001
8:28 AM
To: 'Oscar Jacobsson'; Slone, Skip
Cc:
[email-masked]
Subject: RE: Basic Cert-2-Directory mapping
question

The naming scheme (at least the higher levels of it) that is
being referenced is
originally outlined in an
informative annex to X.521 and its also in some LDAP specs.

In some countries this type of naming is being more readily
adopted than in others. It
is my VERY strong belief
that trying to impose a single naming structure or a single naming

hierarchy for all applications and all environments simply is
a recipe for disaster. The US
has historically been
the absolute most difficult place to do this in the past (reference

the North American Directory Forum effort that Bob
references). Regulatory differences and
differing
business models and operating environments lead to different naming
structures.

Borrowing from Marshall Rose's writing style, let me step on
my soapbox for a minute:

Rather than try to name the world and every object in it, I
believe a more constructive approach
is to accept the
fact that different parts of the world and different environments will have

use a variety of nameforms and work within that
context to make the best use of the tools we have
at
our disposal to find the information that is needed. We should not be trying
to solve the "global
directory problem", we are the
PKIX WG. We should ensure that appropriate PKIX information can be located and

retrieved. We are not the global naming police either
and should not try to impose the rules that
anyone
uses to name entities to which they issue certificates. Finding a particular
certificate is
one problem and determining whether or
not to 'trust' and make use of it is another. Repository
locator discussions should be restricted to the former.

Step off soapbox.

I do agree that 2377 and the PKIX repository locator document
are a nice fit and will satisfy a
lot of the
requirement for many environments. Those that use the geographical, DNS or
other style
of DNs for the certs and directories can
all be supported for applications where the domain name is
known. There may however be some additional support tools that can
defined to ease the 'knowledge'
gathering process as
Skip suggests. One that was raised earlier on the list and for which we don't
yet
have an answer is the provision of search base
data for LDAP SRV records for PKI repositories. If there
is a way to add additional information to DNS that will help resolve
these types of issues then I'm
all for it. Another
option that might be worth exploring is piggybacking repository locator
information
in certificate management protocols (e.g.
when one CA sends a cert request to another CA it could provide

the details of how to access its repository in that cert
requests - it is relying parties from the issuer's
domain that will need that access). Again that won't satisfy every
case, since strict hierarchies that
don't
cross-certify with other domains wouldn't be covered). Skip, I'm not
necessarily objecting to the
mapping you are
proposing, but am trying to understand within the context of PKI requirements
and I'm not
quite there yet :-)

However, I really would like to see us work from a focused
'requirements' standpoint rather
than from the
abstract level that a lot of this thread seems to have.

Sharon

> -----Original Message-----
>
From: Oscar Jacobsson [mailto:[email-masked]]

> Sent: Thursday, January 11, 2001 4:47 AM

> To: Slone, Skip
> Cc:
[email-masked]
> Subject: Re: Basic
Cert-2-Directory mapping question

> "Slone, Skip"
wrote:
> > Since civil-to-DNS name mapping
typically fails to yield to a
> > character
string transliteration algorithm (e.g., "o=Joe's Bar and
> > Grill" does not readily translate to are-you-hungry.com),

> this leaves
> > us
with a choice of either registering the translations or
> > complaining that it can't be done.
>
> Pardon my ignorance of these matters,
but where exactly is this civil
> naming scheme
outlined?
> IMHO the
DNS-based naming scheme for in RFC 2377 has been around for a
> couple years now, and when combined with the repository
locator
> documents I'd say it provides the
information necessary for an RP to
> locate the
relevant repository.
//oscar

--Boundary_(ID_YoGC80SyjBHJbuOumsLDJw)--

Received: from ns.celocom.se ([email-masked] [212.209.40.66]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA00873 for ; Thu, 11 Jan 2001 07:40:26 -0800 (PST)
Received: by ns.celocom.se; id QAA08363; Thu, 11 Jan 2001 16:45:33 +0100 (CET)
Received: from unknown(10.10.10.1) by ns.celocom.se via smap (V5.0) id xma008360; Thu, 11 Jan 01 16:44:35 +0100
Received: from celocom.com (stan.celocom.se [10.10.10.129]) by zap.celocom.se (8.8.7/8.8.7) with ESMTP id QAA00442; Thu, 11 Jan 2001 16:44:33 +0100
Message-ID: <[email-masked]>
Date: Thu, 11 Jan 2001 16:44:32 +0100
From: Oscar Jacobsson
Organization: Celo Communications
X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Sharon Boeyen
CC: [email-masked]
Subject: Re: Basic Cert-2-Directory mapping question
References:
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Sharon Boeyen wrote:
> The naming scheme (at least the higher levels of it) that is being
> referenced is
> originally outlined in an informative annex to X.521 and its also in
> some LDAP specs.

Ah, all right. I was of the mistaken impression that it was a more or
less arbitrary naming scheme. Should have done my homework better.

> Rather than try to name the world and every object in it, ...

I took the liberty of trimming your soapbox address, because we are
using rather different scopes as the bases for our arguments, so I'd
much rather begin by explaining mine:

What I am proposing is "simply" to name every directory server on the
Internet (which I think the DNS does a very good job of) and
subsequently to name every entry in all these directories (which I think
can safely be left up to local administrators).

The PKIX charter states the intent of the group as "developing Internet
standards needed to support an X.509-based PKI". To develop a new
standard, or to endorse those already existing, for how certificates
(and thus the directory entries they may certify) should be named in
order to be usable (please see the discussion on requirements/use cases
below) over the Internet seems like a worthwhile endeavour.

And while on the subject of naming, didn't Rosseau in his day propose
the abolition of common nouns all together? It would be interesting to
know what naming schemes he proposed. :-)

> However, I really would like to see us work from a focused
> 'requirements' standpoint rather
> than from the abstract level that a lot of this thread seems to have.

Definitely. I feel cases could be argued far better formally, backed by
specific use cases and requirements.

Just as an OTOH example, these are a few use cases I would want an
Internet-based naming scheme to address:

1. Allowing RPs to discover the location of the directory in which the
subject entry resides, from which additional attributes could be
retreived as required.

2. Allowing RPs to discover the location of the directory in which the
issuer entry resides, from which additional attributes -- specifically
revocation lists -- could be retreived as required.

3. Allowing RPs to discover the location of the directory in which the
cRLDistributionPoint entry resides, from which revocation lists could be
retreived as required.

Regards,

//oscar

Received: from junker.ms.inka.de (pD9011427.dip.t-dialin.net [217.1.20.39] (may be forged)) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA00207 for ; Thu, 11 Jan 2001 07:27:15 -0800 (PST)
Received: from stroeder.com (localhost [127.0.0.1]) by junker.ms.inka.de (Postfix) with ESMTP id 6649967C58 for ; Thu, 11 Jan 2001 16:30:43 +0100 (CET)
Sender: [email-masked]
Message-ID: <[email-masked]>
Date: Thu, 11 Jan 2001 16:30:42 +0100
From: Michael =?iso-8859-1?Q?Str=F6der?=
Organization: stroeder.com
X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.18 i686)
X-Accept-Language: de-DE, de, en
MIME-Version: 1.0
To: "[email-masked]"
Subject: Re: Basic Cert-2-Directory mapping question
References:
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

"Slone, Skip" wrote:
>
> If LDAPv3 referrals were sufficient, we wouldn't be having this
> conversation.

Who said that LDAPv3 referrals are the overall solution without
prior configuration?

> LDAPv3 referrals WILL work in the following two cases:
>
> 1) where my server's administrator already knows how to
> find the target name
> space, or
> 2) where my server and the server holding the target name space
> participate in some fully-connected DIT
> [..]

Yes.

> What I'm discussing is a way to fill in the gap where (1) my server does not
> already know how to find a certain name space, and (2) there's a knowledge
> disconnect between my server and the server holding the target. In this
> case, LDAPv3 referrals WILL NOT work.

Yes.

And RFC2377 does not work without SRV RRs. Yes. And I can't access
http://www.ietf.org without somebody having added the entry
www.ietf.org to DNS. Yes. And... Yes.

No doubt, if you do not know any service access point or you don't
have any rule how to derive the service access point from an
information at hand you can't access the service. Yes.

Now about which *use-case* are we talking here?

Ciao, Michael.

Received: from mailgw2a.lmco.com (mailgw2a.lmco.com [192.91.147.7]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA29016 for ; Thu, 11 Jan 2001 07:14:27 -0800 (PST)
Received: from emss03g01.ems.lmco.com (emss03g01.ems.lmco.com [141.240.4.144]) by mailgw2a.lmco.com (8.8.8/8.8.8) with ESMTP id KAA12452; Thu, 11 Jan 2001 10:19:32 -0500 (EST)
Received: from CONVERSION-DAEMON by lmco.com (PMDF V5.2-32 #38888) id <[email-masked]>; Thu, 11 Jan 2001 10:18:30 -0500 (EST)
Received: from emss03i00.ems.lmco.com ([141.240.31.211]) by lmco.com (PMDF V5.2-32 #38888) with ESMTP id <[email-masked]>; Thu, 11 Jan 2001 10:18:26 -0500 (EST)
Received: by emss03i00.orl.lmco.com with Internet Mail Service (5.5.2650.21) id ; Thu, 11 Jan 2001 10:19:35 -0500
Content-return: allowed
Date: Thu, 11 Jan 2001 10:19:34 -0500
From: "Slone, Skip"
Subject: RE: Basic Cert-2-Directory mapping question
To: "'Oscar Jacobsson'"
Cc: [email-masked]
Message-id:
MIME-version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-type: text/plain
Content-transfer-encoding: 7BIT

RFC 2377 proposes using dc-based naming as an alternative to "civil" naming
schemes. Such naming schemes (using RDNs constructed from attributes such as
country, stateOrProvince, organization, etc.) were originally published in
an Informative Annex to X.521. Neither scheme is mandated anywhere (civil is
documented in an Informative Annex; RFC 2377 is an Informational RFC).
Consequently, in the real world, we have both.

As you have suggested, RFC 2377-style names are readily resolved using the
approach outlined in pkixref; X.521-style names are not. If we could assume
the whole world would convert to RFC 2377-style naming, we wouldn't have to
worry about resolving civil names. However, as long as we have civil names
lying around in certificates and elsewhere, we have to either deal with them
or choose to ignore them.

-- Skip

-----Original Message-----
From: Oscar Jacobsson [mailto:[email-masked]]
Sent: Thursday, January 11, 2001 4:47 AM
To: Slone, Skip
Cc: [email-masked]
Subject: Re: Basic Cert-2-Directory mapping question

"Slone, Skip" wrote:
> Since civil-to-DNS name mapping typically fails to yield to a
> character string transliteration algorithm (e.g., "o=Joe's Bar and
> Grill" does not readily translate to are-you-hungry.com), this leaves
> us with a choice of either registering the translations or
> complaining that it can't be done.

Pardon my ignorance of these matters, but where exactly is this civil
naming scheme outlined?

IMHO the DNS-based naming scheme for in RFC 2377 has been around for a
couple years now, and when combined with the repository locator
documents I'd say it provides the information necessary for an RP to
locate the relevant repository.

//oscar

Received: from ext-mail.valicert.com (ns1.valicert.com [63.65.221.10]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA28368 for ; Thu, 11 Jan 2001 07:09:27 -0800 (PST)
Received: from CONVERSION-DAEMON by ext-mail.valicert.com (PMDF V5.2-33 #46613) id <[email-masked]> for [email-masked]; Thu, 11 Jan 2001 07:14:34 -0800 (PST)
Received: from polaris.valicert.com ([192.168.2.34]) by ext-mail.valicert.com (PMDF V5.2-33 #46613) with ESMTP id <[email-masked]>; Thu, 11 Jan 2001 07:14:34 -0800 (PST)
Received: by exchange.valicert.com with Internet Mail Service (5.5.2650.21) id ; Thu, 11 Jan 2001 07:10:31 -0800
Content-return: allowed
Date: Thu, 11 Jan 2001 07:10:30 -0800
From: Frank Balluffi
Subject: RE: DPD & DPV requirements - Recursion Issues
To: "'Covey, Carlin'" , PKIX-List
Message-id: <[email-masked]>
MIME-version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-type: text/plain; charset="iso-8859-1"

Wouldn't a DPD/DPV server solely carry out the task of discovering and
validating paths, and possibly use other protocols (e.g., LPAP, OCSP, etc.),
which might be recursive, to assist in this process? So unless sub-DPD/DPV
servers take part in path discovery or validation I would not describe
DPD/DPV as recursive.

Frank

> -----Original Message-----
> From: Covey, Carlin [mailto:[email-masked]]
> Sent: Wednesday, January 10, 2001 8:10 PM
> To: PKIX-List
> Subject: RE: DPD & DPV requirements - Recursion Issues
>
>
> Steve,
>
> I'm sorry that this isn't much of an analysis, but I think
> that any such analysis should clearly separate the issues.
> Here are three issues that I can think of:
>
> 1) One issue concerns the syntactic complexity of the protocol.
> If the protocol permits a DPV/DPD response to include embedded
> DPD/DPD responses from other servers, then the syntax will be a
> bit more complex than it might be otherwise.
>
> 2) A second issue concerns transitive trust. This is an issue
> even if embedded responses aren't permitted in the protocol.
> A DPV/DPD server could contact another server and repackage
> the response that it receives. This issue might be addressed
> by providing hooks in the protocol to limit the extent of this
> transitive trust. On the other hand, the issue might be
> addressed by DPV/DPD server practice statements. "This is what
> I might do, trust me or not." Or the issue might be addressed
> by a combination of the two by using policy OIDs in the request
> to indicate which practice statement the client is willing
> to tolerate.
>
> 3) A third issue is whether the benefits of recursion outweigh the
> difficulties presented by the first two issues. The authors of
> the SCVP and OCSP-DPV proposals, and the author of the proposed
> DPV/DPD requirements (someone well known to you, Steve) all chose
> to permit OCSP v1 responses to be embedded in the DPD responses,
> despite issues 1 and 2.
>
> Regards, Carlin
>
> ----------------------------
> - Carlin Covey
> Cylink Corp.
>
>
>
> -----Original Message-----
> From: Stephen Kent [mailto:[email-masked]]
> Sent: Wednesday, January 10, 2001 3:10 PM
> To: Slone, Skip
> Cc: PKIX-List
> Subject: RE: DPD & DPV requirements
>
>
> Skip,
>
> If we do agree to support DPV server recursion, then the suggested
> changes are appropriate ones to consider.
>
> First, though, on what basis would you propose that a client
> enable/disable recursion or set a depth limit? Since a client is
> completely dependent on a DPV server to answer a query, and has no
> local means of validating any supporting data sent along with the
> answer, what does recursion say about the trust that the client
> places in the server? If one believes that trust is transitive,
> recursion may well be fine, and a simple numerical limit on depth of
> recursion would not seem to be a good way to express limits on the
> transitivity (e.g., one bad choice of a DPV server for reliance is
> enough to kill you). If you don't think trust is transitive, then
> recursion is inappropriate, unless you operate in a closed
> environment where the recursion is among servers operated by the same
> org and is really just an internal decision on how to implement the
> server.
>
> Perhaps this is one reason why I am not yet comfortable with adding
> recursion to servers. I'd like to see some analysis of why it makes
> sense, whether it makes sense for both DPD and DPV, etc.
>
> Steve
>

Received: from mailgw2a.lmco.com (mailgw2a.lmco.com [192.91.147.7]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA27881 for ; Thu, 11 Jan 2001 06:58:20 -0800 (PST)
Received: from emss03g01.ems.lmco.com (emss03g01.ems.lmco.com [141.240.4.144]) by mailgw2a.lmco.com (8.8.8/8.8.8) with ESMTP id KAA11094; Thu, 11 Jan 2001 10:03:16 -0500 (EST)
Received: from CONVERSION-DAEMON by lmco.com (PMDF V5.2-32 #38888) id <[email-masked]>; Thu, 11 Jan 2001 10:02:18 -0500 (EST)
Received: from emss03i00.ems.lmco.com ([141.240.31.211]) by lmco.com (PMDF V5.2-32 #38888) with ESMTP id <[email-masked]>; Thu, 11 Jan 2001 10:01:47 -0500 (EST)
Received: by emss03i00.orl.lmco.com with Internet Mail Service (5.5.2650.21) id ; Thu, 11 Jan 2001 10:02:56 -0500
Content-return: allowed
Date: Thu, 11 Jan 2001 10:02:55 -0500
From: "Slone, Skip"
Subject: RE: Basic Cert-2-Directory mapping question
To: =?ISO-8859-1?Q?=27Michael_Str=F6der=27?= , [email-masked]
Message-id:
MIME-version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id GAA27882

If LDAPv3 referrals were sufficient, we wouldn't be having this
conversation.

LDAPv3 referrals WILL work in the following two cases:

1) where my server's administrator already knows how to find the target name
space, or
2) where my server and the server holding the target name space participate
in some fully-connected DIT in which unknown names are resolved by way of a
default referral up to a server maintaining the root naming context, from
where I can get a referral leading back down to the target. (Extended
globally, this is the original X.500 vision; on a smaller scale, it's
practical for something like an industry-wide association.)

What I'm discussing is a way to fill in the gap where (1) my server does not
already know how to find a certain name space, and (2) there's a knowledge
disconnect between my server and the server holding the target. In this
case, LDAPv3 referrals WILL NOT work.

-- Skip

-----Original Message-----
From: Michael Ströder [mailto:[email-masked]]
Sent: Thursday, January 11, 2001 3:40 AM
To: [email-masked]
Subject: Re: Basic Cert-2-Directory mapping question

"Slone, Skip" wrote:
>
> By way of example, what I'm talking about is the ability to
> take a DN of the form "cn=Skip Slone, o=Lockheed Martin, c=US" and
> determine that the LDAP server to check is found at (for example)
> ldap1.external.lmco.com.

Could be done with LDAPv3 referrals from your default LDAP server to
the target LDAP server holding the entry (e.g. described on
http://www.terena.nl/projects/direct/ for country-level
directories). I'm pretty sure Janus Liebregts and David Chadwick
know more about it.

Ciao, Michael.

Received: from sottmxs02.entrust.com (gatekeeper.entrust.com [204.101.128.170]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA27532 for ; Thu, 11 Jan 2001 06:52:20 -0800 (PST)
Received: by sottmxs02.entrust.com with Internet Mail Service (5.5.2650.21) id ; Thu, 11 Jan 2001 09:55:52 -0500
Message-ID:
From: Sharon Boeyen
To: =?iso-8859-1?Q?=27Michael_Str=F6der=27?= , [email-masked]
Subject: RE: Basic Cert-2-Directory mapping question
Date: Thu, 11 Jan 2001 09:53:49 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C07BDE.4E514900"

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_01C07BDE.4E514900
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

For item 1, clearly a non-issue. For 2, it might still be helpful to=20
have search base information in an SRV record, especially if it is in =
the
same PKI repository locator service record. It will eliminate that =
extra
call to the directory to get the naming context info and might also =
help in
cases where a third party service provider is operating the directory =
and
has a large number of naming contexts, only one of which is of interest =
for
a specific domain's PKI data. I agree that the basics are already =
there, but
as PKI deployments grow to very large scale, some efficiency could be =
be
achieved by reducing the number of calls required to a directory and =
the
amount of data returned from each call.

Sharon

> -----Original Message-----
> From: Michael Str=F6der [mailto:[email-masked]]
> Sent: Thursday, January 11, 2001 9:15 AM
> To: [email-masked]
> Subject: Re: Basic Cert-2-Directory mapping question
>=20
>=20
> Sharon Boeyen wrote:
> >=20
> > Finding a particular certificate is
> > one problem and determining whether or not to 'trust' and make use
> > of it is another.
>=20
> Agreed.
>=20
> > I do agree that 2377 and the PKIX repository locator document are
> > a nice fit and will satisfy a lot of the requirement for many
> > environments.
> > [..]
> > we don't yet have an answer is the provision of search base
> > data for LDAP SRV records for PKI repositories.
>=20
> ??? You simply don't have to provide the LDAP search base in DNS.
>=20
> 1. If you are using RFC2377 naming and RFC2782 SRV records you're
> looking up the server's DNS entry/IP address by already knowing the
> dc-style search base. If you want to locate the entry of a given
> e-mail address I would suggest that one searches all the sub-domains
> up to top-level domain if you can find a SRV record. After that you
> do a search for the e-mail address with this matching search base.
>=20
> 2. If you contact a given LDAPv3 server you can retrieve his search
> base(s) by looking at the namingContexts attribute in the RootDSE.
> (A similar non-standard work-around exists for UMich-derived LDAPv2
> servers.)
>=20
> Example for 1.:
>=20
> a) Assuming you want to locate an entry for
> [email-masked] for retrieving the certificate and your
> client implementation is capable of searching the SRV RR in the DNS.
>=20
> 1. You search for SRV record _ldap._tcp.www.stroeder.com. -> no
> result
>=20
> 2. You search for SRV record _ldap._tcp.stroeder.com. -> RR points
> to LDAP server directory.adm.stroeder.com.
>=20
> 3. You're doing the LDAP search
> ldap://directory.adm.stroeder.com/dc=3Dstroeder,dc=3Dcom??sub?(mai
l=[email-masked])
>=20
> b) If your client implementation is not capable of searching the SRV
> RRs itself but is able to follow LDAPv3 referrals (search
> continuations) it uses a service like described on
> http://www.openldap.org/faq/data/cache/393.html and gets redirected
> to the right server when doing a search like
> =
ldap://root.openldap.org/dc=3Dwww,dc=3Dstroeder,dc=3Dcom??sub?(mail=3D
[email-masked]).
>=20
> Now what's the problem? This can all be done without writing a new
> draft or modifying an existing one. Just a matter of implementing
> it...
>=20
> Ciao, Michael.
>=20

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

RE: Basic Cert-2-Directory mapping question

For item 1, clearly a non-issue. For 2, it might =
still be helpful to

have search base information in an SRV record, =
especially if it is in the same PKI repository locator service record. =
It will eliminate that extra call to the directory to get the naming =
context info and might also help in cases where a third party service =
provider is operating the directory and has a large number of naming =
contexts, only one of which is of interest for a specific domain's PKI =
data. I agree that the basics are already there, but as PKI deployments =
grow to very large scale, some efficiency could be be achieved by =
reducing the number of calls required to a directory and the amount of =
data returned from each call.

Sharon

> -----Original Message-----

> From: Michael Str=F6der [mailto:[email-masked]]

> Sent: Thursday, January 11, 2001 9:15 AM

> To: [email-masked]

> Subject: Re: Basic Cert-2-Directory mapping =
question

> Sharon Boeyen wrote:

> > Finding a particular certificate is

> > one problem and determining whether or not =
to 'trust' and make use

> > of it is another.

> Agreed.

> > I do agree that 2377 and the PKIX =
repository locator document are

> > a nice fit and will satisfy a lot of the =
requirement for many

> > environments.

> > [..]

> > we don't yet have an answer is the =
provision of search base

> > data for LDAP SRV records for PKI =
repositories.

> ??? You simply don't have to provide the LDAP =
search base in DNS.

> 1. If you are using RFC2377 naming and RFC2782 =
SRV records you're

> looking up the server's DNS entry/IP address by =
already knowing the

> dc-style search base. If you want to locate the =
entry of a given

> e-mail address I would suggest that one =
searches all the sub-domains

> up to top-level domain if you can find a SRV =
record. After that you

> do a search for the e-mail address with this =
matching search base.

> 2. If you contact a given LDAPv3 server you can =
retrieve his search

> base(s) by looking at the namingContexts =
attribute in the RootDSE.

> (A similar non-standard work-around exists for =
UMich-derived LDAPv2

> servers.)

> Example for 1.:

> a) Assuming you want to locate an entry =
for

> [email-masked] for retrieving the =
certificate and your

> client implementation is capable of searching =
the SRV RR in the DNS.

> 1. You search for SRV record =
_ldap._tcp.www.stroeder.com. -> no

> result

> 2. You search for SRV record =
_ldap._tcp.stroeder.com. -> RR points

> to LDAP server =
directory.adm.stroeder.com.

> 3. You're doing the LDAP search

> =
ldap://directory.adm.stroeder.com/dc=3Dstroeder,dc=3Dcom??sub?(mai

l=[email-masked])

> b) If your client implementation is not capable =
of searching the SRV

> RRs itself but is able to follow LDAPv3 =
referrals (search

> continuations) it uses a service like described =
on

> http://www.openldap.org/faq/data/cache/393.html =
and gets redirected

> to the right server when doing a search =
like

> =
ldap://root.openldap.org/dc=3Dwww,dc=3Dstroeder,dc=3Dcom??sub?(mail=3D

[email-masked]).

> Now what's the problem? This can all be done =
without writing a new

> draft or modifying an existing one. Just a =
matter of implementing

> it...

> Ciao, Michael.

------_=_NextPart_001_01C07BDE.4E514900--

Received: from junker.ms.inka.de (p3EE0AA4F.dip.t-dialin.net [62.224.170.79]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA26616 for ; Thu, 11 Jan 2001 06:11:58 -0800 (PST)
Received: from stroeder.com (localhost [127.0.0.1]) by junker.ms.inka.de (Postfix) with ESMTP id 4AA8B67C52 for ; Thu, 11 Jan 2001 15:15:13 +0100 (CET)
Sender: [email-masked]
Message-ID: <[email-masked]>
Date: Thu, 11 Jan 2001 15:15:11 +0100
From: Michael =?iso-8859-1?Q?Str=F6der?=
Organization: stroeder.com
X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.18 i686)
X-Accept-Language: de-DE, de, en
MIME-Version: 1.0
To: [email-masked]
Subject: Re: Basic Cert-2-Directory mapping question
References:
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Sharon Boeyen wrote:
>
> Finding a particular certificate is
> one problem and determining whether or not to 'trust' and make use
> of it is another.

Agreed.

> I do agree that 2377 and the PKIX repository locator document are
> a nice fit and will satisfy a lot of the requirement for many
> environments.
> [..]
> we don't yet have an answer is the provision of search base
> data for LDAP SRV records for PKI repositories.

??? You simply don't have to provide the LDAP search base in DNS.

1. If you are using RFC2377 naming and RFC2782 SRV records you're
looking up the server's DNS entry/IP address by already knowing the
dc-style search base. If you want to locate the entry of a given
e-mail address I would suggest that one searches all the sub-domains
up to top-level domain if you can find a SRV record. After that you
do a search for the e-mail address with this matching search base.

2. If you contact a given LDAPv3 server you can retrieve his search
base(s) by looking at the namingContexts attribute in the RootDSE.
(A similar non-standard work-around exists for UMich-derived LDAPv2
servers.)

Example for 1.:

a) Assuming you want to locate an entry for
[email-masked] for retrieving the certificate and your
client implementation is capable of searching the SRV RR in the DNS.

1. You search for SRV record _ldap._tcp.www.stroeder.com. -> no
result

2. You search for SRV record _ldap._tcp.stroeder.com. -> RR points
to LDAP server directory.adm.stroeder.com.

3. You're doing the LDAP search
ldap://directory.adm.stroeder.com/dc=stroeder,dc=com??sub?(mail=[email-masked])

b) If your client implementation is not capable of searching the SRV
RRs itself but is able to follow LDAPv3 referrals (search
continuations) it uses a service like described on
http://www.openldap.org/faq/data/cache/393.html and gets redirected
to the right server when doing a search like
ldap://root.openldap.org/dc=www,dc=stroeder,dc=com??sub?(mail=[email-masked]).

Now what's the problem? This can all be done without writing a new
draft or modifying an existing one. Just a matter of implementing
it...

Ciao, Michael.

Received: from marcy.adiron.com ([128.230.111.5]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA25692 for ; Thu, 11 Jan 2001 06:00:25 -0800 (PST)
Received: from localhost (polar@localhost) by marcy.adiron.com (8.9.1/8.9.0) with ESMTP id JAA26340; Thu, 11 Jan 2001 09:00:14 -0500
X-Authentication-Warning: marcy.adiron.com: polar owned process doing -bs
Date: Thu, 11 Jan 2001 09:00:14 -0500 (EST)
From: Polar Humenn
To: Anders Rundgren
cc: [email-masked], [email-masked]
Subject: Re: Basic Cert-2-Directory mapping question
In-Reply-To: <[email-masked]>
Message-ID:
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

On Thu, 11 Jan 2001, Anders Rundgren wrote:

> Peter,
>
> > >Flat name spaces scale poorly, lead to confusion, and are thus not attractive
> > >in various ways. People do like flat name spaces, until they trip over the
> > >limitations they embody, then they complain and look for magic solutions.
> > >I've seen no appropriate magic for this problem.
> >
> > Have you actually seen the problem though? It's automatically assumed that
> > there's some vast, unassailable problem which hierarchical names will solve,
> > but I don't think I've ever seen it except as some special-case, often
> > hypothetical situation which is used to justify the need for DNs (or whatever).
> > In the real world people have been using their flat, non-scalable name spaces
> > for several decades without any sign that civilisation is about to collapse.
>
> I second that 100%. The only thing you gain by hierarchical cert names is rigidness
> (i.e. can only be used in a certain regime) and low trace ability (change position
> and then you become another identity). So even for closed PKI's we do have
> a serious mapping issue IMNSHO.

I'll jump on the band wagon as Peter, Anders, and a few others. DN's to
me, have never been hierarchical. They are basically converted to strings,
or hashed, and used, searched for, and compared, that way. I really enjoy
the "flat" name space, Simple, and normal people, as well as "simple"
programmers know how to deal with it. It's not really flat, but comes in
two parts. 1. tell me where to find it, 2 and tell me how to find it from
there. HTTP is just one good example illustrated by Peter, SDSI (SPKI?) is
another. (And I for one, like that revocation scheme, much better then
trying to find CRLs and calculate delta CRLs, what a waste of precious
processing time!). The whole X.500 thing, in my mind is so bizzare. It's
so complex, and with OSCP servers, and DPV and such, the whole thing is
going to start looking like Kerberos pretty soon, which has one of these
so called flat namespaces.

Cheers,
-Polar

-------------------------------------------------------------------
Polar Humenn Adiron, LLC
mailto:[email-masked] 2-212 CST
Phone: 315-443-3171 Syracuse, NY 13244-4100
Fax: 315-443-4745 http://www.adiron.com

Received: from SOTTMXS01.entrust.com (gatekeeper.entrust.com [204.101.128.170]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id FAA23581 for ; Thu, 11 Jan 2001 05:26:49 -0800 (PST)
Received: by SOTTMXS01.entrust.com with Internet Mail Service (5.5.2650.21) id ; Thu, 11 Jan 2001 08:31:25 -0500
Message-ID:
From: Sharon Boeyen
To: "'Oscar Jacobsson'" , "Slone, Skip"
Cc: [email-masked]
Subject: RE: Basic Cert-2-Directory mapping question
Date: Thu, 11 Jan 2001 08:28:28 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C07BD2.61E39FB0"

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_01C07BD2.61E39FB0
Content-Type: text/plain

The naming scheme (at least the higher levels of it) that is being
referenced is
originally outlined in an informative annex to X.521 and its also in some
LDAP specs.

In some countries this type of naming is being more readily adopted than in
others. It
is my VERY strong belief that trying to impose a single naming structure or
a single naming
hierarchy for all applications and all environments simply is a recipe for
disaster. The US
has historically been the absolute most difficult place to do this in the
past (reference
the North American Directory Forum effort that Bob references). Regulatory
differences and
differing business models and operating environments lead to different
naming structures.

Borrowing from Marshall Rose's writing style, let me step on my soapbox for
a minute:

Rather than try to name the world and every object in it, I believe a more
constructive approach
is to accept the fact that different parts of the world and different
environments will have
use a variety of nameforms and work within that context to make the best use
of the tools we have
at our disposal to find the information that is needed. We should not be
trying to solve the "global
directory problem", we are the PKIX WG. We should ensure that appropriate
PKIX information can be located and
retrieved. We are not the global naming police either and should not try to
impose the rules that
anyone uses to name entities to which they issue certificates. Finding a
particular certificate is
one problem and determining whether or not to 'trust' and make use of it is
another. Repository
locator discussions should be restricted to the former.

Step off soapbox.

I do agree that 2377 and the PKIX repository locator document are a nice fit
and will satisfy a
lot of the requirement for many environments. Those that use the
geographical, DNS or other style
of DNs for the certs and directories can all be supported for applications
where the domain name is
known. There may however be some additional support tools that can defined
to ease the 'knowledge'
gathering process as Skip suggests. One that was raised earlier on the list
and for which we don't yet
have an answer is the provision of search base data for LDAP SRV records for
PKI repositories. If there
is a way to add additional information to DNS that will help resolve these
types of issues then I'm
all for it. Another option that might be worth exploring is piggybacking
repository locator information
in certificate management protocols (e.g. when one CA sends a cert request
to another CA it could provide
the details of how to access its repository in that cert requests - it is
relying parties from the issuer's
domain that will need that access). Again that won't satisfy every case,
since strict hierarchies that
don't cross-certify with other domains wouldn't be covered). Skip, I'm not
necessarily objecting to the
mapping you are proposing, but am trying to understand within the context of
PKI requirements and I'm not
quite there yet :-)

However, I really would like to see us work from a focused 'requirements'
standpoint rather
than from the abstract level that a lot of this thread seems to have.

Sharon

> -----Original Message-----
> From: Oscar Jacobsson [mailto:[email-masked]]
> Sent: Thursday, January 11, 2001 4:47 AM
> To: Slone, Skip
> Cc: [email-masked]
> Subject: Re: Basic Cert-2-Directory mapping question
>
>
> "Slone, Skip" wrote:
> > Since civil-to-DNS name mapping typically fails to yield to a
> > character string transliteration algorithm (e.g., "o=Joe's Bar and
> > Grill" does not readily translate to are-you-hungry.com),
> this leaves
> > us with a choice of either registering the translations or
> > complaining that it can't be done.
>
> Pardon my ignorance of these matters, but where exactly is this civil
> naming scheme outlined?
>
> IMHO the DNS-based naming scheme for in RFC 2377 has been around for a
> couple years now, and when combined with the repository locator
> documents I'd say it provides the information necessary for an RP to
> locate the relevant repository.
>
> //oscar
>

------_=_NextPart_001_01C07BD2.61E39FB0
Content-Type: text/html
Content-Transfer-Encoding: quoted-printable

RE: Basic Cert-2-Directory mapping question

The naming scheme (at least the higher levels of it) =
that is being referenced is

originally outlined in an informative annex to X.521 =
and its also in some LDAP specs.

In some countries this type of naming is being more =
readily adopted than in others. It

is my VERY strong belief that trying to impose a =
single naming structure or a single naming

hierarchy for all applications and all environments =
simply is a recipe for disaster. The US

has historically been the absolute most difficult =
place to do this in the past (reference

the North American Directory Forum effort that Bob =
references). Regulatory differences and

differing business models and operating environments =
lead to different naming structures.

Borrowing from Marshall Rose's writing style, let me =
step on my soapbox for a minute:

Rather than try to name the world and every object in =
it, I believe a more constructive approach

is to accept the fact that different parts of the =
world and different environments will have

use a variety of nameforms and work within that =
context to make the best use of the tools we have

at our disposal to find the information that is =
needed. We should not be trying to solve the "global

directory problem", we are the PKIX WG. We =
should ensure that appropriate PKIX information can be located and =

retrieved. We are not the global naming police =
either and should not try to impose the rules that

anyone uses to name entities to which they issue =
certificates. Finding a particular certificate is

one problem and determining whether or not to =
'trust' and make use of it is another. Repository

locator discussions should be restricted to the =
former.

Step off soapbox.

I do agree that 2377 and the PKIX repository locator =
document are a nice fit and will satisfy a

lot of the requirement for many environments. Those =
that use the geographical, DNS or other style

of DNs for the certs and directories can all be =
supported for applications where the domain name is

known. There may however be some additional support =
tools that can defined to ease the 'knowledge'

gathering process as Skip suggests. One that was =
raised earlier on the list and for which we don't yet

have an answer is the provision of search base data =
for LDAP SRV records for PKI repositories. If there

is a way to add additional information to DNS that =
will help resolve these types of issues then I'm

all for it. Another option that might be worth =
exploring is piggybacking repository locator information

in certificate management protocols (e.g. when one =
CA sends a cert request to another CA it could provide

the details of how to access its repository in that =
cert requests - it is relying parties from the issuer's

domain that will need that access). Again that won't =
satisfy every case, since strict hierarchies that

don't cross-certify with other domains wouldn't be =
covered). Skip, I'm not necessarily objecting to the

mapping you are proposing, but am trying to =
understand within the context of PKI requirements and I'm not

quite there yet :-)

However, I really would like to see us work from a =
focused 'requirements' standpoint rather

than from the abstract level that a lot of this =
thread seems to have.

Sharon

> -----Original Message-----

> From: Oscar Jacobsson [mailto:oscar.jacobsson@celoc=
om.com]

> Sent: Thursday, January 11, 2001 4:47 AM

> To: Slone, Skip

> Cc: [email-masked]

> Subject: Re: Basic Cert-2-Directory mapping =
question

> "Slone, Skip" wrote:

> > Since civil-to-DNS name mapping typically =
fails to yield to a

> > character string transliteration algorithm =
(e.g., "o=3DJoe's Bar and

> > Grill" does not readily translate to =
are-you-hungry.com),

> this leaves

> > us with a choice of either registering the =
translations or

> > complaining that it can't be done.

> Pardon my ignorance of these matters, but where =
exactly is this civil

> naming scheme outlined?

> IMHO the DNS-based naming scheme for in RFC =
2377 has been around for a

> couple years now, and when combined with the =
repository locator

> documents I'd say it provides the information =
necessary for an RP to

> locate the relevant repository.

> //oscar

------_=_NextPart_001_01C07BD2.61E39FB0--

Received: from ns.celocom.se ([email-masked] [212.209.40.66]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id EAA21728 for ; Thu, 11 Jan 2001 04:57:26 -0800 (PST)
Received: by ns.celocom.se; id OAA06647; Thu, 11 Jan 2001 14:02:32 +0100 (CET)
Received: from unknown(10.10.10.1) by ns.celocom.se via smap (V5.0) id xma006643; Thu, 11 Jan 01 14:02:10 +0100
Received: from celocom.com (stan.celocom.se [10.10.10.129]) by zap.celocom.se (8.8.7/8.8.7) with ESMTP id OAA30659; Thu, 11 Jan 2001 14:02:10 +0100
Message-ID: <[email-masked]>
Date: Thu, 11 Jan 2001 14:02:09 +0100
From: Oscar Jacobsson
Organization: Celo Communications
X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Michael =?iso-8859-1?Q?Str=F6der?=
CC: "[email-masked]"
Subject: Re: Basic Cert-2-Directory mapping question
References: <[email-masked]>
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id EAA21729

Michael Ströder wrote:
> Yes, which leads to Anders' question how to map one certificate in
> several directories. In this case you're maintaining your directory
> to hold certificates of your e-mail partners (I still did not find
> the time to write an e-mail filter which automatically pulls out the
> certs found in signed e-mails passing a mail relay and puts them
> into a LDAP directory).

Mapping one certificate to many directories doesn't seem to hard to
accomplish using SRV records, given that the certificate is named in
accordance to RFC 2377.

For purposes of local mirroring however, explicit configuration is
probably required in order to have local RPs query the local "cache"
before, or as a complement to querying external repositories. This would
probably also have to cater for the vast amount of arbitrarily named
certificates currently in circulation.

> For those not having their own domain directory servers for
> hotmail.com, earthlink.net, web.de etc. could hold the directory
> entries (or delegate it to another provider).

The party certifying, say, a webmail.example e-mail address does not
need to be "authoritative" for that domain. A given third party, in this
case ttp.example, could issue the webmail certificate using a 'dc=ttp,
dc=example' DN with the webmail.example e-mail address as an subject
alternate name, directing RPs to query ttp.example responders instead of
webmail.example ones.

This is one way different providers can be selected for hosting e-mail
and directory services.

//oscar

Received: from rom.antech.de (dns.antech.de [194.45.12.2]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id EAA18638 for ; Thu, 11 Jan 2001 04:28:25 -0800 (PST)
Received: from scherbius.secorvo.de (kasiski.secorvo.de [194.45.12.203]) by rom.antech.de (8.9.3/8.9.3) with ESMTP id NAA31595; Thu, 11 Jan 2001 13:23:12 +0100
Message-Id: <[email-masked]>
From: "Stefan Kelm"
Organization: Secorvo Security Consulting GmbH
To: [email-masked], "[email-masked]"
Date: Thu, 11 Jan 2001 13:31:28 +0100
MIME-Version: 1.0
Content-type: text/plain; charset=US-ASCII
Content-transfer-encoding: 7BIT
Subject: Re: Basic Cert-2-Directory mapping question
Reply-to: [email-masked]
Priority: normal
In-reply-to: <[email-masked]>
X-mailer: Pegasus Mail for Win32 (v3.12b)

Michael,

> 3. X.500 is chosen as THE solution (mainly because the X.500 books
> the IT consultant read sounded so promising).

No, in many organisations X.500 is chosen because a directory
is already up and running. You are, however, quite right wrt
the huge problems you mention.

Cheers,

Stefan.

-------------------------------------------------------
Dipl.-Inform. Stefan Kelm
Security Consultant

Secorvo Security Consulting GmbH
Albert-Nestler-Strasse 9, D-76131 Karlsruhe

Tel. +49 721 6105-461, Fax +49 721 6105-455
E-Mail [email-masked], http://www.secorvo.de
-------------------------------------------------------
PGP Fingerprint 87AE E858 CCBC C3A2 E633 D139 B0D9 212B

Received: from ietf.org (odin.ietf.org [132.151.1.176]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id EAA18306 for ; Thu, 11 Jan 2001 04:21:59 -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 HAA29042; Thu, 11 Jan 2001 07:27:04 -0500 (EST)
Message-Id: <[email-masked]>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-pkix-ac509prof-06.txt
Date: Thu, 11 Jan 2001 07:27:04 -0500
Sender: [email-masked]

--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 : An Internet Attribute Certificate Profile for
Authorization
Author(s) : S. Farrell, R. Housley
Filename : draft-ietf-pkix-ac509prof-06.txt
Pages : 39
Date : 10-Jan-01

This specification defines a profile for the use of X.509 Attribute
Certificates in Internet Protocols. Attribute certificates may be
used in a wide range of applications and environments covering a
broad spectrum of interoperability goals and a broader spectrum of
operational and assurance requirements. The goal of this document is
to establish a common baseline for generic applications requiring
broad interoperability as well as limited special purpose
requirements. The profile places emphasis on attribute certificate
support for Internet electronic mail, IPSec, and WWW security
applications.

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

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-ietf-pkix-ac509prof-06.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:
[email-masked].
In the body type:
"FILE /internet-drafts/draft-ietf-pkix-ac509prof-06.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="[email-masked]"

Content-Type: text/plain
Content-ID: <[email-masked]>

ENCODING mime
FILE /internet-drafts/draft-ietf-pkix-ac509prof-06.txt

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

Content-Type: text/plain
Content-ID: <[email-masked]>

--OtherAccess--

--NextPart--

Received: from mail.ec.auckland.ac.nz (mail.student.auckland.ac.nz [130.216.35.201]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id DAA13790 for ; Thu, 11 Jan 2001 03:14:52 -0800 (PST)
Received: from kahu.cs.auckland.ac.nz ([email-masked] [130.216.36.13]) by mail.ec.auckland.ac.nz (8.9.3/8.8.6/cs-master) with SMTP id AAA15256 for ; Fri, 12 Jan 2001 00:19:53 +1300 (NZDT) (sender [email-masked])
Received: by kahu.cs.auckland.ac.nz (relaymail v0.9) id <97921199328126>; Fri, 12 Jan 2001 00:19:53 (NZDT)
From: [email-masked] (Peter Gutmann)
To: [email-masked]
Subject: Re: Basic Cert-2-Directory mapping question
Sender: [email-masked]
Reply-To: [email-masked]
X-Charge-To: pgut001
X-Authenticated: relaymail v0.9 on kahu.cs.auckland.ac.nz
Date: Fri, 12 Jan 2001 00:19:53 (NZDT)
Message-ID: <[email-masked]>

I've got a slightly older copy of the papers I mentioned a few days ago
available online, they're linked via my home page
http://www.cs.auckland.ac.nz/~pgut001/, with the text extracted below. There
are also some slides from my talk at ACSAC which cover some things I didn't
have room for in the paper, I'll put those online within the next week. I'd
be interested in feedback.

-- Snip --

One section of my thesis, which covered certificate stores, had to be dropped
due to size constraints. As with the work in the other chapters, it begins by
analysing the requirements (in this case for a reliable, scalable,
general-purpose certificate store), and then examines various potential
candidates which might meet these requirements. The single chapter ended up
broken down into two papers because of its size, the first paper (published at
ACSAC 2000) mostly stands by itself but the second one, not yet published, is
rather lopsided and needs the first paper to lean against. Both have had some
minor revisions made based on feedback which postdate the online versions, in
addition the second one (which was put together in a bit of a hurry at the
same time my thesis was due and definitely isn't my best work) covers a
slightly older design than what's currently being used and needs some changes
to bring it up to date. I also need to add pointers to work which has
appeared after it was written such as the CCS 2000 papers on undeniable
attestations and fault-tolerant revocations, which is similar to the scheme
which I examine in the second half of the paper. Don't treat this as a
finished work.

The first paper, http://www.cryptoengines.com/~peter/09a_cert_store.pdf A
Reliable, Scalable, General-purpose Certificate Store has a pretty
self-explanatory title. The second one,
http://www.cryptoengines.com/~peter/09b_cert_store.pdf Certificate Management
as Transaction Processing looks at certificate and certificate
status/revocation management from a TP perspective.

-- Snip --

Peter.

Received: from junker.ms.inka.de (pD901158A.dip.t-dialin.net [217.1.21.138]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id CAA09879 for ; Thu, 11 Jan 2001 02:41:18 -0800 (PST)
Received: from stroeder.com (localhost [127.0.0.1]) by junker.ms.inka.de (Postfix) with ESMTP id 7F5FC67C58 for ; Thu, 11 Jan 2001 11:45:49 +0100 (CET)
Sender: [email-masked]
Message-ID: <[email-masked]>
Date: Thu, 11 Jan 2001 11:45:49 +0100
From: Michael =?iso-8859-1?Q?Str=F6der?=
Organization: stroeder.com
X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.18 i686)
X-Accept-Language: de-DE, de, en
MIME-Version: 1.0
To: "[email-masked]"
Subject: Re: Basic Cert-2-Directory mapping question
References: <[email-masked]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Peter Gutmann wrote:
>
> Only yesterday I was talking to someone whose company is
> deploying a nationwide PKI based on HTTP
> [..]
> [I should add an addendum here that the person I was talking
> to asked me about switching to LDAP, since he'd read about it
> a bit in the trade press and wanted to know what was involved.
> I started to run through the standard 5-minute intro to X.500
> and LDAP and he looked at me as if he expected a cuckoo to pop
> out of my forehead on a small spring... I doubt they'll be
> switching over any time soon]

Maybe you should have showed him how easy it is to retrieve an
e-mail certificate when writing e-mail which is stored in a
directory. I really like LDAP for being a standard access protocol
which I can use in mainstream e-mail apps (get a certificate within
an organization with just two more clicks) and in a few lines of
Python/Perl/TCL/PHP code. I don't care that much about the
hierarchical DNs though.

Ciao, Michael.

Received: from ns.celocom.se ([email-masked] [212.209.40.66]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id CAA09002 for ; Thu, 11 Jan 2001 02:33:50 -0800 (PST)
Received: by ns.celocom.se; id LAA05236; Thu, 11 Jan 2001 11:38:55 +0100 (CET)
Received: from unknown(10.10.10.1) by ns.celocom.se via smap (V5.0) id xma005224; Thu, 11 Jan 01 11:38:12 +0100
Received: from celocom.com (stan.celocom.se [10.10.10.129]) by zap.celocom.se (8.8.7/8.8.7) with ESMTP id LAA28477; Thu, 11 Jan 2001 11:38:11 +0100
Message-ID: <[email-masked]>
Date: Thu, 11 Jan 2001 11:38:11 +0100
From: Oscar Jacobsson
Organization: Celo Communications
X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Philip Hallam-Baker
CC: Tim Polk , [email-masked]
Subject: Re: WG Last Call, PKI Repository Locator
References: <[email-masked]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Philip Hallam-Baker wrote:
> The options are (I guess):
>
> 1) _pkix._http._tcp
> 2) _pkix_http._tcp
> 3) _pkixhttp._tcp
>
> I don't really care which we do... (1) seems cleanest???

It does indeed, and seems intuitive enough. BIND 8.2.2 doesn't appear to
have a problem with it either.

//oscar

Received: from junker.ms.inka.de (pD9011857.dip.t-dialin.net [217.1.24.87]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id CAA08910 for ; Thu, 11 Jan 2001 02:33:37 -0800 (PST)
Received: from stroeder.com (localhost [127.0.0.1]) by junker.ms.inka.de (Postfix) with ESMTP id DF48267C50 for ; Thu, 11 Jan 2001 11:33:23 +0100 (CET)
Sender: [email-masked]
Message-ID: <[email-masked]>
Date: Thu, 11 Jan 2001 11:33:22 +0100
From: Michael =?iso-8859-1?Q?Str=F6der?=
Organization: stroeder.com
X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.18 i686)
X-Accept-Language: de-DE, de, en
MIME-Version: 1.0
To: "[email-masked]"
Subject: Re: Basic Cert-2-Directory mapping question
References: <[email-masked]> <[email-masked]>
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id CAA08919

Stephen Kent wrote:
>
> At 9:08 AM +0100 1/10/01, Michael Ströder wrote:
> >
> >
> >
> >=> People are used to flat name spaces. X.500 DNs does not work.
>
> Flat name spaces scale poorly, lead to confusion, and are thus not
> attractive in various ways. People do like flat name spaces, until
> they trip over the limitations they embody, then they complain and
> look for magic solutions.

Now for the X.500/LDAP variant of a "magic solution":

1. An organization tries to find a solution for the flat name space
problem but the managment is clueless.

2. They hire an IT consultant.

3. X.500 is chosen as THE solution (mainly because the X.500 books
the IT consultant read sounded so promising).

4. After discussing weeks or months which DIT rules to use a
hierarchy is defined and written down in a concept paper.

5. The DIT rules are presented but the company's CEO makes some
"strategic" decisions about naming. Mainly he does not like the DN
for his entry because it's too long. He chooses
cn=ceo,dc=famousecommerce,dc=com for his entry and
cn=secretary,dc=famousecommerce,dc=com for his secretary's entry.

6. Again discussing DIT rules according to the new "requirements"
and working out a migration plan. The IT consultant has done his
job...

7. Finally the new X.500 or LDAP server is up and running.
Testing...

8. The directory admin switches off global searches and browsing
mainly for avoiding performance problems.

9. None of the Joe Average user is able to use the new service and
people are still happy with their local address book in their
favourite e-mail app.

10. After a couple of months somebody starts his own flat-named
service and opens it to other users. People are amazed by this "new"
centralized data repository which is easy-to-use...

11. The new service grows to the same scalability problem again.

12. Goto 1.

Don't get me wrong. I am using LDAP servers and I think a directory
service can be very convenient within an organization especially for
retrieving e-mail certificates!

But some of the promises made by directory people were not fulfilled
during the last 10+ years. Still these promises are repeated over
and over again.

> I've seen no appropriate magic for this problem.

Neither have I.

Ciao, Michael.

Received: from junker.ms.inka.de (pD9011857.dip.t-dialin.net [217.1.24.87]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id CAA08909 for ; Thu, 11 Jan 2001 02:33:37 -0800 (PST)
Received: from stroeder.com (localhost [127.0.0.1]) by junker.ms.inka.de (Postfix) with ESMTP id 613B167C4A for ; Thu, 11 Jan 2001 11:01:10 +0100 (CET)
Sender: [email-masked]
Message-ID: <[email-masked]>
Date: Thu, 11 Jan 2001 11:01:10 +0100
From: Michael =?iso-8859-1?Q?Str=F6der?=
Organization: stroeder.com
X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.18 i686)
X-Accept-Language: de-DE, de, en
MIME-Version: 1.0
To: "[email-masked]"
Subject: Re: Basic Cert-2-Directory mapping question
References:
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Bob Jueneman wrote:
>
> But notice some of the problems. I'm not picking on our
> esteemed co-chair, but notice that Steve's e-mail address,
> [email-masked], is two corporate mergers behind the times,

So what? I don't care about his e-mail address at all. I did not
even look at it! Could be hotmail.com, earthlink.net, web.de or
whatever. It does not carry any information for me.

The most important thing to me as a user is to reach *him* under
this e-mail address *he* used as from address. And if I'm really
paranoid I try to get a hold of *his* certificate. And the CA would
have to revoke *his* certificate if *he*'s not reachable under this
e-mail address anymore.

> But in either case, that doesn't necessarily mean that they would
> choose to host their own directory service, and perhaps especially
> not for certificates.

Yes, which leads to Anders' question how to map one certificate in
several directories. In this case you're maintaining your directory
to hold certificates of your e-mail partners (I still did not find
the time to write an e-mail filter which automatically pulls out the
certs found in signed e-mails passing a mail relay and puts them
into a LDAP directory).

> But what if they later decide to switch e-mail service providers. Are
> they they then obligated to get new certificates, even though the old
> ones haven't expired yet?

YES!

> And what does that do to the concept of validation
> of still valid certs for binding transactions?

Revoke the certs for the old e-mail address if they're not using it
anymore => binding will fail. Or did I get you wrong?

> It is for these kinds of reasons that I believe that any form of
> generally workable directory locator scheme CANNOT POSSIBLY be based
> on a deterministic relationship between the location of the directory
> and a web address or e-mail address per se, simply because the directory
> service provider may have nothing whatsoever to do with those other
> services.

We already have primary DNS servers which can give authorative
answers for DNS domains. For a deterministic relationship between
the location of the directory and a web address or e-mail address we
need "primary directory servers" which are responsible for holding
e.g. dc=stroeder,dc=com. I see no reason why I shouldn't be able to
delegate this to a directory service provider similar to my ISP
being responsible for managing *my* DNS domain stroeder.com. And
sure they can be different service providers.

For those not having their own domain directory servers for
hotmail.com, earthlink.net, web.de etc. could hold the directory
entries (or delegate it to another provider).

Locating the directory services and a person's entry would be pretty
easy by using the e-mail address, RFC2377 and/or a service like
ldap://root.openldap.org without any new standards.

Ciao, Michael.

Received: from ns.celocom.se ([email-masked] [212.209.40.66]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id BAA04934 for ; Thu, 11 Jan 2001 01:41:50 -0800 (PST)
Received: by ns.celocom.se; id KAA04709; Thu, 11 Jan 2001 10:46:55 +0100 (CET)
Received: from unknown(10.10.10.1) by ns.celocom.se via smap (V5.0) id xma004705; Thu, 11 Jan 01 10:46:47 +0100
Received: from celocom.com (stan.celocom.se [10.10.10.129]) by zap.celocom.se (8.8.7/8.8.7) with ESMTP id KAA28004; Thu, 11 Jan 2001 10:46:47 +0100
Message-ID: <[email-masked]>
Date: Thu, 11 Jan 2001 10:46:46 +0100
From: Oscar Jacobsson
Organization: Celo Communications
X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: "Slone, Skip"
CC: [email-masked]
Subject: Re: Basic Cert-2-Directory mapping question
References:
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

"Slone, Skip" wrote:
> Since civil-to-DNS name mapping typically fails to yield to a
> character string transliteration algorithm (e.g., "o=Joe's Bar and
> Grill" does not readily translate to are-you-hungry.com), this leaves
> us with a choice of either registering the translations or
> complaining that it can't be done.

Pardon my ignorance of these matters, but where exactly is this civil
naming scheme outlined?

IMHO the DNS-based naming scheme for in RFC 2377 has been around for a
couple years now, and when combined with the repository locator
documents I'd say it provides the information necessary for an RP to
locate the relevant repository.

//oscar

Received: from junker.ms.inka.de (pD90115C6.dip.t-dialin.net [217.1.21.198]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id AAA26605 for ; Thu, 11 Jan 2001 00:40:01 -0800 (PST)
Received: from stroeder.com (localhost [127.0.0.1]) by junker.ms.inka.de (Postfix) with ESMTP id 041A867C4A for ; Thu, 11 Jan 2001 09:44:52 +0100 (CET)
Sender: [email-masked]
Message-ID: <[email-masked]>
Date: Thu, 11 Jan 2001 09:44:50 +0100
From: Michael =?iso-8859-1?Q?Str=F6der?=
Organization: stroeder.com
X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.18 i686)
X-Accept-Language: de-DE, de, en
MIME-Version: 1.0
To: "[email-masked]"
Subject: Re: Basic Cert-2-Directory mapping question
References: <[email-masked]> <[email-masked]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Stephen Kent wrote:
>
> >IMHO one of the main problems with
> >PKIX is that there's so much X.500 in it. ;-)
>
> Perhaps thinking about the WG name will clarify why there's so much
> X.500 in PKIX.

I can also rephrase the sentence with having the same result by
saying:
The main problems with PKIX is that there's not much X.500 in
current implementations any more.

> Were you looking for the SPKI WG list and wound up
> here by accident?

Nope.

Ciao, Michael.

Received: from junker.ms.inka.de (pD90115C6.dip.t-dialin.net [217.1.21.198]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id AAA25982 for ; Thu, 11 Jan 2001 00:34:52 -0800 (PST)
Received: from stroeder.com (localhost [127.0.0.1]) by junker.ms.inka.de (Postfix) with ESMTP id 9CBCD67C4A for ; Thu, 11 Jan 2001 09:39:42 +0100 (CET)
Sender: [email-masked]
Message-ID: <[email-masked]>
Date: Thu, 11 Jan 2001 09:39:42 +0100
From: Michael =?iso-8859-1?Q?Str=F6der?=
Organization: stroeder.com
X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.18 i686)
X-Accept-Language: de-DE, de, en
MIME-Version: 1.0
To: [email-masked]
Subject: Re: Basic Cert-2-Directory mapping question
References:
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

"Slone, Skip" wrote:
>
> By way of example, what I'm talking about is the ability to
> take a DN of the form "cn=Skip Slone, o=Lockheed Martin, c=US" and
> determine that the LDAP server to check is found at (for example)
> ldap1.external.lmco.com.

Could be done with LDAPv3 referrals from your default LDAP server to
the target LDAP server holding the entry (e.g. described on
http://www.terena.nl/projects/direct/ for country-level
directories). I'm pretty sure Janus Liebregts and David Chadwick
know more about it.

Ciao, Michael.

Received: from sina.com ([202.106.187.164]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id WAA09476 for ; Wed, 10 Jan 2001 22:58:53 -0800 (PST)
Received: (qmail 24290 invoked by uid 99); 11 Jan 2001 07:13:09 -0000
Message-ID: <[email-masked]>
From: wxhietf
To: [email-masked]
Subject: AccecptPKCS7 Failed, Why return 424 ?
Date: Thu, Jan 11 2001 15:13:09 +0800
X-Mailer: SinaMail 3.0Beta (FireToad)
X-Priority: 2

hello Everybody:
I have big problems now.
I Call the function CreatePkcs10 to generate aa pkcs10 certificate request package, then , I user a cgi program to sign a normal x509 certificate, convert it into Pkcs7 format, and call the function
AcceptPkcs7(..) to install the certificate to CertStore, But everytime I failed, the ActiveX control return Error Number 424.
Of course ,all these things ocus in MS Internet Explore V 5.5.
Please help me to solve the problem.

the below text is the base64 format Pkcs7 Cert chain :

MIIF1gYJKoZIhvcNAQcCoIIFxzCCBcMCAQExADALBgkqhkiG9w0BBwGgggWrMIICizCCAfSgAwIBAgIBazANBgkqhkiG9w0BAQQFADCBwDERMA8GA1UEAxMIemhvbmd6aGkxCzAJBgNVBAYTAmNuMSAwHgYJKoZIhvcNAQkBFhF6aG9uZ3poaUBtYWlsLmNvbTELMAkGA1UEBxMCY3MxCzAJBgNVBAoTAnp6MQ8wDQYDVQQLEwZ6emluZm8xDzANBgNVBBATBjQxMDAxNTEPMA0GA1UEERMGNDEwMDE1MQswCQYDVQQIEwJobjEQMA4GA1UEFBMHNTUyNjA5MDEQMA4GA1UEFRMHNTUyMzY3MjAeFw0wMTAxMTEwNjQ1MjBaFw0wMjAxMTEwNjQ1MjBaMDoxDTALBgNVBAMTBHNhZGYxCzAJBgNVBAYTAmNuMRwwGgYJKoZIhvcNAQkBFg0xMTJAMzEyMS5zMTIzMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQCjG0TGiuBEdqPWZSwkP8SWkwAH2p8j29gIVdhgQVB2ctIb/MzyLb2puEoCn3mUOwHmXHuSJYLD56M/g5b+C3GRy8p+tSkk+mDgDbeTd88nR5Cn1fTDb1hT139F3yq9anDxsWgO8NpdGfcBLoI+PG3Itc5h9rUbem3ApvatJpAz6wIDAQABoxowGDAJBgNVHRMEAjAAMAsGA1UdDwQEAwIDqDANBgkqhkiG9w0BAQQFAAOBgQB9iJMo5eg1u7bLUpK6UcsIuB8Nu5aMEpAfzSw2TSu3n1rre+nEl79s9RAIaD01kvJZ8gJ7V3CKYal6ZjqHyHthtiQJqjhlPWmPPdUg2qSi0YPfT28qcJv0ODJzFfp+2AepndkEvGK7nZrSDJvMswNCRA2f8hc5q72fPuLB1VM/+jCCAxgwggKBoAMCAQICAQEwDQYJKoZIhvcNAQEFBQAwgcAxETAPBgNVBAMTCHpob25nemhpMQswCQYDVQQGEwJjbjEgMB4GCSqGSIb3DQEJARYRemhvbmd6aGlAbWFpbC5jb20xCzAJBgNVBAcTAmNzMQswCQYDVQQKEwJ6ejEPMA0GA1UECxMGenppbmZvMQ8wDQYDVQQQEwY0MTAwMTUxDzANBgNVBBETBjQxMDAxNTELMAkGA1UECBMCaG4xEDAOBgNVBBQTBzU1MjYwOTAxEDAOBgNVBBUTBzU1MjM2NzIwHhcNMDAxMjIxMDg0OTEzWhcNMDUxMjIxMDg0OTEzWjCBwDERMA8GA1UEAxMIemhvbmd6aGkxCzAJBgNVBAYTAmNuMSAwHgYJKoZIhvcNAQkBFhF6aG9uZ3poaUBtYWlsLmNvbTELMAkGA1UEBxMCY3MxCzAJBgNVBAoTAnp6MQ8wDQYDVQQLEwZ6emluZm8xDzANBgNVBBATBjQxMDAxNTEPMA0GA1UEERMGNDEwMDE1MQswCQYDVQQIEwJobjEQMA4GA1UEFBMHNTUyNjA5MDEQMA4GA1UEFRMHNTUyMzY3MjCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAsoAMc/KgPJQycfWDfg6GmfoUlZTMSDGIx0iq2YITziRuey1eY9wB80SbMJJdfv3CGSWr0/bQAqrEt0laoRcXQdsUdh6ENODruNjQ8cnSsWz4bWrVQIaWhyGjnytI2Ba+Ajne2H3CpgKhhEEUpA7t0oy3kMsQbbD2cRu1Rq/uClMCAwEAAaMgMB4wDwYDVR0TAQH/BAUwAwEB/zALBgNVHQ8EBAMCAQYwDQYJKoZIhvcNAQEFBQADgYEAiFm2dx6s6oO5V4Iyab42ZyC3x3C0YTlIts5aj1OUtV3Kn46xGQLovlFJ2hzffvY8uXodCDxL0KIaRTqckXC3HCKCunL7zx5PPNSom7BjMHsAPT4/u7aLF8kUmbhMuzvvo8m5Zl+Bjp1dv2zvOdex3T5UqaELYXRjvRY1Ej//ZWExAA==

I am anxious to see your back mail
please contack me
mail is: [email-masked]
or [email-masked]

Good luck, you and I .

______________________________________

===================================================================
ÐÂÀËÃâ·Ñµç×ÓÓÊÏä http://mail.sina.com.cn

ÄãÑ¡ÊÖ»úÎÒÂòµ¥£¡(http://mall.sina.com.cn/yesmobile/)

Received: from maila.telia.com (maila.telia.com [194.22.194.231]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id WAA07331 for ; Wed, 10 Jan 2001 22:07:18 -0800 (PST)
Received: from d1o69.telia.com (d1o69.telia.com [62.20.144.241]) by maila.telia.com (8.9.3/8.9.3) with ESMTP id HAA24453; Thu, 11 Jan 2001 07:12:22 +0100 (CET)
Received: from mega (t7o69p39.telia.com [213.65.46.39]) by d1o69.telia.com (8.10.2/8.10.1) with SMTP id f0B6CMl11319; Thu, 11 Jan 2001 07:12:22 +0100 (CET)
Message-ID: <[email-masked]>
From: "Anders Rundgren"
To: ,
References: <[email-masked]>
Subject: Re: Basic Cert-2-Directory mapping question
Date: Thu, 11 Jan 2001 07:10:44 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
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
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id WAA07333

Peter,

> >Flat name spaces scale poorly, lead to confusion, and are thus not attractive
> >in various ways. People do like flat name spaces, until they trip over the
> >limitations they embody, then they complain and look for magic solutions.
> >I've seen no appropriate magic for this problem.
>
> Have you actually seen the problem though? It's automatically assumed that
> there's some vast, unassailable problem which hierarchical names will solve,
> but I don't think I've ever seen it except as some special-case, often
> hypothetical situation which is used to justify the need for DNs (or whatever).
> In the real world people have been using their flat, non-scalable name spaces
> for several decades without any sign that civilisation is about to collapse.

I second that 100%. The only thing you gain by hierarchical cert names is rigidness
(i.e. can only be used in a certain regime) and low trace ability (change position
and then you become another identity). So even for closed PKI's we do have
a serious mapping issue IMNSHO.

Anders

Received: from mail.ec.auckland.ac.nz (mail.student.auckland.ac.nz [130.216.35.201]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id UAA05378 for ; Wed, 10 Jan 2001 20:06:23 -0800 (PST)
Received: from kahu.cs.auckland.ac.nz ([email-masked] [130.216.36.13]) by mail.ec.auckland.ac.nz (8.9.3/8.8.6/cs-master) with SMTP id RAA20768 for ; Thu, 11 Jan 2001 17:11:21 +1300 (NZDT) (sender [email-masked])
Received: by kahu.cs.auckland.ac.nz (relaymail v0.9) id <97918628126857>; Thu, 11 Jan 2001 17:11:21 (NZDT)
From: [email-masked] (Peter Gutmann)
To: [email-masked]
Subject: Re: Basic Cert-2-Directory mapping question
Sender: [email-masked]
Reply-To: [email-masked]
X-Charge-To: pgut001
X-Authenticated: relaymail v0.9 on kahu.cs.auckland.ac.nz
Date: Thu, 11 Jan 2001 17:11:21 (NZDT)
Message-ID: <[email-masked]>

Stephen Kent writes:
>At 9:08 AM +0100 1/10/01, Michael StrM-vder wrote:
>>=> People are used to flat name spaces. X.500 DNs does not work.
>
>Flat name spaces scale poorly, lead to confusion, and are thus not attractive
>in various ways. People do like flat name spaces, until they trip over the
>limitations they embody, then they complain and look for magic solutions.
>I've seen no appropriate magic for this problem.

Have you actually seen the problem though? It's automatically assumed that
there's some vast, unassailable problem which hierarchical names will solve,
but I don't think I've ever seen it except as some special-case, often
hypothetical situation which is used to justify the need for DNs (or whatever).
In the real world people have been using their flat, non-scalable name spaces
for several decades without any sign that civilisation is about to collapse.
Only yesterday I was talking to someone whose company is deploying a nationwide
PKI based on HTTP (you tack the ID of the cert owner onto a URL and grab it
from a server, revocation is handled by removing the cert). Since it's HTTP,
it's guaranteed to work through firewalls, proxies, and other oddities, and is
supported on every platform, I shudder to think what it would take to do the
same thing with CRLs and directories and DNs and whatnot.

In the real world we use flat IDs for practically everything where certs might
at some stage be employed without any problems, for example:

- Access to University account information (Uni. ID number)
- Access to/submission of tax info (taxpayer ID, SSN in the US I guess)
- Email encryption (email address)
- Access to/update of frequent flyer info (frequent flyer number, living
where I do you get handed one of these the first time you buy a ticket :-).
- Bank account access (account number)
- Access to patient medical records (from the discussion yesterday, this uses
some doctor registration number which is centrally managed)

There isn't actually anything I do which needs a hierarchical DN or any of the
accompanying paraphernalia and complexity (X.500/LDAP/whatever), in every case
a simple "Get me the cert for "
will do the job. What major, urgent real-world problem (apart from "Lack of
revenue from selling X.500 services"), which couldn't be addressed much more
simply with existing mechanisms, are DNs et al actually solving?

[I should add an addendum here that the person I was talking to asked me about
switching to LDAP, since he'd read about it a bit in the trade press and
wanted to know what was involved. I started to run through the standard
5-minute intro to X.500 and LDAP and he looked at me as if he expected a
cuckoo to pop out of my forehead on a small spring... I doubt they'll be
switching over any time soon]

Peter.

Received: from exchange.cylink.com (exchange.cylink.com [192.43.161.25]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id RAA20217 for ; Wed, 10 Jan 2001 17:13:12 -0800 (PST)
Received: by exchange.cylink.com with Internet Mail Service (5.5.2650.21) id ; Wed, 10 Jan 2001 17:10:23 -0800
Message-ID: <[email-masked]>
From: "Covey, Carlin"
To: PKIX-List
Subject: RE: DPD & DPV requirements - Recursion Issues
Date: Wed, 10 Jan 2001 17:10:21 -0800
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"

Steve,

I'm sorry that this isn't much of an analysis, but I think
that any such analysis should clearly separate the issues.
Here are three issues that I can think of:

1) One issue concerns the syntactic complexity of the protocol.
If the protocol permits a DPV/DPD response to include embedded
DPD/DPD responses from other servers, then the syntax will be a
bit more complex than it might be otherwise.

2) A second issue concerns transitive trust. This is an issue
even if embedded responses aren't permitted in the protocol.
A DPV/DPD server could contact another server and repackage
the response that it receives. This issue might be addressed
by providing hooks in the protocol to limit the extent of this
transitive trust. On the other hand, the issue might be
addressed by DPV/DPD server practice statements. "This is what
I might do, trust me or not." Or the issue might be addressed
by a combination of the two by using policy OIDs in the request
to indicate which practice statement the client is willing
to tolerate.

3) A third issue is whether the benefits of recursion outweigh the
difficulties presented by the first two issues. The authors of
the SCVP and OCSP-DPV proposals, and the author of the proposed
DPV/DPD requirements (someone well known to you, Steve) all chose
to permit OCSP v1 responses to be embedded in the DPD responses,
despite issues 1 and 2.

Regards, Carlin

----------------------------
- Carlin Covey
Cylink Corp.

-----Original Message-----
From: Stephen Kent [mailto:[email-masked]]
Sent: Wednesday, January 10, 2001 3:10 PM
To: Slone, Skip
Cc: PKIX-List
Subject: RE: DPD & DPV requirements

Skip,

If we do agree to support DPV server recursion, then the suggested
changes are appropriate ones to consider.

First, though, on what basis would you propose that a client
enable/disable recursion or set a depth limit? Since a client is
completely dependent on a DPV server to answer a query, and has no
local means of validating any supporting data sent along with the
answer, what does recursion say about the trust that the client
places in the server? If one believes that trust is transitive,
recursion may well be fine, and a simple numerical limit on depth of
recursion would not seem to be a good way to express limits on the
transitivity (e.g., one bad choice of a DPV server for reliance is
enough to kill you). If you don't think trust is transitive, then
recursion is inappropriate, unless you operate in a closed
environment where the recursion is among servers operated by the same
org and is really just an internal decision on how to implement the
server.

Perhaps this is one reason why I am not yet comfortable with adding
recursion to servers. I'd like to see some analysis of why it makes
sense, whether it makes sense for both DPD and DPV, etc.

Steve

Received: from mta6.snfc21.pbi.net (mta6.snfc21.pbi.net [206.13.28.240]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA13074 for ; Wed, 10 Jan 2001 15:13:43 -0800 (PST)
Received: from [192.168.1.9] ([208.233.228.110]) by mta6.snfc21.pbi.net (Sun Internet Mail Server sims.3.5.2000.01.05.12.18.p9) with ESMTP id <[email-masked]> for [email-masked]; Wed, 10 Jan 2001 15:09:31 -0800 (PST)
Date: Wed, 10 Jan 2001 15:10:59 -0800
From: Aram Perez
Subject: Re: Basic Cert-2-Directory mapping question
In-reply-to:
To: PKIX
Message-id:
MIME-version: 1.0
Content-type: text/plain; charset="US-ASCII"
Content-transfer-encoding: 7bit
User-Agent: Microsoft-Outlook-Express-Macintosh-Edition/5.02.2022

Stephen Kent wrote:

[snip]
> (I'm [email-masked], but [email-masked] works, and [email-masked]
> works too!)

So now you will get three times as much spam from the spammers that use the
PKIX mailing list!

;-)
Aram Perez

Received: from po1.bbn.com (PO1.BBN.COM [192.1.50.38]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA08047 for ; Wed, 10 Jan 2001 14:03:29 -0800 (PST)
Received: from [171.78.30.107] (comsec.bbn.com [171.78.30.107]) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id RAA09033; Wed, 10 Jan 2001 17:08:30 -0500 (EST)
Mime-Version: 1.0
X-Sender: [email-masked]
Message-Id:
In-Reply-To:
References:
Date: Wed, 10 Jan 2001 17:09:31 -0500
To: "Slone, Skip"
From: Stephen Kent
Subject: RE: DPD & DPV requirements
Cc: PKIX-List
Content-Type: text/plain; charset="us-ascii" ; format="flowed"

Skip,

If we do agree to support DPV server recursion, then the suggested
changes are appropriate ones to consider.

First, though, on what basis would you propose that a client
enable/disable recursion or set a depth limit? Since a client is
completely dependent on a DPV server to answer a query, and has no
local means of validating any supporting data sent along with the
answer, what does recursion say about the trust that the client
places in the server? If one believes that trust is transitive,
recursion may well be fine, and a simple numerical limit on depth of
recursion would not seem to be a good way to express limits on the
transitivity (e.g., one bad choice of a DPV server for reliance is
enough to kill you). If you don't think trust is transitive, then
recursion is inappropriate, unless you operate in a closed
environment where the recursion is among servers operated by the same
org and is really just an internal decision on how to implement the
server.

Perhaps this is one reason why I am not yet comfortable with adding
recursion to servers. I'd like to see some analysis of why it makes
sense, whether it makes sense for both DPD and DPV, etc.

Steve

Received: from mailgw2a.lmco.com (mailgw2a.lmco.com [192.91.147.7]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA07811 for ; Wed, 10 Jan 2001 14:02:31 -0800 (PST)
Received: from emss03g01.ems.lmco.com (emss03g01.ems.lmco.com [141.240.4.144]) by mailgw2a.lmco.com (8.8.8/8.8.8) with ESMTP id RAA00193; Wed, 10 Jan 2001 17:07:32 -0500 (EST)
Received: from CONVERSION-DAEMON by lmco.com (PMDF V5.2-32 #38888) id <[email-masked]>; Wed, 10 Jan 2001 17:06:43 -0500 (EST)
Received: from emss03i00.ems.lmco.com ([141.240.31.211]) by lmco.com (PMDF V5.2-32 #38888) with ESMTP id <[email-masked]>; Wed, 10 Jan 2001 17:06:13 -0500 (EST)
Received: by emss03i00.orl.lmco.com with Internet Mail Service (5.5.2650.21) id ; Wed, 10 Jan 2001 17:07:20 -0500
Content-return: allowed
Date: Wed, 10 Jan 2001 17:07:20 -0500
From: "Slone, Skip"
Subject: RE: Basic Cert-2-Directory mapping question
To: "'Sharon Boeyen'" , "'David P. Kemp'" , [email-masked]
Message-id:
MIME-version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-type: MULTIPART/ALTERNATIVE; BOUNDARY="Boundary_(ID_hRQWFJCCUaKlncso8RKU6g)"

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

--Boundary_(ID_hRQWFJCCUaKlncso8RKU6g)
Content-type: text/plain; charset=ISO-8859-1
Content-transfer-encoding: 8BIT

Thanks to all who have responded so quickly! Rather than try to maintain
multiple, divergent conversations on one topic, I'll provide a general
response to Sharon's note below, in hopes that this response clarifies what
I am (and what I'm not) trying to acheive.

Generally speaking, the concept I've been looking at provides a level of
abstraction that can be logically layered on top of the PKI Repository
Locator Service. (In previous posts, I sloppily used the term "directory
service" or "LDAP" when the more general term "repository" would have been
better. Mea culpa.) The pkixrep I-D says what to do to find a PKI
repository serving the domain "example.com." What it stops short of saying
is how one determines that "example.com" is the domain to query in the first
place. Since civil-to-DNS name mapping typically fails to yield to a
character string transliteration algorithm (e.g., "o=Joe's Bar and Grill"
does not readily translate to are-you-hungry.com), this leaves us with a
choice of either registering the translations or complaining that it can't
be done. Rather than complain that it can't be done, I've been exploring
what it would take to support a registration process. And, since I'm not
holding my breath waiting for X.500-based registration, the only globally
recognized registration service I'm aware of is DNS. Thus, my thoughts have
led me in that direction...

What I'm proposing is the development of a new DNS RR type that allows the
registration of arbitrary attribute value assertions (such as "o=Something"
or "ou=Something Else"). These new RRs (let's call them AVA RRs) would
resolve to a domain name that could subsequently be used to construct the
right hand portion of a PKIXREP query (or some other SRV-seeking query). A
remaining critical piece is the specification of c=XX as equivalent to a
corresponding ccTLD. As an example, when resolving a DN ending in o=Entrust,
c=CA, one would first query .ca for an AVA record matching "o=Entrust", and
would get a response such as "entrust.com" which would then be used to
generate a query along the line of _PKIXREP._LDAP.entrust.com. Similarly,
by registering "o=Lockheed Martin"-->lmco.com under .us, one could query .us
for the AVA record "o=Lockheed Martin" to generate a query for me.

With respect to the multiple-repository question, this process could still
lead someone to a company-operated repository, which then has the
appropriate knowledge references to the TTP-based repository. The trick is
getting from "I have no clue about where to go" to "I have a place to
start." Granted, if you have an email address, you have a place to start. I
guess the question is -- is that sufficient?

To address other questions, no, this doesn't solve all the problems (most
notably the problems with TTP certs issued to individuals), but when it
comes to mapping things like GTE to verizon.com, it is as flexible (or
inflexible, as the case may be) as the supporting registration processes.

Hope this helps...

-- Skip

-----Original Message-----
From: Sharon Boeyen [mailto:[email-masked]]
Sent: Wednesday, January 10, 2001 4:13 PM
To: 'Slone, Skip'; 'David P. Kemp'; [email-masked]
Subject: RE: Basic Cert-2-Directory mapping question

I'm not convinced that name mapping would actually satisfy the requirement
because
the issuer and the subject of a certificate may have DNs that are not
linked in the manner you are expecting (e.g. a service provider (lets call
it c=us; o=certpump) might issue certificates to users who have DNs such
as cn=Skip Slone, o=Lockheed Martin, c=US. It might very well be the public
provider that maintains the repository for the certificates it issues and
the fact that Lockheed Martin also maintains a directory with entries for
those users doesn't necessarily mean you'll get to the right place.

That is one of the reasons the PKI repository locator service draft is
different
from the SRV draft the LDAP group defined. Specific to PKI, a domain places
SRV records for the different protocols that can be used to reach their PKI
repository. At present it can provide LDAP records, and others but is
queried on domain name
and perhaps what would help would be a way to get you to a domain domain
name so
that you could then query for the SRV records for that domain's PKI
repository?

One more point, that I think Steve already mentioned is that there are hints
available
already in the SIA and AIA. If we take this back to a "what are we
trying to achieve" level it would sure help me.

If you are verifying a signature, you already have the EE cert and are
either
retrieving revocation information or an intermediate cert. These extensions
should be
useful for that. If you need to encrypt for another user (e.g. an email),
that is where
the PKI repository locator issue seems to be the biggest. For email, you
have the email
address so you know the domain name and can use PKI repository locator
service to obtain
SRV records that give you the necessary information to connect to the
repository that holds
the PKI data for that domain.

If you can outline the type of environment where none of the above provides
what is needed
that will at least help focus the discussion better. I've skimmed very
quickly through the
messages in this thread and apologize in advance if this is already stated
but I missed it.
I do tend to pay more attention to the shorter messages than the longer ones
:-(

Thanks
Sharon

> -----Original Message-----
> From: Slone, Skip [ mailto:[email-masked]
]
> Sent: Wednesday, January 10, 2001 3:27 PM
> To: 'David P. Kemp'; [email-masked]
> Subject: RE: Basic Cert-2-Directory mapping question
>
>
> David,
>
> Only somewhat tongue-in-cheek, I'll say the answer to your
> question is "only
> if you want the right answer" ;-)
>
> As I see it, we're dealing with the fact that we have extant
> DNs all over
> the map with no semblance of a registration authority.
> Consequently, we have
> no reasonable way of getting from an arbitrary DN to a
> directory service.
> The closest thing to a global registration authority that
> exists is DNS
> (including, of course, its whole supporting cast). As such,
> it made sense
> for the Internet community to tackle those names found within
> the current
> DNS struture. What I would like to propose is that we build
> on that success
> and extend the authority of DNS into other parts of the DN
> namespace. To do
> so requires the definition of some mappings (namely c=XX to
> ) and the
> creation of a way (i.e., a new DNS RR type) to use DNS to
> register names
> traditionally associated with X.500/LDAP.
>
> By way of example, what I'm talking about is the ability to
> take a DN of the
> form "cn=Skip Slone, o=Lockheed Martin, c=US" and determine
> that the LDAP
> server to check is found at (for example) ldap1.external.lmco.com.
>
> That said, such registration in DNS, combined with a
> deterministic algorithm
> will return a result of the following form:
> a) the DN maps to an LDAP server found at foo.com, OR
> b) the DN does not map to a registered LDAP server
>
> If you get answer "a" you then send an LDAP query to
> foo.com:389 to find the
> entry itself.
>
> To answer your question properly, I would contend that if
> "o=Foo, Inc." is
> not registered under these rules, you would get answer "b".
> Even though you
> don't find the entry, you still get a deterministic response.
>
> -- Skip
>
> -----Original Message-----
> From: David P. Kemp [ mailto:[email-masked]
]
> Sent: Wednesday, January 10, 2001 2:51 PM
> To: [email-masked]
> Subject: RE: Basic Cert-2-Directory mapping question
>
>
> Skip,
>
> Doesn't the existence of a deterministic algorithm depend on users
> of civil (Country-based) names following the rules?
>
> As Michael Ströder pointed out, everyone wants a short name in a
> flat namespace. But not every Joe's Bar & Grill in the US can
> have certificates with the name "C=US, O=Joe's Bar & Grill". If
> TTP CAs are willing to issue such certificates without evidence
> that the name has been registered with the US national authority,
> what algorithm can possibly find all the directory entries for
> that DN?
>
> Dave
>
>
>
>
> > From: "Slone, Skip"
> > Subject: RE: Basic Cert-2-Directory mapping question
> > To: [email-masked]
> >
> > As the traffic on this topic points out, there are a lot of
> people who see
> > this as an issue. Whether we can agree on exactly what the
> issue is and
> how
> > to proceed may be another matter ... :-)
> >
> > As have many others on this list, I've been giving this
> issue some thought
> > lately, focusing on the problems as seen from the
> perspective of a large
> > user like my company. Although I've come to a different set
> of conclusions
> > from those discussed so far in this thread, my energy has
> been focused on
> > the same problem that Bob Jueneman pointed out: knowing the
> location of a
> > directory service provider that is supposed to contain the DN.
> >
> > My basic premise is that if we can come up with a
> deterministic algorithm
> > that takes an arbitrary (but reasonably well structured) DN
> and resolves
> it
> > to a set of FQDNs where one can find LDAP services, we can
> deterministically
> > get from the DN to the associated directory entry. As
> Steve Kent pointed
> > out, there exists a body of work to do this in the limited
> case of DNs
> based
> > on (DNS) domainComponent naming. My thoughts are along
> that line, but
> > expand to cover the so-called "civil" naming constructs in
> DNs, such as
> > country, organization, and so on. I think that's the goal Anders
> originally
> > stated, starting this whole thread.
> >
> > If people are interested, I'll summarize the algorithm I've
> come up with
> so
> > far and distribute it for review. If need be, we could
> consider whether
> > this is worthy of an I-D, or a BOF at Minneapolis, or whatever...
> >
> > Regards,
> >
> > -- Skip Slone
> > Lockheed Martin
>

--Boundary_(ID_hRQWFJCCUaKlncso8RKU6g)
Content-type: text/html; charset=ISO-8859-1
Content-transfer-encoding: 8BIT

RE: Basic Cert-2-Directory mapping question

Thanks
to all who have responded so quickly! Rather than try to maintain multiple,
divergent conversations on one topic, I'll provide a general response to
Sharon's note below, in hopes that this response clarifies what I am (and what
I'm not) trying to acheive.

Generally speaking, the concept I've been looking at
provides a level of abstraction that can be logically layered on top of the PKI
Repository Locator Service.  (In previous posts, I sloppily used the term
"directory service" or "LDAP" when the more general term "repository" would have
been better.  Mea culpa.) The pkixrep I-D says what to do to find
a PKI repository serving the domain "example.com."  What it stops
short of saying is how one determines that "example.com" is the domain to query
in the first place.  Since civil-to-DNS name mapping typically fails
to yield to a character string transliteration algorithm (e.g., "o=Joe's Bar and
Grill" does not readily translate to are-you-hungry.com), this leaves us with a
choice of either registering the translations or complaining that it can't be
done. Rather than complain that it can't be done, I've been exploring what
it would take to support a registration process.  And, since I'm not
holding my breath waiting for X.500-based registration, the only globally
recognized registration service I'm aware of is DNS.  Thus, my thoughts
have led me in that direction...

What
I'm proposing is the development of a new DNS RR type that allows the
registration of arbitrary attribute value assertions (such as "o=Something"
or "ou=Something Else"). These new RRs (let's call them AVA RRs)
would resolve to a domain name that could subsequently be used to
construct the right hand portion of a PKIXREP query (or some other SRV-seeking
query).  A remaining critical piece is the specification of c=XX
as equivalent to a corresponding ccTLD. As an example, when resolving
a DN ending in o=Entrust, c=CA, one would first query .ca for an AVA record
matching "o=Entrust", and would get a response such as "entrust.com" which would
then be used to generate a query along the line of
_PKIXREP._LDAP.entrust.com.  Similarly, by registering "o=Lockheed
Martin"-->lmco.com under .us, one could query .us for the AVA record
"o=Lockheed Martin" to generate a query for me.

With
respect to the multiple-repository question, this process could still lead
someone to a company-operated repository, which then has the appropriate
knowledge references to the TTP-based repository.  The trick is getting
from "I have no clue about where to go" to "I have a place to start." Granted,
if you have an email address, you have a place to start.  I guess the
question is -- is that sufficient?

To
address other questions, no, this doesn't solve all the problems (most notably
the problems with TTP certs issued to individuals), but when it comes to mapping
things like GTE to verizon.com, it is as flexible (or inflexible, as the case
may be) as the supporting registration processes.

Hope
this helps...

-- Skip

-----Original Message-----
From:
Sharon Boeyen [mailto:[email-masked]]
Sent: Wednesday,
January 10, 2001 4:13 PM
To: 'Slone, Skip'; 'David P. Kemp';
[email-masked]
Subject: RE: Basic Cert-2-Directory mapping
question

I'm not convinced that name mapping would actually satisfy the
requirement because
the issuer and the subject of a
certificate may have DNs that are not
linked in the
manner you are expecting (e.g. a service provider (lets call
it c=us; o=certpump) might issue certificates to users who have DNs
such
as cn=Skip Slone, o=Lockheed Martin, c=US. It
might very well be the public
provider that maintains
the repository for the certificates it issues and
the
fact that Lockheed Martin also maintains a directory with entries for

those users doesn't necessarily mean you'll get to the
right place.

That is one of the reasons the PKI repository locator service
draft is different
from the SRV draft the LDAP group
defined. Specific to PKI, a domain places
SRV records
for the different protocols that can be used to reach their PKI

repository. At present it can provide LDAP records,
and others but is queried on domain name
and perhaps
what would help would be a way to get you to a domain domain name so

that you could then query for the SRV records for that
domain's PKI repository?

One more point, that I think Steve already mentioned is that
there are hints available
already in the SIA and AIA.
If we take this back to a "what are we
trying to
achieve" level it would sure help me.

If you are verifying a signature, you already have the EE cert
and are either
retrieving revocation information or an
intermediate cert. These extensions should be
useful
for that. If you need to encrypt for another user (e.g. an email), that is
where
the PKI repository locator issue seems to be the
biggest. For email, you have the email
address so you
know the domain name and can use PKI repository locator service to obtain

SRV records that give you the necessary information to
connect to the repository that holds
the PKI data for
that domain.

If you can outline the type of environment where none of the
above provides what is needed
that will at least help
focus the discussion better. I've skimmed very quickly through the

messages in this thread and apologize in advance if
this is already stated but I missed it.
I do tend to
pay more attention to the shorter messages than the longer ones :-(

Thanks
Sharon

> -----Original Message-----
>
From: Slone, Skip [mailto:[email-masked]]

> Sent: Wednesday, January 10, 2001 3:27 PM

> To: 'David P. Kemp'; [email-masked]
> Subject: RE: Basic Cert-2-Directory mapping question

> David,
Only somewhat tongue-in-cheek, I'll say the answer to your
> question is "only
> if you want the
right answer" ;-)
> As
I see it, we're dealing with the fact that we have extant
> DNs all over
> the map with no
semblance of a registration authority.
Consequently, we have
> no reasonable way of
getting from an arbitrary DN to a
> directory
service.
> The closest thing to a global
registration authority that
> exists is DNS

> (including, of course, its whole supporting cast). As
such,
> it made sense
for the Internet community to tackle those names found within
> the current
> DNS struture.  What
I would like to propose is that we build
> on that
success
> and extend the authority of DNS into
other parts of the DN
> namespace.  To
do
> so requires the definition of some mappings
(namely c=XX to
> <ccTLD>) and the

> creation of a way (i.e., a new DNS RR type) to use DNS
to
> register names
traditionally associated with X.500/LDAP.

> By way of example, what I'm talking about is the
ability to
> take a DN of the
> form "cn=Skip Slone, o=Lockheed Martin, c=US" and determine

> that the LDAP
> server
to check is found at (for example) ldap1.external.lmco.com.
>
> That said, such registration in DNS,
combined with a
> deterministic algorithm

> will return a result of the following form:

>  a) the DN maps to an LDAP server found at foo.com,
OR
>  b) the DN does not map to a registered
LDAP server
> If you
get answer "a" you then send an LDAP query to
foo.com:389 to find the
> entry itself.

> To answer your
question properly, I would contend that if
"o=Foo, Inc." is
> not registered under these
rules, you would get answer "b".
> Even
though you
> don't find the entry, you still get a
deterministic response.
>
>  -- Skip
>
> -----Original Message-----
> From:
David P. Kemp [mailto:[email-masked]]

> Sent: Wednesday, January 10, 2001 2:51 PM

> To: [email-masked]
Subject: RE: Basic Cert-2-Directory mapping question
Skip,
> Doesn't the
existence of a deterministic algorithm depend on users
> of civil (Country-based) names following the rules?

>
> As Michael Ströder pointed
out, everyone wants a short name in a
> flat
namespace.  But not every Joe's Bar & Grill in the US can

> have certificates with the name "C=US, O=Joe's Bar &
Grill".  If
> TTP CAs are willing to issue
such certificates without evidence
> that the name
has been registered with the US national authority,
> what algorithm can possibly find all the directory entries
for
> that DN?

> Dave

> > From: "Slone, Skip"
<[email-masked]>
> > Subject: RE:
Basic Cert-2-Directory mapping question
> > To:
[email-masked]
> >
> > As the traffic on this topic points out, there are a lot of

> people who see
this as an issue.  Whether we can agree on exactly what the

> issue is and
how
> > to proceed may be another matter ...
:-)
> > As
have many others on this list, I've been giving this
> issue some thought
> > lately,
focusing on the problems as seen from the
perspective of a large
> > user like my company.
Although I've come to a different set
> of
conclusions
> > from those discussed so far in
this thread, my energy has
> been focused on

> > the same problem that Bob Jueneman pointed out:
knowing the
> location of a
> > directory service provider that is supposed to contain the
DN.
> > My
basic premise is that if we can come up with a
deterministic algorithm
> > that takes an
arbitrary (but reasonably well structured) DN
> and
resolves
> it
> > to
a set of FQDNs where one can find LDAP services, we can
> deterministically
> > get from the
DN to the associated directory entry.  As
Steve Kent pointed
> > out, there exists a body
of work to do this in the limited
> case of
DNs
> based
> > on
(DNS) domainComponent naming.  My thoughts are along
> that line, but
> > expand to cover
the so-called "civil" naming constructs in
> DNs,
such as
> > country, organization, and so
on.  I think that's the goal Anders
originally
> > stated, starting this whole
thread.
> > If
people are interested, I'll summarize the algorithm I've
> come up with
> so
> > far and distribute it for review.  If need be, we could

> consider whether
>
> this is worthy of an I-D, or a BOF at Minneapolis, or whatever...

> > Regards,

> >  -- Skip
Slone
> >     Lockheed
Martin

--Boundary_(ID_hRQWFJCCUaKlncso8RKU6g)--

Received: from po1.bbn.com (PO1.BBN.COM [192.1.50.38]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA07117 for ; Wed, 10 Jan 2001 13:53:36 -0800 (PST)
Received: from [171.78.30.107] (comsec.bbn.com [171.78.30.107]) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id QAA07744; Wed, 10 Jan 2001 16:58:37 -0500 (EST)
Mime-Version: 1.0
X-Sender: [email-masked]
Message-Id:
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]>
Date: Wed, 10 Jan 2001 16:58:00 -0500
To: Michael =?iso-8859-1?Q?Str=F6der?=
From: Stephen Kent
Subject: Re: Basic Cert-2-Directory mapping question
Cc: "[email-masked]"
Content-Type: text/plain; charset="us-ascii" ; format="flowed"

Michael,

>Peter Gutmann wrote:
> >
> > Stephen Kent writes:
> >
> > >I have not read your paper, but the assertion that DNs don't work, without
> > >substantiation, seems a bit strong.
> >
> > [.. Very many valid points by Peter deleted..]
>
>Peter, I completely agree with you. IMHO one of the main problems
>with
>PKIX is that there's so much X.500 in it. ;-) (I enjoyed your
>writing about T.61...)

Perhaps thinking about the WG name will clarify why there's so much
X.500 in PKIX. Were you looking for the SPKI WG list and wound up
here by accident?

Steve

Received: from po1.bbn.com (PO1.BBN.COM [192.1.50.38]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA07101 for ; Wed, 10 Jan 2001 13:53:34 -0800 (PST)
Received: from [171.78.30.107] (comsec.bbn.com [171.78.30.107]) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id QAA07741; Wed, 10 Jan 2001 16:58:36 -0500 (EST)
Mime-Version: 1.0
X-Sender: [email-masked]
Message-Id:
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]>
Date: Wed, 10 Jan 2001 16:55:38 -0500
To: Michael =?iso-8859-1?Q?Str=F6der?=
From: Stephen Kent
Subject: Re: Basic Cert-2-Directory mapping question
Cc: [email-masked]
Content-Type: text/plain; charset="iso-8859-1" ; format="flowed"
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id NAA07102

At 9:08 AM +0100 1/10/01, Michael Ströder wrote:
>
>
>
>=> People are used to flat name spaces. X.500 DNs does not work.

Flat name spaces scale poorly, lead to confusion, and are thus not
attractive in various ways. People do like flat name spaces, until
they trip over the limitations they embody, then they complain and
look for magic solutions. I've seen no appropriate magic for this
problem.

Steve

Received: from po1.bbn.com (PO1.BBN.COM [192.1.50.38]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA06259 for ; Wed, 10 Jan 2001 13:43:39 -0800 (PST)
Received: from [171.78.30.107] (comsec.bbn.com [171.78.30.107]) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id QAA06429; Wed, 10 Jan 2001 16:48:32 -0500 (EST)
Mime-Version: 1.0
X-Sender: [email-masked]
Message-Id:
In-Reply-To:
References:
Date: Wed, 10 Jan 2001 16:45:09 -0500
To: "Bob Jueneman"
From: Stephen Kent
Subject: RE: Basic Cert-2-Directory mapping question
Cc:
Content-Type: text/plain; charset="us-ascii" ; format="flowed"

Bob,

>Skip, as you correctly point out, the problem is not so great in the case
>of an organization that operates its own DNS domain, and uses that domain
>as the means of providing directory service access. Certainly a company
>like Novell, Lockheed, GTE (oops, Verizon), etc., could easily do so.
>
>But notice some of the problems. I'm not picking on our esteemed
>co-chair, but
>notice that Steve's e-mail address, [email-masked], is two corporate mergers
>behind the times, since GTE acquired BBN, and then Verizon was formed out
>of GTE and Bell Atlantic. But if his certificate were deposited at
>something like
>directory.verizon.com, how would you extract that from the BBN name?
>would all of those older e-mail address have to have a set of alias
>DNS names for
>the directory server?

Life is a bit more complicated than your example suggests. I still
work at BBN, BBN Technologies, a part of Verizon. We still own the
domain name BBN, and we're getting our own logo again, so mergers and
acquisitions don't always warrant wholesale changes! My GTE
colleagues probably do need to change over to new, Verizon e-mail
addresses, over time, but not instantly. The GTE and Bell Atlantic
logo change will be phased over about 2 years, in the physical arena,
so one could expect a similar grace period in cyberspace. Also, it
would not be unreasonable for a Verizon directory to provide links to
BBN, just as people often maintain multiple e-mail addresses, with
appropriate internal links, to smooth over transitions of this sort.
(I'm [email-masked], but [email-masked] works, and [email-masked]
works too!)

Steve

Received: from po1.bbn.com (PO1.BBN.COM [192.1.50.38]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA06247 for ; Wed, 10 Jan 2001 13:43:37 -0800 (PST)
Received: from [171.78.30.107] (comsec.bbn.com [171.78.30.107]) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id QAA06432; Wed, 10 Jan 2001 16:48:32 -0500 (EST)
Mime-Version: 1.0
X-Sender: [email-masked]
Message-Id:
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Date: Wed, 10 Jan 2001 16:48:28 -0500
To: Peter Sylvester
From: Stephen Kent
Subject: RE: DPD & DPV requirements - Let us Recurse
Cc: [email-masked]
Content-Type: text/plain; charset="us-ascii" ; format="flowed"

Peter,

I thinbk we are in agreement that the set of data returned by a DPD
or DPV server will be limited in scope and well defined, i.e.,
sequences of certs, CRLs, and OCSP responses are the initial set.
Whether we allow recursion and allow DPV responses is still an open
question.

Steve

Received: from sottmxs02.entrust.com (gatekeeper.entrust.com [204.101.128.170]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA03867 for ; Wed, 10 Jan 2001 13:11:09 -0800 (PST)
Received: by sottmxs02.entrust.com with Internet Mail Service (5.5.2650.21) id ; Wed, 10 Jan 2001 16:14:37 -0500
Message-ID:
From: Sharon Boeyen
To: "'Slone, Skip'" , "'David P. Kemp'" , [email-masked]
Subject: RE: Basic Cert-2-Directory mapping question
Date: Wed, 10 Jan 2001 16:12:43 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C07B4A.12A0FA70"

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_01C07B4A.12A0FA70
Content-Type: text/plain;
charset="iso-8859-1"

I'm not convinced that name mapping would actually satisfy the requirement
because
the issuer and the subject of a certificate may have DNs that are not
linked in the manner you are expecting (e.g. a service provider (lets call
it c=us; o=certpump) might issue certificates to users who have DNs such
as cn=Skip Slone, o=Lockheed Martin, c=US. It might very well be the public
provider that maintains the repository for the certificates it issues and
the fact that Lockheed Martin also maintains a directory with entries for
those users doesn't necessarily mean you'll get to the right place.

That is one of the reasons the PKI repository locator service draft is
different
from the SRV draft the LDAP group defined. Specific to PKI, a domain places
SRV records for the different protocols that can be used to reach their PKI
repository. At present it can provide LDAP records, and others but is
queried on domain name
and perhaps what would help would be a way to get you to a domain domain
name so
that you could then query for the SRV records for that domain's PKI
repository?

One more point, that I think Steve already mentioned is that there are hints
available
already in the SIA and AIA. If we take this back to a "what are we
trying to achieve" level it would sure help me.

If you are verifying a signature, you already have the EE cert and are
either
retrieving revocation information or an intermediate cert. These extensions
should be
useful for that. If you need to encrypt for another user (e.g. an email),
that is where
the PKI repository locator issue seems to be the biggest. For email, you
have the email
address so you know the domain name and can use PKI repository locator
service to obtain
SRV records that give you the necessary information to connect to the
repository that holds
the PKI data for that domain.

If you can outline the type of environment where none of the above provides
what is needed
that will at least help focus the discussion better. I've skimmed very
quickly through the
messages in this thread and apologize in advance if this is already stated
but I missed it.
I do tend to pay more attention to the shorter messages than the longer ones
:-(

Thanks
Sharon

> -----Original Message-----
> From: Slone, Skip [mailto:[email-masked]]
> Sent: Wednesday, January 10, 2001 3:27 PM
> To: 'David P. Kemp'; [email-masked]
> Subject: RE: Basic Cert-2-Directory mapping question
>
>
> David,
>
> Only somewhat tongue-in-cheek, I'll say the answer to your
> question is "only
> if you want the right answer" ;-)
>
> As I see it, we're dealing with the fact that we have extant
> DNs all over
> the map with no semblance of a registration authority.
> Consequently, we have
> no reasonable way of getting from an arbitrary DN to a
> directory service.
> The closest thing to a global registration authority that
> exists is DNS
> (including, of course, its whole supporting cast). As such,
> it made sense
> for the Internet community to tackle those names found within
> the current
> DNS struture. What I would like to propose is that we build
> on that success
> and extend the authority of DNS into other parts of the DN
> namespace. To do
> so requires the definition of some mappings (namely c=XX to
> ) and the
> creation of a way (i.e., a new DNS RR type) to use DNS to
> register names
> traditionally associated with X.500/LDAP.
>
> By way of example, what I'm talking about is the ability to
> take a DN of the
> form "cn=Skip Slone, o=Lockheed Martin, c=US" and determine
> that the LDAP
> server to check is found at (for example) ldap1.external.lmco.com.
>
> That said, such registration in DNS, combined with a
> deterministic algorithm
> will return a result of the following form:
> a) the DN maps to an LDAP server found at foo.com, OR
> b) the DN does not map to a registered LDAP server
>
> If you get answer "a" you then send an LDAP query to
> foo.com:389 to find the
> entry itself.
>
> To answer your question properly, I would contend that if
> "o=Foo, Inc." is
> not registered under these rules, you would get answer "b".
> Even though you
> don't find the entry, you still get a deterministic response.
>
> -- Skip
>
> -----Original Message-----
> From: David P. Kemp [mailto:[email-masked]]
> Sent: Wednesday, January 10, 2001 2:51 PM
> To: [email-masked]
> Subject: RE: Basic Cert-2-Directory mapping question
>
>
> Skip,
>
> Doesn't the existence of a deterministic algorithm depend on users
> of civil (Country-based) names following the rules?
>
> As Michael Ströder pointed out, everyone wants a short name in a
> flat namespace. But not every Joe's Bar & Grill in the US can
> have certificates with the name "C=US, O=Joe's Bar & Grill". If
> TTP CAs are willing to issue such certificates without evidence
> that the name has been registered with the US national authority,
> what algorithm can possibly find all the directory entries for
> that DN?
>
> Dave
>
>
>
>
> > From: "Slone, Skip"
> > Subject: RE: Basic Cert-2-Directory mapping question
> > To: [email-masked]
> >
> > As the traffic on this topic points out, there are a lot of
> people who see
> > this as an issue. Whether we can agree on exactly what the
> issue is and
> how
> > to proceed may be another matter ... :-)
> >
> > As have many others on this list, I've been giving this
> issue some thought
> > lately, focusing on the problems as seen from the
> perspective of a large
> > user like my company. Although I've come to a different set
> of conclusions
> > from those discussed so far in this thread, my energy has
> been focused on
> > the same problem that Bob Jueneman pointed out: knowing the
> location of a
> > directory service provider that is supposed to contain the DN.
> >
> > My basic premise is that if we can come up with a
> deterministic algorithm
> > that takes an arbitrary (but reasonably well structured) DN
> and resolves
> it
> > to a set of FQDNs where one can find LDAP services, we can
> deterministically
> > get from the DN to the associated directory entry. As
> Steve Kent pointed
> > out, there exists a body of work to do this in the limited
> case of DNs
> based
> > on (DNS) domainComponent naming. My thoughts are along
> that line, but
> > expand to cover the so-called "civil" naming constructs in
> DNs, such as
> > country, organization, and so on. I think that's the goal Anders
> originally
> > stated, starting this whole thread.
> >
> > If people are interested, I'll summarize the algorithm I've
> come up with
> so
> > far and distribute it for review. If need be, we could
> consider whether
> > this is worthy of an I-D, or a BOF at Minneapolis, or whatever...
> >
> > Regards,
> >
> > -- Skip Slone
> > Lockheed Martin
>

------_=_NextPart_001_01C07B4A.12A0FA70
Content-Type: text/html;
charset="iso-8859-1"

RE: Basic Cert-2-Directory mapping question

I'm not convinced that name mapping would actually satisfy the requirement because

the issuer and the subject of a certificate may have DNs that are not

linked in the manner you are expecting (e.g. a service provider (lets call

it c=us; o=certpump) might issue certificates to users who have DNs such

as cn=Skip Slone, o=Lockheed Martin, c=US. It might very well be the public

provider that maintains the repository for the certificates it issues and

the fact that Lockheed Martin also maintains a directory with entries for

those users doesn't necessarily mean you'll get to the right place.

That is one of the reasons the PKI repository locator service draft is different

from the SRV draft the LDAP group defined. Specific to PKI, a domain places

SRV records for the different protocols that can be used to reach their PKI

repository. At present it can provide LDAP records, and others but is queried on domain name

and perhaps what would help would be a way to get you to a domain domain name so

that you could then query for the SRV records for that domain's PKI repository?

One more point, that I think Steve already mentioned is that there are hints available

already in the SIA and AIA. If we take this back to a "what are we

trying to achieve" level it would sure help me.

If you are verifying a signature, you already have the EE cert and are either

retrieving revocation information or an intermediate cert. These extensions should be

useful for that. If you need to encrypt for another user (e.g. an email), that is where

the PKI repository locator issue seems to be the biggest. For email, you have the email

address so you know the domain name and can use PKI repository locator service to obtain

SRV records that give you the necessary information to connect to the repository that holds

the PKI data for that domain.

If you can outline the type of environment where none of the above provides what is needed

that will at least help focus the discussion better. I've skimmed very quickly through the

messages in this thread and apologize in advance if this is already stated but I missed it.

I do tend to pay more attention to the shorter messages than the longer ones :-(

Thanks

Sharon

> -----Original Message-----

> From: Slone, Skip [mailto:[email-masked]]

> Sent: Wednesday, January 10, 2001 3:27 PM

> To: 'David P. Kemp'; [email-masked]

> Subject: RE: Basic Cert-2-Directory mapping question

> David,

> Only somewhat tongue-in-cheek, I'll say the answer to your

> question is "only

> if you want the right answer" ;-)

> As I see it, we're dealing with the fact that we have extant

> DNs all over

> the map with no semblance of a registration authority.

> Consequently, we have

> no reasonable way of getting from an arbitrary DN to a

> directory service.

> The closest thing to a global registration authority that

> exists is DNS

> (including, of course, its whole supporting cast). As such,

> it made sense

> for the Internet community to tackle those names found within

> the current

> DNS struture.  What I would like to propose is that we build

> on that success

> and extend the authority of DNS into other parts of the DN

> namespace.  To do

> so requires the definition of some mappings (namely c=XX to

> <ccTLD>) and the

> creation of a way (i.e., a new DNS RR type) to use DNS to

> register names

> traditionally associated with X.500/LDAP.

> By way of example, what I'm talking about is the ability to

> take a DN of the

> form "cn=Skip Slone, o=Lockheed Martin, c=US" and determine

> that the LDAP

> server to check is found at (for example) ldap1.external.lmco.com.

> That said, such registration in DNS, combined with a

> deterministic algorithm

> will return a result of the following form:

>  a) the DN maps to an LDAP server found at foo.com, OR

>  b) the DN does not map to a registered LDAP server

> If you get answer "a" you then send an LDAP query to

> foo.com:389 to find the

> entry itself.

> To answer your question properly, I would contend that if

> "o=Foo, Inc." is

> not registered under these rules, you would get answer "b".

> Even though you

> don't find the entry, you still get a deterministic response.

>  -- Skip

> -----Original Message-----

> From: David P. Kemp [mailto:[email-masked]]

> Sent: Wednesday, January 10, 2001 2:51 PM

> To: [email-masked]

> Subject: RE: Basic Cert-2-Directory mapping question

> Skip,

> Doesn't the existence of a deterministic algorithm depend on users

> of civil (Country-based) names following the rules?

> As Michael Ströder pointed out, everyone wants a short name in a

> flat namespace.  But not every Joe's Bar & Grill in the US can

> have certificates with the name "C=US, O=Joe's Bar & Grill".  If

> TTP CAs are willing to issue such certificates without evidence

> that the name has been registered with the US national authority,

> what algorithm can possibly find all the directory entries for

> that DN?

> Dave

> > From: "Slone, Skip" <[email-masked]>

> > Subject: RE: Basic Cert-2-Directory mapping question

> > To: [email-masked]

> > As the traffic on this topic points out, there are a lot of

> people who see

> > this as an issue.  Whether we can agree on exactly what the

> issue is and

> how

> > to proceed may be another matter ... :-)

> > As have many others on this list, I've been giving this

> issue some thought

> > lately, focusing on the problems as seen from the

> perspective of a large

> > user like my company. Although I've come to a different set

> of conclusions

> > from those discussed so far in this thread, my energy has

> been focused on

> > the same problem that Bob Jueneman pointed out: knowing the

> location of a

> > directory service provider that is supposed to contain the DN.

> > My basic premise is that if we can come up with a

> deterministic algorithm

> > that takes an arbitrary (but reasonably well structured) DN

> and resolves

> it

> > to a set of FQDNs where one can find LDAP services, we can

> deterministically

> > get from the DN to the associated directory entry.  As

> Steve Kent pointed

> > out, there exists a body of work to do this in the limited

> case of DNs

> based

> > on (DNS) domainComponent naming.  My thoughts are along

> that line, but

> > expand to cover the so-called "civil" naming constructs in

> DNs, such as

> > country, organization, and so on.  I think that's the goal Anders

> originally

> > stated, starting this whole thread.

> > If people are interested, I'll summarize the algorithm I've

> come up with

> so

> > far and distribute it for review.  If need be, we could

> consider whether

> > this is worthy of an I-D, or a BOF at Minneapolis, or whatever...

> > Regards,

> >  -- Skip Slone

> >     Lockheed Martin

------_=_NextPart_001_01C07B4A.12A0FA70--

Received: from maila.telia.com (maila.telia.com [194.22.194.231]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA03178 for ; Wed, 10 Jan 2001 13:04:51 -0800 (PST)
Received: from d1o69.telia.com (d1o69.telia.com [62.20.144.241]) by maila.telia.com (8.9.3/8.9.3) with ESMTP id WAA18270; Wed, 10 Jan 2001 22:09:53 +0100 (CET)
Received: from mega (t7o69p95.telia.com [213.65.46.95]) by d1o69.telia.com (8.10.2/8.10.1) with SMTP id f0AL9pl03699; Wed, 10 Jan 2001 22:09:52 +0100 (CET)
Message-ID: <[email-masked]>
From: "Anders Rundgren"
To: "Slone, Skip" ,
References:
Subject: Re: Basic Cert-2-Directory mapping question
Date: Wed, 10 Jan 2001 22:08:15 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
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
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id NAA03181

Skip,

I have a feeling that we are addressing slightly different problems.
Your suggestion *seems* to address the mapping of one cert DN into *one*
particular directory.

I am more interested in the mapping of one cert DN into *many* different RPs directories.
In that case DNS would not help as the mapping is entirely local.

Anders

>
> As I see it, we're dealing with the fact that we have extant DNs all over
> the map with no semblance of a registration authority. Consequently, we have
> no reasonable way of getting from an arbitrary DN to a directory service.
> The closest thing to a global registration authority that exists is DNS
> (including, of course, its whole supporting cast). As such, it made sense
> for the Internet community to tackle those names found within the current
> DNS struture. What I would like to propose is that we build on that success
> and extend the authority of DNS into other parts of the DN namespace. To do
> so requires the definition of some mappings (namely c=XX to ) and the
> creation of a way (i.e., a new DNS RR type) to use DNS to register names
> traditionally associated with X.500/LDAP.
>
> By way of example, what I'm talking about is the ability to take a DN of the
> form "cn=Skip Slone, o=Lockheed Martin, c=US" and determine that the LDAP
> server to check is found at (for example) ldap1.external.lmco.com.
>
> That said, such registration in DNS, combined with a deterministic algorithm
> will return a result of the following form:
> a) the DN maps to an LDAP server found at foo.com, OR
> b) the DN does not map to a registered LDAP server
>
> If you get answer "a" you then send an LDAP query to foo.com:389 to find the
> entry itself.
>
> To answer your question properly, I would contend that if "o=Foo, Inc." is
> not registered under these rules, you would get answer "b". Even though you
> don't find the entry, you still get a deterministic response.
>
> -- Skip
>
> -----Original Message-----
> From: David P. Kemp [mailto:[email-masked]]
> Sent: Wednesday, January 10, 2001 2:51 PM
> To: [email-masked]
> Subject: RE: Basic Cert-2-Directory mapping question
>
>
> Skip,
>
> Doesn't the existence of a deterministic algorithm depend on users
> of civil (Country-based) names following the rules?
>
> As Michael Ströder pointed out, everyone wants a short name in a
> flat namespace. But not every Joe's Bar & Grill in the US can
> have certificates with the name "C=US, O=Joe's Bar & Grill". If
> TTP CAs are willing to issue such certificates without evidence
> that the name has been registered with the US national authority,
> what algorithm can possibly find all the directory entries for
> that DN?
>
> Dave
>
>
>
>
> > From: "Slone, Skip"
> > Subject: RE: Basic Cert-2-Directory mapping question
> > To: [email-masked]
> >
> > As the traffic on this topic points out, there are a lot of people who see
> > this as an issue. Whether we can agree on exactly what the issue is and
> how
> > to proceed may be another matter ... :-)
> >
> > As have many others on this list, I've been giving this issue some thought
> > lately, focusing on the problems as seen from the perspective of a large
> > user like my company. Although I've come to a different set of conclusions
> > from those discussed so far in this thread, my energy has been focused on
> > the same problem that Bob Jueneman pointed out: knowing the location of a
> > directory service provider that is supposed to contain the DN.
> >
> > My basic premise is that if we can come up with a deterministic algorithm
> > that takes an arbitrary (but reasonably well structured) DN and resolves
> it
> > to a set of FQDNs where one can find LDAP services, we can
> deterministically
> > get from the DN to the associated directory entry. As Steve Kent pointed
> > out, there exists a body of work to do this in the limited case of DNs
> based
> > on (DNS) domainComponent naming. My thoughts are along that line, but
> > expand to cover the so-called "civil" naming constructs in DNs, such as
> > country, organization, and so on. I think that's the goal Anders
> originally
> > stated, starting this whole thread.
> >
> > If people are interested, I'll summarize the algorithm I've come up with
> so
> > far and distribute it for review. If need be, we could consider whether
> > this is worthy of an I-D, or a BOF at Minneapolis, or whatever...
> >
> > Regards,
> >
> > -- Skip Slone
> > Lockheed Martin
>

Received: from prv-mail20.provo.novell.com (prv-mail20.provo.novell.com [137.65.81.122]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id MAA02025 for ; Wed, 10 Jan 2001 12:54:44 -0800 (PST)
Received: from INET-PRV-Message_Server by prv-mail20.provo.novell.com with Novell_GroupWise; Wed, 10 Jan 2001 13:59:05 -0700
Message-Id:
X-Mailer: Novell GroupWise Internet Agent 5.5.5.1
Date: Wed, 10 Jan 2001 13:59:06 -0700
From: "Bob Jueneman"
To: ,
Subject: RE: Basic Cert-2-Directory mapping question
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id MAA02026

Skip, as you correctly point out, the problem is not so great in the case
of an organization that operates its own DNS domain, and uses that domain
as the means of providing directory service access. Certainly a company
like Novell, Lockheed, GTE (oops, Verizon), etc., could easily do so.

But notice some of the problems. I'm not picking on our esteemed co-chair, but
notice that Steve's e-mail address, [email-masked], is two corporate mergers
behind the times, since GTE acquired BBN, and then Verizon was formed out
of GTE and Bell Atlantic. But if his certificate were deposited at something like
directory.verizon.com, how would you extract that from the BBN name?
would all of those older e-mail address have to have a set of alias DNS names for
the directory server?

With smaller organizations, the problem is much worse. A small law firm, for
example, may or may not operate their own domain name, either for web
purposes or for e-mail. Some do, but many are still using commercial services
such as earthlink, pipeline, etc.

A company may decide to operate their own domain, either physically, or by
outsourcing the server with their own domain name to an ISP or ASP.

But in either case, that doesn't necessarily mean that they would choose to
host their own directory service, and perhaps especially not for certificates.

Instead, they might opt to leave that functionality up to the CA that issued
the certificates, for example VeriSign.

Or perhaps they create their own certificates, using a toolkit such as is
provided by Entrust, Baltimore Technologies, Microsoft, or Novell. In
that case, they might choose to contract with a Trusted Repository,
someone who chooses to take on the responsibility of operating a 24x7,
high availability directory server and/or OCSP provider, such as Digital
Signature Trust. (Note that creating certificates does not require that type
of availability. The Pasadena Ladies Garden Club can issue certs to
all of their members once a year, and never turn the server back on again
until next year.)

And then we have the problem of the mom and pop residential user.
The path of least resistance might be for them to publish their certificate
with their ISP, for example Yahoo, AOL, or MSN.

But what if they later decide to switch e-mail service providers. Are they
they then obligated to get new certificates, even though the old ones
haven't expired yet? And what does that do to the concept of validation
of still valid certs for binding transactions?

It is for these kinds of reasons that I believe that any form of generally
workable directory locator scheme CANNOT POSSIBLY be based
on a deterministic relationship between the location of the directory and
a web address or e-mail address per se, simply because the directory
service provider may have nothing whatsoever to do with those other
services.

Instead, I believe that we should either use some kind of a URL prefix
that identifies the type of access protocol followed by the DNS name of the
service, followed by the DN that you are trying to look up, assuming
that is what you are trying to do.

An example might look like ldap://ldap.mydirectory.com/rfc822=[email-masked],

Another possibility would be what John Wray suggested:

dir="directory.VeriSign.com", c=us, st=ut, l=provo, cN="Robert R. Jueneman"

I'm assuming in this case that the port number of the directory service can
be provided by default within the "dir" component, otherwise it may have
to be provided specifically.

I'd be interested in your thoughts, as it seems that you may be thinking
about something similar to the second example.

Once we can at least find the appropriate directory, we can concentrate
on how to ensure schema compatibility between the directory and the
certificate. But I believe that if the certificate subscriber gets to pick
the directory provider, then these problems can be accommodated rather
easily, and certainly if the directory service provider is the CA.

It is when someone tries to cram a certificate willy-nilly into a directory
without any prior coordination that the problems really become intractable.

Regards,

Bob

>>> "Slone, Skip" 01/10/01 12:17PM >>>
As the traffic on this topic points out, there are a lot of people who see
this as an issue. Whether we can agree on exactly what the issue is and how
to proceed may be another matter ... :-)

As have many others on this list, I've been giving this issue some thought
lately, focusing on the problems as seen from the perspective of a large
user like my company. Although I've come to a different set of conclusions
from those discussed so far in this thread, my energy has been focused on
the same problem that Bob Jueneman pointed out: knowing the location of a
directory service provider that is supposed to contain the DN.

My basic premise is that if we can come up with a deterministic algorithm
that takes an arbitrary (but reasonably well structured) DN and resolves it
to a set of FQDNs where one can find LDAP services, we can deterministically
get from the DN to the associated directory entry. As Steve Kent pointed
out, there exists a body of work to do this in the limited case of DNs based
on (DNS) domainComponent naming. My thoughts are along that line, but
expand to cover the so-called "civil" naming constructs in DNs, such as
country, organization, and so on. I think that's the goal Anders originally
stated, starting this whole thread.

If people are interested, I'll summarize the algorithm I've come up with so
far and distribute it for review. If need be, we could consider whether
this is worthy of an I-D, or a BOF at Minneapolis, or whatever...

Regards,

-- Skip Slone
Lockheed Martin

Received: from mailgw2a.lmco.com (mailgw2a.lmco.com [192.91.147.7]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA01390 for ; Wed, 10 Jan 2001 12:47:42 -0800 (PST)
Received: from emss03g01.ems.lmco.com (emss03g01.ems.lmco.com [141.240.4.144]) by mailgw2a.lmco.com (8.8.8/8.8.8) with ESMTP id PAA22959; Wed, 10 Jan 2001 15:52:30 -0500 (EST)
Received: from CONVERSION-DAEMON by lmco.com (PMDF V5.2-32 #38888) id <[email-masked]>; Wed, 10 Jan 2001 15:50:52 -0500 (EST)
Received: from emss03i00.ems.lmco.com ([141.240.31.211]) by lmco.com (PMDF V5.2-32 #38888) with ESMTP id <[email-masked]>; Wed, 10 Jan 2001 15:50:32 -0500 (EST)
Received: by emss03i00.orl.lmco.com with Internet Mail Service (5.5.2650.21) id ; Wed, 10 Jan 2001 15:51:40 -0500
Content-return: allowed
Date: Wed, 10 Jan 2001 15:51:39 -0500
From: "Slone, Skip"
Subject: RE: DPD & DPV requirements
To: "'Stephen Kent'" , PKIX-List
Message-id:
MIME-version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-type: MULTIPART/ALTERNATIVE; BOUNDARY="Boundary_(ID_EeMaPt2ILxiI621D7j9G/A)"

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

--Boundary_(ID_EeMaPt2ILxiI621D7j9G/A)
Content-type: text/plain
Content-transfer-encoding: 7BIT

Given the discussion generated on the topic of recursion, it seems we should
probably assume that in some cases, DPx servers will turn around and behave
as DPx clients in response to a given query. Rather than debate the merits
of recursion, I would like to suggest the following minor changes in the
requirements (to allow a client to specify whether recursion is an
acceptable practice, and if so, to what extent):

(1) Change 1.4 to add DPV to the list of acceptable sources of revocation
status.

(2) Add a new 1.x clause to allow the client to specify whether recursion of
this sort is permitted. This could be either a boolean (to give a simple
yes/no answer) or it could be an integer with count-to-zero semantics
similar to that of inhibitPolicyMapping in X.509. (One could argue that this
could be implied by the policy in clause 1.9, but it seems like something
that ought to be made explicit.)

-- Skip Slone

-----Original Message-----
From: Stephen Kent [mailto:[email-masked]]
Sent: Friday, December 29, 2000 1:25 PM
To: PKIX-List
Subject: DPD & DPV requirements

As promised, here is the strawman requirements specification for DPV and
DPD. Questions that the WG needs to address as part of deciding on the scope
of these requirements are in boldface.

[snip]

--Boundary_(ID_EeMaPt2ILxiI621D7j9G/A)
Content-type: text/html
Content-transfer-encoding: 7BIT

Given the discussion generated on the topic of
recursion, it seems we should probably assume that in some cases, DPx servers
will turn around and behave as DPx clients in response to a given query. Rather
than debate the merits of recursion, I would like to suggest the following minor
changes in the requirements (to allow a client to specify whether recursion is
an acceptable practice, and if so, to what extent):

(1) Change 1.4 to add DPV to the list of acceptable
sources of revocation status.

(2) Add a new 1.x clause to allow the client to
specify whether recursion of this sort is permitted. This could be either a
boolean (to give a simple yes/no answer) or it could be an integer with
count-to-zero semantics similar to that of inhibitPolicyMapping in X.509. (One
could argue that this could be implied by the policy in clause 1.9, but it seems
like something that ought to be made explicit.)

-- Skip Slone

-----Original Message-----
From: Stephen Kent
[mailto:[email-masked]]
Sent: Friday, December 29, 2000 1:25 PM
To:
PKIX-List
Subject: DPD & DPV requirements

As promised, here is the strawman requirements
specification for DPV and DPD. Questions that the WG needs to address as part
of deciding on the scope of these requirements are in boldface.

[snip]

--Boundary_(ID_EeMaPt2ILxiI621D7j9G/A)--

Received: from mailgw2a.lmco.com (mailgw2a.lmco.com [192.91.147.7]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA29782 for ; Wed, 10 Jan 2001 12:21:56 -0800 (PST)
Received: from emss03g01.ems.lmco.com (emss03g01.ems.lmco.com [141.240.4.144]) by mailgw2a.lmco.com (8.8.8/8.8.8) with ESMTP id PAA14131; Wed, 10 Jan 2001 15:26:59 -0500 (EST)
Received: from CONVERSION-DAEMON by lmco.com (PMDF V5.2-32 #38888) id <[email-masked]>; Wed, 10 Jan 2001 15:26:03 -0500 (EST)
Received: from emss03i00.ems.lmco.com ([141.240.31.211]) by lmco.com (PMDF V5.2-32 #38888) with ESMTP id <[email-masked]>; Wed, 10 Jan 2001 15:25:42 -0500 (EST)
Received: by emss03i00.orl.lmco.com with Internet Mail Service (5.5.2650.21) id ; Wed, 10 Jan 2001 15:26:49 -0500
Content-return: allowed
Date: Wed, 10 Jan 2001 15:26:47 -0500
From: "Slone, Skip"
Subject: RE: Basic Cert-2-Directory mapping question
To: "'David P. Kemp'" , [email-masked]
Message-id:
MIME-version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id MAA29784

David,

Only somewhat tongue-in-cheek, I'll say the answer to your question is "only
if you want the right answer" ;-)

As I see it, we're dealing with the fact that we have extant DNs all over
the map with no semblance of a registration authority. Consequently, we have
no reasonable way of getting from an arbitrary DN to a directory service.
The closest thing to a global registration authority that exists is DNS
(including, of course, its whole supporting cast). As such, it made sense
for the Internet community to tackle those names found within the current
DNS struture. What I would like to propose is that we build on that success
and extend the authority of DNS into other parts of the DN namespace. To do
so requires the definition of some mappings (namely c=XX to ) and the
creation of a way (i.e., a new DNS RR type) to use DNS to register names
traditionally associated with X.500/LDAP.

By way of example, what I'm talking about is the ability to take a DN of the
form "cn=Skip Slone, o=Lockheed Martin, c=US" and determine that the LDAP
server to check is found at (for example) ldap1.external.lmco.com.

That said, such registration in DNS, combined with a deterministic algorithm
will return a result of the following form:
a) the DN maps to an LDAP server found at foo.com, OR
b) the DN does not map to a registered LDAP server

If you get answer "a" you then send an LDAP query to foo.com:389 to find the
entry itself.

To answer your question properly, I would contend that if "o=Foo, Inc." is
not registered under these rules, you would get answer "b". Even though you
don't find the entry, you still get a deterministic response.

-- Skip

-----Original Message-----
From: David P. Kemp [mailto:[email-masked]]
Sent: Wednesday, January 10, 2001 2:51 PM
To: [email-masked]
Subject: RE: Basic Cert-2-Directory mapping question

Skip,

Doesn't the existence of a deterministic algorithm depend on users
of civil (Country-based) names following the rules?

As Michael Ströder pointed out, everyone wants a short name in a
flat namespace. But not every Joe's Bar & Grill in the US can
have certificates with the name "C=US, O=Joe's Bar & Grill". If
TTP CAs are willing to issue such certificates without evidence
that the name has been registered with the US national authority,
what algorithm can possibly find all the directory entries for
that DN?

Dave

> From: "Slone, Skip"
> Subject: RE: Basic Cert-2-Directory mapping question
> To: [email-masked]
>
> As the traffic on this topic points out, there are a lot of people who see
> this as an issue. Whether we can agree on exactly what the issue is and
how
> to proceed may be another matter ... :-)
>
> As have many others on this list, I've been giving this issue some thought
> lately, focusing on the problems as seen from the perspective of a large
> user like my company. Although I've come to a different set of conclusions
> from those discussed so far in this thread, my energy has been focused on
> the same problem that Bob Jueneman pointed out: knowing the location of a
> directory service provider that is supposed to contain the DN.
>
> My basic premise is that if we can come up with a deterministic algorithm
> that takes an arbitrary (but reasonably well structured) DN and resolves
it
> to a set of FQDNs where one can find LDAP services, we can
deterministically
> get from the DN to the associated directory entry. As Steve Kent pointed
> out, there exists a body of work to do this in the limited case of DNs
based
> on (DNS) domainComponent naming. My thoughts are along that line, but
> expand to cover the so-called "civil" naming constructs in DNs, such as
> country, organization, and so on. I think that's the goal Anders
originally
> stated, starting this whole thread.
>
> If people are interested, I'll summarize the algorithm I've come up with
so
> far and distribute it for review. If need be, we could consider whether
> this is worthy of an I-D, or a BOF at Minneapolis, or whatever...
>
> Regards,
>
> -- Skip Slone
> Lockheed Martin

Received: from stingray.missi.ncsc.mil (stingray.missi.ncsc.mil [144.51.50.20]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA28987 for ; Wed, 10 Jan 2001 12:05:38 -0800 (PST)
Received: from stingray.missi.ncsc.mil (root@localhost) by stingray.missi.ncsc.mil with ESMTP id PAA09414 for ; Wed, 10 Jan 2001 15:10:11 -0500 (EST)
Message-Id: <[email-masked]>
Date: Wed, 10 Jan 2001 15:11:33 -0500 (EST)
From: [email-masked]
Reply-To: [email-masked]
Subject: RE: WG Last Call, PKI Repository Locator
To: [email-masked]
MIME-Version: 1.0
Content-Type: TEXT/plain; charset=us-ascii
Content-MD5: uSsX5SAp8qfteM7Nej/1bQ==

Before going to RFC, I would like to see a short statement
comparing and contrasting this draft with

draft-ietf-ldapext-locate-04.txt

There appears to be significant overlap in functionality, and the LDAP
draft has a higher revision number :-).

Dave

> >
> > Tim Polk wrote:
> > > As most of you know, there is no requirement for a WG Last Call for
> > > experimental RFCs. However, this specification has been
> > through only a
> > > single draft, and has drawn a very small number of
> > comments. I am hoping
> > > that a Last Call will prompt some of you to review the
> > specification.

Received: from stingray.missi.ncsc.mil (stingray.missi.ncsc.mil [144.51.50.20]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA27384 for ; Wed, 10 Jan 2001 11:44:45 -0800 (PST)
Received: from stingray.missi.ncsc.mil (root@localhost) by stingray.missi.ncsc.mil with ESMTP id OAA06629 for ; Wed, 10 Jan 2001 14:49:18 -0500 (EST)
Message-Id: <[email-masked]>
Date: Wed, 10 Jan 2001 14:50:40 -0500 (EST)
From: "David P. Kemp"
Reply-To: "David P. Kemp"
Subject: RE: Basic Cert-2-Directory mapping question
To: [email-masked]
MIME-Version: 1.0
Content-Type: TEXT/plain; charset=ISO-8859-1
Content-MD5: VA0HSoRDwOxyxWR6BUVMgg==
X-Mailer: dtmail 1.3.0 CDE Version 1.3 SunOS 5.7 sun4u sparc
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from QUOTED-PRINTABLE to 8bit by ns.secondary.com id LAA27385

Skip,

Doesn't the existence of a deterministic algorithm depend on users
of civil (Country-based) names following the rules?

As Michael Ströder pointed out, everyone wants a short name in a
flat namespace. But not every Joe's Bar & Grill in the US can
have certificates with the name "C=US, O=Joe's Bar & Grill". If
TTP CAs are willing to issue such certificates without evidence
that the name has been registered with the US national authority,
what algorithm can possibly find all the directory entries for
that DN?

Dave

> From: "Slone, Skip"
> Subject: RE: Basic Cert-2-Directory mapping question
> To: [email-masked]
>
> As the traffic on this topic points out, there are a lot of people who see
> this as an issue. Whether we can agree on exactly what the issue is and how
> to proceed may be another matter ... :-)
>
> As have many others on this list, I've been giving this issue some thought
> lately, focusing on the problems as seen from the perspective of a large
> user like my company. Although I've come to a different set of conclusions
> from those discussed so far in this thread, my energy has been focused on
> the same problem that Bob Jueneman pointed out: knowing the location of a
> directory service provider that is supposed to contain the DN.
>
> My basic premise is that if we can come up with a deterministic algorithm
> that takes an arbitrary (but reasonably well structured) DN and resolves it
> to a set of FQDNs where one can find LDAP services, we can deterministically
> get from the DN to the associated directory entry. As Steve Kent pointed
> out, there exists a body of work to do this in the limited case of DNs based
> on (DNS) domainComponent naming. My thoughts are along that line, but
> expand to cover the so-called "civil" naming constructs in DNs, such as
> country, organization, and so on. I think that's the goal Anders originally
> stated, starting this whole thread.
>
> If people are interested, I'll summarize the algorithm I've come up with so
> far and distribute it for review. If need be, we could consider whether
> this is worthy of an I-D, or a BOF at Minneapolis, or whatever...
>
> Regards,
>
> -- Skip Slone
> Lockheed Martin

Received: from exchange.cylink.com (exchange.cylink.com [192.43.161.25]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA25212 for ; Wed, 10 Jan 2001 11:16:42 -0800 (PST)
Received: by exchange.cylink.com with Internet Mail Service (5.5.2650.21) id ; Wed, 10 Jan 2001 11:13:51 -0800
Message-ID: <[email-masked]>
From: "Covey, Carlin"
To: [email-masked]
Subject: RE: DPD & DPV requirements - Let us Recurse
Date: Wed, 10 Jan 2001 11:13:44 -0800
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"

Peter and Kent,

I second Peter's strawman proposal.

-----Original Message-----
From: Peter Sylvester [mailto:[email-masked]]
Sent: Wednesday, January 10, 2001 12:07 PM
To: [email-masked]; [email-masked]
Cc: [email-masked]
Subject: RE: DPD & DPV requirements - Let us Recurse

[Peter]

A strawman proposal:

A server should have the ability to return in the response
a rather limited set of well-known protocol elements, certs,
crls, ocsp response, pkistatus, DPV response, at least those
that he had used to make up its decision or which it wishes
to communicate to the client for whatever reason.

[Carlin]

If a DPD server can't return an embedded DPD response from
another DPD server, then the first DPD server has more
constraints on forming a valid certificate path than a DPV
server would have. (Presumably a DPV server could consult a
DPD server to collect path validation information)

Received: from edelweb.fr (edelweb.fr [212.234.46.16]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA24962 for ; Wed, 10 Jan 2001 11:15:58 -0800 (PST)
Received: from champagne.edelweb.fr (localhost.edelweb.fr [127.0.0.1]) by edelweb.fr with ESMTP id UAA22014 for ; Wed, 10 Jan 2001 20:21:01 +0100 (MET)
Received: from champagne.edelweb.fr (champagne.edelweb.fr [193.51.14.161]) by edelweb.fr (nospam/1.3); Wed, 10 Jan 2001 20:21:01 +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 UAA29129 for ; Wed, 10 Jan 2001 20:20:59 +0100 (MET)
From: Peter Sylvester
Received: (sylvest@localhost) by emeriau.edelweb.fr (8.7.6/8.6.6) id UAA17445 for [email-masked]; Wed, 10 Jan 2001 20:20:59 +0100 (MET)
Date: Wed, 10 Jan 2001 20:20:59 +0100 (MET)
Message-Id: <[email-masked]>
To: [email-masked]
Subject: time stamping interoperability tests

Hello,

during the last two months I had a chnce to make a few
interoperability tests with some implementations of
experimental services. There haven't been many so far.

I would like to share the few results here so in order
to allow other implementors to gain some time.

Socket protocol:

- The first 4 octets need to be in network byte order.

- An errMsg response (X'06') is not a possible response to
a request according to the protocol specification.

- The connection is immediately closed after having sent the
response. This is a possible interpretation of the protocol,
but seems unfortunate to me, since it doesn't make it possible
to make several requests through the same tcp connection.
Note that during CMP interoperability testing a similar
problem occured, an internet draft describes this.

- Implementations did not implement any time out for the TCP
connection.

TSP encoding :

- Instead of encoding a bit string, one implementation encoded
the position of one error bit as an integer.

- One implementation did not accept a NULL parameter for the digest algorithm.

- So far, I haven't send really nasty requests with valid or invalid
arbitrary asn1 structures, but:

One implementation does not parse the request correctly,
a symptom was that the reqCert flag is not detected.
The actual case was that due to a change in the syntax
between some drafts that I missed the request did not encode
correctly the tsaPolicy, instead of accepting the request,
an encoding error should have been signaled I guess.

Note, that the format of the request and response have
changed in incompatible ways several times.

Peter Sylvester

Received: from mailgw2a.lmco.com (mailgw2a.lmco.com [192.91.147.7]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA24526 for ; Wed, 10 Jan 2001 11:12:56 -0800 (PST)
Received: from emss03g01.ems.lmco.com (emss03g01.ems.lmco.com [141.240.4.144]) by mailgw2a.lmco.com (8.8.8/8.8.8) with ESMTP id OAA03911 for ; Wed, 10 Jan 2001 14:17:59 -0500 (EST)
Received: from CONVERSION-DAEMON by lmco.com (PMDF V5.2-32 #38888) id <[email-masked]> for [email-masked]; Wed, 10 Jan 2001 14:16:50 -0500 (EST)
Received: from emss03i00.ems.lmco.com ([141.240.31.211]) by lmco.com (PMDF V5.2-32 #38888) with ESMTP id <[email-masked]> for [email-masked]; Wed, 10 Jan 2001 14:16:41 -0500 (EST)
Received: by emss03i00.orl.lmco.com with Internet Mail Service (5.5.2650.21) id ; Wed, 10 Jan 2001 14:17:47 -0500
Content-return: allowed
Date: Wed, 10 Jan 2001 14:17:44 -0500
From: "Slone, Skip"
Subject: RE: Basic Cert-2-Directory mapping question
To: [email-masked]
Message-id:
MIME-version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-type: text/plain
Content-transfer-encoding: 7BIT

As the traffic on this topic points out, there are a lot of people who see
this as an issue. Whether we can agree on exactly what the issue is and how
to proceed may be another matter ... :-)

As have many others on this list, I've been giving this issue some thought
lately, focusing on the problems as seen from the perspective of a large
user like my company. Although I've come to a different set of conclusions
from those discussed so far in this thread, my energy has been focused on
the same problem that Bob Jueneman pointed out: knowing the location of a
directory service provider that is supposed to contain the DN.

My basic premise is that if we can come up with a deterministic algorithm
that takes an arbitrary (but reasonably well structured) DN and resolves it
to a set of FQDNs where one can find LDAP services, we can deterministically
get from the DN to the associated directory entry. As Steve Kent pointed
out, there exists a body of work to do this in the limited case of DNs based
on (DNS) domainComponent naming. My thoughts are along that line, but
expand to cover the so-called "civil" naming constructs in DNs, such as
country, organization, and so on. I think that's the goal Anders originally
stated, starting this whole thread.

If people are interested, I'll summarize the algorithm I've come up with so
far and distribute it for review. If need be, we could consider whether
this is worthy of an I-D, or a BOF at Minneapolis, or whatever...

Regards,

-- Skip Slone
Lockheed Martin

Received: from maild.telia.com ([email-masked] [194.22.190.3]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA23993 for ; Wed, 10 Jan 2001 11:07:04 -0800 (PST)
Received: from d1o69.telia.com (d1o69.telia.com [62.20.144.241]) by maild.telia.com (8.9.3/8.9.3) with ESMTP id UAA26183; Wed, 10 Jan 2001 20:12:05 +0100 (CET)
Received: from mega (t3o69p32.telia.com [62.20.145.32]) by d1o69.telia.com (8.10.2/8.10.1) with SMTP id f0AJC4l05380; Wed, 10 Jan 2001 20:12:04 +0100 (CET)
Message-ID: <[email-masked]>
From: "Anders Rundgren"
To: =?iso-8859-1?Q?Michael_Str=F6der?= ,
References: <[email-masked]> <[email-masked]>
Subject: Re: Basic Cert-2-Directory mapping question
Date: Wed, 10 Jan 2001 20:10:27 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
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
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id LAA23996

Michael,

> IMHO one of the main problems with PKIX is that there's so much X.500 in it. ;-)

I must put that in a frame!

/anders

Received: from edelweb.fr (edelweb.fr [212.234.46.16]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA23337 for ; Wed, 10 Jan 2001 11:02:24 -0800 (PST)
Received: from champagne.edelweb.fr (localhost.edelweb.fr [127.0.0.1]) by edelweb.fr with ESMTP id UAA21937; Wed, 10 Jan 2001 20:07:19 +0100 (MET)
Received: from champagne.edelweb.fr (champagne.edelweb.fr [193.51.14.161]) by edelweb.fr (nospam/1.3); Wed, 10 Jan 2001 20:07:19 +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 UAA29054; Wed, 10 Jan 2001 20:07:17 +0100 (MET)
From: Peter Sylvester
Received: (sylvest@localhost) by emeriau.edelweb.fr (8.7.6/8.6.6) id UAA17442; Wed, 10 Jan 2001 20:07:17 +0100 (MET)
Date: Wed, 10 Jan 2001 20:07:17 +0100 (MET)
Message-Id: <[email-masked]>
To: [email-masked], [email-masked]
Subject: RE: DPD & DPV requirements - Let us Recurse
Cc: [email-masked]

> Peter,
>
> >
> >
> >What do you mean by revocation status not quite perfect? A server
> >makes a desision, and tells what it had looked at, it may happen
> >that another server verifier looks at the same data in a different
> >way, and comes to another conclusion; this tru independant of
> >whether the first returns its justifications or not. One entity
> >might validate a cert chain, another might not, etc. Returning
> >as much as possible data about why one decision has been made
> >does not change that.
>
> What if a server has a CRL for a along the path but the CRL is old,
> and the server cannot get a current one? The simple answer is that
> the validity of the target cert is unknown, but that may not be a
> totally satisfying answer. You are correct that we face this problem
> already for DPV (for DPD we could return what we have and let the
> client work it out) irrespective of whether we have to return
> justifications. As we move into "explaining" an evaluation, I was
> thinking that we might want to be more sophisticated about the whole
> process, but that was sloppy on my part. You're right!

Maybe my wording of using 'justification' wasn't good. It is
rather to indicate that the server return all information in
form of approriate return codes or statements from other
servers so that in case that the client believes the correctness
it has all necessary information available.

There may be a problem with CRLs when they are large, but in
this case for example the server could simulate an OCSP response.

>
> >If a client has a user interface to explain a server decision,
> >it seems necessary anyway to display certificates, elements on
> >a CRL, OCSP reponses, PKIStatus data.
> >
> >We already have the problem of user interfaces of certificate
> >and CRL displays, and also of how to display responses from
> >a OCSP server, or from the new services to be standardized.
> >But do we actually care? But: I don't see in other pkix standards a
> >description of about how a certificate chain has to be presented
> >or even a single certificate.
>
> No, the last RFC to broach the subject of cert path info presentation
> was 1422, for PEM! If we return status, cert chains and revocation
> status, then we get to ignore this. But, if we return what purports
> to be an "explanation" of why a cert is valid, then I think we have
> opened up a can of worms with regard to user interface issues,
> because the purported customer for the explanation. This is
> especially true for DPV and non-PKI aware clients.

I don't ask for something that all kind of explanations of 'why'.

The distinction of why and whether something is good/bad
is not quite clear if one already returns values like
revoked, expired, or else.

>
> >What seems useful to me is to specify a list of elements that may
> >be supposed to be presented to users. Such a list should be a simple
> >as possible, contain a small number of different data type that
> >allow to express a large set of situations, so that we don't have
> >to add new stuff each 6 months or 3 years. We have already *MANY*
> >standards that return 'status information' in different ways.
> >One question here would be: Is it more appropriate to use a
> >new textual format like in SCVP or something like PKIStatus as
> >used in several standards maybe accompanied by OCSP responses?
>
> I think the answer has to be driven by the context in which the
> response is to be used. For machine consumption a binary status
> representation is appropriate, but for a human user, text is
> preferable. However, in the latter case, I think we are entering a
> very complex arena that, as you noted, we have avoided in the past,
> re HMI for PKI info.

I am not entering at all into that area.

A strawman proposal:

A server should have the ability to return in the response
a rather limited set of well-known protocol elements, certs,
crls, ocsp response, pkistatus, DPV response, at least those
that he had used to make up its decision or which it wishes
to communicate to the client for whatever reason.

Received: from eagle.verisign.com (eagle.verisign.com [208.206.241.105]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA21864 for ; Wed, 10 Jan 2001 10:46:31 -0800 (PST)
Received: from postal-gw2.verisign.com (verisign.com [63.104.27.102]) by eagle.verisign.com (8.9.3/BCH1.7.1) with ESMTP id KAA18650; Wed, 10 Jan 2001 10:53:19 -0800 (PST)
Received: by postal-gw.verisign.com with Internet Mail Service (5.5.2650.21) id ; Wed, 10 Jan 2001 10:51:29 -0800
Message-ID: <[email-masked]>
From: Philip Hallam-Baker
To: "'Oscar Jacobsson'" , Tim Polk
Cc: [email-masked]
Subject: RE: WG Last Call, PKI Repository Locator
Date: Wed, 10 Jan 2001 10:51:28 -0800
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"

This sounds like a good plan, the SRV draft is not really adapted to a
multi-layer protocol, but it really does not matter too much I guess so long
as clients are consistent.

The options are (I guess):

1) _pkix._http._tcp
2) _pkix_http._tcp
3) _pkixhttp._tcp

I don't really care which we do... (1) seems cleanest???

Phill

> -----Original Message-----
> From: Oscar Jacobsson [mailto:[email-masked]]
> Sent: Tuesday, January 09, 2001 5:27 AM
> To: Tim Polk
> Cc: [email-masked]
> Subject: Re: WG Last Call, PKI Repository Locator
>
>
> Tim Polk wrote:
> > As most of you know, there is no requirement for a WG Last Call for
> > experimental RFCs. However, this specification has been
> through only a
> > single draft, and has drawn a very small number of
> comments. I am hoping
> > that a Last Call will prompt some of you to review the
> specification.
>
> I'm afraid I seem to have missed the previous batch of
> comments, and was
> wondering if you might help me clear out a minor niggle or two.
>
> The repository locator draft and RFC 2782 seem to refer to different
> layers of protocols. Where 2782 refers to protocols in the transport
> layer, such as TCP, UDP, etc. the draft apparently uses application
> layer protocols like HTTP, LDAP, and OCSP. These application layer
> protocols are referred to as services by RFC 2782, where the draft in
> stead uses the name "PKIXREP".
>
> I assume the intention is to differentiate between generic
> directory or
> web services and PKI repositories, but would it in such a case not be
> more prudent to restrict the usage of PKIX defined names to just
> services instead of both to services and protocols. This could be
> accomplished, say, by defining the service definitions "PKIXHTTP",
> "PKIXLDAP", and "PKIXOCSP", which compliant applications could then
> query at their leisure.
>
> Granted, it *is* perfectly possible to employ both RFC 2782 and the
> locator draft schemes independently to indicate the same directory or
> web server, but I was curios about these apparent
> discrepancies between
> the two documents and was wondering if anybody would care to
> explain the
> reasoning behind it to me.
>
> Thanks in advance,
>
> //oscar
>

Received: from po1.bbn.com (PO1.BBN.COM [192.1.50.38]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA19042 for ; Wed, 10 Jan 2001 09:44:09 -0800 (PST)
Received: from [171.78.30.107] (comsec.bbn.com [171.78.30.107]) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id MAA00706; Wed, 10 Jan 2001 12:49:07 -0500 (EST)
Mime-Version: 1.0
X-Sender: [email-masked]
Message-Id:
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Date: Wed, 10 Jan 2001 12:43:40 -0500
To: Denis Pinkas
From: Stephen Kent
Subject: Re: DPD & DPV requirements
Cc: PKIX-List
Content-Type: multipart/alternative; boundary="============_-1232973474==_ma============"

--============_-1232973474==_ma============
Content-Type: text/plain; charset="iso-8859-1" ; format="flowed"
Content-Transfer-Encoding: quoted-printable

Denis,

>Steve,
>
>See my responses embbeded with your comments.
>
>=20 > Denis,
>=20 >
>=20 > Steve,
>=20 >
>=20 > First of all, many thanks for posting this long document.
>=20 >
>=20 > I will not respond using directly your text, since my arguments
>=20 > are fairly different. I will however re-use some of your argumen=
ts.
>=20 >
>=20 > Let us use the concept of "validation policy", that you=20
>introduce, which is
>=20 > all the set of rules to be followed when validating a=20
>certificate. It will
>=20 > usually not simply be the rules mentioned in RFC 2459, but=20
>these rules with
>=20 > additional conditions. Note that in the context of=20
>electronic signatures, a
>=20 > "signature policy" is a specific example of a "validation policy=
".
>=20 >
>
>[Steve]
>
>We need to be explicit about what are the parameters that control path
>validation. The 2459 validation algorithm has a well-defined set, but if
>there are others, we need to have them specified and agreed upon. One
>conversation that took place in San Diego noted that one could imagine a lo=
t
>of parameters that a user might want to express re path validation, but
>which have not been standardized, and for which we do not have general
>agreement. A very rich list of this sort, and the associated complexity tha=
t
>would accompany an enhanced validation algorithm that used thise parameters=
,
>was thought to be out of scope for now, more an R&D topic vs. a topic for
>standardization. So we have to be careful here.
>
>
>[Denis]
>
>The current validation algorithm described in RFC 2459 is fine but too
>restritive. It works fine with a single root key in the case where there ar=
e
>no naming constraints nor Certification Policy constraints, or in the case
>where there are are included in the (root) self-signed certificates. I have
>worked with Tim Polk so that in the "son-of-RFC2459" we will have the
>description of an enhanced path validation algorithm that will take care of
>multiple roots, each one associated with different naming constraints or
>Certification Policy constraints - which will not necessarilly be included
>in the root self-signed certificates.

Self-signed certs are not the only way to deal with multiple roots,=20
and it often seems to me that they are a poor way, when we want to=20
make use of features like naming constraints. Why not just have cross=20
certs issued to other "roots" by a local CA and embed the naming (and=20
policy?) constraints into those cross certs?

>
>So we would need to support two options, which are not mutually exclusive:
>
>=20 1) define with a great level of accuracy each of the parameters, or
>=20 2) provide an OID which is a global reference to all these parameters.
>
>
>=20 > DPV
>=20 > =3D=3D=3D
>=20 >
>=20 > Let us start with DPV first. A DPV client will not=20
>necessarily be either
>=20 > PKI-aware, nor ASN.1 aware. I thus see two flavors for a DPV pro=
tocol:
>=20 >
>=20 > 1) one not using ASN.1 (e.g. using XML),
>=20 > 2) one using ASN.1.
>=20 >
>=20 > In both cases the client only supplies an unambiguous reference=
of the
>=20 > certificate (CA name, serial number and a hash of the=20
>certificate) or the
>=20 > certificate itself and specifies the rules to be followed to=20
>validate the
>=20 > certificate: an identification of a pre-defined "validation=20
>policy" (e.g. an
>=20 > OID and/or a URL to find the policy and a hash of that=20
>validation policy).
>=20 >
>
>[Steve]
>
>Given the problems we have had in OCSP (v1) re referring to a target cert, =
I
>am not comfortable specifying a target cert other than by providing a copy
>of that cert to the server.
>
>
>[Denis]
>
>
>In a signed CMS message, you may only have the EESCertID, without the
>certificate itself.
>
>=20 ESSCertID ::=3D SEQUENCE {
>=20 certHash Hash,
>=20 issuerSerial IssuerSerial OPTIONAL
>=20 }
>
>=20 Hash ::=3D OCTET STRING -- SHA1 hash of entire certificate
>
>=20 IssuerSerial ::=3D SEQUENCE {
>=20 issuer GeneralNames,
>=20 serialNumber CertificateSerialNumber
>=20 }
>
>The idea is to be able to use ESSCertID without the need to fetch the
>certificate itself.

I see your example, but I also stand by my observation that providing=20
anything other than the target cert per se has potential problems and=20
adds complexity to the server. We'll have to decide whether we want=20
to impose such adde complexity on servers, and whether we can provide=20
clean, algorithmic means of dealing with this complexity.

>=20 > As a result, the client expects a signed response which=
reproduces the
>=20 > requested parameters and includes a status. The status is not si=
mply:
>=20 > "passed validation", "failed validation", or "don't' know"=20
>but can also be
>=20 > "incomplete validation", meaning that some revocation status=20
>information is
>=20 > not yet available at the time of processing and a later attempt =
might
>=20 > succeed.
>=20 >
>
>[Steve]
>
>Incomplete validation is a reasonable response.

Yes, it will have to be one of the responses, hopefully with an=20
explanation of what caused the response to be incomplete.

>
>[Denis]
>
>:-)
>
>[Steve]
>
>maybe we should include the
>set of parameters used for the validation, including ones not supplied by
>the client, e.g., defaults, or overrides imposed by the server, or the
>values bound to a policy that was specified.
>
>[Denis]
>
>We are not on the same track here. I am assuming that a DPV client is PKI
>ignorant. You are making the assumption that the client MAY simply some
>elements of the certification path, where I make the assumption that the
>single element that MAY be supplied in a DPV request is the leaf
>certificate. For all the other elements of a certification path, the server
>is supposed to have access to the various repositories. The response
>contains a blob of what has been used, that can be blinding copied and
>stored.

A DPV client MAY be not PKI-aware, but that is not the only case we=20
agreed to address. I'll need to see more comments from WG members to=20
persuade me that we wish to restrict DPV interactions to clients that=20
are presumed to be PKI-ignorant, to use your term.

>
>=20 > The response must include the time at which the validation has b=
een
>=20 > performed. Allowing to test a certificate "in the past",=20
>would place some
>=20 > requirements that cannot always be accomplished by a=20
>standard PKI: currently
>=20 > we do not mandate CAs to maintain revocation information=20
>beyond the end of
>=20 > the validity period of a certificate. We should not change=20
>that rule. So I
>=20 > am very reluctant to autorise validation in the past, e.g.=20
>10 years later.
>=20 >
>
>[Steve]
>
>Good points; we should include the time of the response. I added the "in th=
e
>past" requirement based on its inclusion in SCVP, but there clearly limits
>to one's ability to support that feature. However, if the server is uable t=
o
>verify a cert relative to a prior time, based on unavailability of some
>revocation data, it can always state that in a response. One might add a
>requirement to allow the server to be configured to reject requests for
>validation that cite a time/date prior to some confugured value.
>
>
>[Denis]
>
>Since archiving of recocation information is not mandated to the CAs, such =
a
>function would need to be provided by some other trusted service provider.
>We should be very careful before allowing the provision of such a new
>service. I believe that the PKI is already sufficiently complex so that we
>make our best efforts not to introduced additional Trusted Service Provider=
s
>(that could be avoided). The only case to be supported should be the
>"current time" and some time "soon after the end of validity of a
>certificate" (i.e. a few weeks, in case someone being on holidays would lik=
e
>to check, when coming back from holidays, if a received message, was signed
>by a revoked certificate or not).

There was some sentiment for having the "was it valid then" function=20
as provided in SCVP, but if there is not continued support we could=20
delete it. I want to get more feedback on this issue.

>=20 > If a client is interested in a later proof, then it should=
obtain that
>=20 > information from the server at the time the information is=20
>still available.
>=20 > This means that a client should have the possibility to ask=20
>the server to
>=20 > optionally return an opaque blob that contains all what has=20
>been used to
>=20 > validate the certificate (i.e. a certification path and all=20
>the CRLs or
>=20 > OCSPs needed for each certificate from the path).
>=20 >
>
>[Steve]
>
>We have this requirement already, with a time stamp option.
>
>[Denis]
>
>We should remove the time stamp option.

Yes, we could.

>=20 > A question arises from the requirements 1.5 and 1.6 that you=20
>listed: should
>=20 > that opaque blob be time-stamped ? If there is a fear that some=
of the
>=20 > issuing keys used in the certification path might later on=20
>be compromised,
>=20 > then this can be useful. This case should be very seldom and=20
>hence this
>=20 > service would not always be required. In addition, why=20
>should that service
>=20 > be embedded in this protocol ? This could be obtained using=20
>directly the
>=20 > TSP, leaving more possibilities: free choice of the TSAs,=20
>time stamp of the
>=20 > full blob, time stamp of the certification chain only, time=20
>stamp on both
>=20 > the certification chain and the revocation information. Thus=20
>I do not favor
>=20 > to piggy-back the two services.
>=20 >
>
>[Steve]
>
>Yes, one could keep the services separate. I am not hard over on this, and
>can be persuaded to remove the requirement, or to make server support for i=
t
>optional.
>
>
>[Denis]
>
>If you are not hard on this issue, let us remove the time stamping option.
>
>:-)

I'll remove it if I hear from a few more people who agree that it is=20
best provided as a separate call to a TSA.

>=20 > In order to simplify the protocol and allow for PKI-ignorant=20
>clients, the
>=20 > client should NOT be allowed to provide any other element than t=
he
>=20 > certificate, that might help to construct the path or the revoca=
tion
>=20 > information.
>=20 >
>
>[Steve]
>
>I don't see the rationale for this. We already have application protocols
>where a client that is not PKI-aware might acquire cert paths and/or
>revocation data that it could pass on to a DPV server. So, I don't think yo=
u
>have made a good argument here for not allowing such data to be transmitted=
=2E
>Also, I don't think we have agreement yet that we are supporting clients
>that are not PKI-aware. I merely noted that IF we choose to support such
>clients, then there are implications for the syntax used for the protocol,
>and for the semantics of what is transmitted. I don't think we have made th=
e
>next step to agree to support such clients.
>
>
>[Denis]
>
>I have difficulties to understand how a client that would NOT be "PKI-aware
>might acquire cert paths and/or revocation data" :-)
>
>Once again, I am advocating a simple protocol for DPV to be used by PKI
>ignorant clients.

As I noted, a client might acquire cert paths and CRLs via a protocol=20
like SSL or IKE. Such clients could be ASN.1 capable but want to=20
offload validation for the reasons cited earlier.

>=20 > This means that, not only I do not agree with a common list=20
>of requirements
>=20 > for both DPV and DPD, but also that I do not agree with many of =
the
>=20 > requirements that you listed:
>=20 >
>=20 > For a DPV client:
>=20 >
>=20 > 1.1. Only a single certificate should be allowed.
>=20 > 1.2. No revocation items should be allowed.
>=20 > 1.3. No request in the past should be allowed.
>=20 > 1.4. Imposing constraints for CRLs or OCSP responses should be h=
idden
>=20 > under the "validation policy" that is selected.
>=20 > 1.5. and 1.6. Time stamped responses, if needed, should not=20
>be part of the
>=20 > service.
>=20 > 1.7. Validation policies are not necessarily "configured at=20
>the server",
>=20 > but can simply be pre-defined, outside the server. I any case, t=
he
>=20 > rules that has been followed - i.e. "validation policy" - must b=
e
>=20 > indicated in the response.
>=20 > 1.8. For DPV, responses must be signed.
>=20 > 1.9. The policy ID format can/will be specified in the protocol.
>=20 >
>=20 > For a DPV server:
>=20 >
>=20 > 2.1. A DPV server, will have to do more than RFC 2459, hence=20
>why the use
>=20 > of a validation policy is needed.
>=20 > 2.2. An opaque blob MAY be returned.
>=20 > 2.3. Time stamping is not needed.
>=20 > 2.4. The concept of policy overriding is too complex: a=
reference to
>=20 > a validation policy is sufficient.
>=20 > 2.5. No comment.
>=20 > 2.6. A server must support LDAP for certificate fetching,=20
>and EITHER CRL
>=20 > fetching OR OSCP (OCSP should not be mandatory).
>=20 > 2.7. No comment.
>=20 >
>
>[Steve]
>
>Given that we no longer agree on the underlying assumptions, it probably is
>not worthwhile discussing each of your proposed changes above.
>
>[Denis]
>
>Yes and no. We clearly have different assumptions, but we need to find an
>agreement. I am first advocating to separate the requirements for DPV from
>the requirements for DPD. Then we need to discuss the requirements for each
>of them. So we need to come with separate lists of requirements. This is
>what I did in my response.

If we don't agree on whether a DPV client might still pass on certs=20
and CRLs acquired via a protocol exchange, we can't proceed along=20
these lines. Such a DPV client looks a lot like a DPD client in=20
terms of what it might pass to the server in a request. In any case=20
the servers do much the same function, with the primary differences=20
being the form in which validation parameters are specified by the=20
client, and the form of the answers returned by the server. The vast=20
majority of the processing performed by the servers for DPD and DPV=20
is the same, even for a PKI-ignorant client.

>
>=20 > DPD
>=20 > =3D=3D=3D
>=20 >
>=20 > Let us continue with DPD. I agree in general with many of=20
>the requirements
>=20 > that you listed in that case. In particular, since a DPD=20
>client must be both
>=20 > PKI-aware and ASN.1 aware, the protocol should only be=20
>described in ASN.1.
>=20 >
>=20 > The major difference with the previous protocol is that no=20
>evaluation of the
>=20 > returned chain needs to be done, since the client is=20
>supposed to be able to
>=20 > perform all the checks himself. Therefor no validation=20
>status is returned by
>=20 > the server.
>=20 >
>
>
>[Steve]
>
>I don't think I agree with both of the statements above. No explicit
>validation status is returned, but I do think the server is performing
>validation so that only valid chains are returned.
>
>[Denis]
>
>Since these chains may not be complete, I would not consider such chains to
>be "valid". These chains will comply with the request, but some elements
>(more probably revovation information, but also certificates ?) may be
>missing.

I don't think I have seen anyone suggest that DPD return partial path=20
info, but maybe I have overlooked this. We obviously have different=20
models here.

>=20 > The service is more a single place for shopping all (?) the need=
ed
>=20 > certificates and revocation status information.
>=20 >
>=20 > In the request, the client could either specify a validation=20
>policy or the
>=20 > trusted points with, for each level of the chain, the=20
>indication whether
>=20 > CRLs or OCSP responses are requested.
>=20 >
>=20 > One or more chains, corresponding to the request may be obtained=
=2E
>=20 >
>=20 > The response does not need to be signed, but only protected=20
>by a combined
>=20 > integrity and data origin authentication service.
>=20 >
>=20 > CONCLUSION
>=20 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>=20 >
>=20 > We could support three protocols:
>=20 >
>=20 > 1=B0 DPV in XML,
>=20 > 2=B0 DPV in ASN.1,
>=20 > 3=B0 DPD in ASN.1.
>=20 >
>[Steve]
>
>The operative term here is "could." Also, DPV in XML and DPV in ASN.1 need
>not be the same protocol, because of different assumptions about the
>clients. So I think of it three protocols where 2 & 3 may be very similar,
>but 1 is quite different.
>
>[Denis]
>
>Two remarks:
>
>1) What kind of different assumptions are you making on:
>
>=20 1) DPV in XML and
>=20 2) DPV in ASN.1 ?
>
>2) You think that protocols 2 & 3 may be very similar, but you do not
>provide arguments. On the contrary, I do not think the same and I have have
>provided arguments to explain why they are pretty different.

Protocols 2 & 3 are quite similar because I assume that a DPV client=20
using ASN.1 will be able to supply cert path and revocation status=20
data in cases such as the ones I noted, e.g., when the protocols=20
allow clients to pass this info around even if they do not understand=20
it. We have examples of such protocols now. It's a reasonable design=20
approach, allowing a mix of PKI-aware and PKI-ignorant=20
implementations for the same protocol.

>=20 > ADDITIONAL QUESTION
>=20 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>=20 >
>=20 > For the two protocols in ASN.1, should these two protocols=20
>be piggy-back on
>=20 > OCSP ?
>=20 >
>
>[Steve]
>
>That's one of the proposals, but the answer should be the result of analysi=
s
>of a revised proposal consistent with the requirements that we adopt.
>
>[Denis]
>
>Agreed.
>
>
>=20 > Before going at the technical details, it is important to raise =
the
>=20 > following question: which combination(s) of the three basic=20
>requests (OCSP,
>=20 > DPV and DPD) could make sense ?
>=20 >
>=20 > If a client requests DPV, then it does not care about OCSP=20
>and neither on
>=20 > DPD (multiple certification chains to be tested).
>=20 >
>=20 > For a PKI-aware client, only OCSP + DPD makes sense.
>=20 >
>=20 > This means that :
>=20 >
>=20 > 1) DPV does not need to be supported by OCSP.
>=20 > 2) The only protocol to be piggy-backed to OCSP would be DPD.
>=20 >
>
>[Steve]
>
>I don't understand these comments. You need to provide more substantiation.
>
>[Denis]
>
>OK. Let me try to explain more:
>
>" If a client requests DPV, then it does not care about OCSP and neither on
>DPD (multiple certification chains to be tested)."
>
>If a client requests DPV, it would normally like to get the response "passe=
d
>validation", and will ask whether or not it wants back the single proof (as
>a blob) that lead to that conclusion. In that case, it does not care about
>the OCSP response which has been used in the validation algorithm and is
>part from the blob. A single chain is returned in that case.

I begin to see the differences in our perspectives here. Yes, return=20
of a single path and associated revocation status data would seem to=20
suffice for DPV, but I don't think that DPD necessarily returns=20
multiple paths, and I certainly don't think of it doing so in most=20
cases. Also, why would a DPV server not return OSCP responses as part=20
of its revocation status data, in an opaque blob? I would assume that=20
either type of server might return either CRLs or OCSP responses,=20
unless otherwise directed by the client (or by locally configured=20
parameters).

>
>"For a PKI-aware client, only OCSP + DPD makes sense.
>This means that :
>
>=20 1) DPV does not need to be supported by OCSP.
>=20 2) The only protocol to be piggy-backed to OCSP would be DPD."
>
>DPV is NOT designed for a PKI-aware client, but of course can be used by a
>PKI aware client, that will behave as if it were PKI ignorant.
>
>So the single combination that remains is between the two remaining
>protocols for PKI-aware clients (i.e. OCSP and DPD). In that sense, DPD
>could be piggy-backed on top of OCSP.

The wording here may be confusing me. Are you saying that DPD could=20
be implemented as an extension to OCSP (as has been proposed),=20
because an OCSP client must be PKI-aware, whereas a DPV client is=20
nominally PKI-ignorant and thus would never use OCSP in the first=20
place? I agree with that analysis, although it only suggests that=20
the DPD/OCSP combination is plausible, not necessarily preferable,=20
and that a DPV/OCSP combination is less plausible. though not=20
impossible.

Steve

--============_-1232973474==_ma============
Content-Type: text/enriched; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Denis,

Steve,

See my responses embbeded with your comments.

> Denis,

>=20

> Steve,

>=20

> First of all, many thanks for posting this long document.

>=20

> I will not respond using directly your text, since my arguments

> are fairly different. I will however re-use some of your
arguments.

>=20

> Let us use the concept of "validation policy", that you
introduce, which is

> all the set of rules to be followed when validating a
certificate. It will

> usually not simply be the rules mentioned in RFC 2459, but these
rules with

> additional conditions. Note that in the context of electronic
signatures, a

> "signature policy" is a specific example of a "validation
policy".

>=20

=20

[Steve]

We need to be explicit about what are the parameters that control path

validation. The 2459 validation algorithm has a well-defined set, but
if

there are others, we need to have them specified and agreed upon. One

conversation that took place in San Diego noted that one could imagine
a lot

of parameters that a user might want to express re path validation,
but

which have not been standardized, and for which we do not have general

agreement. A very rich list of this sort, and the associated complexity
that

would accompany an enhanced validation algorithm that used thise
parameters,

was thought to be out of scope for now, more an R&D topic vs. a topic
for

standardization. So we have to be careful here.

[Denis]

The current validation algorithm described in RFC 2459 is fine but too

restritive. It works fine with a single root key in the case where
there are

no naming constraints nor Certification Policy constraints, or in the
case

where there are are included in the (root) self-signed certificates. I
have

worked with Tim Polk so that in the "son-of-RFC2459" we will have the

description of an enhanced path validation algorithm that will take
care of

multiple roots, each one associated with different naming constraints
or

Certification Policy constraints - which will not necessarilly be
included

in the root self-signed certificates.

Self-signed certs are not the only way to deal with multiple roots, and
it often seems to me that they are a poor way, when we want to make use
of features like naming constraints. Why not just have cross certs
issued to other "roots" by a local CA and embed the naming (and
policy?) constraints into those cross certs?

So we would need to support two options, which are not mutually
exclusive:=20

1) define with a great level of accuracy each of the parameters, or

2) provide an OID which is a global reference to all these
parameters.

=20

> DPV

> =3D=3D=3D

>=20

> Let us start with DPV first. A DPV client will not necessarily
be either

> PKI-aware, nor ASN.1 aware. I thus see two flavors for a DPV
protocol:

>=20

> 1) one not using ASN.1 (e.g. using XML),

> 2) one using ASN.1.

>=20

> In both cases the client only supplies an unambiguous reference
of the

> certificate (CA name, serial number and a hash of the
certificate) or the

> certificate itself and specifies the rules to be followed to
validate the

> certificate: an identification of a pre-defined "validation
policy" (e.g. an

> OID and/or a URL to find the policy and a hash of that
validation policy).

>=20

[Steve]

Given the problems we have had in OCSP (v1) re referring to a target
cert, I

am not comfortable specifying a target cert other than by providing a
copy

of that cert to the server.

[Denis]

In a signed CMS message, you may only have the EESCertID, without the

certificate itself.

ESSCertID ::=3D SEQUENCE {

certHash Hash,

issuerSerial IssuerSerial OPTIONAL

}

Hash ::=3D OCTET STRING -- SHA1 hash of entire certificate

IssuerSerial ::=3D SEQUENCE {

issuer GeneralNames,

serialNumber CertificateSerialNumber

}

The idea is to be able to use ESSCertID without the need to fetch the

certificate itself.

I see your example, but I also stand by my observation that providing
anything other than the target cert per se has potential problems and
adds complexity to the server. We'll have to decide whether we want to
impose such adde complexity on servers, and whether we can provide
clean, algorithmic means of dealing with this complexity.

> As a result, the client expects a signed response which
reproduces the

> requested parameters and includes a status. The status is not
simply:

> "passed validation", "failed validation", or "don't' know" but
can also be

> "incomplete validation", meaning that some revocation status
information is

> not yet available at the time of processing and a later attempt
might

> succeed.

>=20

[Steve]

Incomplete validation is a reasonable response.=20

Yes, it will have to be one of the responses, hopefully with an
explanation of what caused the response to be incomplete.

[Denis]

:-)

[Steve]

maybe we should include the

set of parameters used for the validation, including ones not supplied
by

the client, e.g., defaults, or overrides imposed by the server, or the

values bound to a policy that was specified.

[Denis]

We are not on the same track here. I am assuming that a DPV client is
PKI

ignorant. You are making the assumption that the client MAY simply
some

elements of the certification path, where I make the assumption that
the

single element that MAY be supplied in a DPV request is the leaf

certificate. For all the other elements of a certification path, the
server

is supposed to have access to the various repositories. The response

contains a blob of what has been used, that can be blinding copied and

stored. =20

A DPV client MAY be not PKI-aware, but that is not the only case we
agreed to address. I'll need to see more comments from WG members to
persuade me that we wish to restrict DPV interactions to clients that
are presumed to be PKI-ignorant, to use your term.

=20

> The response must include the time at which the validation has
been

> performed. Allowing to test a certificate "in the past", would
place some

> requirements that cannot always be accomplished by a standard
PKI: currently

> we do not mandate CAs to maintain revocation information beyond
the end of

> the validity period of a certificate. We should not change that
rule. So I

> am very reluctant to autorise validation in the past, e.g. 10
years later.

>=20

[Steve]

Good points; we should include the time of the response. I added the
"in the

past" requirement based on its inclusion in SCVP, but there clearly
limits

to one's ability to support that feature. However, if the server is
uable to

verify a cert relative to a prior time, based on unavailability of
some

revocation data, it can always state that in a response. One might add
a

requirement to allow the server to be configured to reject requests
for

validation that cite a time/date prior to some confugured value.

[Denis]

Since archiving of recocation information is not mandated to the CAs,
such a

function would need to be provided by some other trusted service
provider.

We should be very careful before allowing the provision of such a new

service. I believe that the PKI is already sufficiently complex so that
we

make our best efforts not to introduced additional Trusted Service
Providers

(that could be avoided). The only case to be supported should be the

"current time" and some time "soon after the end of validity of a

certificate" (i.e. a few weeks, in case someone being on holidays would
like

to check, when coming back from holidays, if a received message, was
signed

by a revoked certificate or not). =20

There was some sentiment for having the "was it valid then" function as
provided in SCVP, but if there is not continued support we could delete
it. I want to get more feedback on this issue.

> If a client is interested in a later proof, then it
should obtain that

> information from the server at the time the information is still
available.

> This means that a client should have the possibility to ask the
server to

> optionally return an opaque blob that contains all what has been
used to

> validate the certificate (i.e. a certification path and all the
CRLs or

> OCSPs needed for each certificate from the path).

>=20

[Steve]

We have this requirement already, with a time stamp option.

[Denis]

We should remove the time stamp option.

Yes, we could.

> A question arises from the requirements 1.5 and 1.6
that you listed: should

> that opaque blob be time-stamped ? If there is a fear that some
of the

> issuing keys used in the certification path might later on be
compromised,

> then this can be useful. This case should be very seldom and
hence this

> service would not always be required. In addition, why should
that service

> be embedded in this protocol ? This could be obtained using
directly the

> TSP, leaving more possibilities: free choice of the TSAs, time
stamp of the

> full blob, time stamp of the certification chain only, time
stamp on both

> the certification chain and the revocation information. Thus I
do not favor

> to piggy-back the two services.

>=20

[Steve]

Yes, one could keep the services separate. I am not hard over on this,
and

can be persuaded to remove the requirement, or to make server support
for it

optional.

[Denis]

If you are not hard on this issue, let us remove the time stamping
option.

:-)

I'll remove it if I hear from a few more people who agree that it is
best provided as a separate call to a TSA.

> In order to simplify the protocol and allow for
PKI-ignorant clients, the

> client should NOT be allowed to provide any other element than
the

> certificate, that might help to construct the path or the
revocation

> information.

>=20

[Steve]

I don't see the rationale for this. We already have application
protocols

where a client that is not PKI-aware might acquire cert paths and/or

revocation data that it could pass on to a DPV server. So, I don't
think you

have made a good argument here for not allowing such data to be
transmitted.

Also, I don't think we have agreement yet that we are supporting
clients

that are not PKI-aware. I merely noted that IF we choose to support
such

clients, then there are implications for the syntax used for the
protocol,

and for the semantics of what is transmitted. I don't think we have
made the

next step to agree to support such clients.

[Denis]

I have difficulties to understand how a client that would NOT be
"PKI-aware

might acquire cert paths and/or revocation data" :-)

Once again, I am advocating a simple protocol for DPV to be used by
PKI

ignorant clients.=20

As I noted, a client might acquire cert paths and CRLs via a protocol
like SSL or IKE. Such clients could be ASN.1 capable but want to
offload validation for the reasons cited earlier.

> This means that, not only I do not agree with a common
list of requirements

> for both DPV and DPD, but also that I do not agree with many of
the

> requirements that you listed:

>=20

> For a DPV client:

>=20

> 1.1. Only a single certificate should be allowed.

> 1.2. No revocation items should be allowed.

> 1.3. No request in the past should be allowed.

> 1.4. Imposing constraints for CRLs or OCSP responses should be
hidden

> under the "validation policy" that is selected.

> 1.5. and 1.6. Time stamped responses, if needed, should not be
part of the

> service.

> 1.7. Validation policies are not necessarily "configured at the
server",

> but can simply be pre-defined, outside the server. I any case,
the

> rules that has been followed - i.e. "validation policy" - must
be

> indicated in the response.

> 1.8. For DPV, responses must be signed.

> 1.9. The policy ID format can/will be specified in the
protocol.

>=20

> For a DPV server:

>=20

> 2.1. A DPV server, will have to do more than RFC 2459, hence why
the use

> of a validation policy is needed.

> 2.2. An opaque blob MAY be returned.

> 2.3. Time stamping is not needed.

> 2.4. The concept of policy overriding is too complex: a
reference to

> a validation policy is sufficient.

> 2.5. No comment.

> 2.6. A server must support LDAP for certificate fetching, and
EITHER CRL

> fetching OR OSCP (OCSP should not be mandatory).

> 2.7. No comment.

>=20

[Steve]

Given that we no longer agree on the underlying assumptions, it
probably is

not worthwhile discussing each of your proposed changes above.

[Denis]

Yes and no. We clearly have different assumptions, but we need to find
an

agreement. I am first advocating to separate the requirements for DPV
from

the requirements for DPD. Then we need to discuss the requirements for
each

of them. So we need to come with separate lists of requirements. This
is

what I did in my response.

If we don't agree on whether a DPV client might still pass on certs and
CRLs acquired via a protocol exchange, we can't proceed along these
lines. Such a DPV client looks a lot like a DPD client in terms of
what it might pass to the server in a request. In any case the servers
do much the same function, with the primary differences being the form
in which validation parameters are specified by the client, and the
form of the answers returned by the server. The vast majority of the
processing performed by the servers for DPD and DPV is the same, even
for a PKI-ignorant client.

> DPD

> =3D=3D=3D

>=20

> Let us continue with DPD. I agree in general with many of the
requirements

> that you listed in that case. In particular, since a DPD client
must be both

> PKI-aware and ASN.1 aware, the protocol should only be described
in ASN.1.

>=20

> The major difference with the previous protocol is that no
evaluation of the

> returned chain needs to be done, since the client is supposed to
be able to

> perform all the checks himself. Therefor no validation status is
returned by

> the server.

>=20

[Steve]

I don't think I agree with both of the statements above. No explicit

validation status is returned, but I do think the server is performing

validation so that only valid chains are returned.

[Denis]

Since these chains may not be complete, I would not consider such
chains to

be "valid". These chains will comply with the request, but some
elements

(more probably revovation information, but also certificates ?) may be

missing.

I don't think I have seen anyone suggest that DPD return partial path
info, but maybe I have overlooked this. We obviously have different
models here.

> The service is more a single place for shopping all (?)
the needed

> certificates and revocation status information.

>=20

> In the request, the client could either specify a validation
policy or the

> trusted points with, for each level of the chain, the indication
whether

> CRLs or OCSP responses are requested.

>=20

> One or more chains, corresponding to the request may be
obtained.

>=20

> The response does not need to be signed, but only protected by a
combined

> integrity and data origin authentication service.

>=20

> CONCLUSION

> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

>=20

> We could support three protocols:

>=20

> 1=B0 DPV in XML,

> 2=B0 DPV in ASN.1,

> 3=B0 DPD in ASN.1.

>=20

[Steve]

The operative term here is "could." Also, DPV in XML and DPV in ASN.1
need

not be the same protocol, because of different assumptions about the

clients. So I think of it three protocols where 2 & 3 may be very
similar,

but 1 is quite different.

[Denis]

Two remarks:

1) What kind of different assumptions are you making on:

1) DPV in XML and=20

2) DPV in ASN.1 ?

2) You think that protocols 2 & 3 may be very similar, but you do not

provide arguments. On the contrary, I do not think the same and I have
have

provided arguments to explain why they are pretty different. =20

Protocols 2 & 3 are quite similar because I assume that a DPV client
using ASN.1 will be able to supply cert path and revocation status data
in cases such as the ones I noted, e.g., when the protocols allow
clients to pass this info around even if they do not understand it. We
have examples of such protocols now. It's a reasonable design approach,
allowing a mix of PKI-aware and PKI-ignorant implementations for the
same protocol.=20

> ADDITIONAL QUESTION

> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

>=20

> For the two protocols in ASN.1, should these two protocols be
piggy-back on

> OCSP ?

>=20

[Steve]

That's one of the proposals, but the answer should be the result of
analysis

of a revised proposal consistent with the requirements that we adopt.

[Denis]

Agreed.

=20

> Before going at the technical details, it is important to raise
the

> following question: which combination(s) of the three basic
requests (OCSP,

> DPV and DPD) could make sense ?

>=20

> If a client requests DPV, then it does not care about OCSP and
neither on

> DPD (multiple certification chains to be tested).

>=20

> For a PKI-aware client, only OCSP + DPD makes sense.

>=20

> This means that :

>=20

> 1) DPV does not need to be supported by OCSP.

> 2) The only protocol to be piggy-backed to OCSP would be DPD.

>=20

[Steve]

I don't understand these comments. You need to provide more
substantiation.

=20

[Denis]

OK. Let me try to explain more:

" If a client requests DPV, then it does not care about OCSP and
neither on

DPD (multiple certification chains to be tested)."

If a client requests DPV, it would normally like to get the response
"passed

validation", and will ask whether or not it wants back the single proof
(as

a blob) that lead to that conclusion. In that case, it does not care
about

the OCSP response which has been used in the validation algorithm and
is

part from the blob. A single chain is returned in that case.

I begin to see the differences in our perspectives here. Yes, return of
a single path and associated revocation status data would seem to
suffice for DPV, but I don't think that DPD
necessarily returns multiple paths, and I
certainly don't think of it doing so in most cases. Also, why would a
DPV server not return OSCP responses as part of its revocation status
data, in an opaque blob? I would assume that either type of server
might return either CRLs or OCSP responses, unless otherwise directed
by the client (or by locally configured parameters).

"For a PKI-aware client, only OCSP + DPD makes sense.

This means that :

1) DPV does not need to be supported by OCSP.

2) The only protocol to be piggy-backed to OCSP would be DPD."

DPV is NOT designed for a PKI-aware client, but of course can be used
by a

PKI aware client, that will behave as if it were PKI ignorant.

So the single combination that remains is between the two remaining

protocols for PKI-aware clients (i.e. OCSP and DPD). In that sense,
DPD

could be piggy-backed on top of OCSP.

The wording here may be confusing me. Are you saying that DPD could be
implemented as an extension to OCSP (as has been proposed), because an
OCSP client must be PKI-aware, whereas a DPV client is nominally
PKI-ignorant and thus would never use OCSP in the first place? I agree
with that analysis, although it only suggests that the DPD/OCSP
combination is plausible, not necessarily preferable, and that a
DPV/OCSP combination is less plausible. though not impossible.

Steve

--============_-1232973474==_ma============--

Received: from gadolinium.btinternet.com (gadolinium.btinternet.com [194.73.73.111]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id CAA14673 for ; Wed, 10 Jan 2001 02:32:57 -0800 (PST)
Received: from [195.99.54.165] (helo=vaio) by gadolinium.btinternet.com with smtp (Exim 3.03 #83) id 14GIdh-0001ue-00 for [email-masked]; Wed, 10 Jan 2001 10:37:57 +0000
Message-ID: <003201c07af2$226088c0$a53663c3@vaio>
Reply-To: "Liaquat Khan"
From: "Liaquat Khan"
To: "PKIX-List"
References: <[email-masked]>
Subject: Re: OCSP authorized responder clarification.
Date: Wed, 10 Jan 2001 10:43:12 -0000
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.4522.1200
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200

Just to confirm that the GTA has come to the same conclusion. As such, the
CA which has given authorisation to the OCSP responder is also the one that
issues the OCSP responder with the certificate for its public key.

Within the GTA model, a particular OCSP responder's public key could be
certified by more than one CA.

Directly certifying an OCSP responder has the advantage that one OCSP
responder cannot potentially 'spoof' another OCSP responder within the same
infrastructure. A root certifying all OCSP responders within an
infrastructure could potentially open up this security concern.

Regards,
Liaquat
----- Original Message -----
From: "Ambarish Malpani"
To: "'Dr S N Henson'" ; "PKIX-List"
Sent: Wednesday, January 10, 2001 9:18 AM
Subject: RE: OCSP authorized responder clarification.

>
> Hi Steve,
> You are absolutely right - the CA needs to directly authorize
> the OCSP responder to respond on its behalf. The fact that the
> root authorized you to respond doesn't allow you to respond for all
> CAs certified by that root in the CA delegated trust model of OCSP.
>
> Regards,
> Ambarish
>
>
>
> ---------------------------------------------------------------------
> Ambarish Malpani
> Architect 650.567.5457
> ValiCert, Inc. [email-masked]
> 339 N. Bernardo Ave. http://www.valicert.com
> Mountain View, CA 94043
>
>
> > -----Original Message-----
> > From: Dr S N Henson [mailto:[email-masked]]
> > Sent: Monday, January 08, 2001 4:34 AM
> > To: PKIX-List
> > Subject: OCSP authorized responder clarification.
> >
> >
> > In RFC2560 4.2.2.2 the certificate signing an OCSP request is valid if
> > it:
> >
> > > 3. Includes a value of id-ad-ocspSigning in an ExtendedKeyUsage
> > > extension and is issued by the CA that issued the certificate in
> > > question."
> >
> > A certain CA issues end user certificates signed by an intermediate CA
> > which is in turn signed by the root CA.
> >
> > The responder certificate is signed by the root CA. Does this, as
> > appears to be the case, mean that the above condition does not apply
> > because the OCSP reponder certificate is not signed by the
> > intermediate
> > CA?
> >
> > Alternatively is the condition satisfied because they both
> > have the same
> > root CA?
> >
> > Steve.
> > --
> > Dr Stephen N. Henson. http://www.drh-consultancy.demon.co.uk/
> > Personal Email: [email-masked]
> > Senior crypto engineer, Celo Communications: http://www.celocom.com/
> > Core developer of the OpenSSL project: http://www.openssl.org/
> > Business Email: [email-masked] PGP key: via homepage.
> >
>

Received: from ext-mail.valicert.com (ns1.valicert.com [63.65.221.10]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id BAA06523 for ; Wed, 10 Jan 2001 01:17:50 -0800 (PST)
Received: from CONVERSION-DAEMON by ext-mail.valicert.com (PMDF V5.2-33 #46613) id <[email-masked]> for [email-masked]; Wed, 10 Jan 2001 01:22:36 -0800 (PST)
Received: from polaris.valicert.com ([192.168.2.34]) by ext-mail.valicert.com (PMDF V5.2-33 #46613) with ESMTP id <[email-masked]>; Wed, 10 Jan 2001 01:22:36 -0800 (PST)
Received: by exchange.valicert.com with Internet Mail Service (5.5.2650.21) id ; Wed, 10 Jan 2001 01:18:35 -0800
Content-return: allowed
Date: Wed, 10 Jan 2001 01:18:34 -0800
From: Ambarish Malpani
Subject: RE: OCSP authorized responder clarification.
To: "'Dr S N Henson'" , PKIX-List
Message-id: <[email-masked]>
MIME-version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-type: text/plain; charset="iso-8859-1"

Hi Steve,
You are absolutely right - the CA needs to directly authorize
the OCSP responder to respond on its behalf. The fact that the
root authorized you to respond doesn't allow you to respond for all
CAs certified by that root in the CA delegated trust model of OCSP.

Regards,
Ambarish

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

> -----Original Message-----
> From: Dr S N Henson [mailto:[email-masked]]
> Sent: Monday, January 08, 2001 4:34 AM
> To: PKIX-List
> Subject: OCSP authorized responder clarification.
>
>
> In RFC2560 4.2.2.2 the certificate signing an OCSP request is valid if
> it:
>
> > 3. Includes a value of id-ad-ocspSigning in an ExtendedKeyUsage
> > extension and is issued by the CA that issued the certificate in
> > question."
>
> A certain CA issues end user certificates signed by an intermediate CA
> which is in turn signed by the root CA.
>
> The responder certificate is signed by the root CA. Does this, as
> appears to be the case, mean that the above condition does not apply
> because the OCSP reponder certificate is not signed by the
> intermediate
> CA?
>
> Alternatively is the condition satisfied because they both
> have the same
> root CA?
>
> Steve.
> --
> Dr Stephen N. Henson. http://www.drh-consultancy.demon.co.uk/
> Personal Email: [email-masked]
> Senior crypto engineer, Celo Communications: http://www.celocom.com/
> Core developer of the OpenSSL project: http://www.openssl.org/
> Business Email: [email-masked] PGP key: via homepage.
>

Received: from junker.ms.inka.de (pD901CD06.dip.t-dialin.net [217.1.205.6]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id AAA26343 for ; Wed, 10 Jan 2001 00:05:29 -0800 (PST)
Received: from stroeder.com (localhost [127.0.0.1]) by junker.ms.inka.de (Postfix) with ESMTP id 1034167C5B for ; Wed, 10 Jan 2001 09:08:50 +0100 (CET)
Sender: [email-masked]
Message-ID: <[email-masked]>
Date: Wed, 10 Jan 2001 09:08:49 +0100
From: Michael =?iso-8859-1?Q?Str=F6der?=
Organization: stroeder.com
X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.18 i686)
X-Accept-Language: de-DE, de, en
MIME-Version: 1.0
To: [email-masked]
Subject: Re: Basic Cert-2-Directory mapping question
References: <[email-masked]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Stephen Kent wrote:
>
> I have not read your paper, but the assertion that DNs don't work,
> without substantiation, seems a bit strong. Certainly when people
> create arbitrary DNs, without regard to the semantics of directory
> structure, bad things happen.

Please review some discussion threads on LDAP-related lists about
directory tree design........................never-ending story.

Suggestions are ranging from traditional X.521 naming to flat-tree
name space under a dc=domain,dc=domain root.

> Also, it is fair to say that the grand,
> nations as top level directory operators model that X.500 envisioned
> has not happened,

Even if it would have happened X.521 tree naming would simply suck.
Think of multi-national companies which are not eager revealing
their directory structure to the public. Not to speak of the
different country-dependent rules for the registration process...

> finally, the IETF has had a standard means of encoding a DNS name as
> a DN for several years, which suggests that there is at least one
> scheme that would work.

I agree that DNS-based naming (often called dc naming in the LDAP
world) is a way of at least find a division for global and
organizational name space. System admins are used to it and they
have to sub-divide their organizations into DNS sub domains anyway
(which is a pretty hard job though).

But who of you on the list has a mail address [email-masked] or
even [email-masked]? Will you agree with your admin if
you're assigned such an e-mail address? No, you will ask him for a
shorter one. Or you will go to a cheap free mail service to get a
shorter one. Or register your name as domain (me too ;-).

=> People are used to flat name spaces. X.500 DNs does not work.

Ciao, Michael.

Received: from junker.ms.inka.de (pD901CD06.dip.t-dialin.net [217.1.205.6]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id AAA26342 for ; Wed, 10 Jan 2001 00:05:29 -0800 (PST)
Received: from stroeder.com (localhost [127.0.0.1]) by junker.ms.inka.de (Postfix) with ESMTP id DA94E67C7D for ; Wed, 10 Jan 2001 09:08:57 +0100 (CET)
Sender: [email-masked]
Message-ID: <[email-masked]>
Date: Wed, 10 Jan 2001 09:08:57 +0100
From: Michael =?iso-8859-1?Q?Str=F6der?=
Organization: stroeder.com
X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.18 i686)
X-Accept-Language: de-DE, de, en
MIME-Version: 1.0
To: [email-masked]
Subject: Re: Basic Cert-2-Directory mapping question
References: <[email-masked]> <[email-masked]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Anders Rundgren wrote:
>
> BOF-like feasibility study to see if DNs must continue
> to be broken until the end of time?

The main problem is that the world is not hierarchical or more
precise: There are so many possibilities even within small
organizations to divide them into a hierarchy. Not to speak of
connecting the names spaces of different organizations...

Most X.500 directory books suffer from not accepting this.

Ciao, Michael.

Received: from junker.ms.inka.de (pD901CD06.dip.t-dialin.net [217.1.205.6]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id AAA26341 for ; Wed, 10 Jan 2001 00:05:29 -0800 (PST)
Received: from stroeder.com (localhost [127.0.0.1]) by junker.ms.inka.de (Postfix) with ESMTP id A721A680E2 for ; Wed, 10 Jan 2001 09:09:03 +0100 (CET)
Sender: [email-masked]
Message-ID: <[email-masked]>
Date: Wed, 10 Jan 2001 09:09:03 +0100
From: Michael =?iso-8859-1?Q?Str=F6der?=
Organization: stroeder.com
X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.18 i686)
X-Accept-Language: de-DE, de, en
MIME-Version: 1.0
To: "[email-masked]"
Subject: Re: Basic Cert-2-Directory mapping question
References: <[email-masked]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Peter Gutmann wrote:
>
> Stephen Kent writes:
>
> >I have not read your paper, but the assertion that DNs don't work, without
> >substantiation, seems a bit strong.
>
> [.. Very many valid points by Peter deleted..]

Peter, I completely agree with you. IMHO one of the main problems
with
PKIX is that there's so much X.500 in it. ;-) (I enjoyed your
writing about T.61...)

> The sole meaningful piece of information in any of my certs is my email
> address

Agreed again. And IMHO the e-mail address combined with fast
searching (the real
advantage of directory servers) is the only working solution for a
person's entry today.

> That's the point I made in the analysis in my
> paper, noone (well, almost noone :-) actually uses a DN in the way X.500 says
> it's supposed to be used.

And if you try it's sometimes even hard to find the "right" value
for the CN person's attribute of a person's entry. BTW: Ed Gerck
wrote a nice paper about these naming problems too (available around
'98 if I remember correctly).

> >finally, the IETF has had a standard means of encoding a DNS name as a DN for
> >several years, which suggests that there is at least one scheme that would
> >work.
>
> (I have a vague
> memory of actually having seen a solitary DC in a cert somewhere, but a quick
> check of my collection has failed to locate one...

;-)

> does anyone know of examples of these being used?

Yes.

> How does the average third-party app handle
> them?).

OpenSSL can handle them. Netscape Messenger seems to be able to use
them. web2ldap displays them...

Ciao, Michael.

Received: from junker.ms.inka.de (pD901CD06.dip.t-dialin.net [217.1.205.6]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id AAA26337 for ; Wed, 10 Jan 2001 00:05:29 -0800 (PST)
Received: from stroeder.com (localhost [127.0.0.1]) by junker.ms.inka.de (Postfix) with ESMTP id 5843C67C80 for ; Wed, 10 Jan 2001 09:09:01 +0100 (CET)
Sender: [email-masked]
Message-ID: <[email-masked]>
Date: Wed, 10 Jan 2001 09:09:00 +0100
From: Michael =?iso-8859-1?Q?Str=F6der?=
Organization: stroeder.com
X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.18 i686)
X-Accept-Language: de-DE, de, en
MIME-Version: 1.0
To: [email-masked]
Subject: Re: Basic Cert-2-Directory mapping question
References: <[email-masked]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

"David P. Kemp" wrote:
>
> The Web works only because every Internet URL begins with
> DNS-registered name.

For most users the web works like this:

www.mycompany.com

This is a completely flat name space. And yes, I know that one can
even create valid URLs like http://host1.subdomain.domain.net... ;-)

Ciao, Michael.

Received: from junker.ms.inka.de (pD901CD06.dip.t-dialin.net [217.1.205.6]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id AAA26338 for ; Wed, 10 Jan 2001 00:05:29 -0800 (PST)
Received: from stroeder.com (localhost [127.0.0.1]) by junker.ms.inka.de (Postfix) with ESMTP id C8A0E680E3 for ; Wed, 10 Jan 2001 09:09:05 +0100 (CET)
Sender: [email-masked]
Message-ID: <[email-masked]>
Date: Wed, 10 Jan 2001 09:09:05 +0100
From: Michael =?iso-8859-1?Q?Str=F6der?=
Organization: stroeder.com
X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.18 i686)
X-Accept-Language: de-DE, de, en
MIME-Version: 1.0
To: "[email-masked]"
Subject: Re: Basic Cert-2-Directory mapping question
References: <[email-masked]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Oscar Jacobsson wrote:
>
> Bob Jueneman wrote:
> > What we need, and have needed for ten years, is a STANDARD!
>
> Apart from the fact that RFC 2377 is "only" Informational, are there any
> perceived problems with the naming plan it proposes that I'm unaware of?
> I should probably add that I've yet to attempt to implement an
> infrastructure using this naming scheme yet. :-)

ldap://root.openldap.org

Ciao, Michael.

Received: from poptop.llnl.gov (poptop.llnl.gov [128.115.41.70]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id SAA07064 for ; Tue, 9 Jan 2001 18:52:17 -0800 (PST)
Received: from catalyst (catalyst.llnl.gov [128.115.222.68]) by poptop.llnl.gov (8.8.8/LLNL-3.0.2/pop.llnl.gov-5.1) with ESMTP id SAA17063; Tue, 9 Jan 2001 18:56:15 -0800 (PST)
Message-Id: <[email-masked]>
X-Sender: [email-masked]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2
Date: Tue, 09 Jan 2001 19:01:57 -0800
To: Janus Liebregts
From: Tony Bartoletti
Subject: Re: Basic Cert-2-Directory mapping question
Cc: [email-masked]
In-Reply-To: <[email-masked]>
References:
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed

At 10:36 PM 1/9/01 +0100, Janus Liebregts wrote:

>btw the EU has released a eye-opening working document on privacy issues
>on the Internet:
>http://europa.eu.int/comm/internal_market/en/media/dataprot/wpdocs/index.htm

Thanks Janus!

A readable, educational and enlightened document!

___tony___

Tony Bartoletti 925-422-3881
Information Operations, Warfare and Assurance Center
Lawrence Livermore National Laboratory
Livermore, CA 94551-9900

Received: from smtp1.libero.it (smtp1.libero.it [193.70.192.51]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id RAA05524 for ; Tue, 9 Jan 2001 17:07:30 -0800 (PST)
Received: from libero.it (193.70.192.41) by smtp1.libero.it (5.5.015.5) id 3A531603004F2B4F for [email-masked]; Wed, 10 Jan 2001 02:11:58 +0100
Date: Wed, 10 Jan 2001 02:10:45 +0100
Message-Id:
Subject: unsubscribe
MIME-Version: 1.0
X-Priority: 1 (Highest)
Content-Type: text/plain
From: "[email-masked]"
To: [email-masked]
X-XaM3-API-Version: 1.1.9.1.31
X-SenderIP: 213.45.249.245
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id RAA05525

unsubscribe [email-masked]

Received: from po1.bbn.com (PO1.BBN.COM [192.1.50.38]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA03780 for ; Tue, 9 Jan 2001 15:48:43 -0800 (PST)
Received: from [171.78.30.107] (comsec.bbn.com [171.78.30.107]) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id SAA15943; Tue, 9 Jan 2001 18:53:33 -0500 (EST)
Mime-Version: 1.0
X-Sender: [email-masked]
Message-Id:
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Date: Tue, 9 Jan 2001 18:51:39 -0500
To: Peter Sylvester
From: Stephen Kent
Subject: RE: DPD & DPV requirements - Let us Recurse
Cc: [email-masked]
Content-Type: text/plain; charset="us-ascii" ; format="flowed"

Peter,

>
>
>What do you mean by revocation status not quite perfect? A server
>makes a desision, and tells what it had looked at, it may happen
>that another server verifier looks at the same data in a different
>way, and comes to another conclusion; this tru independant of
>whether the first returns its justifications or not. One entity
>might validate a cert chain, another might not, etc. Returning
>as much as possible data about why one decision has been made
>does not change that.

What if a server has a CRL for a along the path but the CRL is old,
and the server cannot get a current one? The simple answer is that
the validity of the target cert is unknown, but that may not be a
totally satisfying answer. You are correct that we face this problem
already for DPV (for DPD we could return what we have and let the
client work it out) irrespective of whether we have to return
justifications. As we move into "explaining" an evaluation, I was
thinking that we might want to be more sophisticated about the whole
process, but that was sloppy on my part. You're right!

>If a client has a user interface to explain a server decision,
>it seems necessary anyway to display certificates, elements on
>a CRL, OCSP reponses, PKIStatus data.
>
>We already have the problem of user interfaces of certificate
>and CRL displays, and also of how to display responses from
>a OCSP server, or from the new services to be standardized.
>But do we actually care? But: I don't see in other pkix standards a
>description of about how a certificate chain has to be presented
>or even a single certificate.

No, the last RFC to broach the subject of cert path info presentation
was 1422, for PEM! If we return status, cert chains and revocation
status, then we get to ignore this. But, if we return what purports
to be an "explanation" of why a cert is valid, then I think we have
opened up a can of worms with regard to user interface issues,
because the purported customer for the explanation. This is
especially true for DPV and non-PKI aware clients.

>What seems useful to me is to specify a list of elements that may
>be supposed to be presented to users. Such a list should be a simple
>as possible, contain a small number of different data type that
>allow to express a large set of situations, so that we don't have
>to add new stuff each 6 months or 3 years. We have already *MANY*
>standards that return 'status information' in different ways.
>One question here would be: Is it more appropriate to use a
>new textual format like in SCVP or something like PKIStatus as
>used in several standards maybe accompanied by OCSP responses?

I think the answer has to be driven by the context in which the
response is to be used. For machine consumption a binary status
representation is appropriate, but for a human user, text is
preferable. However, in the latter case, I think we are entering a
very complex arena that, as you noted, we have avoided in the past,
re HMI for PKI info.

Steve

Received: from survis.surfnet.nl (survis.surfnet.nl [192.87.108.3]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA00165 for ; Tue, 9 Jan 2001 13:30:52 -0800 (PST)
Received: from survis.surfnet.nl ([192.87.108.3] helo=surfnet.nl) by survis.surfnet.nl with ESMTP (exPP) id 14G6Qm-0001Qi-00; Tue, 9 Jan 2001 22:35:48 +0100
Message-ID: <[email-masked]>
Date: Tue, 09 Jan 2001 22:36:18 +0100
From: Janus Liebregts
Organization: SURFnet bv
X-Mailer: Mozilla 4.7 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Bob Jueneman
CC: [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Re: Basic Cert-2-Directory mapping question
References:
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Bob Jueneman wrote:
>
> >>>> "Anders Rundgren" 01/09/01 12:13AM >>>
> >Guys!
> >The response on this "basic" question has simply been overwhelming!
> >
> >Even if you can force CAs to obey certain rules regarding DNs, I still believe
> >that this inability to use certificates created in "one regime", as credentials in
> >another Win2K or NetWare "regime" calls for *some* kind of action.
> >
> >At least those who are into TTPs (commercial or not) should be interested.
> >
> >/anders
> >
>
> Anders, I won't attempt to speak for Microsoft -- Bill has more money than I
> do, and can speak for himself.
>
> But although I certainly share some of your frustration, it isn't clear as yet
> that most of our customers have this problem, although perhaps we wish they
> did.
>
> Whether someone within the enterprise is trying to log on to Win2K, NetWare,
> or our NDS/eDirectory, 95% to 99% of the time they are using access control
> solutions established BY the enterprise FOR the enterprise.
>
> In that type of closed environment, it simply doesn't matter all that much what
> the directory schema or the PKI schema looks like, as they will be designed to
> match each other.
>
> Notice that this really isn't a "closed PKI" as Steve discusses -- it's even more closed
> than that, because the access control is almost entirely within ONE enterprise,
> and not multiple enterprises, much less the much broader retail consumer
> or residentialPerson marketplace.
>
> Now, I'm certainly not arguing that it wouldn't be interesting to talk about
> extranet access control, and PKI-based authorizations that extend beyond the
> boundaries of one organization. It would be interesting, and I and others have
> been talking about that for what seems like eons.
>
> But by and large, it isn't happening.
>
> Is this, as some would claim, due to the fact that we haven't solved the directory
> naming problem?
>
> No, the problem is deeper than that.
>
> The problem is one of TRUST.
>
> And I would claim, with some regret, that PKI isn't about TRUST, it is about
> IDENTITY.
>
> Unfortunately, when it comes to making an access control decision, it isn't
> sufficient to have a chain of certificate stretching back to some ubiquitous
> issuer of low-cost certificates which attests to the fact that the holder of
> a given private key is in fact cn="Village Idiot #13", even if he really is.
>
> If I'm the system administrator, I don't care who someone IS, I want to
> know what that person is permitted to DO.
>
> At least at present, the way that people are controlling those decisions is to
> pre-enroll that individual into an authoritative directory or database, and then
> assign or share some secret with that individual which can be used to
> authenticate that person as the same individual that was authorized, assuming
> he hasn't shared that secret with someone else.
>
> Granted, there are nuances of security and control, but the bottom line is
> that it isn't the person's DN that matters, assuming that DN can be found
> somehow. The only thing that really matters is the shared secret, and
> the fact that the person who knows that secret has been granted certain
> permissions or authority.
>
> Whether that secret is a password, a private key, or some token device
> is of secondary importance to the fact of pre-enrollment and the granting of
> access authority.
>
> So the lack of a universal naming solution, although irritating to those of us
> in the profession, hasn't yet reach the point of being a crisis with our customers,
> because those customers either don't allow external users into their system at
> all, or they base their decisions on other things than identity, such as whether or
> not the person has a valid credit card account, and it isn't maxed out.
>
> Note that I have been talking exclusively about access control, and not
> legally-binding transactions or other aspects of a more global use of PKI,
> where identity may (someday) play a larger role. But even in that context,
> I would claim that trust comes first, and is anchored by identity, and not
> the other way around.
>
> Regards,
>
> Bob
>
> Robert R. Jueneman
> Security Architect
> Novell, Inc. -- the leading provider of Net services software.

Bob,

when taking privacy aspects into account, for several services, you even
don't want to give your identity as a credential for access control.
For the access control SERVICE trust comes first anchored by identity.
For the access control USER trust comes first, anchored by guaranteeing
the service and privacy.

Indeed in the closed enterprise environment privacy is a non issue.
In an inter business environment privacy isn't really an issue, you want
to have a guarantee which role a person has.
I think both can be addresses with the Privilege Management
infrastructure using attribute certificates, for the time being access
control providers misuse the identity certificate for giving privileges!

Where identity really is an issue, are those type of actions where in
real life you have to show your passport or similar paper or where a
handwritten signature is required.

I would claim that the LEVEL of trust is dependable of the SERVICE and
on which side of the service you are.
The current LEVEL of trust of access control solutions (established BY
the enterprise FOR the enterprise) has to be a little bit higher as the
username/password scheme has, for the user (employee) trust is a non
issue.
Access control solutions established by the enterprise for the public
have other requirements, here trust is really an issue.

I agree on some action about:
1. defining (attribute) certificate profiles for access control
2a. defining some sort of Attribute Authority or credential Service for
generating the certificates based on a identity certificate and taken
into account of the privacy wishes of the identity.
2b or defining some sort of gateway or proxy which can be fed by an
identity certificate and spits out some sort of other credential, based
on the identity's wishes.

And in my view, as I would build a pki for our domain, the origin of
this information is controlled by the identity, using his bare identity
certificate, which is as basic as can be. All the other attributes are
stored in the identity's corresponding ldap-entry using the same DN. One
of them could be the access control attribute (certificate), maybe one
want to generate this privilege on the fly.

I think identity certificates are usable as we do today, not for win2k
but who cares ;-)

btw the EU has released a eye-opening working document on privacy issues
on the Internet:
http://europa.eu.int/comm/internal_market/en/media/dataprot/wpdocs/index.htm

regards,
janus

Received: from prv-mail20.provo.novell.com (prv-mail20.provo.novell.com [137.65.81.122]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id IAA16375 for ; Tue, 9 Jan 2001 08:45:58 -0800 (PST)
Received: from INET-PRV-Message_Server by prv-mail20.provo.novell.com with Novell_GroupWise; Tue, 09 Jan 2001 09:50:23 -0700
Message-Id:
X-Mailer: Novell GroupWise Internet Agent 5.5.5.1
Date: Tue, 09 Jan 2001 09:50:18 -0700
From: "Bob Jueneman"
To: ,
Subject: Re: Basic Cert-2-Directory mapping question
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id IAA16376

>>>> "Anders Rundgren" 01/09/01 12:13AM >>>
>Guys!
>The response on this "basic" question has simply been overwhelming!
>
>Even if you can force CAs to obey certain rules regarding DNs, I still believe
>that this inability to use certificates created in "one regime", as credentials in
>another Win2K or NetWare "regime" calls for *some* kind of action.
>
>At least those who are into TTPs (commercial or not) should be interested.
>
>/anders
>

Anders, I won't attempt to speak for Microsoft -- Bill has more money than I
do, and can speak for himself.

But although I certainly share some of your frustration, it isn't clear as yet
that most of our customers have this problem, although perhaps we wish they
did.

Whether someone within the enterprise is trying to log on to Win2K, NetWare,
or our NDS/eDirectory, 95% to 99% of the time they are using access control
solutions established BY the enterprise FOR the enterprise.

In that type of closed environment, it simply doesn't matter all that much what
the directory schema or the PKI schema looks like, as they will be designed to
match each other.

Notice that this really isn't a "closed PKI" as Steve discusses -- it's even more closed
than that, because the access control is almost entirely within ONE enterprise,
and not multiple enterprises, much less the much broader retail consumer
or residentialPerson marketplace.

Now, I'm certainly not arguing that it wouldn't be interesting to talk about
extranet access control, and PKI-based authorizations that extend beyond the
boundaries of one organization. It would be interesting, and I and others have
been talking about that for what seems like eons.

But by and large, it isn't happening.

Is this, as some would claim, due to the fact that we haven't solved the directory
naming problem?

No, the problem is deeper than that.

The problem is one of TRUST.

And I would claim, with some regret, that PKI isn't about TRUST, it is about
IDENTITY.

Unfortunately, when it comes to making an access control decision, it isn't
sufficient to have a chain of certificate stretching back to some ubiquitous
issuer of low-cost certificates which attests to the fact that the holder of
a given private key is in fact cn="Village Idiot #13", even if he really is.

If I'm the system administrator, I don't care who someone IS, I want to
know what that person is permitted to DO.

At least at present, the way that people are controlling those decisions is to
pre-enroll that individual into an authoritative directory or database, and then
assign or share some secret with that individual which can be used to
authenticate that person as the same individual that was authorized, assuming
he hasn't shared that secret with someone else.

Granted, there are nuances of security and control, but the bottom line is
that it isn't the person's DN that matters, assuming that DN can be found
somehow. The only thing that really matters is the shared secret, and
the fact that the person who knows that secret has been granted certain
permissions or authority.

Whether that secret is a password, a private key, or some token device
is of secondary importance to the fact of pre-enrollment and the granting of
access authority.

So the lack of a universal naming solution, although irritating to those of us
in the profession, hasn't yet reach the point of being a crisis with our customers,
because those customers either don't allow external users into their system at
all, or they base their decisions on other things than identity, such as whether or
not the person has a valid credit card account, and it isn't maxed out.

Note that I have been talking exclusively about access control, and not
legally-binding transactions or other aspects of a more global use of PKI,
where identity may (someday) play a larger role. But even in that context,
I would claim that trust comes first, and is anchored by identity, and not
the other way around.

Regards,

Bob

Robert R. Jueneman
Security Architect
Novell, Inc. -- the leading provider of Net services software.

Received: from rom.antech.de (dns.antech.de [194.45.12.2]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA13881 for ; Tue, 9 Jan 2001 07:52:05 -0800 (PST)
Received: from scherbius.secorvo.de (kasiski.secorvo.de [194.45.12.203]) by rom.antech.de (8.9.3/8.9.3) with ESMTP id QAA13126; Tue, 9 Jan 2001 16:46:06 +0100
Message-Id: <[email-masked]>
From: "Stefan Kelm"
Organization: Secorvo Security Consulting GmbH
To: [email-masked], [email-masked]
Date: Tue, 9 Jan 2001 16:54:32 +0100
MIME-Version: 1.0
Content-type: text/plain; charset=US-ASCII
Content-transfer-encoding: 7BIT
Subject: Re: Basic Cert-2-Directory mapping question
Reply-to: [email-masked]
Priority: normal
In-reply-to: <[email-masked]>
X-mailer: Pegasus Mail for Win32 (v3.12b)

Peter,

> >finally, the IETF has had a standard means of encoding a DNS name as a DN for
> >several years, which suggests that there is at least one scheme that would
> >work.
>
> I assume you mean the RFC 2247 domainComponent? It's a nice theory, but since
> anyone who needs a URL/FQDN will use a GeneralName where it's available (which
> is in most cases when it's required) and where only a DN is available will
> stuff it into a CN like everyone else does and like everyone's software
> expects, I can't see it ever going beyond being a nice theory (I have a vague
> memory of actually having seen a solitary DC in a cert somewhere, but a quick
> check of my collection has failed to locate one... does anyone know of
> examples of these being used? How does the average third-party app handle
> them?).

we've used certificates with DC attributes (encoded as IA5STRING) with
customers. Needless to say that applications do have problems; most
will accept the certificates but will not display the full DN, esp.
not the DC attributes... :)

Cheers,

Stefan.

-------------------------------------------------------
Dipl.-Inform. Stefan Kelm
Security Consultant

Secorvo Security Consulting GmbH
Albert-Nestler-Strasse 9, D-76131 Karlsruhe

Tel. +49 721 6105-461, Fax +49 721 6105-455
E-Mail [email-masked], http://www.secorvo.de
-------------------------------------------------------
PGP Fingerprint 87AE E858 CCBC C3A2 E633 D139 B0D9 212B

Received: from ns.celocom.se ([email-masked] [212.209.40.66]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA12615 for ; Tue, 9 Jan 2001 07:44:25 -0800 (PST)
Received: by ns.celocom.se; id QAA12122; Tue, 9 Jan 2001 16:49:20 +0100 (CET)
Received: from unknown(10.10.10.1) by ns.celocom.se via smap (V5.0) id xma012102; Tue, 9 Jan 01 16:48:48 +0100
Received: from celocom.com (stan.celocom.se [10.10.10.129]) by zap.celocom.se (8.8.7/8.8.7) with ESMTP id QAA27903; Tue, 9 Jan 2001 16:48:47 +0100
Message-ID: <[email-masked]>
Date: Tue, 09 Jan 2001 16:48:47 +0100
From: Oscar Jacobsson
Organization: Celo Communications
X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Bob Jueneman
CC: [email-masked]
Subject: Re: Basic Cert-2-Directory mapping question
References:
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Bob Jueneman wrote:
> What we need, and have needed for ten years, is a STANDARD!

Apart from the fact that RFC 2377 is "only" Informational, are there any
perceived problems with the naming plan it proposes that I'm unaware of?
I should probably add that I've yet to attempt to implement an
infrastructure using this naming scheme yet. :-)

Cheers!

//oscar

Received: from prv-mail20.provo.novell.com (prv-mail20.provo.novell.com [137.65.81.122]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id HAA11168 for ; Tue, 9 Jan 2001 07:37:46 -0800 (PST)
Received: from INET-PRV-Message_Server by prv-mail20.provo.novell.com with Novell_GroupWise; Tue, 09 Jan 2001 08:42:10 -0700
Message-Id:
X-Mailer: Novell GroupWise Internet Agent 5.5.5.1
Date: Tue, 09 Jan 2001 08:42:03 -0700
From: "Bob Jueneman"
To: ,
Cc:
Subject: Re: Basic Cert-2-Directory mapping question
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id HAA11169

Peter, it's obvious that your talents are being wasted. You could easily
be the Michael Crichton of the PKI industry, and go on to fame and fortune.

I can see it now -- first a book, which lays out in layman's terms what ASN.1 is
really all about, then a mild little spin -- nothing too far fetched or provably wrong --
and then the story line commences. Suddenly, certificates are stretching
endlessly throughout all time, the inevitable consequence of "nonrepudiation"
being stretched, not too implausibly, both forwards and backwards.

Then the movie begins, with a subterranean bass that requires Dolby 5.1 and
at least 40,000 watts of powered subwoofer to do it justice. Without warning
(well, maybe a bit of Carnival of the Animals leitmotiv), an innocent MPEG movie
of a cat playing with its master, embedded in an antique certificate DN like a
mosquito in a bit of amber, is morphed back through time to the ancestral
saber-tooth tiger, devouring its prey in the carbonaceous (as opposed to
siliconaceous) Internet jungle, complete with T3 vines and monolithic (one rock)
servers.

Man, that ASN.1 is really, really powerful stuff! Who needs XML?!

Bob

>>> Peter Gutmann 01/09/01 08:35PM >>>
Stephen Kent writes:

>I think your analysis shows that we have a lot of folks playing CA who are
>not "qualified" to do so.

(Wibbly-wobbly effect, fade to shot of John Cleese being turned on
a spit by some nuns)
JOHN CLEESE: And now for something completely different...
(Fairly empty generic modern room. End entity being rushed into
the room on a dolly. PKI architects are flipping through
standards documents)
PKI ARCHITECT 1: commonName qualified with a serialNumber in the same RDN!
PKI ARCHITECT 2: firstName + surname + generationQualifier (if required) +
dnQualifier!
(Sysadmin enters and interrupts them)
SYSADMIN: The end entity is ready.
PKI ARCHITECT 1: Good, take her into the PKI frightening room.
SYSADMIN: Right.
PKI ARCHITECT 2: I say, it's a bit barren in here isn't it?
PKI ARCHITECT 1: Yes, more junk please sysadmin. The smart cards, the
Safekeyper, and the biometrics.
SYSADMIN: Yes, most certainly.
PKI ARCHITECT 1: And get the machine that issues certificates!
(Sysadmin wheels in a cart containing a PC which has "Intel
Inside" and "Designed for Microsoft Windows" stickers on it)
END ENTITY: What's that for?
PKI ARCHITECT 1: That's the machine that issues certificates
(Machine goes PING and pops up a "Save certificate as..." dialog)
PKI ARCHITECT 1: You see, that means the end entity has been certified!
PKI ARCHITECT 2: And that is the most expensive machine in the whole building!
PKI ARCHITECT 1: Yes, it cost over three quarters of a million pounds.
PKI ARCHITECT 2: Aren't you lucky?!
SYSADMIN: The CEO is here doctor.
PKI ARCHITECT 1: Switch everything on!
(Bleep... whirrr... bing... rumble rumble)
CEO: Ah very impressive, very impressive, and what are you doing
this morning?
PKI ARCHITECT 2: It is a certification.
CEO: Ahhh,.. and what sort of thing is that?
PKI ARCHITECT 2: Well, that's where we certify uncontestably and undeniably
that someone we've never met before who lives on the other
side of the planet and who we know only as a (possibly
forged) email address really is who they claim to be and can
be trusted to write good cheques, buy alcohol, sign
contracts, and run a dot-com selling PKI services.
CEO: Wonderful what you can do nowadays. (PING) Ahh, I see that
you have the machine that issues certificates. This is my
favorite. You see we leased it back from the company we sold
it to and that way it comes out of the monthly current budget
and not the capital account.
(Applause)
Thank you, thank you, we try to do our best, well do carry
on.
(CEO leaves)
PKI ARCHITECT 1: Lovely, lovely, jolly good, that's better, much much better.
PKI ARCHITECT 2: Yes, that's more like it.
PKI ARCHITECT 1: Uhh... still something missing though.
PKI ARCHITECT 1+2:END ENTITY!
PKI ARCHITECT 2: Yes, where's the end entity?
PKI ARCHITECT 1: Anyone seen the end entity?
SYSADMIN: Ahhh... here she is!
PKI ARCHITECT 1: Bring her over here.
PKI ARCHITECT 2: Mind the machine.
PKI ARCHITECT 1: Hello, now don't you worry.
PKI ARCHITECT 2: We'll soon have you certified!
PKI ARCHITECT 1: Leave it all to us, you'll never know what hit you.
END ENTITY: Will it be a nonRepudiation certificate?
PKI ARCHITECT 1: Now I think it's a little early to start imposing roles on it,
don't you? Now a word of advice, you may find that you
suffer for some time a totally irrational feeling of
depression, PKID as we call it. So, it's lots of happy pills
for you and you can find out all about the certification when
you get home. It's available on Betamax, VHS, and Super-8.
(Reporters and photographers enter the PKI frightening room)
PKI ARCHITECT 1: Who are you?
NOTARY PUBLIC: I am the end entity's notary public.
PKI ARCHITECT 1: I am sorry, only people involved are allowed in here.
END ENTITY: What do I do?
PKI ARCHITECT 2: Yes?
END ENTITY: What do I Do?
PKI ARCHITECT 2: Nothing dear, you're not "qualified"!
(Machine that issues certificates blue screens, camera zooms in to
reveal text that says "And now for something completely
different...")

Peter :-).

Received: from prv-mail20.provo.novell.com (prv-mail20.provo.novell.com [137.65.81.122]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id HAA07040 for ; Tue, 9 Jan 2001 07:12:15 -0800 (PST)
Received: from INET-PRV-Message_Server by prv-mail20.provo.novell.com with Novell_GroupWise; Tue, 09 Jan 2001 08:16:31 -0700
Message-Id:
X-Mailer: Novell GroupWise Internet Agent 5.5.5.1
Date: Tue, 09 Jan 2001 08:16:33 -0700
From: "Bob Jueneman"
To:
Cc:
Subject: Re: Basic Cert-2-Directory mapping question
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id HAA07043

John, as I said, I don't care much what the syntax is. I don't mean
to suggest that such details aren't important, but they wouldn't
make or break the Internet. There is a community of applications
(like browsers, etc.) that are used to dealing with URLs, but your
suggestion of a "super-top" class could also be made to work.

Your suggestion would also have the implicit implication (I guess that's
redundant) that the lower levels of the RDN tree are subordinate to,
and defined within, the top level directory., and that might be desirable.

What we need, and have needed for ten years, is a STANDARD!

Bob

Aside to David Kemp -- mail sent to your return address of
[email-masked] bounces with "User unknown".

>>> 01/09/01 07:32AM >>>

Bob,

Accepting the fact that the X.500 dream of a single global directory is not
going to happen any time soon, DNs can still be turned into globally
significant pointers into a federation of directories in the way you
suggest, but it doesn't require altering the DN syntax (and therefore
doesn't have to break existing implementations). All that's needed is a DN
attribute that names the particular directory within which the name
resides. e.g. instead of "c=us;..;cn=My Name" you'd have "dir=My
Directory;c=us;...;cn=My Name", where "My Directory" is the URL of a
directory access point.

John

"Bob Jueneman" on 01/08/2001 04:56:58 PM

To: ,
cc:
Subject: Re: Basic Cert-2-Directory mapping question

This has been a train wreck about the happen for nearly ten years.
It's like watching "The Fugitive" one still frame at a time. The NADF
tried to address this problem and gave up, and PKIX hasn't even tried.

To quote Pogo, "We have met the enemy, and they is us."

The first problem is not the DN -- that's secondary. As you correctly
state, the first problem is knowing the location of a directory service
provider that is supposed to contain the DN, so we can at least get
to the right point and start browsing around for a certificate.

I don't know that we need to name a Registration Point for a DN -- that
might get all tangled up in naming issues, who has the right to name
someone, etc.

What I proposed more than a year ago, and what I think you are in
essence saying, was that DNs in certificate should really be URLs,
in essentially the same fashion as CRLDistributionPoints are.

I don't particularly care what the exact syntax is -- something like

ldap://ldap.mycompany.com/c=us, ....cn="My Name"

would do just fine, I think, but I'll let other people debate that.

Once we finally locate the directory, then we can have all of the religious
arguments about my RDN schema vs. yours, and why yours is wrong and mine
is the only one that any right-thinking system administer could possibly
support, yada, yada, yada.

Unfortunately, since the contents of PKI certificates are generally viewed
as supposedly providing some degree of specificity with regard to a
geopolitical
identification and location of an end-entity, those schemas sometimes
conflict with
directory structures which are often organized around completely different
principles, such as more or less reflecting the network structure or
topology
or span of control issues.

But those issues, although certainly important, could reasonably be
resolved by
aliases, etc., no matter how painful But if a consumer of certificates
doesn't even
know where the directory can be found to start looking, then schema
problems
won't matter.

Regards,

Bob

Robert R. Jueneman
Security Architect
Novell, Inc. -- the leading provider of Net services software

>>> "David P. Kemp" 01/08/01 11:29AM >>>
Peter,

I thought what Anders asked was:
"given an arbitrary DN, how do I find a cert stored somewhere in an
arbitrary collection of independently-managed X.500 or LDAP directory
servers",

not:
"given an arbitrary DN, how do I fetch a cert which I already have a
copy of, stored on my own server."

It shouldn't be at all surprising that a db or ISAM store, with or
without an RDBMS layer above, and with or without a DAP or LDAP access
layer, is a reasonable way to store certs on your own machine. [1]
Developing a DN-schema-independent local retrieval mechanism is all
well and good, but it doesn't solve the registration problem, and as a
result, it doesn't help you to find a cert which you don't already
have.

The real problem with finding and using certs which are stored
elsewhere is the reverse of what you stated, namely:

cause: people fill DNs with whatever they like, and therefore
effect: those particular DN's don't work (i.e. they don't solve
Anders' question because they aren't valid addresses in
a global address space.)

Instead of saying "DN's don't work", with a footnote, it would
be more accurate to say "people choose not to use working DNs".

The Web works only because every Internet URL begins with
DNS-registered name. Something related to your third approach below,
requiring all certs and directories to use a standard DN registration
scheme, may be extraordinarily painful, but it's better than ad-hoc
workarounds using other certificate fields. If PKI consumers and
providers aren't willing to standardise within a global DN space, we
will have only islands of interoperability. [2]

Dave

[1] You could also just use the native filesystem, storing each cert
as a file in an RDN-based folder heirarchy or in a DN or hash(DN)-based
flat folder. This works as long as you keep secondary indices
synchronised with the folder contents, or if you don't need secondary
indices at all.

[2] Blue sky thought: it might be nice if there were a "Registration
Point (RP)" DN attribute which would be analogous to the hostname
portion of a URL. The RP attribute would be the first RDN of a
DN, and the RP value would be an OID identifying the registration
authority and the schema for the remainder of the DN. In principle,
this is no better (except for being less verbose) than current DNs, but
in practice OIDs are better managed - people actually choose to follow
OID registration procedures instead of just poaching in somebody else's
space.

> From: [email-masked] (Peter Gutmann)
>
> The main problem is that DN's don't work [0], so you end up with ones
which
> people have filled with whatever they feel like, odd things required by
cert
> profiles or signature laws or organisational constraints or whatever
which
> generally don't fit any known directory schema. The current approaches
to
> this problem if you're using a directory as a cert store are:
>
> - Continually update the directory schema to match any new DNs which
appear
> until the directory admin(s) go insane (hi Paul :-).
> - Create aliases in the directory mapping DNs in certs to the (fixed)
> directory schema.
> - Force all certs to use the schema used in the directory (someone
who's
> been through this one once described it to me as "extraordinarily
painful").
> - Use the directory DN to identify the cert owner and store the cert as
just
> another attribute, with the actual cert DN ignored.
> - (There may be more, since the whole thing is badly broken there are
> probably lots of workarounds being used. If anyone knows of others
> please let me know)
>
> A much better approach IMNSHO, and the one I look at in my paper, is to
treat
> the DN as a blob and hash it down to a fixed-length value which you use
as a
> key to look up the cert in an RDBMS or something like dbm if you don't
need
> the full RDBMS functionality [1]. This approach just plain works no
matter
> how garbled and broken the DN is.

Received: from po1.bbn.com (PO1.BBN.COM [192.1.50.38]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA06018 for ; Tue, 9 Jan 2001 06:39:53 -0800 (PST)
Received: from [171.78.30.107] (comsec.bbn.com [171.78.30.107]) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id JAA03605; Tue, 9 Jan 2001 09:44:46 -0500 (EST)
Mime-Version: 1.0
X-Sender: [email-masked]
Message-Id:
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]>
Date: Tue, 9 Jan 2001 09:37:25 -0500
To: "Anders Rundgren"
From: Stephen Kent
Subject: Re: Basic Cert-2-Directory mapping question
Cc: "PKIX-List"
Content-Type: text/plain; charset="us-ascii" ; format="flowed"

Anders,

>Guys!
>The response on this "basic" question has simply been overwhelming!
>
>Even if you can force CAs to obey certain rules regarding DNs, I still believe
>that this inability to use certificates created in "one regime", as
>credentials in
>another Win2K or NetWare "regime" calls for *some* kind of action.

Not necessarily. Personally, I'm comfortable having multiple certs
issued by different CAs, each authoritative for a distinct PKI.
Large, isolated PKIs are OK, if one has a clear plan for why they
will remain isolated. SET, though a failure in many respects, is a
good example of such an isolated PKI. Also, although we have not
mentioned it in this exchange, PKIX has the AIA extension, and will
add back the SIA extension, which provide explicit pointers to
directories once you have a target certificate, e.g., for retrieval
of CA certs and CRLs. Many security protocols provide an ability to
send certs as part of the protocol, which alleviates the need for
blind searching for certs.

>At least those who are into TTPs (commercial or not) should be interested.

yes, TTPs who argue for "one person, one cert" have an interest in
this issue, but that's not the only game in town, and if the problem
is mostly a directory issue, then the discussion belongs in a
directory WG, not in PKIX.

Steve

Received: from e23.nc.us.ibm.com (e23.nc.us.ibm.com [32.97.136.229]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA05359 for ; Tue, 9 Jan 2001 06:27:37 -0800 (PST)
Received: from southrelay02.raleigh.ibm.com (southrelay02.raleigh.ibm.com [9.37.3.209]) by e23.nc.us.ibm.com (8.9.3/8.9.3) with ESMTP id JAA48740; Tue, 9 Jan 2001 09:28:22 -0600
Received: from d04nm203.raleigh.ibm.com (d04nm203.raleigh.ibm.com [9.67.228.40]) by southrelay02.raleigh.ibm.com (8.8.8m3/NCO v4.95) with ESMTP id JAA21156; Tue, 9 Jan 2001 09:32:27 -0500
Importance: Normal
Subject: Re: [tf-lsd] Re: Basic Cert-2-Directory mapping question
To: [email-masked]
Cc: Anders Rundgren , [email-masked], [email-masked], [email-masked]
X-Mailer: Lotus Notes Release 5.0.3 (Intl) 21 March 2000
Message-ID:
From: "John McGarvey"
Date: Tue, 9 Jan 2001 09:30:08 -0500
X-MIMETrack: Serialize by Router on D04NM203/04/M/IBM(Release 5.0.3 (Intl)|21 March 2000) at 01/09/2001 09:32:27 AM
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii

Janus,
In describing the Microsoft case, you put your finger right on the problem.
There is no guarantee that the LDAP directory to be used by a given
application, and the CA that issues a certificate, adhere to the same
namespace rules or are administered by the same processes or people. So
the certificate DN may not correspond to any DN in the directory. This
problem will often occur in eBusiness or B2B applications, when the
certificates may be issued by well known public CAs, but the directory in
which policies, preferences, and whitepages information is stored is
maintained by a given enterprise or web hosting service. Also, there is no
guarantee that the DNs in the certificates uniquely identify the same
principal. Different well known CAs might use the same DN to describe
different principals.

If one is building a CA infrastructure and a directory infrastructure
together, of course one can make the certificate DNs match the LDAP DNs.
But, as it is often the case that the two are constructed separately, there
needs to be a means of mapping from one to the other.

Regards,
John McGarvey

Janus Liebregts @terena.nl on 2001/01/09
08:56:44 AM

Please respond to [email-masked]

Sent by: [email-masked]

To: Anders Rundgren
cc: [email-masked], [email-masked], [email-masked], "Bosch,
J.C.F.v.d."
Subject: [tf-lsd] Re: Basic Cert-2-Directory mapping question

Anders,

as far as we have tested: you can use certs using X.521 naming in a
win2k local authentication environment, the only restriction is that the
issuing-CA HAS to be a MS enterprise CA and thus has to use dc-naming
(in the current win2000-version).

janus

Anders Rundgren wrote:
>
> Janus,
> Unforntunately your certificates will not be useful for Win2K local
authentication
> due to this mapping problem. Does Novell offer a more flexible use of
> TTP-issued certificates without requiring the RP to use a 1-2-1 DN
> versus directory mapping?
>
> /anders
>
> > I fully agree with David.
> >
> > I don't agree that using a standard DN registration scheme, is
> > extraordinarily painful. Currently we, SURFnet (as the dutch National
> > Research Network) use two simple rules for our pki-domain (Higher
> > Education & Research):
> >
> > 1. only certify CA's using DN's as registered within our (LDAP)domain
> > using the rules of our Naming Authority.
> > 2. store CA-certificates & CRL's in the DN's (LDAP)entry as certified.
> >
> > with this we build our pki according to the ldap-namespace ACCORDING to
> > SURFnet. We claim to be the Naming Authority for the C=NL namespace...
> >
> > Probably every country & state have their own laws about naming
> > organisations, in Holland the Chambres of Commerce have such a
> > (delegated) task. Every country (C= or state c=US, ST=) should have
some
> > sort of naming authority and name-registration is already taken place.
> > But how to make available these authorative Naming databases in a
(LDAP)
> > way, to be the authorative name for certification....
> >
> > For our community we have made available a pki-ldap cookbook which
> > describes a method how to organise your DIT and how to store
pki-related
> > material http://ldap.gigacorp.nl/pkildap.html
> >
> > Janus Liebregts
> > SURFnet
> >
> >
> >
> >
> > "David P. Kemp" wrote:
> > >
> > > Peter,
> > >
> > > I thought what Anders asked was:
> > > "given an arbitrary DN, how do I find a cert stored somewhere in an
> > > arbitrary collection of independently-managed X.500 or LDAP
directory
> > > servers",
> > >
> > > not:
> > > "given an arbitrary DN, how do I fetch a cert which I already have
a
> > > copy of, stored on my own server."
> > >
> > > It shouldn't be at all surprising that a db or ISAM store, with or
> > > without an RDBMS layer above, and with or without a DAP or LDAP
access
> > > layer, is a reasonable way to store certs on your own machine. [1]
> > > Developing a DN-schema-independent local retrieval mechanism is all
> > > well and good, but it doesn't solve the registration problem, and as
a
> > > result, it doesn't help you to find a cert which you don't already
> > > have.
> > >
> > > The real problem with finding and using certs which are stored
> > > elsewhere is the reverse of what you stated, namely:
> > >
> > > cause: people fill DNs with whatever they like, and therefore
> > > effect: those particular DN's don't work (i.e. they don't solve
> > > Anders' question because they aren't valid addresses in
> > > a global address space.)
> > >
> > > Instead of saying "DN's don't work", with a footnote, it would
> > > be more accurate to say "people choose not to use working DNs".
> > >
> > > The Web works only because every Internet URL begins with
> > > DNS-registered name. Something related to your third approach below,
> > > requiring all certs and directories to use a standard DN registration
> > > scheme, may be extraordinarily painful, but it's better than ad-hoc
> > > workarounds using other certificate fields. If PKI consumers and
> > > providers aren't willing to standardise within a global DN space, we
> > > will have only islands of interoperability. [2]
> > >
> > > Dave
> > >
> > > [1] You could also just use the native filesystem, storing each cert
> > > as a file in an RDN-based folder heirarchy or in a DN or hash(DN)
-based
> > > flat folder. This works as long as you keep secondary indices
> > > synchronised with the folder contents, or if you don't need secondary
> > > indices at all.
> > >
> > > [2] Blue sky thought: it might be nice if there were a "Registration
> > > Point (RP)" DN attribute which would be analogous to the hostname
> > > portion of a URL. The RP attribute would be the first RDN of a
> > > DN, and the RP value would be an OID identifying the registration
> > > authority and the schema for the remainder of the DN. In principle,
> > > this is no better (except for being less verbose) than current DNs,
but
> > > in practice OIDs are better managed - people actually choose to
follow
> > > OID registration procedures instead of just poaching in somebody
else's
> > > space.
> > >
> > > > From: [email-masked] (Peter Gutmann)
> > > >
> > > > The main problem is that DN's don't work [0], so you end up with
ones which
> > > > people have filled with whatever they feel like, odd things
required by cert
> > > > profiles or signature laws or organisational constraints or
whatever which
> > > > generally don't fit any known directory schema. The current
approaches to
> > > > this problem if you're using a directory as a cert store are:
> > > >
> > > > - Continually update the directory schema to match any new DNs
which appear
> > > > until the directory admin(s) go insane (hi Paul :-).
> > > > - Create aliases in the directory mapping DNs in certs to the
(fixed)
> > > > directory schema.
> > > > - Force all certs to use the schema used in the directory
(someone who's
> > > > been through this one once described it to me as
"extraordinarily
> > > painful").
> > > > - Use the directory DN to identify the cert owner and store the
cert as just
> > > > another attribute, with the actual cert DN ignored.
> > > > - (There may be more, since the whole thing is badly broken there
are
> > > > probably lots of workarounds being used. If anyone knows of
others
> > > > please let me know)
> > > >
> > > > A much better approach IMNSHO, and the one I look at in my paper,
is to treat
> > > > the DN as a blob and hash it down to a fixed-length value which you
use as a
> > > > key to look up the cert in an RDBMS or something like dbm if you
don't need
> > > > the full RDBMS functionality [1]. This approach just plain works
no matter
> > > > how garbled and broken the DN is.

Received: from arista.iris.com (arista.iris.com [198.112.211.42]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA05306 for ; Tue, 9 Jan 2001 06:27:26 -0800 (PST)
From: [email-masked]
Subject: Re: Basic Cert-2-Directory mapping question
To: "Bob Jueneman"
Cc: ,
X-Mailer: Lotus Notes Release 5.0.2c February 2, 2000
Message-ID:
Date: Tue, 9 Jan 2001 09:32:03 -0500
X-MIMETrack: Serialize by Router on Arista/Iris(Build V505_07112000 |July 11, 2000) at 01/09/2001 09:36:56 AM
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii

Bob,

Accepting the fact that the X.500 dream of a single global directory is not
going to happen any time soon, DNs can still be turned into globally
significant pointers into a federation of directories in the way you
suggest, but it doesn't require altering the DN syntax (and therefore
doesn't have to break existing implementations). All that's needed is a DN
attribute that names the particular directory within which the name
resides. e.g. instead of "c=us;..;cn=My Name" you'd have "dir=My
Directory;c=us;...;cn=My Name", where "My Directory" is the URL of a
directory access point.

John

"Bob Jueneman" on 01/08/2001 04:56:58 PM

To: ,
cc:
Subject: Re: Basic Cert-2-Directory mapping question

This has been a train wreck about the happen for nearly ten years.
It's like watching "The Fugitive" one still frame at a time. The NADF
tried to address this problem and gave up, and PKIX hasn't even tried.

To quote Pogo, "We have met the enemy, and they is us."

The first problem is not the DN -- that's secondary. As you correctly
state, the first problem is knowing the location of a directory service
provider that is supposed to contain the DN, so we can at least get
to the right point and start browsing around for a certificate.

I don't know that we need to name a Registration Point for a DN -- that
might get all tangled up in naming issues, who has the right to name
someone, etc.

What I proposed more than a year ago, and what I think you are in
essence saying, was that DNs in certificate should really be URLs,
in essentially the same fashion as CRLDistributionPoints are.

I don't particularly care what the exact syntax is -- something like

ldap://ldap.mycompany.com/c=us, ....cn="My Name"

would do just fine, I think, but I'll let other people debate that.

Once we finally locate the directory, then we can have all of the religious
arguments about my RDN schema vs. yours, and why yours is wrong and mine
is the only one that any right-thinking system administer could possibly
support, yada, yada, yada.

Unfortunately, since the contents of PKI certificates are generally viewed
as supposedly providing some degree of specificity with regard to a
geopolitical
identification and location of an end-entity, those schemas sometimes
conflict with
directory structures which are often organized around completely different
principles, such as more or less reflecting the network structure or
topology
or span of control issues.

But those issues, although certainly important, could reasonably be
resolved by
aliases, etc., no matter how painful But if a consumer of certificates
doesn't even
know where the directory can be found to start looking, then schema
problems
won't matter.

Regards,

Bob

Robert R. Jueneman
Security Architect
Novell, Inc. -- the leading provider of Net services software

>>> "David P. Kemp" 01/08/01 11:29AM >>>
Peter,

I thought what Anders asked was:
"given an arbitrary DN, how do I find a cert stored somewhere in an
arbitrary collection of independently-managed X.500 or LDAP directory
servers",

not:
"given an arbitrary DN, how do I fetch a cert which I already have a
copy of, stored on my own server."

It shouldn't be at all surprising that a db or ISAM store, with or
without an RDBMS layer above, and with or without a DAP or LDAP access
layer, is a reasonable way to store certs on your own machine. [1]
Developing a DN-schema-independent local retrieval mechanism is all
well and good, but it doesn't solve the registration problem, and as a
result, it doesn't help you to find a cert which you don't already
have.

The real problem with finding and using certs which are stored
elsewhere is the reverse of what you stated, namely:

cause: people fill DNs with whatever they like, and therefore
effect: those particular DN's don't work (i.e. they don't solve
Anders' question because they aren't valid addresses in
a global address space.)

Instead of saying "DN's don't work", with a footnote, it would
be more accurate to say "people choose not to use working DNs".

The Web works only because every Internet URL begins with
DNS-registered name. Something related to your third approach below,
requiring all certs and directories to use a standard DN registration
scheme, may be extraordinarily painful, but it's better than ad-hoc
workarounds using other certificate fields. If PKI consumers and
providers aren't willing to standardise within a global DN space, we
will have only islands of interoperability. [2]

Dave

[1] You could also just use the native filesystem, storing each cert
as a file in an RDN-based folder heirarchy or in a DN or hash(DN)-based
flat folder. This works as long as you keep secondary indices
synchronised with the folder contents, or if you don't need secondary
indices at all.

[2] Blue sky thought: it might be nice if there were a "Registration
Point (RP)" DN attribute which would be analogous to the hostname
portion of a URL. The RP attribute would be the first RDN of a
DN, and the RP value would be an OID identifying the registration
authority and the schema for the remainder of the DN. In principle,
this is no better (except for being less verbose) than current DNs, but
in practice OIDs are better managed - people actually choose to follow
OID registration procedures instead of just poaching in somebody else's
space.

> From: [email-masked] (Peter Gutmann)
>
> The main problem is that DN's don't work [0], so you end up with ones
which
> people have filled with whatever they feel like, odd things required by
cert
> profiles or signature laws or organisational constraints or whatever
which
> generally don't fit any known directory schema. The current approaches
to
> this problem if you're using a directory as a cert store are:
>
> - Continually update the directory schema to match any new DNs which
appear
> until the directory admin(s) go insane (hi Paul :-).
> - Create aliases in the directory mapping DNs in certs to the (fixed)
> directory schema.
> - Force all certs to use the schema used in the directory (someone
who's
> been through this one once described it to me as "extraordinarily
painful").
> - Use the directory DN to identify the cert owner and store the cert as
just
> another attribute, with the actual cert DN ignored.
> - (There may be more, since the whole thing is badly broken there are
> probably lots of workarounds being used. If anyone knows of others
> please let me know)
>
> A much better approach IMNSHO, and the one I look at in my paper, is to
treat
> the DN as a blob and hash it down to a fixed-length value which you use
as a
> key to look up the cert in an RDBMS or something like dbm if you don't
need
> the full RDBMS functionality [1]. This approach just plain works no
matter
> how garbled and broken the DN is.

Received: from survis.surfnet.nl (survis.surfnet.nl [192.87.108.3]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA04973 for ; Tue, 9 Jan 2001 06:22:53 -0800 (PST)
Received: from zuurtje.surfnet.nl ([192.87.109.5]) by survis.surfnet.nl with ESMTP (exPP) id 14Fzkb-00007h-00; Tue, 9 Jan 2001 15:27:49 +0100
Received: from surfnet.nl (janus1.sec.nl [192.87.109.32]) by zuurtje.surfnet.nl (8.9.3/8.9.3/ZUURTJE-0.8) with ESMTP id PAA02184; Tue, 9 Jan 2001 15:27:48 +0100 (MET)
Message-ID: <[email-masked]>
Date: Tue, 09 Jan 2001 15:30:32 +0100
From: Janus Liebregts
Organization: SURFnet bv
X-Mailer: Mozilla 4.7 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Bob Jueneman
CC: [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Re: Basic Cert-2-Directory mapping question
References:
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Bob,

every country has its own monopoly on local law, every country has a tax
department which have to distinguish which company and which citizen has
to pay tax.

There should be some sort of distinguishing between companies and
citizens done by authorities. Mapping of names, which can be used under
this law, has to be done in every country.

I think the problem is really simple, you can use a name not recognized
by your law, but one of the CA's in your pki-hierarchy has to give some
guarantee of this CA is operating under a CPS AND a certain law to be
trustworthy. Some kind of company or citizen has to provide this
guarantee. How do you sue a CSP if you don't know under which identity
(recognized by some law) he operates?

This is a main issue when doing business using pki-technology in between
2 or more legal systems.

janus

Bob Jueneman wrote:
>
> Unfortunately, the model you cite, with naming authorities that
> are truly authoritative, and in addition a monopoly, is in fact NOT the
> case the United States, and in a number of other countries in the
> world as well.
>
> If the government decrees what DNs are allowable, and perhaps where
> they have to be stored, then the problem is certainly simplified.
> Unfortunately, usually isn't the case.
>
> Bob
>
> >>> Janus Liebregts 01/08/01 01:36PM >>>
> I fully agree with David.
>
> I don't agree that using a standard DN registration scheme, is
> extraordinarily painful. Currently we, SURFnet (as the dutch National
> Research Network) use two simple rules for our pki-domain (Higher
> Education & Research):
>
> 1. only certify CA's using DN's as registered within our (LDAP)domain
> using the rules of our Naming Authority.
> 2. store CA-certificates & CRL's in the DN's (LDAP)entry as certified.
>
> with this we build our pki according to the ldap-namespace ACCORDING to
> SURFnet. We claim to be the Naming Authority for the C=NL namespace...
>
> Probably every country & state have their own laws about naming
> organisations, in Holland the Chambres of Commerce have such a
> (delegated) task. Every country (C= or state c=US, ST=) should have some
> sort of naming authority and name-registration is already taken place.
> But how to make available these authorative Naming databases in a (LDAP)
> way, to be the authorative name for certification....
>
> For our community we have made available a pki-ldap cookbook which
> describes a method how to organise your DIT and how to store pki-related
> material http://ldap.gigacorp.nl/pkildap.html
>
> Janus Liebregts
> SURFnet
>
> "David P. Kemp" wrote:
> >
> > Peter,
> >
> > I thought what Anders asked was:
> > "given an arbitrary DN, how do I find a cert stored somewhere in an
> > arbitrary collection of independently-managed X.500 or LDAP directory
> > servers",
> >
> > not:
> > "given an arbitrary DN, how do I fetch a cert which I already have a
> > copy of, stored on my own server."
> >
> > It shouldn't be at all surprising that a db or ISAM store, with or
> > without an RDBMS layer above, and with or without a DAP or LDAP access
> > layer, is a reasonable way to store certs on your own machine. [1]
> > Developing a DN-schema-independent local retrieval mechanism is all
> > well and good, but it doesn't solve the registration problem, and as a
> > result, it doesn't help you to find a cert which you don't already
> > have.
> >
> > The real problem with finding and using certs which are stored
> > elsewhere is the reverse of what you stated, namely:
> >
> > cause: people fill DNs with whatever they like, and therefore
> > effect: those particular DN's don't work (i.e. they don't solve
> > Anders' question because they aren't valid addresses in
> > a global address space.)
> >
> > Instead of saying "DN's don't work", with a footnote, it would
> > be more accurate to say "people choose not to use working DNs".
> >
> > The Web works only because every Internet URL begins with
> > DNS-registered name. Something related to your third approach below,
> > requiring all certs and directories to use a standard DN registration
> > scheme, may be extraordinarily painful, but it's better than ad-hoc
> > workarounds using other certificate fields. If PKI consumers and
> > providers aren't willing to standardise within a global DN space, we
> > will have only islands of interoperability. [2]
> >
> > Dave
> >
> > [1] You could also just use the native filesystem, storing each cert
> > as a file in an RDN-based folder heirarchy or in a DN or hash(DN)-based
> > flat folder. This works as long as you keep secondary indices
> > synchronised with the folder contents, or if you don't need secondary
> > indices at all.
> >
> > [2] Blue sky thought: it might be nice if there were a "Registration
> > Point (RP)" DN attribute which would be analogous to the hostname
> > portion of a URL. The RP attribute would be the first RDN of a
> > DN, and the RP value would be an OID identifying the registration
> > authority and the schema for the remainder of the DN. In principle,
> > this is no better (except for being less verbose) than current DNs, but
> > in practice OIDs are better managed - people actually choose to follow
> > OID registration procedures instead of just poaching in somebody else's
> > space.
> >
> > > From: [email-masked] (Peter Gutmann)
> > >
> > > The main problem is that DN's don't work [0], so you end up with ones which
> > > people have filled with whatever they feel like, odd things required by cert
> > > profiles or signature laws or organisational constraints or whatever which
> > > generally don't fit any known directory schema. The current approaches to
> > > this problem if you're using a directory as a cert store are:
> > >
> > > - Continually update the directory schema to match any new DNs which appear
> > > until the directory admin(s) go insane (hi Paul :-).
> > > - Create aliases in the directory mapping DNs in certs to the (fixed)
> > > directory schema.
> > > - Force all certs to use the schema used in the directory (someone who's
> > > been through this one once described it to me as "extraordinarily
> > painful").
> > > - Use the directory DN to identify the cert owner and store the cert as just
> > > another attribute, with the actual cert DN ignored.
> > > - (There may be more, since the whole thing is badly broken there are
> > > probably lots of workarounds being used. If anyone knows of others
> > > please let me know)
> > >
> > > A much better approach IMNSHO, and the one I look at in my paper, is to treat
> > > the DN as a blob and hash it down to a fixed-length value which you use as a
> > > key to look up the cert in an RDBMS or something like dbm if you don't need
> > > the full RDBMS functionality [1]. This approach just plain works no matter
> > > how garbled and broken the DN is.

Received: from survis.surfnet.nl (survis.surfnet.nl [192.87.108.3]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id FAA02654 for ; Tue, 9 Jan 2001 05:49:05 -0800 (PST)
Received: from zuurtje.surfnet.nl ([192.87.109.5]) by survis.surfnet.nl with ESMTP (exPP) id 14FzDt-00000V-00; Tue, 9 Jan 2001 14:54:01 +0100
Received: from surfnet.nl (janus1.sec.nl [192.87.109.32]) by zuurtje.surfnet.nl (8.9.3/8.9.3/ZUURTJE-0.8) with ESMTP id OAA12223; Tue, 9 Jan 2001 14:54:00 +0100 (MET)
Message-ID: <[email-masked]>
Date: Tue, 09 Jan 2001 14:56:44 +0100
From: Janus Liebregts
Organization: SURFnet bv
X-Mailer: Mozilla 4.7 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Anders Rundgren
CC: [email-masked], [email-masked], [email-masked], "Bosch, J.C.F.v.d."
Subject: Re: Basic Cert-2-Directory mapping question
References: <[email-masked]> <[email-masked]> <[email-masked]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Anders,

as far as we have tested: you can use certs using X.521 naming in a
win2k local authentication environment, the only restriction is that the
issuing-CA HAS to be a MS enterprise CA and thus has to use dc-naming
(in the current win2000-version).

janus

Anders Rundgren wrote:
>
> Janus,
> Unforntunately your certificates will not be useful for Win2K local authentication
> due to this mapping problem. Does Novell offer a more flexible use of
> TTP-issued certificates without requiring the RP to use a 1-2-1 DN
> versus directory mapping?
>
> /anders
>
> > I fully agree with David.
> >
> > I don't agree that using a standard DN registration scheme, is
> > extraordinarily painful. Currently we, SURFnet (as the dutch National
> > Research Network) use two simple rules for our pki-domain (Higher
> > Education & Research):
> >
> > 1. only certify CA's using DN's as registered within our (LDAP)domain
> > using the rules of our Naming Authority.
> > 2. store CA-certificates & CRL's in the DN's (LDAP)entry as certified.
> >
> > with this we build our pki according to the ldap-namespace ACCORDING to
> > SURFnet. We claim to be the Naming Authority for the C=NL namespace...
> >
> > Probably every country & state have their own laws about naming
> > organisations, in Holland the Chambres of Commerce have such a
> > (delegated) task. Every country (C= or state c=US, ST=) should have some
> > sort of naming authority and name-registration is already taken place.
> > But how to make available these authorative Naming databases in a (LDAP)
> > way, to be the authorative name for certification....
> >
> > For our community we have made available a pki-ldap cookbook which
> > describes a method how to organise your DIT and how to store pki-related
> > material http://ldap.gigacorp.nl/pkildap.html
> >
> > Janus Liebregts
> > SURFnet
> >
> >
> >
> >
> > "David P. Kemp" wrote:
> > >
> > > Peter,
> > >
> > > I thought what Anders asked was:
> > > "given an arbitrary DN, how do I find a cert stored somewhere in an
> > > arbitrary collection of independently-managed X.500 or LDAP directory
> > > servers",
> > >
> > > not:
> > > "given an arbitrary DN, how do I fetch a cert which I already have a
> > > copy of, stored on my own server."
> > >
> > > It shouldn't be at all surprising that a db or ISAM store, with or
> > > without an RDBMS layer above, and with or without a DAP or LDAP access
> > > layer, is a reasonable way to store certs on your own machine. [1]
> > > Developing a DN-schema-independent local retrieval mechanism is all
> > > well and good, but it doesn't solve the registration problem, and as a
> > > result, it doesn't help you to find a cert which you don't already
> > > have.
> > >
> > > The real problem with finding and using certs which are stored
> > > elsewhere is the reverse of what you stated, namely:
> > >
> > > cause: people fill DNs with whatever they like, and therefore
> > > effect: those particular DN's don't work (i.e. they don't solve
> > > Anders' question because they aren't valid addresses in
> > > a global address space.)
> > >
> > > Instead of saying "DN's don't work", with a footnote, it would
> > > be more accurate to say "people choose not to use working DNs".
> > >
> > > The Web works only because every Internet URL begins with
> > > DNS-registered name. Something related to your third approach below,
> > > requiring all certs and directories to use a standard DN registration
> > > scheme, may be extraordinarily painful, but it's better than ad-hoc
> > > workarounds using other certificate fields. If PKI consumers and
> > > providers aren't willing to standardise within a global DN space, we
> > > will have only islands of interoperability. [2]
> > >
> > > Dave
> > >
> > > [1] You could also just use the native filesystem, storing each cert
> > > as a file in an RDN-based folder heirarchy or in a DN or hash(DN)-based
> > > flat folder. This works as long as you keep secondary indices
> > > synchronised with the folder contents, or if you don't need secondary
> > > indices at all.
> > >
> > > [2] Blue sky thought: it might be nice if there were a "Registration
> > > Point (RP)" DN attribute which would be analogous to the hostname
> > > portion of a URL. The RP attribute would be the first RDN of a
> > > DN, and the RP value would be an OID identifying the registration
> > > authority and the schema for the remainder of the DN. In principle,
> > > this is no better (except for being less verbose) than current DNs, but
> > > in practice OIDs are better managed - people actually choose to follow
> > > OID registration procedures instead of just poaching in somebody else's
> > > space.
> > >
> > > > From: [email-masked] (Peter Gutmann)
> > > >
> > > > The main problem is that DN's don't work [0], so you end up with ones which
> > > > people have filled with whatever they feel like, odd things required by cert
> > > > profiles or signature laws or organisational constraints or whatever which
> > > > generally don't fit any known directory schema. The current approaches to
> > > > this problem if you're using a directory as a cert store are:
> > > >
> > > > - Continually update the directory schema to match any new DNs which appear
> > > > until the directory admin(s) go insane (hi Paul :-).
> > > > - Create aliases in the directory mapping DNs in certs to the (fixed)
> > > > directory schema.
> > > > - Force all certs to use the schema used in the directory (someone who's
> > > > been through this one once described it to me as "extraordinarily
> > > painful").
> > > > - Use the directory DN to identify the cert owner and store the cert as just
> > > > another attribute, with the actual cert DN ignored.
> > > > - (There may be more, since the whole thing is badly broken there are
> > > > probably lots of workarounds being used. If anyone knows of others
> > > > please let me know)
> > > >
> > > > A much better approach IMNSHO, and the one I look at in my paper, is to treat
> > > > the DN as a blob and hash it down to a fixed-length value which you use as a
> > > > key to look up the cert in an RDBMS or something like dbm if you don't need
> > > > the full RDBMS functionality [1]. This approach just plain works no matter
> > > > how garbled and broken the DN is.

Received: from ns.celocom.se ([email-masked] [212.209.40.66]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id CAA17869 for ; Tue, 9 Jan 2001 02:22:28 -0800 (PST)
Received: by ns.celocom.se; id LAA07121; Tue, 9 Jan 2001 11:27:19 +0100 (CET)
Received: from unknown(10.10.10.1) by ns.celocom.se via smap (V5.0) id xma007115; Tue, 9 Jan 01 11:27:12 +0100
Received: from celocom.com (stan.celocom.se [10.10.10.129]) by zap.celocom.se (8.8.7/8.8.7) with ESMTP id LAA22577; Tue, 9 Jan 2001 11:27:11 +0100
Message-ID: <[email-masked]>
Date: Tue, 09 Jan 2001 11:27:10 +0100
From: Oscar Jacobsson
Organization: Celo Communications
X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Tim Polk
CC: [email-masked]
Subject: Re: WG Last Call, PKI Repository Locator
References: <[email-masked]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Tim Polk wrote:
> As most of you know, there is no requirement for a WG Last Call for
> experimental RFCs. However, this specification has been through only a
> single draft, and has drawn a very small number of comments. I am hoping
> that a Last Call will prompt some of you to review the specification.

I'm afraid I seem to have missed the previous batch of comments, and was
wondering if you might help me clear out a minor niggle or two.

The repository locator draft and RFC 2782 seem to refer to different
layers of protocols. Where 2782 refers to protocols in the transport
layer, such as TCP, UDP, etc. the draft apparently uses application
layer protocols like HTTP, LDAP, and OCSP. These application layer
protocols are referred to as services by RFC 2782, where the draft in
stead uses the name "PKIXREP".

I assume the intention is to differentiate between generic directory or
web services and PKI repositories, but would it in such a case not be
more prudent to restrict the usage of PKIX defined names to just
services instead of both to services and protocols. This could be
accomplished, say, by defining the service definitions "PKIXHTTP",
"PKIXLDAP", and "PKIXOCSP", which compliant applications could then
query at their leisure.

Granted, it *is* perfectly possible to employ both RFC 2782 and the
locator draft schemes independently to indicate the same directory or
web server, but I was curios about these apparent discrepancies between
the two documents and was wondering if anybody would care to explain the
reasoning behind it to me.

Thanks in advance,

//oscar

Received: from mail.ec.auckland.ac.nz (mail.student.auckland.ac.nz [130.216.35.201]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id XAA26807 for ; Mon, 8 Jan 2001 23:30:23 -0800 (PST)
Received: from kahu.cs.auckland.ac.nz ([email-masked] [130.216.36.13]) by mail.ec.auckland.ac.nz (8.9.3/8.8.6/cs-master) with SMTP id UAA01017; Tue, 9 Jan 2001 20:35:17 +1300 (NZDT) (sender [email-masked])
Received: by kahu.cs.auckland.ac.nz (relaymail v0.9) id <97902571718933>; Tue, 9 Jan 2001 20:35:17 (NZDT)
From: [email-masked] (Peter Gutmann)
To: [email-masked]
Subject: Re: Basic Cert-2-Directory mapping question
Cc: [email-masked]
Sender: [email-masked]
Reply-To: [email-masked]
X-Charge-To: pgut001
X-Authenticated: relaymail v0.9 on kahu.cs.auckland.ac.nz
Date: Tue, 9 Jan 2001 20:35:17 (NZDT)
Message-ID: <[email-masked]>

Stephen Kent writes:

>I think your analysis shows that we have a lot of folks playing CA who are
>not "qualified" to do so.

(Wibbly-wobbly effect, fade to shot of John Cleese being turned on
a spit by some nuns)
JOHN CLEESE: And now for something completely different...
(Fairly empty generic modern room. End entity being rushed into
the room on a dolly. PKI architects are flipping through
standards documents)
PKI ARCHITECT 1: commonName qualified with a serialNumber in the same RDN!
PKI ARCHITECT 2: firstName + surname + generationQualifier (if required) +
dnQualifier!
(Sysadmin enters and interrupts them)
SYSADMIN: The end entity is ready.
PKI ARCHITECT 1: Good, take her into the PKI frightening room.
SYSADMIN: Right.
PKI ARCHITECT 2: I say, it's a bit barren in here isn't it?
PKI ARCHITECT 1: Yes, more junk please sysadmin. The smart cards, the
Safekeyper, and the biometrics.
SYSADMIN: Yes, most certainly.
PKI ARCHITECT 1: And get the machine that issues certificates!
(Sysadmin wheels in a cart containing a PC which has "Intel
Inside" and "Designed for Microsoft Windows" stickers on it)
END ENTITY: What's that for?
PKI ARCHITECT 1: That's the machine that issues certificates
(Machine goes PING and pops up a "Save certificate as..." dialog)
PKI ARCHITECT 1: You see, that means the end entity has been certified!
PKI ARCHITECT 2: And that is the most expensive machine in the whole building!
PKI ARCHITECT 1: Yes, it cost over three quarters of a million pounds.
PKI ARCHITECT 2: Aren't you lucky?!
SYSADMIN: The CEO is here doctor.
PKI ARCHITECT 1: Switch everything on!
(Bleep... whirrr... bing... rumble rumble)
CEO: Ah very impressive, very impressive, and what are you doing
this morning?
PKI ARCHITECT 2: It is a certification.
CEO: Ahhh,.. and what sort of thing is that?
PKI ARCHITECT 2: Well, that's where we certify uncontestably and undeniably
that someone we've never met before who lives on the other
side of the planet and who we know only as a (possibly
forged) email address really is who they claim to be and can
be trusted to write good cheques, buy alcohol, sign
contracts, and run a dot-com selling PKI services.
CEO: Wonderful what you can do nowadays. (PING) Ahh, I see that
you have the machine that issues certificates. This is my
favorite. You see we leased it back from the company we sold
it to and that way it comes out of the monthly current budget
and not the capital account.
(Applause)
Thank you, thank you, we try to do our best, well do carry
on.
(CEO leaves)
PKI ARCHITECT 1: Lovely, lovely, jolly good, that's better, much much better.
PKI ARCHITECT 2: Yes, that's more like it.
PKI ARCHITECT 1: Uhh... still something missing though.
PKI ARCHITECT 1+2:END ENTITY!
PKI ARCHITECT 2: Yes, where's the end entity?
PKI ARCHITECT 1: Anyone seen the end entity?
SYSADMIN: Ahhh... here she is!
PKI ARCHITECT 1: Bring her over here.
PKI ARCHITECT 2: Mind the machine.
PKI ARCHITECT 1: Hello, now don't you worry.
PKI ARCHITECT 2: We'll soon have you certified!
PKI ARCHITECT 1: Leave it all to us, you'll never know what hit you.
END ENTITY: Will it be a nonRepudiation certificate?
PKI ARCHITECT 1: Now I think it's a little early to start imposing roles on it,
don't you? Now a word of advice, you may find that you
suffer for some time a totally irrational feeling of
depression, PKID as we call it. So, it's lots of happy pills
for you and you can find out all about the certification when
you get home. It's available on Betamax, VHS, and Super-8.
(Reporters and photographers enter the PKI frightening room)
PKI ARCHITECT 1: Who are you?
NOTARY PUBLIC: I am the end entity's notary public.
PKI ARCHITECT 1: I am sorry, only people involved are allowed in here.
END ENTITY: What do I do?
PKI ARCHITECT 2: Yes?
END ENTITY: What do I Do?
PKI ARCHITECT 2: Nothing dear, you're not "qualified"!
(Machine that issues certificates blue screens, camera zooms in to
reveal text that says "And now for something completely
different...")

Peter :-).

Received: from mailc.telia.com (mailc.telia.com [194.22.190.4]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id XAA23044 for ; Mon, 8 Jan 2001 23:10:27 -0800 (PST)
Received: from d1o69.telia.com (d1o69.telia.com [62.20.144.241]) by mailc.telia.com (8.11.0/8.11.0) with ESMTP id f097FK415902; Tue, 9 Jan 2001 08:15:20 +0100 (CET)
Received: from mega (t4o69p44.telia.com [62.20.145.164]) by d1o69.telia.com (8.10.2/8.10.1) with SMTP id f097FJl01366; Tue, 9 Jan 2001 08:15:19 +0100 (CET)
Message-ID: <[email-masked]>
From: "Anders Rundgren"
To: "Bob Jueneman" , , "Stephen Kent" , "PKIX-List"
References: <[email-masked]>
Subject: Re: Basic Cert-2-Directory mapping question
Date: Tue, 9 Jan 2001 08:13:43 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
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
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id XAA23048

Guys!
The response on this "basic" question has simply been overwhelming!

Even if you can force CAs to obey certain rules regarding DNs, I still believe
that this inability to use certificates created in "one regime", as credentials in
another Win2K or NetWare "regime" calls for *some* kind of action.

At least those who are into TTPs (commercial or not) should be interested.

/anders

Received: from po1.bbn.com (PO1.BBN.COM [192.1.50.38]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id QAA11766 for ; Mon, 8 Jan 2001 16:02:50 -0800 (PST)
Received: from [171.78.30.107] (comsec.bbn.com [171.78.30.107]) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id TAA19078; Mon, 8 Jan 2001 19:07:20 -0500 (EST)
Mime-Version: 1.0
X-Sender: [email-masked]
Message-Id:
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Date: Mon, 8 Jan 2001 19:00:40 -0500
To: [email-masked]
From: Stephen Kent
Subject: Re: Basic Cert-2-Directory mapping question
Cc: [email-masked]
Content-Type: text/plain; charset="us-ascii" ; format="flowed"

Peter,

I think your analysis shows that we have a lot of folks playing CA
who are not "qualified" to do so. This is somewhat analogous to
people who operate closed IP nets and screw up address assignment,
subnetting etc. It's all OK until they try to connect to the rest of
the world, and then we get NAT!

In the CA case, if you really want a closed CA environment, that's a
more defensible practice, but then there is a responsibility to
provide the whole environment, which includes the directory. If you
do it right, then you can play fast and loose with names and users
will be OK. But, all too often we see that systems that were
intended to never be open, start developing cracks, and then people
see what a mess has been made. I have no sympathy for folks who get
themselves into messes of this sort.

I think our friends at MS have adopted your attitude to DNs, i.e.,
"they're too hard to deal with properly and nobody uses them right
anyway, so lets use a shortcut for lookups, etc." That appears to be
at the heart of a design in which subject key ID takes on more
significance than the names in a cert, is used as a search key in a
local repository, and for chaining, overriding the 2459 cert path
validation rules, etc. That will work if everyone plays by their
rules, but does it scale well? Also, it has unintended effects, as
one PKIX list member already reported when he discovered differing
behavior between Explorer and Navigator. Surprises are never good in
a security context.

In the later half of the 1980s, Lotus (really Iris) developed its own
cert format for use with the Notes product. It worked just fine
within each work group context, but they soon discovered then when
work groups tried to interconnect and they had issued certs in their
own little CA domains without a bigger structure in mind, collisions
happened and problems ensued.

The problems you cite are real, and they arise for a wide range of
reasons, some bad, some understandable. Today I encourage folks to
use names from spaces where authoritative CAs can exist, e.g., DNS
names, and to use DNs with caution.

Steve

Received: from mail.ec.auckland.ac.nz (mail.student.auckland.ac.nz [130.216.35.201]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA10529 for ; Mon, 8 Jan 2001 15:14:59 -0800 (PST)
Received: from kahu.cs.auckland.ac.nz ([email-masked] [130.216.36.13]) by mail.ec.auckland.ac.nz (8.9.3/8.8.6/cs-master) with SMTP id MAA07786 for ; Tue, 9 Jan 2001 12:19:51 +1300 (NZDT) (sender [email-masked])
Received: by kahu.cs.auckland.ac.nz (relaymail v0.9) id <97899599117616>; Tue, 9 Jan 2001 12:19:51 (NZDT)
From: [email-masked] (Peter Gutmann)
To: [email-masked]
Subject: Re: Basic Cert-2-Directory mapping question
Sender: [email-masked]
Reply-To: [email-masked]
X-Charge-To: pgut001
X-Authenticated: relaymail v0.9 on kahu.cs.auckland.ac.nz
Date: Tue, 9 Jan 2001 12:19:51 (NZDT)
Message-ID: <[email-masked]>

Stephen Kent writes:

>I have not read your paper, but the assertion that DNs don't work, without
>substantiation, seems a bit strong. Certainly when people create arbitrary
>DNs, without regard to the semantics of directory structure, bad things
>happen. Also, it is fair to say that the grand, nations as top level
>directory operators model that X.500 envisioned has not happened, and it
>unlikely to ever happen in some places, e.g., the U.S. However, the
>suggestion of hashing a DN and using it as a search key always seems to have
>the problem of breaking the knowledge reference part of X.500 (and of all,
>analogous, tree structure, distributed directories), which rely on looking at
>name structure to figure out where to look for an entry that is not local.

This is a somewhat circular argument, that if you have a DN which has been
artificially constructed to be meaningful it will in fact be meaningful in
locating a cert. In practice this never works except in the special case I
mentioned earlier where everyone has been forced (on pain of pain) to use some
fixed schema for their DN's.

Consider for example finding one of the certs I've acquired over time for
testing purposes (most of them have probably expired by now). Looking at my
email address you'd start with C=NZ, and then perhaps O=Auckland University,
or maybe University of Auckland, or perhaps University of New Zealand with
another O=Auckland (the last one's definitely wrong, but non-NZers may not
know that). After that it gets tricky, is it OU=Computer Science, Computer
Science Department, Department of Computer Science, CompSci, CS, or even
Mathematics and /School of Mathematics and
../Faculty of... with another OU specifying the department? (I've just
checked and it's currently "School of Mathematical and Inforation Sciences",
I'm sure if I asked 10 people here I'd get 15 different guesses as to how all
this stuff is supposed to be specified in a DN). Even if you manage to find a
directory which contains Uni certs (good luck with that) *and* spend an hour
or two playing guess the DN, you won't find anything because all the CAs which
I've got certs from use DNs which are meaningful to them, not to arbitrary
third parties.

It gets worse than that. Because the DNs are meaningful to the issuing CAs
(which is perfectly OK, they issue the certs so they get to control the DN
space) rather than the EE, the EE generally doesn't know their own DN. I
can't actually tell you, without cheating and taking a look, what any of the
DNs in the certs issued in my name are. I'll emphasise that again: I don't
even know my *own* DNs without looking, and I doubt most other people outside
of .govs/.mils which force you to use fixed DNs would either.

The sole meaningful piece of information in any of my certs is my email
address (my CN is vaguely meaningful, but suffers from the "Which John Smith"
problem. There should also be certs out there with my email address but
apparently belonging to the Jolly Green Giant - isn't it wonderful what CAs
will let you put in a cert?). That's the point I made in the analysis in my
paper, noone (well, almost noone :-) actually uses a DN in the way X.500 says
it's supposed to be used. It's used in a check for equality when checking an
S/MIME sig or fetching a decryption key or whatever, but an SHA-1 hash would
do just as well, which is why I proposed hashing the DN to a fixed-length
value and using that instead. Without wanting to rehash the entire paper,
what I did was analyse the types of cert lookups which are typically performed
and then design a scheme which handled them.

A general summary of the concept is that if you design your application with
the assuption that any DNs it encounters are meaningless blobs, you won't be
disappointed. If you assume the DN has some sort of magical properties, your
application breaks for the vast majority of DNs which don't have those magical
properties.

>finally, the IETF has had a standard means of encoding a DNS name as a DN for
>several years, which suggests that there is at least one scheme that would
>work.

I assume you mean the RFC 2247 domainComponent? It's a nice theory, but since
anyone who needs a URL/FQDN will use a GeneralName where it's available (which
is in most cases when it's required) and where only a DN is available will
stuff it into a CN like everyone else does and like everyone's software
expects, I can't see it ever going beyond being a nice theory (I have a vague
memory of actually having seen a solitary DC in a cert somewhere, but a quick
check of my collection has failed to locate one... does anyone know of
examples of these being used? How does the average third-party app handle
them?).

Peter.

Received: from prv-mail20.provo.novell.com (prv-mail20.provo.novell.com [137.65.81.122]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id OAA09823 for ; Mon, 8 Jan 2001 14:44:02 -0800 (PST)
Received: from INET-PRV-Message_Server by prv-mail20.provo.novell.com with Novell_GroupWise; Mon, 08 Jan 2001 15:48:18 -0700
Message-Id:
X-Mailer: Novell GroupWise Internet Agent 5.5.5.1
Date: Mon, 08 Jan 2001 15:48:09 -0700
From: "Bob Jueneman"
To:
Cc:
Subject: Re: Basic Cert-2-Directory mapping question
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id OAA09824

>>> "Anders Rundgren" 01/08/01 01:41PM >>>
Janus,
>Unforntunately your certificates will not be useful for Win2K local authentication
due to this mapping problem.

>Does Novell offer a more flexible use of
TTP-issued certificates without requiring the RP to use a 1-2-1 DN
versus directory mapping?

Sorry, I don't think we have any magic bullet in this space yet either.

For those RP applications that matter, typically applications that are authenticating
a user to the directory itself, perhaps in order to authenticate themselves to other
resources, we tend to require a unique 1:1 mapping between the DN in the
certificate and the DN of the directory. Of course the customer, or perhaps
one of our consulting partners, may develop more complex solutions to fit
particular requirements.

How we get them into the directory in the first place is one of those
infamous "local matters".

The real telling issue is when you start to go beyond the intranet, and launch
into the extranet or internet space. In the intranet space, it generally isn't too
difficult to persuade the CA to issue certificate with the right schema, or to modify
your directory schema to fit that of the PKI vendor or CA.

What you do with a bunch of certificates from different CAs and/or toolkit
vendors, none of which necessarily match the schema of your directory, is
still an unsolved problem. We've started down the path of non-global schemas,
and we have some other solutions that involve DirXML, which is a way of
synchronizing two directories and/or databases via XML, but the basic
problem is still with us.

Yes, you could arbitrarily store the certificate somewhere, using for example
the keyID a hash of the public key, or perhaps of the certificate itself, but
is that what we really want to do?

Maybe I'm making too big a point of this, but I don't necessarily want to import
your certificate into MY directory. Instead, I think that I want to retrieve
your certificate from your directory, or perhaps your CA's directory,
where ever that might be. If I don't have to actually import the cert,
most of these schema issues tend to go away.

BTW, Tom Gindin just asked me why pkixrep didn't solve that problem,
and I confess that I am clueless about that spec, so perhaps I've missed
something fundamental here.

But at the risk of oversimplifying, when it comes to extranet access,
my preference is to base access control decisions on role-based criteria
such as are embodied in the Novell Security Attributes, and to AUDIT
the action of that user based on the information provided in his certificate,
whatever that might be, assuming I have validated and accepted it.

Bob

Robert R. Jueneman
Security Architect
Novell, Inc. -- the leading provider of Net services software.

Received: from prv-mail20.provo.novell.com (prv-mail20.provo.novell.com [137.65.81.122]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id OAA07190 for ; Mon, 8 Jan 2001 14:04:10 -0800 (PST)
Received: from INET-PRV-Message_Server by prv-mail20.provo.novell.com with Novell_GroupWise; Mon, 08 Jan 2001 15:08:32 -0700
Message-Id:
X-Mailer: Novell GroupWise Internet Agent 5.5.5.1
Date: Mon, 08 Jan 2001 15:08:24 -0700
From: "Bob Jueneman"
To: ,
Cc: , ,
Subject: Re: Basic Cert-2-Directory mapping question
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id OAA07192

Unfortunately, the model you cite, with naming authorities that
are truly authoritative, and in addition a monopoly, is in fact NOT the
case the United States, and in a number of other countries in the
world as well.

If the government decrees what DNs are allowable, and perhaps where
they have to be stored, then the problem is certainly simplified.
Unfortunately, usually isn't the case.

Bob

>>> Janus Liebregts 01/08/01 01:36PM >>>
I fully agree with David.

I don't agree that using a standard DN registration scheme, is
extraordinarily painful. Currently we, SURFnet (as the dutch National
Research Network) use two simple rules for our pki-domain (Higher
Education & Research):

1. only certify CA's using DN's as registered within our (LDAP)domain
using the rules of our Naming Authority.
2. store CA-certificates & CRL's in the DN's (LDAP)entry as certified.

with this we build our pki according to the ldap-namespace ACCORDING to
SURFnet. We claim to be the Naming Authority for the C=NL namespace...

Probably every country & state have their own laws about naming
organisations, in Holland the Chambres of Commerce have such a
(delegated) task. Every country (C= or state c=US, ST=) should have some
sort of naming authority and name-registration is already taken place.
But how to make available these authorative Naming databases in a (LDAP)
way, to be the authorative name for certification....

For our community we have made available a pki-ldap cookbook which
describes a method how to organise your DIT and how to store pki-related
material http://ldap.gigacorp.nl/pkildap.html

Janus Liebregts
SURFnet

"David P. Kemp" wrote:
>
> Peter,
>
> I thought what Anders asked was:
> "given an arbitrary DN, how do I find a cert stored somewhere in an
> arbitrary collection of independently-managed X.500 or LDAP directory
> servers",
>
> not:
> "given an arbitrary DN, how do I fetch a cert which I already have a
> copy of, stored on my own server."
>
> It shouldn't be at all surprising that a db or ISAM store, with or
> without an RDBMS layer above, and with or without a DAP or LDAP access
> layer, is a reasonable way to store certs on your own machine. [1]
> Developing a DN-schema-independent local retrieval mechanism is all
> well and good, but it doesn't solve the registration problem, and as a
> result, it doesn't help you to find a cert which you don't already
> have.
>
> The real problem with finding and using certs which are stored
> elsewhere is the reverse of what you stated, namely:
>
> cause: people fill DNs with whatever they like, and therefore
> effect: those particular DN's don't work (i.e. they don't solve
> Anders' question because they aren't valid addresses in
> a global address space.)
>
> Instead of saying "DN's don't work", with a footnote, it would
> be more accurate to say "people choose not to use working DNs".
>
> The Web works only because every Internet URL begins with
> DNS-registered name. Something related to your third approach below,
> requiring all certs and directories to use a standard DN registration
> scheme, may be extraordinarily painful, but it's better than ad-hoc
> workarounds using other certificate fields. If PKI consumers and
> providers aren't willing to standardise within a global DN space, we
> will have only islands of interoperability. [2]
>
> Dave
>
> [1] You could also just use the native filesystem, storing each cert
> as a file in an RDN-based folder heirarchy or in a DN or hash(DN)-based
> flat folder. This works as long as you keep secondary indices
> synchronised with the folder contents, or if you don't need secondary
> indices at all.
>
> [2] Blue sky thought: it might be nice if there were a "Registration
> Point (RP)" DN attribute which would be analogous to the hostname
> portion of a URL. The RP attribute would be the first RDN of a
> DN, and the RP value would be an OID identifying the registration
> authority and the schema for the remainder of the DN. In principle,
> this is no better (except for being less verbose) than current DNs, but
> in practice OIDs are better managed - people actually choose to follow
> OID registration procedures instead of just poaching in somebody else's
> space.
>
> > From: [email-masked] (Peter Gutmann)
> >
> > The main problem is that DN's don't work [0], so you end up with ones which
> > people have filled with whatever they feel like, odd things required by cert
> > profiles or signature laws or organisational constraints or whatever which
> > generally don't fit any known directory schema. The current approaches to
> > this problem if you're using a directory as a cert store are:
> >
> > - Continually update the directory schema to match any new DNs which appear
> > until the directory admin(s) go insane (hi Paul :-).
> > - Create aliases in the directory mapping DNs in certs to the (fixed)
> > directory schema.
> > - Force all certs to use the schema used in the directory (someone who's
> > been through this one once described it to me as "extraordinarily
> painful").
> > - Use the directory DN to identify the cert owner and store the cert as just
> > another attribute, with the actual cert DN ignored.
> > - (There may be more, since the whole thing is badly broken there are
> > probably lots of workarounds being used. If anyone knows of others
> > please let me know)
> >
> > A much better approach IMNSHO, and the one I look at in my paper, is to treat
> > the DN as a blob and hash it down to a fixed-length value which you use as a
> > key to look up the cert in an RDBMS or something like dbm if you don't need
> > the full RDBMS functionality [1]. This approach just plain works no matter
> > how garbled and broken the DN is.

Received: from prv-mail20.provo.novell.com (prv-mail20.provo.novell.com [137.65.81.122]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id NAA06512 for ; Mon, 8 Jan 2001 13:55:54 -0800 (PST)
Received: from INET-PRV-Message_Server by prv-mail20.provo.novell.com with Novell_GroupWise; Mon, 08 Jan 2001 15:00:07 -0700
Message-Id:
X-Mailer: Novell GroupWise Internet Agent 5.5.5.1
Date: Mon, 08 Jan 2001 14:56:58 -0700
From: "Bob Jueneman"
To: ,
Subject: Re: Basic Cert-2-Directory mapping question
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id NAA06513

This has been a train wreck about the happen for nearly ten years.
It's like watching "The Fugitive" one still frame at a time. The NADF
tried to address this problem and gave up, and PKIX hasn't even tried.

To quote Pogo, "We have met the enemy, and they is us."

The first problem is not the DN -- that's secondary. As you correctly
state, the first problem is knowing the location of a directory service
provider that is supposed to contain the DN, so we can at least get
to the right point and start browsing around for a certificate.

I don't know that we need to name a Registration Point for a DN -- that
might get all tangled up in naming issues, who has the right to name
someone, etc.

What I proposed more than a year ago, and what I think you are in
essence saying, was that DNs in certificate should really be URLs,
in essentially the same fashion as CRLDistributionPoints are.

I don't particularly care what the exact syntax is -- something like

ldap://ldap.mycompany.com/c=us, ....cn="My Name"

would do just fine, I think, but I'll let other people debate that.

Once we finally locate the directory, then we can have all of the religious
arguments about my RDN schema vs. yours, and why yours is wrong and mine
is the only one that any right-thinking system administer could possibly
support, yada, yada, yada.

Unfortunately, since the contents of PKI certificates are generally viewed
as supposedly providing some degree of specificity with regard to a geopolitical
identification and location of an end-entity, those schemas sometimes conflict with
directory structures which are often organized around completely different
principles, such as more or less reflecting the network structure or topology
or span of control issues.

But those issues, although certainly important, could reasonably be resolved by
aliases, etc., no matter how painful But if a consumer of certificates doesn't even
know where the directory can be found to start looking, then schema problems
won't matter.

Regards,

Bob

Robert R. Jueneman
Security Architect
Novell, Inc. -- the leading provider of Net services software

>>> "David P. Kemp" 01/08/01 11:29AM >>>
Peter,

I thought what Anders asked was:
"given an arbitrary DN, how do I find a cert stored somewhere in an
arbitrary collection of independently-managed X.500 or LDAP directory
servers",

not:
"given an arbitrary DN, how do I fetch a cert which I already have a
copy of, stored on my own server."

It shouldn't be at all surprising that a db or ISAM store, with or
without an RDBMS layer above, and with or without a DAP or LDAP access
layer, is a reasonable way to store certs on your own machine. [1]
Developing a DN-schema-independent local retrieval mechanism is all
well and good, but it doesn't solve the registration problem, and as a
result, it doesn't help you to find a cert which you don't already
have.

The real problem with finding and using certs which are stored
elsewhere is the reverse of what you stated, namely:

cause: people fill DNs with whatever they like, and therefore
effect: those particular DN's don't work (i.e. they don't solve
Anders' question because they aren't valid addresses in
a global address space.)

Instead of saying "DN's don't work", with a footnote, it would
be more accurate to say "people choose not to use working DNs".

The Web works only because every Internet URL begins with
DNS-registered name. Something related to your third approach below,
requiring all certs and directories to use a standard DN registration
scheme, may be extraordinarily painful, but it's better than ad-hoc
workarounds using other certificate fields. If PKI consumers and
providers aren't willing to standardise within a global DN space, we
will have only islands of interoperability. [2]

Dave

[1] You could also just use the native filesystem, storing each cert
as a file in an RDN-based folder heirarchy or in a DN or hash(DN)-based
flat folder. This works as long as you keep secondary indices
synchronised with the folder contents, or if you don't need secondary
indices at all.

[2] Blue sky thought: it might be nice if there were a "Registration
Point (RP)" DN attribute which would be analogous to the hostname
portion of a URL. The RP attribute would be the first RDN of a
DN, and the RP value would be an OID identifying the registration
authority and the schema for the remainder of the DN. In principle,
this is no better (except for being less verbose) than current DNs, but
in practice OIDs are better managed - people actually choose to follow
OID registration procedures instead of just poaching in somebody else's
space.

> From: [email-masked] (Peter Gutmann)
>
> The main problem is that DN's don't work [0], so you end up with ones which
> people have filled with whatever they feel like, odd things required by cert
> profiles or signature laws or organisational constraints or whatever which
> generally don't fit any known directory schema. The current approaches to
> this problem if you're using a directory as a cert store are:
>
> - Continually update the directory schema to match any new DNs which appear
> until the directory admin(s) go insane (hi Paul :-).
> - Create aliases in the directory mapping DNs in certs to the (fixed)
> directory schema.
> - Force all certs to use the schema used in the directory (someone who's
> been through this one once described it to me as "extraordinarily
painful").
> - Use the directory DN to identify the cert owner and store the cert as just
> another attribute, with the actual cert DN ignored.
> - (There may be more, since the whole thing is badly broken there are
> probably lots of workarounds being used. If anyone knows of others
> please let me know)
>
> A much better approach IMNSHO, and the one I look at in my paper, is to treat
> the DN as a blob and hash it down to a fixed-length value which you use as a
> key to look up the cert in an RDBMS or something like dbm if you don't need
> the full RDBMS functionality [1]. This approach just plain works no matter
> how garbled and broken the DN is.

Received: from maila.telia.com (maila.telia.com [194.22.194.231]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA02944 for ; Mon, 8 Jan 2001 12:38:30 -0800 (PST)
Received: from d1o69.telia.com (d1o69.telia.com [62.20.144.241]) by maila.telia.com (8.9.3/8.9.3) with ESMTP id VAA13409; Mon, 8 Jan 2001 21:43:20 +0100 (CET)
Received: from mega (t6o69p100.telia.com [213.64.110.220]) by d1o69.telia.com (8.10.2/8.10.1) with SMTP id f08KhIl07274; Mon, 8 Jan 2001 21:43:18 +0100 (CET)
Message-ID: <[email-masked]>
From: "Anders Rundgren"
To: "Janus Liebregts"
Cc: , ,
References: <[email-masked]> <[email-masked]>
Subject: Re: Basic Cert-2-Directory mapping question
Date: Mon, 8 Jan 2001 21:41:42 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
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
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id MAA02948

Janus,
Unforntunately your certificates will not be useful for Win2K local authentication
due to this mapping problem. Does Novell offer a more flexible use of
TTP-issued certificates without requiring the RP to use a 1-2-1 DN
versus directory mapping?

/anders

> I fully agree with David.
>
> I don't agree that using a standard DN registration scheme, is
> extraordinarily painful. Currently we, SURFnet (as the dutch National
> Research Network) use two simple rules for our pki-domain (Higher
> Education & Research):
>
> 1. only certify CA's using DN's as registered within our (LDAP)domain
> using the rules of our Naming Authority.
> 2. store CA-certificates & CRL's in the DN's (LDAP)entry as certified.
>
> with this we build our pki according to the ldap-namespace ACCORDING to
> SURFnet. We claim to be the Naming Authority for the C=NL namespace...
>
> Probably every country & state have their own laws about naming
> organisations, in Holland the Chambres of Commerce have such a
> (delegated) task. Every country (C= or state c=US, ST=) should have some
> sort of naming authority and name-registration is already taken place.
> But how to make available these authorative Naming databases in a (LDAP)
> way, to be the authorative name for certification....
>
> For our community we have made available a pki-ldap cookbook which
> describes a method how to organise your DIT and how to store pki-related
> material http://ldap.gigacorp.nl/pkildap.html
>
> Janus Liebregts
> SURFnet
>
>
>
>
> "David P. Kemp" wrote:
> >
> > Peter,
> >
> > I thought what Anders asked was:
> > "given an arbitrary DN, how do I find a cert stored somewhere in an
> > arbitrary collection of independently-managed X.500 or LDAP directory
> > servers",
> >
> > not:
> > "given an arbitrary DN, how do I fetch a cert which I already have a
> > copy of, stored on my own server."
> >
> > It shouldn't be at all surprising that a db or ISAM store, with or
> > without an RDBMS layer above, and with or without a DAP or LDAP access
> > layer, is a reasonable way to store certs on your own machine. [1]
> > Developing a DN-schema-independent local retrieval mechanism is all
> > well and good, but it doesn't solve the registration problem, and as a
> > result, it doesn't help you to find a cert which you don't already
> > have.
> >
> > The real problem with finding and using certs which are stored
> > elsewhere is the reverse of what you stated, namely:
> >
> > cause: people fill DNs with whatever they like, and therefore
> > effect: those particular DN's don't work (i.e. they don't solve
> > Anders' question because they aren't valid addresses in
> > a global address space.)
> >
> > Instead of saying "DN's don't work", with a footnote, it would
> > be more accurate to say "people choose not to use working DNs".
> >
> > The Web works only because every Internet URL begins with
> > DNS-registered name. Something related to your third approach below,
> > requiring all certs and directories to use a standard DN registration
> > scheme, may be extraordinarily painful, but it's better than ad-hoc
> > workarounds using other certificate fields. If PKI consumers and
> > providers aren't willing to standardise within a global DN space, we
> > will have only islands of interoperability. [2]
> >
> > Dave
> >
> > [1] You could also just use the native filesystem, storing each cert
> > as a file in an RDN-based folder heirarchy or in a DN or hash(DN)-based
> > flat folder. This works as long as you keep secondary indices
> > synchronised with the folder contents, or if you don't need secondary
> > indices at all.
> >
> > [2] Blue sky thought: it might be nice if there were a "Registration
> > Point (RP)" DN attribute which would be analogous to the hostname
> > portion of a URL. The RP attribute would be the first RDN of a
> > DN, and the RP value would be an OID identifying the registration
> > authority and the schema for the remainder of the DN. In principle,
> > this is no better (except for being less verbose) than current DNs, but
> > in practice OIDs are better managed - people actually choose to follow
> > OID registration procedures instead of just poaching in somebody else's
> > space.
> >
> > > From: [email-masked] (Peter Gutmann)
> > >
> > > The main problem is that DN's don't work [0], so you end up with ones which
> > > people have filled with whatever they feel like, odd things required by cert
> > > profiles or signature laws or organisational constraints or whatever which
> > > generally don't fit any known directory schema. The current approaches to
> > > this problem if you're using a directory as a cert store are:
> > >
> > > - Continually update the directory schema to match any new DNs which appear
> > > until the directory admin(s) go insane (hi Paul :-).
> > > - Create aliases in the directory mapping DNs in certs to the (fixed)
> > > directory schema.
> > > - Force all certs to use the schema used in the directory (someone who's
> > > been through this one once described it to me as "extraordinarily
> > painful").
> > > - Use the directory DN to identify the cert owner and store the cert as just
> > > another attribute, with the actual cert DN ignored.
> > > - (There may be more, since the whole thing is badly broken there are
> > > probably lots of workarounds being used. If anyone knows of others
> > > please let me know)
> > >
> > > A much better approach IMNSHO, and the one I look at in my paper, is to treat
> > > the DN as a blob and hash it down to a fixed-length value which you use as a
> > > key to look up the cert in an RDBMS or something like dbm if you don't need
> > > the full RDBMS functionality [1]. This approach just plain works no matter
> > > how garbled and broken the DN is.

Received: from survis.surfnet.nl (survis.surfnet.nl [192.87.108.3]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA02227 for ; Mon, 8 Jan 2001 12:30:43 -0800 (PST)
Received: from survis.surfnet.nl ([192.87.108.3] helo=surfnet.nl) by survis.surfnet.nl with ESMTP (exPP) id 14Fj0w-0007hg-00; Mon, 8 Jan 2001 21:35:34 +0100
Message-ID: <[email-masked]>
Date: Mon, 08 Jan 2001 21:36:08 +0100
From: Janus Liebregts
Organization: SURFnet bv
X-Mailer: Mozilla 4.7 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: "David P. Kemp"
CC: [email-masked], [email-masked], [email-masked]
Subject: Re: Basic Cert-2-Directory mapping question
References: <[email-masked]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

I fully agree with David.

I don't agree that using a standard DN registration scheme, is
extraordinarily painful. Currently we, SURFnet (as the dutch National
Research Network) use two simple rules for our pki-domain (Higher
Education & Research):

1. only certify CA's using DN's as registered within our (LDAP)domain
using the rules of our Naming Authority.
2. store CA-certificates & CRL's in the DN's (LDAP)entry as certified.

with this we build our pki according to the ldap-namespace ACCORDING to
SURFnet. We claim to be the Naming Authority for the C=NL namespace...

Probably every country & state have their own laws about naming
organisations, in Holland the Chambres of Commerce have such a
(delegated) task. Every country (C= or state c=US, ST=) should have some
sort of naming authority and name-registration is already taken place.
But how to make available these authorative Naming databases in a (LDAP)
way, to be the authorative name for certification....

For our community we have made available a pki-ldap cookbook which
describes a method how to organise your DIT and how to store pki-related
material http://ldap.gigacorp.nl/pkildap.html

Janus Liebregts
SURFnet

"David P. Kemp" wrote:
>
> Peter,
>
> I thought what Anders asked was:
> "given an arbitrary DN, how do I find a cert stored somewhere in an
> arbitrary collection of independently-managed X.500 or LDAP directory
> servers",
>
> not:
> "given an arbitrary DN, how do I fetch a cert which I already have a
> copy of, stored on my own server."
>
> It shouldn't be at all surprising that a db or ISAM store, with or
> without an RDBMS layer above, and with or without a DAP or LDAP access
> layer, is a reasonable way to store certs on your own machine. [1]
> Developing a DN-schema-independent local retrieval mechanism is all
> well and good, but it doesn't solve the registration problem, and as a
> result, it doesn't help you to find a cert which you don't already
> have.
>
> The real problem with finding and using certs which are stored
> elsewhere is the reverse of what you stated, namely:
>
> cause: people fill DNs with whatever they like, and therefore
> effect: those particular DN's don't work (i.e. they don't solve
> Anders' question because they aren't valid addresses in
> a global address space.)
>
> Instead of saying "DN's don't work", with a footnote, it would
> be more accurate to say "people choose not to use working DNs".
>
> The Web works only because every Internet URL begins with
> DNS-registered name. Something related to your third approach below,
> requiring all certs and directories to use a standard DN registration
> scheme, may be extraordinarily painful, but it's better than ad-hoc
> workarounds using other certificate fields. If PKI consumers and
> providers aren't willing to standardise within a global DN space, we
> will have only islands of interoperability. [2]
>
> Dave
>
> [1] You could also just use the native filesystem, storing each cert
> as a file in an RDN-based folder heirarchy or in a DN or hash(DN)-based
> flat folder. This works as long as you keep secondary indices
> synchronised with the folder contents, or if you don't need secondary
> indices at all.
>
> [2] Blue sky thought: it might be nice if there were a "Registration
> Point (RP)" DN attribute which would be analogous to the hostname
> portion of a URL. The RP attribute would be the first RDN of a
> DN, and the RP value would be an OID identifying the registration
> authority and the schema for the remainder of the DN. In principle,
> this is no better (except for being less verbose) than current DNs, but
> in practice OIDs are better managed - people actually choose to follow
> OID registration procedures instead of just poaching in somebody else's
> space.
>
> > From: [email-masked] (Peter Gutmann)
> >
> > The main problem is that DN's don't work [0], so you end up with ones which
> > people have filled with whatever they feel like, odd things required by cert
> > profiles or signature laws or organisational constraints or whatever which
> > generally don't fit any known directory schema. The current approaches to
> > this problem if you're using a directory as a cert store are:
> >
> > - Continually update the directory schema to match any new DNs which appear
> > until the directory admin(s) go insane (hi Paul :-).
> > - Create aliases in the directory mapping DNs in certs to the (fixed)
> > directory schema.
> > - Force all certs to use the schema used in the directory (someone who's
> > been through this one once described it to me as "extraordinarily
> painful").
> > - Use the directory DN to identify the cert owner and store the cert as just
> > another attribute, with the actual cert DN ignored.
> > - (There may be more, since the whole thing is badly broken there are
> > probably lots of workarounds being used. If anyone knows of others
> > please let me know)
> >
> > A much better approach IMNSHO, and the one I look at in my paper, is to treat
> > the DN as a blob and hash it down to a fixed-length value which you use as a
> > key to look up the cert in an RDBMS or something like dbm if you don't need
> > the full RDBMS functionality [1]. This approach just plain works no matter
> > how garbled and broken the DN is.

Received: from pigeon.verisign.com (pigeon.verisign.com [208.206.241.106]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA27400 for ; Mon, 8 Jan 2001 11:00:32 -0800 (PST)
Received: from postal-gw1.verisign.com (verisign.com [63.104.27.101]) by pigeon.verisign.com (8.9.3/BCH1.7.1) with ESMTP id LAA22303 for ; Mon, 8 Jan 2001 11:00:52 -0800 (PST)
Received: by postal-gw.verisign.com with Internet Mail Service (5.5.2650.21) id ; Mon, 8 Jan 2001 11:05:25 -0800
Message-ID:
From: Alex Deacon
To: [email-masked]
Cc: cmc-interop
Subject: CMC Interop testing...
Date: Mon, 8 Jan 2001 11:05:22 -0800
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C079A5.F3213B60"

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_01C079A5.F3213B60
Content-Type: text/plain;
charset="iso-8859-1"

VeriSign is seeking to conduct interoperability testing with individuals
and/or organizations who have (or are working on) CMC implementations.

If you are interested in participating and would like further details and
information, please send email to

[email-masked]

Regards,
Alex

------_=_NextPart_001_01C079A5.F3213B60
Content-Type: text/html;
charset="iso-8859-1"

VeriSign is
seeking to conduct interoperability testing with individuals and/or
organizations who have (or are working on) CMC implementations.

If you are
interested in participating and would like further details and information,
please send email to

[email-masked]

Regards,

Alex

------_=_NextPart_001_01C079A5.F3213B60--

Received: from mail-fwd.verio-web.com ([161.58.16.59]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id KAA24145 for ; Mon, 8 Jan 2001 10:27:21 -0800 (PST)
Received: from 161.58.117.181 (161.58.117.181) by mail11b.verio-web.com (RS ver 1.0.57s) with SMTP id 017831031; Mon, 8 Jan 2001 13:31:46 -0500 (EST)
Received: from caveosystems.com (adsl-141-154-28-165.bostma.adsl.bellatlantic.net [141.154.28.165]) by os390.caveosystems.com (8.9.3/8.9.3) with ESMTP id NAA02748; Mon, 8 Jan 2001 13:33:11 -0500
Message-ID: <[email-masked]>
Date: Mon, 08 Jan 2001 13:36:43 -0500
From: Rich Salz
X-Mailer: Mozilla 4.73 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Dr S N Henson
CC: PKIX-List
Subject: Re: OCSP authorized responder clarification.
References: <[email-masked]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Loop-Detect: 1

> A certain CA issues end user certificates signed by an intermediate CA
> which is in turn signed by the root CA.

So do you mean this
Root->Certain CA->End-Entity
\->Responder->

Now a client has an EE cert and wants to know if Responder is authorized?

Then you are right, there is nothing inherent in the PKI. A client would have
to treat it as case two, at the top of page 2 of RFC 2560 -- a trusted
responder whose key it trusts (because it has out of band information.)

I can think of two ways to strengthen the trust decision for a client. First,
the "Certain CA" could include an AIA in the end-entity certs that points to
where the Responder is listening. Second, the Certain CA could on its own
cross-certify the Responder and distribute the cert that *IT* signed. The root
might also issue the Responder cert using the same DN as it did for the
Certain CA.
(Just as some vendors like(d) to sure DN's for signing and CRL-issuing.)

The first method only provides a hint, since no crypto rigor is involved, just
the foundation of sand that is DNS. The second could be seen as voiding your
hypothesis.

In my limited experience of OCSP deployment, the client trust issue is almost
always addressed by saying "trust this responder" analogous to the way the
client is told to "just trust this root."

/r$

Received: from stingray.missi.ncsc.mil (stingray.missi.ncsc.mil [144.51.50.20]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA23315 for ; Mon, 8 Jan 2001 10:23:57 -0800 (PST)
Received: from stingray.missi.ncsc.mil (root@localhost) by stingray.missi.ncsc.mil with ESMTP id NAA17324 for ; Mon, 8 Jan 2001 13:28:20 -0500 (EST)
Message-Id: <[email-masked]>
Date: Mon, 8 Jan 2001 13:29:47 -0500 (EST)
From: "David P. Kemp"
Reply-To: "David P. Kemp"
Subject: Re: Basic Cert-2-Directory mapping question
To: [email-masked]
MIME-Version: 1.0
Content-Type: TEXT/plain; charset=us-ascii
Content-MD5: hS5xcvaUDuw0+geNhWJ/6A==
X-Mailer: dtmail 1.3.0 CDE Version 1.3 SunOS 5.7 sun4u sparc

Peter,

I thought what Anders asked was:
"given an arbitrary DN, how do I find a cert stored somewhere in an
arbitrary collection of independently-managed X.500 or LDAP directory
servers",

not:
"given an arbitrary DN, how do I fetch a cert which I already have a
copy of, stored on my own server."

It shouldn't be at all surprising that a db or ISAM store, with or
without an RDBMS layer above, and with or without a DAP or LDAP access
layer, is a reasonable way to store certs on your own machine. [1]
Developing a DN-schema-independent local retrieval mechanism is all
well and good, but it doesn't solve the registration problem, and as a
result, it doesn't help you to find a cert which you don't already
have.

The real problem with finding and using certs which are stored
elsewhere is the reverse of what you stated, namely:

cause: people fill DNs with whatever they like, and therefore
effect: those particular DN's don't work (i.e. they don't solve
Anders' question because they aren't valid addresses in
a global address space.)

Instead of saying "DN's don't work", with a footnote, it would
be more accurate to say "people choose not to use working DNs".

The Web works only because every Internet URL begins with
DNS-registered name. Something related to your third approach below,
requiring all certs and directories to use a standard DN registration
scheme, may be extraordinarily painful, but it's better than ad-hoc
workarounds using other certificate fields. If PKI consumers and
providers aren't willing to standardise within a global DN space, we
will have only islands of interoperability. [2]

Dave

[1] You could also just use the native filesystem, storing each cert
as a file in an RDN-based folder heirarchy or in a DN or hash(DN)-based
flat folder. This works as long as you keep secondary indices
synchronised with the folder contents, or if you don't need secondary
indices at all.

[2] Blue sky thought: it might be nice if there were a "Registration
Point (RP)" DN attribute which would be analogous to the hostname
portion of a URL. The RP attribute would be the first RDN of a
DN, and the RP value would be an OID identifying the registration
authority and the schema for the remainder of the DN. In principle,
this is no better (except for being less verbose) than current DNs, but
in practice OIDs are better managed - people actually choose to follow
OID registration procedures instead of just poaching in somebody else's
space.

> From: [email-masked] (Peter Gutmann)
>
> The main problem is that DN's don't work [0], so you end up with ones which
> people have filled with whatever they feel like, odd things required by cert
> profiles or signature laws or organisational constraints or whatever which
> generally don't fit any known directory schema. The current approaches to
> this problem if you're using a directory as a cert store are:
>
> - Continually update the directory schema to match any new DNs which appear
> until the directory admin(s) go insane (hi Paul :-).
> - Create aliases in the directory mapping DNs in certs to the (fixed)
> directory schema.
> - Force all certs to use the schema used in the directory (someone who's
> been through this one once described it to me as "extraordinarily
painful").
> - Use the directory DN to identify the cert owner and store the cert as just
> another attribute, with the actual cert DN ignored.
> - (There may be more, since the whole thing is badly broken there are
> probably lots of workarounds being used. If anyone knows of others
> please let me know)
>
> A much better approach IMNSHO, and the one I look at in my paper, is to treat
> the DN as a blob and hash it down to a fixed-length value which you use as a
> key to look up the cert in an RDBMS or something like dbm if you don't need
> the full RDBMS functionality [1]. This approach just plain works no matter
> how garbled and broken the DN is.

Received: from edelweb.fr (edelweb.fr [212.234.46.16]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA23144 for ; Mon, 8 Jan 2001 10:22:35 -0800 (PST)
Received: from champagne.edelweb.fr (localhost.edelweb.fr [127.0.0.1]) by edelweb.fr with ESMTP id TAA07059; Mon, 8 Jan 2001 19:27:24 +0100 (MET)
Received: from champagne.edelweb.fr (champagne.edelweb.fr [193.51.14.161]) by edelweb.fr (nospam/1.3); Mon, 8 Jan 2001 19:27:25 +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 TAA21022; Mon, 8 Jan 2001 19:27:22 +0100 (MET)
From: Peter Sylvester
Received: (sylvest@localhost) by emeriau.edelweb.fr (8.7.6/8.6.6) id TAA16605; Mon, 8 Jan 2001 19:27:22 +0100 (MET)
Date: Mon, 8 Jan 2001 19:27:22 +0100 (MET)
Message-Id: <[email-masked]>
To: [email-masked], [email-masked]
Subject: RE: DPD & DPV requirements - Let us Recurse
Cc: [email-masked]

>
> Peter,
>
> > >
> > > Returning info that explains why a server believes that the returned
> > > data supports validation is an interesting notion. The first example
> > > of that I saw was in work performed by colleagues here at BBN, on a
> > > project calls IOS, in the early 90s, where servers did that. But, I
> > > think this is still an R&D topic for now, not yet ready for
> > > standardization.
> >
> >Isn't part of this 'interesting notion' the cert chain itself. The
> >certificate chain return by a DPV server is the chain that has
> >been used to validate it, and the server believes that this chain
> >is valid.
>
> The interesting part of the notion is using a common representation,
> which can then be translated into human readable language, to express
> the validation chain assertions, especially when the validation
> process is incomplete, or not exact, e.g., outdated CRLs.

There are several interesting things IMHO:

- what statements are to be returned,

- whether ALL elements that contribute to a decision are returned.

- how can they be translated into whatever a client tells.

There exist already a data structure which is used in other
protocols, i.e. PKIStatus, that can be used to carry additional
information.

It just seems to me that if one starts to create a DPV response that
by itself already contains information about whether or not the
certificate is valid, then one should try to return all the information
that might be appropriate. This includes CRLs, OCSP reponses,
statement expressed in PKIStatus or an attribute certificate.

A validation server makes it decision in some linear way, or at
least it can assemble all the results in a linear way. Thus,
a simple list of statements, "I've looked at this", "I consider it
to be valid/invalid/incomplete" seems to me a good starting point.
A cert chain is just a subset of that.

>
> Well, there is already a suggestion (that I need to look into
> further) that proxied OCSP responses may pose problems. if one has to
> assemble a mix of serial and parallel signed responses to satisfy a
> query, that adds complexity both syntactically and semantically. But,
> for the most part, my allusion to R&D issues has to do with the
> problems that arise when the revocation status data is not quite
> perfect and one wants to respond with something more that "NP" and
> with the human interface presentation issues.

Just because it create complexity, this is one reason that these things
are discussed and standardized. I have just given a provoking
example of parallel or enbedded signatures by borrowing some
ideas from CMS; it may be sufficient that a relaying server just embeds
a response from another server, and parallel CMS signedData are
not necessary.

What do you mean by revocation status not quite perfect? A server
makes a desision, and tells what it had looked at, it may happen
that another server verifier looks at the same data in a different
way, and comes to another conclusion; this tru independant of
whether the first returns its justifications or not. One entity
might validate a cert chain, another might not, etc. Returning
as much as possible data about why one decision has been made
does not change that.

If a client has a user interface to explain a server decision,
it seems necessary anyway to display certificates, elements on
a CRL, OCSP reponses, PKIStatus data.

We already have the problem of user interfaces of certificate
and CRL displays, and also of how to display responses from
a OCSP server, or from the new services to be standardized.
But do we actually care? But: I don't see in other pkix standards a
description of about how a certificate chain has to be presented
or even a single certificate.

What seems useful to me is to specify a list of elements that may
be supposed to be presented to users. Such a list should be a simple
as possible, contain a small number of different data type that
allow to express a large set of situations, so that we don't have
to add new stuff each 6 months or 3 years. We have already *MANY*
standards that return 'status information' in different ways.
One question here would be: Is it more appropriate to use a
new textual format like in SCVP or something like PKIStatus as
used in several standards maybe accompanied by OCSP responses?

Peter

Received: from po1.bbn.com (PO1.BBN.COM [192.1.50.38]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA20352 for ; Mon, 8 Jan 2001 08:59:25 -0800 (PST)
Received: from [171.78.30.107] (comsec.bbn.com [171.78.30.107]) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id MAA21077; Mon, 8 Jan 2001 12:04:09 -0500 (EST)
Mime-Version: 1.0
X-Sender: [email-masked]
Message-Id:
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Date: Mon, 8 Jan 2001 12:02:45 -0500
To: Peter Sylvester
From: Stephen Kent
Subject: RE: DPD & DPV requirements - Let us Recurse
Cc: [email-masked]
Content-Type: text/plain; charset="us-ascii" ; format="flowed"

Peter,

> >
> > Returning info that explains why a server believes that the returned
> > data supports validation is an interesting notion. The first example
> > of that I saw was in work performed by colleagues here at BBN, on a
> > project calls IOS, in the early 90s, where servers did that. But, I
> > think this is still an R&D topic for now, not yet ready for
> > standardization.
>
>Isn't part of this 'interesting notion' the cert chain itself. The
>certificate chain return by a DPV server is the chain that has
>been used to validate it, and the server believes that this chain
>is valid.

The interesting part of the notion is using a common representation,
which can then be translated into human readable language, to express
the validation chain assertions, especially when the validation
process is incomplete, or not exact, e.g., outdated CRLs.

>If the service is implemented using some relaying, such that a
>server becomes a client of someone else, what research problem
>is there that the intermediate server/client wants to provide the
>results? If for the initial client the result of the validation
>becomes something that can be stored somewhere, e.g. similar to
>an OCSP response stored in the SMIME/ETSI signature format stuff,
>then essentially this client becomes an intermediate server for
>another verifier of the enhanced signature.

Well, there is already a suggestion (that I need to look into
further) that proxied OCSP responses may pose problems. if one has to
assemble a mix of serial and parallel signed responses to satisfy a
query, that adds complexity both syntactically and semantically. But,
for the most part, my allusion to R&D issues has to do with the
problems that arise when the revocation status data is not quite
perfect and one wants to respond with something more that "NP" and
with the human interface presentation issues.

Steve

Received: from indy.gradient.com ([email-masked] [192.92.110.1]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA17634 for ; Mon, 8 Jan 2001 08:32:59 -0800 (PST)
Received: from bigbird.gradient.com (bigbird.gradient.com [192.92.110.50]) by indy.gradient.com (8.9.1a/8.9.1) with ESMTP id LAA23122; Mon, 8 Jan 2001 11:37:48 -0500 (EST)
Received: by bigbird.gradient.com with Internet Mail Service (5.5.2650.10) id ; Mon, 8 Jan 2001 11:36:18 -0500
Message-ID: <[email-masked]>
From: Hal Lockhart
To: "'Richard Levitte at Celo'" , Anders Rundgren
Cc: PKIX-List , Philip Hallam-Baker
Subject: RE: Basic Cert-2-Directory mapping question
Date: Mon, 8 Jan 2001 11:36:17 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.10)
Content-Type: text/plain; charset="iso-8859-1"

> I've always wondered what those "Kerberos Certificates" are,
> or do you mean
> tickets? They have nothing to do with PKI, since Kerberos
> doesn't use PKC.

This is not true. The Kerberos working group has developed a scheme for
allowing an initial PKI handshake in place of the original symmetric key
scheme. Once the exchange is over, symmetric key-based tickets are used as
always. The spec is:

http://www.ietf.org/internet-drafts/draft-ietf-cat-kerberos-pk-init-12.txt

certificates may or may not be used. If they are used, there are special
requirements. For example, the DN must correspond to a Kerberos name/realm.

Hal
=======================================================
Harold W. Lockhart Entegrity Solutions
2 Mount Royal Avenue Marlborough, MA 01752 USA
V: 1-508-624-9600 x 260 [email-masked]
F: 1-508-229-0338 www.entegrity.com
=======================================================

Received: from po1.bbn.com (PO1.BBN.COM [192.1.50.38]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA16913 for ; Mon, 8 Jan 2001 08:29:57 -0800 (PST)
Received: from [171.78.30.107] (comsec.bbn.com [171.78.30.107]) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id LAA16649; Mon, 8 Jan 2001 11:34:13 -0500 (EST)
Mime-Version: 1.0
X-Sender: [email-masked]
Message-Id:
In-Reply-To:
References:
Date: Mon, 8 Jan 2001 11:30:14 -0500
To: "Michael Myers"
From: Stephen Kent
Subject: RE: DPD & DPV requirements - Let us Recurse
Cc:
Content-Type: text/plain; charset="us-ascii" ; format="flowed"

Mike,

>Steve,
>
>It is precisely this overlap that led to the existence and architecture of
>the current DPV and DPD drafts, namely that a DPD server was simply tapping
>into the path discovery logic that a DPV server must execute.
>
>Care must taken however as we go forward with high-level requirements to
>ensure that a DPD server delivers up that path a DPV server would have used.
>Or are we otherwise comfortable that some ambiguity may emerge? This was an
>open question that we as DPV and DPD authors were and are grappling with.

We'll see what the group says, but for now I am assuming that
ASN.1-based DPD and DPV servers will exhibit considerable mechanism
and maybe message format overlap.

Steve

Received: from po1.bbn.com (PO1.BBN.COM [192.1.50.38]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA13327 for ; Mon, 8 Jan 2001 07:39:33 -0800 (PST)
Received: from [171.78.30.107] (comsec.bbn.com [171.78.30.107]) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id KAA08993; Mon, 8 Jan 2001 10:44:20 -0500 (EST)
Mime-Version: 1.0
X-Sender: [email-masked]
Message-Id:
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Date: Mon, 8 Jan 2001 10:40:10 -0500
To: [email-masked]
From: Stephen Kent
Subject: Re: Basic Cert-2-Directory mapping question
Cc: [email-masked]
Content-Type: text/plain; charset="us-ascii" ; format="flowed"

Peter,

I have not read your paper, but the assertion that DNs don't work,
without substantiation, seems a bit strong. Certainly when people
create arbitrary DNs, without regard to the semantics of directory
structure, bad things happen. Also, it is fair to say that the grand,
nations as top level directory operators model that X.500 envisioned
has not happened, and it unlikely to ever happen in some places,
e.g., the U.S. However, the suggestion of hashing a DN and using it
as a search key always seems to have the problem of breaking the
knowledge reference part of X.500 (and of all, analogous, tree
structure, distributed directories), which rely on looking at name
structure to figure out where to look for an entry that is not local.

finally, the IETF has had a standard means of encoding a DNS name as
a DN for several years, which suggests that there is at least one
scheme that would work.

Steve

Received: from extapps03.intra.dmz ([194.200.144.248]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA05861 for ; Mon, 8 Jan 2001 06:24:07 -0800 (PST)
From: [email-masked]
Received: from SymbianUK05.Symbian.com (unverified) by extapps03.intra.dmz (Content Technologies SMTPRS 4.1.5) with ESMTP id for ; Mon, 8 Jan 2001 14:26:48 +0000
Received: from symbianuk20.symbian.com ([10.170.2.25]) by SymbianUK05.Symbian.com (Lotus Domino Release 5.0.1b (Intl)) with ESMTP id 2001010814271044:16537 ; Mon, 8 Jan 2001 14:27:10 +0000
Subject: Servers for OCSP v1 interoperability testing
To: [email-masked]
Cc:
X-Mailer: Lotus Notes Release 5.0.2c (Intl) 2 February 2000
Message-ID:
Date: Mon, 8 Jan 2001 14:27:00 +0000
X-Priority: 3 (Normal)
MIME-Version: 1.0
X-MIMETrack: Serialize by Router on SymbianUK20/Symbian(Release 5.0.1b (Intl)|30 September 1999) at 01/08/2001 02:27:00 PM, Itemize by SMTP Server on SymbianUK05/Symbian(Release 5.0.1b (Intl)|30 September 1999) at 08/01/2001 02:27:10 PM, Serialize by Router on SymbianUK05/Symbian(Release 5.0.1b (Intl)|30 September 1999) at 08/01/2001 02:27:10 PM, Serialize complete at 08/01/2001 02:27:10 PM
Content-type: text/plain; charset=us-ascii

All,

Does anyone currently run an OCSP (v1) server against which we can test our
OCSP client implementation? Any help would be much appreciated. Of
course, we would be happy to give feedback in exchange.

Regards,

Jonathan
-------------------------
Dr Jonathan Tuliani
[email-masked]
www.symbian.com

*******************************************************************************************************************
Symbian Limited (Co.No.3173352) Registered Office: Sentinel House, 16 Harcourt Street, London, W1H 1DS, UK.
This message is intended only for use by the named addressee and may contain privileged and/or confidential information. If you are not the named addressee you should not disseminate, copy or take any action in reliance on it. If you have received this message in error please notify [email-masked] and delete the message and any attachments accompanying it immediately. Symbian does not accept liability for any corruption, interception, amendment, tampering or viruses occuring to this message in transit or for any message sent by its employees which is not in compliance with Symbian corporate policy.
*******************************************************************************************************************

Received: from magpie.csie.nctu.edu.tw ([email-masked] [140.113.209.21]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA05794 for ; Mon, 8 Jan 2001 06:23:15 -0800 (PST)
Received: (from leefy@localhost) by magpie.csie.nctu.edu.tw (8.11.1/8.9.1) id f08ERRJ45827 for [email-masked]; Mon, 8 Jan 2001 22:27:27 +0800 (CST)
Date: Mon, 8 Jan 2001 22:27:27 +0800
From: Lee Fu-yuan
To: [email-masked]
Subject: subscribe
Message-ID: <[email-masked]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 1.0i

uth ab43ec31 subscribe ietf-pkix \
Lee Fu-yuan

Received: from tienesmail.com (cx116181-b.tulsa1.ok.home.com [24.179.28.16]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id FAA00380; Mon, 8 Jan 2001 05:08:04 -0800 (PST)
From: [email-masked]
Subject: A Curious and Interesting Opportunity!!
Date: Mon, 8 Jan 2001 03:32:52
Message-Id: <[email-masked]>

Dear Friend:

AS SEEN ON NATIONAL TV :

''Making over half million dollars every 4 to 5 months from
your home for an investment of only $25 U.S. Dollars expense
one time'' THANKS TO THE COMPUTER AGE AND THE INTERNET!
=================================================

BE A MILLIONAIRE LIKE OTHERS WITHIN A YEAR!!!

Before you say ''Bull'', please read the following. This is
the letter you have been hearing about on the news lately.
Due to the popularity of this letter on the internet, a
national weekly news program recently devoted an entire show
to the investigation of this program described below, to see
if it really can make people money.

The show also investigated whether or not the program was
legal. Their findings proved once and for all that there are
''absolutely NO laws prohibiting the participation in the
program and if people can follow the simple instructions,
they are bound to make some mega bucks with only $25 out of
pocket cost''.

DUE TO THE RECENT INCREASE OF POPULARITY & RESPECT THIS
PROGRAM HAS ATTAINED, IT IS CURRENTLY WORKING BETTER THAN
EVER.

This is what one had to say: ''Thanks to this profitable
opportunity. I was approached many times before but each
time I passed on it. I am so glad I finally joined just to
see what one could expect in return for the minimal effort
and money required. To my astonishment, I received total $
610,470.00 in 21 weeks, with money still coming in''. Pam
Hedland, Fort Lee, New Jersey.
------------------------------------------------------------

Here is another testimonial:

''This program has been around for a long time but I never
believed in it. But one day when I received this again in
the mail I decided to gamble my $25 on it. I followed the
simple instructions and voila' - 3 weeks later the money
started to come in. First month I only made $240.00 but the
next 2 months after that I made a total of $290,000.00. So
far, in the past 8 months by re-entering the program, I have
made over $710,000.00 and I am playing it again. The key to
success in this program is to follow the simple steps and
NOT change anything'' More testimonials later but first,

****PRINT THIS NOW FOR YOUR FUTURE REFERENCE****

$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$ If
you would like to make at least $500,000 every 4 to 5 months
easily and comfortably, please read the following...THEN
READ IT AGAIN and AGAIN!!!
$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$

FOLLOW THE SIMPLE INSTRUCTION BELOW AND YOUR FINANCIAL
DREAMS WILL COME TRUE, GUARANTEED!

INSTRUCTIONS:

****Order all 5 reports shown on the list below.

****For each report, send $5 CASH, THE NAME & NUMBER OF THE
REPORT YOU ARE ORDERING and YOUR E-MAIL ADDRESS to the
person whose name appears ON THAT LIST next to the report.
MAKE SURE YOUR RETURN ADDRESS IS ON YOUR ENVELOPE TOP LEFT
CORNER in case of any mail problems.

****When you place your order, make sure you order each of
the 5 reports. You will need all 5 reports so that you can
save them on your computer and resell them. YOUR TOTAL COST
$5 X 5 = $25.00.

****Within a few days you will receive, vie e-mail, each of
the 5 reports from these 5 different individuals. Save them
on your computer so they will be accessible for you to send
to the 1,000's of people who will order them from you. Also
make a floppy of these reports and keep it on your desk in
case something happen to your computer.

****IMPORTANT __ DO NOT alter the names of the people who
are listed next to each report, or their sequence on the
list, in any way other than what is instructed below in step
'' 1 through 6 '' or you will loose out on majority of your
profits. Once you understand the way this works, you will
also see how it does not work if you change it.

Remember, this method has been tested, and if you alter, it
will NOT work!!! People have tried to put their
friends/relatives names on all five thinking they could get
all the money. But it does not work this way. Believe us, we
all have tried to be greedy and then nothing happened. So Do
Not try to change anything other than what is instructed.
Because if you do, it will not work for you. Remember,
honesty reaps the reward!!!

1....After you have ordered all 5 reports, take this
advertisement and REMOVE the name & address of the person in
REPORT #5. This person has made it through the cycle and is
no doubt counting their fortune.

2....Move the name & address in REPORT #4 down TO REPORT #5

3....Move the name & address in REPORT #3 down TO REPORT #4

4....Move the name & address in REPORT #2 down TO REPORT #3

5....Move the name & address in REPORT #1 down TO REPORT #2

6....Insert YOUR name & address in the REPORT #1 Position.

PLEASE MAKE SURE you copy every name & address ACCURATELY!
=================================================

****Take this entire letter, with the modified list of
names, and save it on your computer. DO NOT MAKE ANY OTHER
CHANGES. Save this on a disk as well just in case if you
loose any data.

****To assist you with marketing your business on the
internet, the 5 reports you purchase will provide you with
invaluable marketing information which includes how to send
bulk e-mails legally, where to find thousands of free
classified ads and much more.

There are 2 Primary methods to get this venture going:

METHOD #1 : BY SENDING BULK E-MAIL LEGALLY
================================================= Let's say
that you decide to start small, just to see how it goes, and
we will assume You and those involved send out only 5,000 e-
mails each. Let's also assume that the mailing receive only
a 0.2% response (the response could be much better but lets
just say it is only 0.2% . Also many people will send out
hundreds of thousands e-mails instead of only 5,000 each).

Continuing with this example, you send out only 5,000 e-
mails. With a 0.2% response, that is only 10 orders for
report # 1.Those 10 people responded by sending out 5,000 e-
mail each for a total of 50,000. Out of those 50,000 e-mails
only 0.2% responded with orders. That's = 100 people
responded and ordered Report # 2. Those 100 people mail out
5,000 e-mails each for a total of 500,000 e-mails. The 0.2%
response to that is 1000 orders for Report # 3. Those 1000
people send out 5,000 e-mails each for a total of 5 million
e-mails sent out. The 0.2% response to that is 10,000 orders
for Report # 4. Those 10,000 people send out 5,000 e-mails
each for a total of 50,000,000 (50 million) e-mails. The
0.2% response to that is 100,000 orders for Report # 5

THAT'S 100,000 ORDERS TIMES $5 EACH = $500,000.00 (half
million).

Your total income in this example is: 1..... $50 + 2.....
$500 + 3..... $5,000 + 4..... $50,000 + 5..... $500,000
......... Grand Total = $555,550.00

NUMBERS DO NOT LIE. GET A PENCIL & PAPER AND FIGURE OUT THE
WORST POSSIBLE RESPONSES AND NO MATTER HOW YOU CALCULATE IT,
YOU WILL STILL MAKE A LOT OF MONEY!
------------------------------------------------------------

REMEMBER FRIEND, THIS IS ASSUMING ONLY 10 PEOPLE ORDERING
OUT OF 5,000 YOU MAILED TO. Dare to think for a moment what
would happen if everyone, or half or even one 4th of those
people mailed 100,000 e-mails each or more? There are over
150 million people on the internet worldwide and counting.
Believe me, any people will do just that, and more!

METHOD #2 : BY PLACING FREE ADS ON THE INTERNET
=================================================
Advertising on the net is very very inexpensive and there
are hundreds of FREE places to advertise. Placing a lot of
free ads on the internet will easily get a larger response.
We strongly suggest you start with method #1 and add METHOD
#2 as you go along. For every $5 you receive, all you must
do is e-mail them the Report they ordered. That's it .
Always provide same day service on all orders. This will
guarantee that the e-mail they send out, with your name and
address on it, will be prompt because they cannot advertise
until they receive the report.

_________________AVAILABLE REPORTS__________________

ORDER EACH REPORT BY ITS NUMBER & NAME ONLY. Notes: Always
send $5 cash (U.S. CURRENCY) for each Report. Checks NOT
accepted. Make sure the cash is concealed by wrapping it in
at least 2 sheets of paper. On one of those sheets of paper,
Write the NUMBER & the NAME of the Report you are ordering, YOUR
E-MAIL ADDRESS and your name and postal address.

PLACE YOUR ORDER FOR THESE REPORTS NOW:
=================================================

REPORT #1 ''The Insider's Guide to Advertising for Free on
the Net''

Order Report #1 from:

M. Somerstein
9904 E 73 ST S #1004
Tulsa, OK 74133 U.S.A

_____________________________________________________

REPORT #2 ''The Insider's Guide to Sending Bulk e-mail on
the Net''

Order Report #2 from :

A. Bain
P.O. Box 811331
Chicago, IL 60681 U.S.A.

____________________________________________________

REPORT #3 ''The Secret to Multilevel marketing on the Net''

Order Report #3 from:

T. Kann
P.O. Box 218
Woody Creek, CO 81656 U.S.A.

_____________________________________________________

REPORT #4 ''How to become a millionaire utilizing MLM & the
Net''

Order Report #4 from:

Bonnie Jay
P.O. Box 1463
Montrose, CO 81402 U.S.A.

______________________________________________________

REPORT #5 ''HOW TO SEND 1 MILLION E-MAILS FOR FREE''

Order Report #5 from:

Daryn Dunn
6214 E. 126th St., Apt 302
Grandview, MO 64030
U.S.A.

____________________________________________________
$$$$$$$$$$$$ YOUR SUCCESS GUIDELINES $$$$$$$$$$$$$$

Follow these guidelines to guarantee your success:

***If you do not receive at least 10 orders for Report #1
within 2 weeks, continue sending e-mails until you do.

***After you have received 10 orders, 2 to 3 weeks after
that you should receive 100 orders or more for REPORT #2. If
you did not, continue advertising or sending e-mails until
you do.

***Once you have received 100 or more orders for Report #2,
YOU CAN RELAX, because the system is already working for you
and the cash will continue to roll in!

THIS IS IMPORTANT TO REMEMBER : Every time your name is
moved down on the list, you are placed in front of a
Different report. You can KEEP TRACK of your PROGRESS by
watching which report people are ordering from you. IF YOU
WANT TO GENERATE MORE INCOME SEND ANOTHER BATCH OF E-MAILS
AND START THE WHOLE PROCESS AGAIN. There is NO LIMIT to the
income you can generate from this business!!!
______________________________________________________

FOLLOWING IS A NOTE FROM THE ORIGINATOR OF THIS PROGRAM:

"You have just received information that can give you
financial freedom for the rest of your life, with NO RISK
and JUST A LITTLE BIT OF EFFORT. You can make more money in
the next few weeks and months than you have ever imagined.

Follow the program EXACTLY AS INSTRUCTED. Do Not change it
in any way. It works exceedingly well as it is now. Remember
to e-mail a copy of this exciting report after you have put
your name and address in Report #1 and moved others to #2
...........#5 as instructed above. One of the people you
send this to may send out 100,000 or more e-mails and your
name will be on every one of them. Remember though, the more
you send out the more potential customers you will reach.

So my friend, I have given you the ideas, information,
materials and opportunity to become financially independent.
IT IS UP TO YOU NOW!

****************MORE TESTIMONIALS*****************

'My name is Mitchell. My wife, Jody and I live in Chicago. I
am an accountant with a major U.S. Corporation and I make
pretty good money. When I received this program I grumbled
to Jody about receiving ''junk mail''. I made fun of the
whole thing, spouting my knowledge of the population and
percentages involved. I ''knew'' it wouldn't work. Jody
totally ignored my supposed intelligence and few days later
she jumped in with both feet. I made merciless fun of her,
and was ready to lay the old ''I told you so'' on her when
the thing didn't work. Well, the laugh was on me! Within 3
weeks she had received 50 responses. Within the next 45 days
she had received total $ 147,200.00 ......... all cash! I
was shocked. I have joined Jody in her ''hobby''. Mitchell
Wolf, M.D. , Chicago, Illinois
------------------------------------------------------------

''Not being the gambling type, it took me several weeks to
make up my mind to participate in this plan. But
conservative that I am, I decided that the initial
investment was so little that there was just no way that I
wouldn't get enough orders to at least get my money back''.
''I was surprised when I found my medium size post office
box crammed with orders. I made $319,210.00 in the first 12
weeks. The nice thing about this deal is that it does not
matter where people live. There simply isn't a better
investment with a faster return and so big''. Dan Sondstrom,
Alberta, Canada
------------------------------------------------------------

''I had received this program before. I deleted it, but
later I wondered if I should have given it a try. Of course,
I had no no idea who to contact

to get another copy, so I had to wait until I was e-mailed
again by someone else.........11 months passed then it
luckily came again...... I

did not delete this one! I made more than $490,000 on my
first try and all the money came within 22 weeks''. Susan De
Suza, New York, N.Y.
------------------------------------------------------------

''It really is a great opportunity to make relatively easy
money with little cost to you. I followed the simple
instructions carefully and within 10 days the money started
to come in. My first month I made $ 20, 560.00 and by the
end of third month my total cash count was $ 362,840.00.
Life is beautiful, Thanx to internet''. Fred Dellaca,
Westport, New Zealand
------------------------------------------------------------

ORDER YOUR REPORTS TODAY AND GET STARTED ON YOUR ROAD TO
FINANCIAL FREEDOM!
==================================================

If you have any questions of the legality of this program,
contact the Office of Associate Director for Marketing
Practices, Federal Trade Commission, Bureau of Consumer
Protection, Washington, D.C.

////////////////////////////////////////////////////////////

ONE TIME MAILING, NO NEED TO REMOVE

////////////////////////////////////////////////////////////

This message is sent in compliance of the proposed bill
SECTION 301. per Section 301, Paragraph (a)(2)(C) of S.
1618. Further transmission to you by the sender of this e-
mail may be stopped at no cost to you by sending a reply to: [email-masked] with the word Remove in the subject
line. This message is not intended for residents in the
State of Washington, screening of addresses has been done to
the best of our technical ability.

Received: from anchor-post-32.mail.demon.net (anchor-post-32.mail.demon.net [194.217.242.90]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id EAA26228 for ; Mon, 8 Jan 2001 04:26:16 -0800 (PST)
Received: from drh-consultancy.demon.co.uk ([193.237.150.98] helo=celocom.com) by anchor-post-32.mail.demon.net with esmtp (Exim 2.12 #1) id 14FbS6-000ObU-0W for [email-masked]; Mon, 8 Jan 2001 12:31:07 +0000
Message-ID: <[email-masked]>
Date: Mon, 08 Jan 2001 12:33:55 +0000
From: Dr S N Henson
Organization: S N Henson
X-Mailer: Mozilla 4.73 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: PKIX-List
Subject: OCSP authorized responder clarification.
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

In RFC2560 4.2.2.2 the certificate signing an OCSP request is valid if
it:

> 3. Includes a value of id-ad-ocspSigning in an ExtendedKeyUsage
> extension and is issued by the CA that issued the certificate in
> question."

A certain CA issues end user certificates signed by an intermediate CA
which is in turn signed by the root CA.

The responder certificate is signed by the root CA. Does this, as
appears to be the case, mean that the above condition does not apply
because the OCSP reponder certificate is not signed by the intermediate
CA?

Alternatively is the condition satisfied because they both have the same
root CA?

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

Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id EAA25769 for ; Mon, 8 Jan 2001 04:14: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 NAA44762; Mon, 8 Jan 2001 13:25:56 +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 NAA23532; Mon, 8 Jan 2001 13:18:32 +0100
Message-ID: <[email-masked]>
Date: Mon, 08 Jan 2001 13:18:32 +0100
From: Denis Pinkas
Organization: Bull
X-Mailer: Mozilla 4.7 [fr] (Win98; I)
X-Accept-Language: fr
MIME-Version: 1.0
To: Stephen Kent
CC: PKIX-List
Subject: Re: DPD & DPV requirements
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id EAA25770

Steve,

See my responses embbeded with your comments.

> Denis,
>
> Steve,
>
> First of all, many thanks for posting this long document.
>
> I will not respond using directly your text, since my arguments
> are fairly different. I will however re-use some of your arguments.
>
> Let us use the concept of "validation policy", that you introduce, which is
> all the set of rules to be followed when validating a certificate. It will
> usually not simply be the rules mentioned in RFC 2459, but these rules with
> additional conditions. Note that in the context of electronic signatures, a
> "signature policy" is a specific example of a "validation policy".
>

[Steve]

We need to be explicit about what are the parameters that control path
validation. The 2459 validation algorithm has a well-defined set, but if
there are others, we need to have them specified and agreed upon. One
conversation that took place in San Diego noted that one could imagine a lot
of parameters that a user might want to express re path validation, but
which have not been standardized, and for which we do not have general
agreement. A very rich list of this sort, and the associated complexity that
would accompany an enhanced validation algorithm that used thise parameters,
was thought to be out of scope for now, more an R&D topic vs. a topic for
standardization. So we have to be careful here.

[Denis]

The current validation algorithm described in RFC 2459 is fine but too
restritive. It works fine with a single root key in the case where there are
no naming constraints nor Certification Policy constraints, or in the case
where there are are included in the (root) self-signed certificates. I have
worked with Tim Polk so that in the "son-of-RFC2459" we will have the
description of an enhanced path validation algorithm that will take care of
multiple roots, each one associated with different naming constraints or
Certification Policy constraints - which will not necessarilly be included
in the root self-signed certificates.

So we would need to support two options, which are not mutually exclusive:

1) define with a great level of accuracy each of the parameters, or
2) provide an OID which is a global reference to all these parameters.

> DPV
> ===
>
> Let us start with DPV first. A DPV client will not necessarily be either
> PKI-aware, nor ASN.1 aware. I thus see two flavors for a DPV protocol:
>
> 1) one not using ASN.1 (e.g. using XML),
> 2) one using ASN.1.
>
> In both cases the client only supplies an unambiguous reference of the
> certificate (CA name, serial number and a hash of the certificate) or the
> certificate itself and specifies the rules to be followed to validate the
> certificate: an identification of a pre-defined "validation policy" (e.g. an
> OID and/or a URL to find the policy and a hash of that validation policy).
>

[Steve]

Given the problems we have had in OCSP (v1) re referring to a target cert, I
am not comfortable specifying a target cert other than by providing a copy
of that cert to the server.

[Denis]

In a signed CMS message, you may only have the EESCertID, without the
certificate itself.

ESSCertID ::= SEQUENCE {
certHash Hash,
issuerSerial IssuerSerial OPTIONAL
}

Hash ::= OCTET STRING -- SHA1 hash of entire certificate

IssuerSerial ::= SEQUENCE {
issuer GeneralNames,
serialNumber CertificateSerialNumber
}

The idea is to be able to use ESSCertID without the need to fetch the
certificate itself.

> As a result, the client expects a signed response which reproduces the
> requested parameters and includes a status. The status is not simply:
> "passed validation", "failed validation", or "don't' know" but can also be
> "incomplete validation", meaning that some revocation status information is
> not yet available at the time of processing and a later attempt might
> succeed.
>

[Steve]

Incomplete validation is a reasonable response.

[Denis]

:-)

[Steve]

maybe we should include the
set of parameters used for the validation, including ones not supplied by
the client, e.g., defaults, or overrides imposed by the server, or the
values bound to a policy that was specified.

[Denis]

We are not on the same track here. I am assuming that a DPV client is PKI
ignorant. You are making the assumption that the client MAY simply some
elements of the certification path, where I make the assumption that the
single element that MAY be supplied in a DPV request is the leaf
certificate. For all the other elements of a certification path, the server
is supposed to have access to the various repositories. The response
contains a blob of what has been used, that can be blinding copied and
stored.

> The response must include the time at which the validation has been
> performed. Allowing to test a certificate "in the past", would place some
> requirements that cannot always be accomplished by a standard PKI: currently
> we do not mandate CAs to maintain revocation information beyond the end of
> the validity period of a certificate. We should not change that rule. So I
> am very reluctant to autorise validation in the past, e.g. 10 years later.
>

[Steve]

Good points; we should include the time of the response. I added the "in the
past" requirement based on its inclusion in SCVP, but there clearly limits
to one's ability to support that feature. However, if the server is uable to
verify a cert relative to a prior time, based on unavailability of some
revocation data, it can always state that in a response. One might add a
requirement to allow the server to be configured to reject requests for
validation that cite a time/date prior to some confugured value.

[Denis]

Since archiving of recocation information is not mandated to the CAs, such a
function would need to be provided by some other trusted service provider.
We should be very careful before allowing the provision of such a new
service. I believe that the PKI is already sufficiently complex so that we
make our best efforts not to introduced additional Trusted Service Providers
(that could be avoided). The only case to be supported should be the
"current time" and some time "soon after the end of validity of a
certificate" (i.e. a few weeks, in case someone being on holidays would like
to check, when coming back from holidays, if a received message, was signed
by a revoked certificate or not).

> If a client is interested in a later proof, then it should obtain that
> information from the server at the time the information is still available.
> This means that a client should have the possibility to ask the server to
> optionally return an opaque blob that contains all what has been used to
> validate the certificate (i.e. a certification path and all the CRLs or
> OCSPs needed for each certificate from the path).
>

[Steve]

We have this requirement already, with a time stamp option.

[Denis]

We should remove the time stamp option.

> A question arises from the requirements 1.5 and 1.6 that you listed: should
> that opaque blob be time-stamped ? If there is a fear that some of the
> issuing keys used in the certification path might later on be compromised,
> then this can be useful. This case should be very seldom and hence this
> service would not always be required. In addition, why should that service
> be embedded in this protocol ? This could be obtained using directly the
> TSP, leaving more possibilities: free choice of the TSAs, time stamp of the
> full blob, time stamp of the certification chain only, time stamp on both
> the certification chain and the revocation information. Thus I do not favor
> to piggy-back the two services.
>

[Steve]

Yes, one could keep the services separate. I am not hard over on this, and
can be persuaded to remove the requirement, or to make server support for it
optional.

[Denis]

If you are not hard on this issue, let us remove the time stamping option.

:-)

> In order to simplify the protocol and allow for PKI-ignorant clients, the
> client should NOT be allowed to provide any other element than the
> certificate, that might help to construct the path or the revocation
> information.
>

[Steve]

I don't see the rationale for this. We already have application protocols
where a client that is not PKI-aware might acquire cert paths and/or
revocation data that it could pass on to a DPV server. So, I don't think you
have made a good argument here for not allowing such data to be transmitted.
Also, I don't think we have agreement yet that we are supporting clients
that are not PKI-aware. I merely noted that IF we choose to support such
clients, then there are implications for the syntax used for the protocol,
and for the semantics of what is transmitted. I don't think we have made the
next step to agree to support such clients.

[Denis]

I have difficulties to understand how a client that would NOT be "PKI-aware
might acquire cert paths and/or revocation data" :-)

Once again, I am advocating a simple protocol for DPV to be used by PKI
ignorant clients.

> This means that, not only I do not agree with a common list of requirements
> for both DPV and DPD, but also that I do not agree with many of the
> requirements that you listed:
>
> For a DPV client:
>
> 1.1. Only a single certificate should be allowed.
> 1.2. No revocation items should be allowed.
> 1.3. No request in the past should be allowed.
> 1.4. Imposing constraints for CRLs or OCSP responses should be hidden
> under the "validation policy" that is selected.
> 1.5. and 1.6. Time stamped responses, if needed, should not be part of the
> service.
> 1.7. Validation policies are not necessarily "configured at the server",
> but can simply be pre-defined, outside the server. I any case, the
> rules that has been followed - i.e. "validation policy" - must be
> indicated in the response.
> 1.8. For DPV, responses must be signed.
> 1.9. The policy ID format can/will be specified in the protocol.
>
> For a DPV server:
>
> 2.1. A DPV server, will have to do more than RFC 2459, hence why the use
> of a validation policy is needed.
> 2.2. An opaque blob MAY be returned.
> 2.3. Time stamping is not needed.
> 2.4. The concept of policy overriding is too complex: a reference to
> a validation policy is sufficient.
> 2.5. No comment.
> 2.6. A server must support LDAP for certificate fetching, and EITHER CRL
> fetching OR OSCP (OCSP should not be mandatory).
> 2.7. No comment.
>

[Steve]

Given that we no longer agree on the underlying assumptions, it probably is
not worthwhile discussing each of your proposed changes above.

[Denis]

Yes and no. We clearly have different assumptions, but we need to find an
agreement. I am first advocating to separate the requirements for DPV from
the requirements for DPD. Then we need to discuss the requirements for each
of them. So we need to come with separate lists of requirements. This is
what I did in my response.

> DPD
> ===
>
> Let us continue with DPD. I agree in general with many of the requirements
> that you listed in that case. In particular, since a DPD client must be both
> PKI-aware and ASN.1 aware, the protocol should only be described in ASN.1.
>
> The major difference with the previous protocol is that no evaluation of the
> returned chain needs to be done, since the client is supposed to be able to
> perform all the checks himself. Therefor no validation status is returned by
> the server.
>

[Steve]

I don't think I agree with both of the statements above. No explicit
validation status is returned, but I do think the server is performing
validation so that only valid chains are returned.

[Denis]

Since these chains may not be complete, I would not consider such chains to
be "valid". These chains will comply with the request, but some elements
(more probably revovation information, but also certificates ?) may be
missing.

> The service is more a single place for shopping all (?) the needed
> certificates and revocation status information.
>
> In the request, the client could either specify a validation policy or the
> trusted points with, for each level of the chain, the indication whether
> CRLs or OCSP responses are requested.
>
> One or more chains, corresponding to the request may be obtained.
>
> The response does not need to be signed, but only protected by a combined
> integrity and data origin authentication service.
>
> CONCLUSION
> ==========
>
> We could support three protocols:
>
> 1° DPV in XML,
> 2° DPV in ASN.1,
> 3° DPD in ASN.1.
>
[Steve]

The operative term here is "could." Also, DPV in XML and DPV in ASN.1 need
not be the same protocol, because of different assumptions about the
clients. So I think of it three protocols where 2 & 3 may be very similar,
but 1 is quite different.

[Denis]

Two remarks:

1) What kind of different assumptions are you making on:

1) DPV in XML and
2) DPV in ASN.1 ?

2) You think that protocols 2 & 3 may be very similar, but you do not
provide arguments. On the contrary, I do not think the same and I have have
provided arguments to explain why they are pretty different.

> ADDITIONAL QUESTION
> ===================
>
> For the two protocols in ASN.1, should these two protocols be piggy-back on
> OCSP ?
>

[Steve]

That's one of the proposals, but the answer should be the result of analysis
of a revised proposal consistent with the requirements that we adopt.

[Denis]

Agreed.

> Before going at the technical details, it is important to raise the
> following question: which combination(s) of the three basic requests (OCSP,
> DPV and DPD) could make sense ?
>
> If a client requests DPV, then it does not care about OCSP and neither on
> DPD (multiple certification chains to be tested).
>
> For a PKI-aware client, only OCSP + DPD makes sense.
>
> This means that :
>
> 1) DPV does not need to be supported by OCSP.
> 2) The only protocol to be piggy-backed to OCSP would be DPD.
>

[Steve]

I don't understand these comments. You need to provide more substantiation.

[Denis]

OK. Let me try to explain more:

" If a client requests DPV, then it does not care about OCSP and neither on
DPD (multiple certification chains to be tested)."

If a client requests DPV, it would normally like to get the response "passed
validation", and will ask whether or not it wants back the single proof (as
a blob) that lead to that conclusion. In that case, it does not care about
the OCSP response which has been used in the validation algorithm and is
part from the blob. A single chain is returned in that case.

"For a PKI-aware client, only OCSP + DPD makes sense.
This means that :

1) DPV does not need to be supported by OCSP.
2) The only protocol to be piggy-backed to OCSP would be DPD."

DPV is NOT designed for a PKI-aware client, but of course can be used by a
PKI aware client, that will behave as if it were PKI ignorant.

So the single combination that remains is between the two remaining
protocols for PKI-aware clients (i.e. OCSP and DPD). In that sense, DPD
could be piggy-backed on top of OCSP.

Denis

> Steve

Received: from edelweb.fr (edelweb.fr [212.234.46.16]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id DAA24454 for ; Mon, 8 Jan 2001 03:46:21 -0800 (PST)
Received: from champagne.edelweb.fr (localhost.edelweb.fr [127.0.0.1]) by edelweb.fr with ESMTP id MAA03744; Mon, 8 Jan 2001 12:51:05 +0100 (MET)
Received: from champagne.edelweb.fr (champagne.edelweb.fr [193.51.14.161]) by edelweb.fr (nospam/1.3); Mon, 8 Jan 2001 12:51:05 +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 MAA19405; Mon, 8 Jan 2001 12:51:03 +0100 (MET)
From: Peter Sylvester
Received: (sylvest@localhost) by emeriau.edelweb.fr (8.7.6/8.6.6) id MAA16511; Mon, 8 Jan 2001 12:51:03 +0100 (MET)
Date: Mon, 8 Jan 2001 12:51:03 +0100 (MET)
Message-Id: <[email-masked]>
To: [email-masked]
Subject: RE: DPD & DPV requirements - Let us Recurse
Cc: [email-masked]

>
> Returning info that explains why a server believes that the returned
> data supports validation is an interesting notion. The first example
> of that I saw was in work performed by colleagues here at BBN, on a
> project calls IOS, in the early 90s, where servers did that. But, I
> think this is still an R&D topic for now, not yet ready for
> standardization.

Isn't part of this 'interesting notion' the cert chain itself. The
certificate chain return by a DPV server is the chain that has
been used to validate it, and the server believes that this chain
is valid.

If the service is implemented using some relaying, such that a
server becomes a client of someone else, what research problem
is there that the intermediate server/client wants to provide the
results? If for the initial client the result of the validation
becomes something that can be stored somewhere, e.g. similar to
an OCSP response stored in the SMIME/ETSI signature format stuff,
then essentially this client becomes an intermediate server for
another verifier of the enhanced signature.

Received: from venus.initech.com ([203.238.37.132]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id AAA03081 for ; Mon, 8 Jan 2001 00:28:48 -0800 (PST)
Received: from initech.com ([203.238.37.143]) by venus.initech.com (8.11.0/8.11.0) with ESMTP id f088Tlj02631 for ; Mon, 8 Jan 2001 17:29:47 +0900 (KST)
Message-ID: <[email-masked]>
Date: Mon, 08 Jan 2001 17:33:32 +0900
From: ChungKil Kim
X-Mailer: Mozilla 4.76 [en] (Win98; U)
X-Accept-Language: en,ko
MIME-Version: 1.0
To: [email-masked]
Subject: Experimental TSA
Content-Type: text/plain; charset=EUC-KR
Content-Transfer-Encoding: 7bit

Our TSA service is available at the following
address 203.238.37.132 , port 3318.

this TSA is TCP/IP based service.
Implementation based on draft-ietf-pkix-time-stamp-12.txt

thanks

Received: from fsnt.future.futsoft.com ([203.197.140.35]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id WAA15728 for ; Sun, 7 Jan 2001 22:03:54 -0800 (PST)
Received: from kailash.future.futsoft.com (unverified) by fsnt.future.futsoft.com (Content Technologies SMTPRS 2.0.15) with ESMTP id for ; Mon, 08 Jan 2001 11:43:24 +0530
Received: from ruheenar (ruheenar.future.futsoft.com [10.0.12.41]) by kailash.future.futsoft.com (8.11.0/8.11.0) with SMTP id f0868O217357 for ; Mon, 8 Jan 2001 11:38:25 +0530
Reply-To:
From: "Ruheena Rashid"
To:
Subject: unsubscribe
Date: Mon, 8 Jan 2001 11:46:32 +0530
Message-Id: <[email-masked]>
MIME-Version: 1.0
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0)
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600
Importance: Normal
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

unsubscribe

Received: from maila.telia.com (maila.telia.com [194.22.194.231]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA23295 for ; Sun, 7 Jan 2001 09:44:25 -0800 (PST)
Received: from d1o69.telia.com (d1o69.telia.com [62.20.144.241]) by maila.telia.com (8.9.3/8.9.3) with ESMTP id SAA11942; Sun, 7 Jan 2001 18:49:11 +0100 (CET)
Received: from mega (t7o69p165.telia.com [213.65.46.165]) by d1o69.telia.com (8.10.2/8.10.1) with SMTP id f07HnAl18592; Sun, 7 Jan 2001 18:49:10 +0100 (CET)
Message-ID: <[email-masked]>
From: "Anders Rundgren"
To:
Cc:
References: <[email-masked]>
Subject: Re: Basic Cert-2-Directory mapping question
Date: Sun, 7 Jan 2001 18:45:25 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
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
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id JAA23297

Peter,
Thanx for the very elaborate answer that matched my worst fears about TTP-issued
certificates! I could not find your paper though - please send me it directly and I will respond
with a paper that I am currently working on, on how to solve this problem. Would you
BTW be interested in participating in a BOF-like feasibility study to see if DNs must continue
to be broken until the end of time? Or maybe you have already given IYNSHO the likely outcome of
such a study :-):-)

/Anders

> Anders Rundgren writes:
>
> >The question rephrased: How could an RFC2459-compliant cert using an
> >arbitrary DN map in an equally arbitrary X.500-compliant directory?
> >Arbitrary could also be expressed in this context as: The certs are not
> >tailor-made for this particular directory. This is what you get if you for
> >example buy a Swedish Electronic ID-card based on a citizen registration
> >system that usually have no relevance in a private company. Still you would
> >like to use it in that context and the question is how? The answer is
> >mapping and my question was how you do that using *directory technology*
> >using an (hopefully) standardized method.
>
> You can't do it. Actually the answer is a lot more complex than that, I
> looked at it in my ACASC'00 paper on certificate stores which should be
> available from http://www.acsac.org, this is a shorter version due to size
> constraints of a somewhat longer work which I'll put on my home page within
> the next week or two (it's the middle of the summer break over here, so some
> things are running at a low priority).
>
> The main problem is that DN's don't work [0], so you end up with ones which
> people have filled with whatever they feel like, odd things required by cert
> profiles or signature laws or organisational constraints or whatever which
> generally don't fit any known directory schema. The current approaches to
> this problem if you're using a directory as a cert store are:
>
> - Continually update the directory schema to match any new DNs which appear
> until the directory admin(s) go insane (hi Paul :-).
> - Create aliases in the directory mapping DNs in certs to the (fixed)
> directory schema.
> - Force all certs to use the schema used in the directory (someone who's
> been through this one once described it to me as "extraordinarily painful").
> - Use the directory DN to identify the cert owner and store the cert as just
> another attribute, with the actual cert DN ignored.
> - (There may be more, since the whole thing is badly broken there are
> probably lots of workarounds being used. If anyone knows of others
> please let me know)
>
> A much better approach IMNSHO, and the one I look at in my paper, is to treat
> the DN as a blob and hash it down to a fixed-length value which you use as a
> key to look up the cert in an RDBMS or something like dbm if you don't need
> the full RDBMS functionality [1]. This approach just plain works no matter
> how garbled and broken the DN is.
>
> That's the short version, the longer one, with a fairly detailed analysis of
> requirements and performance issues, will be on the paper I'll have on my home
> page and in the ACSAC version.
>
> Peter.
>
> [0] Strictly speaking this should say "After ~15 years of trying to make them
> work noone's really managed it", but I usually generalise it to "DN's
> don't work" to save having to update the year count every year or so.
>
> [1] One somewhat surprising thing I found out during and after publishing the
> paper is how many vendors are actually using RDBMS' as cert stores, even
> if they have to bolt an X.500/LDAP interface on top of them. I only know
> of one vendor which isn't using either an RDBMS or dbm with an X.500 glue
> layer on top for their cert store (not counting toy stuff like MS using
> the registry to store certs).
>

Received: from mail.ec.auckland.ac.nz (mail.student.auckland.ac.nz [130.216.35.201]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA17316 for ; Sun, 7 Jan 2001 08:03:21 -0800 (PST)
Received: from kahu.cs.auckland.ac.nz ([email-masked] [130.216.36.13]) by mail.ec.auckland.ac.nz (8.9.3/8.8.6/cs-master) with SMTP id FAA10605; Mon, 8 Jan 2001 05:07:53 +1300 (NZDT) (sender [email-masked])
Received: by kahu.cs.auckland.ac.nz (relaymail v0.9) id <97888367312331>; Mon, 8 Jan 2001 05:07:53 (NZDT)
From: [email-masked] (Peter Gutmann)
To: [email-masked], [email-masked]
Subject: Re: Basic Cert-2-Directory mapping question
Cc: [email-masked]
Sender: [email-masked]
Reply-To: [email-masked]
X-Charge-To: pgut001
X-Authenticated: relaymail v0.9 on kahu.cs.auckland.ac.nz
Date: Mon, 8 Jan 2001 05:07:53 (NZDT)
Message-ID: <[email-masked]>

"Anders Rundgren" writes:

>The question rephrased: How could an RFC2459-compliant cert using an
>arbitrary DN map in an equally arbitrary X.500-compliant directory?
>Arbitrary could also be expressed in this context as: The certs are not
>tailor-made for this particular directory. This is what you get if you for
>example buy a Swedish Electronic ID-card based on a citizen registration
>system that usually have no relevance in a private company. Still you would
>like to use it in that context and the question is how? The answer is
>mapping and my question was how you do that using *directory technology*
>using an (hopefully) standardized method.

You can't do it. Actually the answer is a lot more complex than that, I
looked at it in my ACASC'00 paper on certificate stores which should be
available from http://www.acsac.org, this is a shorter version due to size
constraints of a somewhat longer work which I'll put on my home page within
the next week or two (it's the middle of the summer break over here, so some
things are running at a low priority).

The main problem is that DN's don't work [0], so you end up with ones which
people have filled with whatever they feel like, odd things required by cert
profiles or signature laws or organisational constraints or whatever which
generally don't fit any known directory schema. The current approaches to
this problem if you're using a directory as a cert store are:

- Continually update the directory schema to match any new DNs which appear
until the directory admin(s) go insane (hi Paul :-).
- Create aliases in the directory mapping DNs in certs to the (fixed)
directory schema.
- Force all certs to use the schema used in the directory (someone who's
been through this one once described it to me as "extraordinarily painful").
- Use the directory DN to identify the cert owner and store the cert as just
another attribute, with the actual cert DN ignored.
- (There may be more, since the whole thing is badly broken there are
probably lots of workarounds being used. If anyone knows of others
please let me know)

A much better approach IMNSHO, and the one I look at in my paper, is to treat
the DN as a blob and hash it down to a fixed-length value which you use as a
key to look up the cert in an RDBMS or something like dbm if you don't need
the full RDBMS functionality [1]. This approach just plain works no matter
how garbled and broken the DN is.

That's the short version, the longer one, with a fairly detailed analysis of
requirements and performance issues, will be on the paper I'll have on my home
page and in the ACSAC version.

Peter.

[0] Strictly speaking this should say "After ~15 years of trying to make them
work noone's really managed it", but I usually generalise it to "DN's
don't work" to save having to update the year count every year or so.

[1] One somewhat surprising thing I found out during and after publishing the
paper is how many vendors are actually using RDBMS' as cert stores, even
if they have to bolt an X.500/LDAP interface on top of them. I only know
of one vendor which isn't using either an RDBMS or dbm with an X.500 glue
layer on top for their cert store (not counting toy stuff like MS using
the registry to store certs).

Received: from mailf.telia.com ([email-masked] [194.22.194.25]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id WAA22699 for ; Sat, 6 Jan 2001 22:15:49 -0800 (PST)
Received: from d1o69.telia.com (d1o69.telia.com [62.20.144.241]) by mailf.telia.com (8.9.3/8.9.3) with ESMTP id HAA04978; Sun, 7 Jan 2001 07:20:33 +0100 (CET)
Received: from mega (t3o69p53.telia.com [62.20.145.53]) by d1o69.telia.com (8.10.2/8.10.1) with SMTP id f076KWl24461; Sun, 7 Jan 2001 07:20:32 +0100 (CET)
Message-ID: <[email-masked]>
From: "Anders Rundgren"
To: "Richard Levitte at Celo"
Cc: "PKIX-List"
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Subject: Re: Basic Cert-2-Directory mapping question
Date: Sun, 7 Jan 2001 07:18:56 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
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
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id WAA22700

Richard,

> Anders Rundgren wrote:
> > The key issue is: How do you map/match using *X500 directory technology* (in contrast
> > to using RDBMSs where this is a piece of cake), an arbitrary certificate with an equally arbitrary
> > directory entry in an efficient and standard-conformant way?
>
> Ah... Eh, you got me stumped there. You see, I was under the impression that
> certificate DNs (I assume we're talking RFC2459 or X.509 certificates heer)
> would map more or less directly into a X.500 directory with no trouble at all.
> But then, I don't know X.500 that well, so I may be talking out of my behind...

The question rephrased: How could an RFC2459-compliant cert using an arbitrary DN map
in an equally arbitrary X.500-compliant directory? Arbitrary could also be expressed in
this context as: The certs are not tailor-made for this particular directory. This is what you
get if you for example buy a Swedish Electronic ID-card based on a citizen registration system
that usually have no relevance in a private company. Still you would like to use it in that
context and the question is how? The answer is mapping and my question was how you
do that using *directory technology* using an (hopefully) standardized method.

> > That this is not that easy is demonstrated by the fact that you (AFAIK) cannot use
> > anthyning but a Win2K kerberos certificate to perform a local Win2K PKI-based login.
> > If you have a
> > PKI credential (for example in a GemSAFE card) it will only be usable in one domain
> > which is awkward as you (as a person) may be trusted in multiple *independent* places.
>
> I've always wondered what those "Kerberos Certificates" are, or do you mean
> tickets? They have nothing to do with PKI, since Kerberos doesn't use PKC.
> Could this not just be an IP security policy problem? (in that case, this
> discussion has nothing more to do on this list)

No, maybe the name is bad but I referred to the certificates that the Win2K kerberos accepts
which currently is AFAIK limited to certs issued by the domain controller CA itself (approx.)
which results in the problems noted.

Anders

Received: from ns.celocom.se ([email-masked] [212.209.40.66]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id RAA19530 for ; Sat, 6 Jan 2001 17:27:21 -0800 (PST)
Received: by ns.celocom.se; id CAA17809; Sun, 7 Jan 2001 02:32:04 +0100 (CET)
Received: from unknown(10.10.10.1) by ns.celocom.se via smap (V5.0) id xma017803; Sun, 7 Jan 01 02:31:42 +0100
Received: from celocom.se (root@localhost [127.0.0.1]) by zap.celocom.se (8.8.7/8.8.7) with ESMTP id CAA15308; Sun, 7 Jan 2001 02:31:41 +0100
Sender: [email-masked]
Message-ID: <[email-masked]>
Date: Sun, 07 Jan 2001 02:29:54 +0100
From: Richard Levitte at Celo
Organization: Celo Communications, Ltd.
X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.18 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Anders Rundgren
CC: PKIX-List , Philip Hallam-Baker
Subject: Re: Basic Cert-2-Directory mapping question
References: <[email-masked]> <[email-masked]> <[email-masked]>
Content-Type: multipart/mixed; boundary="------------4A785FE1164DF9E6EE8B9E93"

This is a multi-part message in MIME format.
--------------4A785FE1164DF9E6EE8B9E93
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Anders Rundgren wrote:
> The key issue is: How do you map/match using *X500 directory technology* (in contrast
> to using RDBMSs where this is a piece of cake), an arbitrary certificate with an equally arbitrary
> directory entry in an efficient and standard-conformant way?

Ah... Eh, you got me stumped there. You see, I was under the impression that
certificate DNs (I assume we're talking RFC2459 or X.509 certificates heer)
would map more or less directly into a X.500 directory with no trouble at all.
But then, I don't know X.500 that well, so I may be talking out of my behind...

> That this is not that easy is demonstrated by the fact that you (AFAIK) cannot use
> anthyning but a Win2K kerberos certificate to perform a local Win2K PKI-based login.
> If you have a
> PKI credential (for example in a GemSAFE card) it will only be usable in one domain
> which is awkward as you (as a person) may be trusted in multiple *independent* places.

I've always wondered what those "Kerberos Certificates" are, or do you mean
tickets? They have nothing to do with PKI, since Kerberos doesn't use PKC.
Could this not just be an IP security policy problem? (in that case, this
discussion has nothing more to do on this list)

--
Richard Levitte !!! New cell phone number !!!
[email-masked]

/* You might enjoy viewing the complete vCard */
--------------4A785FE1164DF9E6EE8B9E93
Content-Type: text/x-vcard; charset=us-ascii;
name="richard.levitte.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Richard Levitte at Celo
Content-Disposition: attachment;
filename="richard.levitte.vcf"

begin:vcard
n:Levitte;Richard
tel;cell:+46-733-72 8811
tel;work:+46-8-58 72 8811
x-mozilla-html:FALSE
org:Celo Communications
version:2.1
email;internet:[email-masked]
title:Software Artist
adr;quoted-printable:;;Sveav=E4gen 145, 5tr=0D=0AStockholm;;;;SWEDEN
note;quoted-printable:
=0D=0A
=0D=0A
=0D=0A
c=EAlo, =E2vi, =E2tum, (latin) 1,v.a.=0D=0A to hide something from one, to keep secret, to conceal.=0D=0A
=0D=0A
=0D=0A
=0D=0A
=0D=0A
=0D=0A
=0D=0A
=0D=0A
=0D=0A
=0D=0A
o/~
=0D=0A
Coding, coding, coding
=0D=0A Keep'em hackers coding
=0D=0A And When They're Done Coding
=0D=0A COMPIIIIIIILE!!
=0D=0A
=0D=0A
=0D=0A
=0D=0A
=0D=0A

x-mozilla-cpt:;0
fn:Richard Levitte
end:vcard

--------------4A785FE1164DF9E6EE8B9E93--

Received: from maild.telia.com ([email-masked] [194.22.190.3]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id DAA08609 for ; Sat, 6 Jan 2001 03:35:48 -0800 (PST)
Received: from d1o69.telia.com (d1o69.telia.com [62.20.144.241]) by maild.telia.com (8.9.3/8.9.3) with ESMTP id MAA20975; Sat, 6 Jan 2001 12:40:24 +0100 (CET)
Received: from mega (t3o69p72.telia.com [62.20.145.72]) by d1o69.telia.com (8.10.2/8.10.1) with SMTP id f06BeNl20508; Sat, 6 Jan 2001 12:40:24 +0100 (CET)
Message-ID: <[email-masked]>
From: "Anders Rundgren"
To: "Richard Levitte at Celo" , "PKIX-List"
Cc: "Philip Hallam-Baker"
References: <[email-masked]> <[email-masked]>
Subject: Re: Basic Cert-2-Directory mapping question
Date: Sat, 6 Jan 2001 12:38:47 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
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
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id DAA08611

Richard,

> If I understand things correctly, you need support for one-to-many of
> certificate-to-direntry, because
>
> CN=James Adrian Smith + SN=343434
>
> would map both to
>
> /CN=James Adrian Smith
>
> and
>
> /SN=343434
>
> If I'm incorrect, I'll gladly be corrected.

No, that was not exactly what I searched for. As a side note: Regarding SN I thought that it denoted
serial number that could be used as an entity UID.

The key issue is: How do you map/match using *X500 directory technology* (in contrast
to using RDBMSs where this is a piece of cake), an arbitrary certificate with an equally arbitrary
directory entry in an efficient and standard-conformant way?

That this is not that easy is demonstrated by the fact that you (AFAIK) cannot use
anthyning but a Win2K kerberos certificate to perform a local Win2K PKI-based login. If you have a
PKI credential (for example in a GemSAFE card) it will only be usable in one domain
which is awkward as you (as a person) may be trusted in multiple *independent* places.

####################################################################
Essentially the value of TTP-issued ID-certificates is severely reduced by such limitations.
Commercial CA vendors out there! Are you listening?
####################################################################

The request for many-to-one mappings is optional but potentially extremely useful as you
could end-up having different credentials in your PDA than in your smart card.

If my findings are correct I would say this this issue should absolutely be studied to see if there
is a feasibility to come up with a generic solution. Yet Another Standard that is.

/Anders

Received: from heather.ithnet.com (ns.ithnet.com [62.157.157.10]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id CAA02146 for ; Sat, 6 Jan 2001 02:57:47 -0800 (PST)
Received: by heather.ithnet.com (Smail3.2 #4) id m14Er7D-000Dz9C; Sat, 6 Jan 2001 12:02:27 +0100 (CET)
Received: from gate.ots-erdl.de(62.157.156.209), claiming to be "gate.ots-ag.de" via SMTP by mail2.ithnet.com, id smtpdWeWliQ; Sat Jan 6 12:02:13 2001
Received: from newsmail.com ([193.255.114.246]) by gate.ots-ag.de (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with SMTP id MAA08959 for ; Sat, 6 Jan 2001 12:01:44 +0100
Date: Sat, 6 Jan 2001 12:01:44 +0100
Message-Id: <[email-masked]>
Reply-To: [email-masked]
Content-Type: text/html; charset=us-ascii
X-Priority: 1
From: House of Pleasure
To: [email-masked]
Subject: NEW CYBERPAGE IN SPACE, HAVE FUN

Hello There,

Threre is a very new Website aboub fun, fun and fun again.

The URL is http://www.h-o-p.de

visit it !!!!

HOP Webmaster.

This email was sent via Ellipse Bulk Emailer v2.0

Received: from ns.celocom.se ([email-masked] [212.209.40.66]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id AAA20531 for ; Sat, 6 Jan 2001 00:53:18 -0800 (PST)
Received: by ns.celocom.se; id JAA15387; Sat, 6 Jan 2001 09:57:58 +0100 (CET)
Received: from unknown(10.10.10.1) by ns.celocom.se via smap (V5.0) id xma015383; Sat, 6 Jan 01 09:57:17 +0100
Received: from celocom.se (root@localhost [127.0.0.1]) by zap.celocom.se (8.8.7/8.8.7) with ESMTP id JAA09532; Sat, 6 Jan 2001 09:57:16 +0100
Sender: [email-masked]
Message-ID: <[email-masked]>
Date: Sat, 06 Jan 2001 09:55:30 +0100
From: Richard Levitte at Celo
Organization: Celo Communications, Ltd.
X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.18 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Anders Rundgren , PKIX-List
Subject: Re: Basic Cert-2-Directory mapping question
References: <[email-masked]> <[email-masked]>
Content-Type: multipart/mixed; boundary="------------D659D55E13529837EA4826C9"

This is a multi-part message in MIME format.
--------------D659D55E13529837EA4826C9
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Sorry for the double message. I had some trouble on my end and it looked like
the first try didn't get through...

--
Richard Levitte !!! New cell phone number !!!
[email-masked]

/* You might enjoy viewing the complete vCard */
--------------D659D55E13529837EA4826C9
Content-Type: text/x-vcard; charset=us-ascii;
name="richard.levitte.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Richard Levitte at Celo
Content-Disposition: attachment;
filename="richard.levitte.vcf"

begin:vcard
n:Levitte;Richard
tel;cell:+46-733-72 8811
tel;work:+46-8-58 72 8811
x-mozilla-html:FALSE
org:Celo Communications
version:2.1
email;internet:[email-masked]
title:Software Artist
adr;quoted-printable:;;Sveav=E4gen 145, 5tr=0D=0AStockholm;;;;SWEDEN
note;quoted-printable:
=0D=0A
=0D=0A
=0D=0A
c=EAlo, =E2vi, =E2tum, (latin) 1,v.a.=0D=0A to hide something from one, to keep secret, to conceal.=0D=0A
=0D=0A
=0D=0A
=0D=0A
=0D=0A
=0D=0A
=0D=0A
=0D=0A
=0D=0A
=0D=0A
o/~
=0D=0A
Coding, coding, coding
=0D=0A Keep'em hackers coding
=0D=0A And When They're Done Coding
=0D=0A COMPIIIIIIILE!!
=0D=0A
=0D=0A
=0D=0A
=0D=0A
=0D=0A

x-mozilla-cpt:;0
fn:Richard Levitte
end:vcard

--------------D659D55E13529837EA4826C9--

Received: from ns.celocom.se ([email-masked] [212.209.40.66]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id AAA17727 for ; Sat, 6 Jan 2001 00:40:18 -0800 (PST)
Received: by ns.celocom.se; id JAA15220; Sat, 6 Jan 2001 09:44:58 +0100 (CET)
Received: from unknown(10.10.10.1) by ns.celocom.se via smap (V5.0) id xma015209; Sat, 6 Jan 01 09:44:32 +0100
Received: from celocom.se (root@localhost [127.0.0.1]) by zap.celocom.se (8.8.7/8.8.7) with ESMTP id JAA09457; Sat, 6 Jan 2001 09:44:31 +0100
Sender: [email-masked]
Message-ID: <[email-masked]>
Date: Sat, 06 Jan 2001 09:42:46 +0100
From: Richard Levitte at Celo
Organization: Celo Communications, Ltd.
X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.18 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Anders Rundgren
CC: PKIX-List
Subject: Re: Basic Cert-2-Directory mapping question
References: <[email-masked]>
Content-Type: multipart/mixed; boundary="------------E7551AC1AED3DDBAB3E04901"

This is a multi-part message in MIME format.
--------------E7551AC1AED3DDBAB3E04901
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

If I understand things correctly, you need support for one-to-many of
certificate-to-direntry, because

CN=James Adrian Smith + SN=343434

would map both to

/CN=James Adrian Smith

and

/SN=343434

If I'm incorrect, I'll gladly be corrected.

Anders Rundgren wrote:
>
> Basic question from an RDBMS-hack.
>
> Assume you have a directory structure like
>
> /O=Internet/DC=COM/DC=Acme/CN=Users/CN=James A Smith
>
> Now you have a [probably TTP-issued] certificate for this person with a DN
>
> CN=James Adrian Smith + SN=343434
>
> How do you map/match such a "alien" certificate in an efficient and easy-to-adminster way
> using directory technology? The solution should support many-to-one mappings
> of certificates-to-individuals. To make it simple, ignore the issuer part.

--
Richard Levitte !!! New cell phone number !!!
[email-masked]

/* You might enjoy viewing the complete vCard */
--------------E7551AC1AED3DDBAB3E04901
Content-Type: text/x-vcard; charset=us-ascii;
name="richard.levitte.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Richard Levitte at Celo
Content-Disposition: attachment;
filename="richard.levitte.vcf"

begin:vcard
n:Levitte;Richard
tel;cell:+46-733-72 8811
tel;work:+46-8-58 72 8811
x-mozilla-html:FALSE
org:Celo Communications
version:2.1
email;internet:[email-masked]
title:Software Artist
adr;quoted-printable:;;Sveav=E4gen 145, 5tr=0D=0AStockholm;;;;SWEDEN
note;quoted-printable:
=0D=0A
=0D=0A
=0D=0A
c=EAlo, =E2vi, =E2tum, (latin) 1,v.a.=0D=0A to hide something from one, to keep secret, to conceal.=0D=0A
=0D=0A
=0D=0A
=0D=0A
=0D=0A
=0D=0A
=0D=0A
=0D=0A
=0D=0A
=0D=0A
o/~
=0D=0A
Coding, coding, coding
=0D=0A Keep'em hackers coding
=0D=0A And When They're Done Coding
=0D=0A COMPIIIIIIILE!!
=0D=0A
=0D=0A
=0D=0A
=0D=0A
=0D=0A

x-mozilla-cpt:;0
fn:Richard Levitte
end:vcard

--------------E7551AC1AED3DDBAB3E04901--

Received: from ns.celocom.se ([email-masked] [212.209.40.66]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id AAA17180 for ; Sat, 6 Jan 2001 00:37:21 -0800 (PST)
Received: by ns.celocom.se; id JAA15192; Sat, 6 Jan 2001 09:41:58 +0100 (CET)
Received: from unknown(10.10.10.1) by ns.celocom.se via smap (V5.0) id xma015188; Sat, 6 Jan 01 09:41:22 +0100
Received: from celocom.se (root@localhost [127.0.0.1]) by zap.celocom.se (8.8.7/8.8.7) with ESMTP id JAA09429; Sat, 6 Jan 2001 09:41:21 +0100
Sender: [email-masked]
Message-ID: <[email-masked]>
Date: Sat, 06 Jan 2001 09:39:34 +0100
From: Richard Levitte at Celo
Organization: Celo Communications, Ltd.
X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.18 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Anders Rundgren
CC: PKIX-List
Subject: Re: Basic Cert-2-Directory mapping question
References: <[email-masked]>
Content-Type: multipart/mixed; boundary="------------6EE9DA735EFDC58FE31BDC3E"

This is a multi-part message in MIME format.
--------------6EE9DA735EFDC58FE31BDC3E
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

If I understand things correctly, you need support for one-to-many of
certificate-to-direntry, because

CN=James Adrian Smith + SN=343434

would map both to

/CN=James Adrian Smith

and

/SN=343434

If I'm incorrect, I'll gladly be corrected.

Anders Rundgren wrote:
>
> Basic question from an RDBMS-hack.
>
> Assume you have a directory structure like
>
> /O=Internet/DC=COM/DC=Acme/CN=Users/CN=James A Smith
>
> Now you have a [probably TTP-issued] certificate for this person with a DN
>
> CN=James Adrian Smith + SN=343434
>
> How do you map/match such a "alien" certificate in an efficient and easy-to-adminster way
> using directory technology? The solution should support many-to-one mappings
> of certificates-to-individuals. To make it simple, ignore the issuer part.

--
Richard Levitte !!! New cell phone number !!!
[email-masked]

/* You might enjoy viewing the complete vCard */
--------------6EE9DA735EFDC58FE31BDC3E
Content-Type: text/x-vcard; charset=us-ascii;
name="richard.levitte.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Richard Levitte at Celo
Content-Disposition: attachment;
filename="richard.levitte.vcf"

begin:vcard
n:Levitte;Richard
tel;cell:+46-733-72 8811
tel;work:+46-8-58 72 8811
x-mozilla-html:FALSE
org:Celo Communications
version:2.1
email;internet:[email-masked]
title:Software Artist
adr;quoted-printable:;;Sveav=E4gen 145, 5tr=0D=0AStockholm;;;;SWEDEN
note;quoted-printable:
=0D=0A
=0D=0A
=0D=0A
c=EAlo, =E2vi, =E2tum, (latin) 1,v.a.=0D=0A to hide something from one, to keep secret, to conceal.=0D=0A
=0D=0A
=0D=0A
=0D=0A
=0D=0A
=0D=0A
=0D=0A
=0D=0A
=0D=0A
=0D=0A
o/~
=0D=0A
Coding, coding, coding
=0D=0A Keep'em hackers coding
=0D=0A And When They're Done Coding
=0D=0A COMPIIIIIIILE!!
=0D=0A
=0D=0A
=0D=0A
=0D=0A
=0D=0A

x-mozilla-cpt:;0
fn:Richard Levitte
end:vcard

--------------6EE9DA735EFDC58FE31BDC3E--

Received: from heather.ithnet.com (ns.ithnet.com [62.157.157.10]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id TAA18801 for ; Fri, 5 Jan 2001 19:44:46 -0800 (PST)
Received: by heather.ithnet.com (Smail3.2 #4) id m14EkM9-000CMfC; Sat, 6 Jan 2001 04:49:25 +0100 (CET)
Received: from gate.ots-erdl.de(62.157.156.209), claiming to be "gate.ots-ag.de" via SMTP by mail2.ithnet.com, id smtpdCBQsxb; Sat Jan 6 04:49:14 2001
Received: from newsletter.com (pC19EB466.dip.t-dialin.net [193.158.180.102]) by gate.ots-ag.de (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with SMTP id EAA26752 for ; Sat, 6 Jan 2001 04:48:45 +0100
Date: Sat, 6 Jan 2001 04:48:45 +0100
Message-Id: <[email-masked]>
Reply-To: [email-masked]
Content-Type: text/plain; charset=us-ascii
X-Priority: 1
From: House Of Pleasure
To: [email-masked]
Subject: A NEW CYBERPAGE IN SPACE, FUN, FUN, FUN !!!

Hello there,

there is a very new Website about fun, fun and fun again.

The URL is www.h-o-p.de

check it out. NOW.
Thanx.

The webmaster

This email was sent via Ellipse Bulk Emailer v2.0

Received: from geos.coastside.net (geos.coastside.net [207.213.212.4]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id SAA17556 for ; Fri, 5 Jan 2001 18:10:48 -0800 (PST)
Received: from heatherdale (dsl-63-194-153-52.coastside.net [63.194.153.52]) by geos.coastside.net (8.11.0/8.11.1) with SMTP id f062EvV23257; Fri, 5 Jan 2001 18:14:58 -0800 (PST)
From: "Michael Myers"
To: "Stephen Kent" , "Peter Sylvester"
Cc:
Subject: RE: DPD & DPV requirements - Let us Recurse
Date: Fri, 5 Jan 2001 18:18:35 -0800
Message-ID:
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)
In-Reply-To:
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300

Steve,

It is precisely this overlap that led to the existence and architecture of
the current DPV and DPD drafts, namely that a DPD server was simply tapping
into the path discovery logic that a DPV server must execute.

Care must taken however as we go forward with high-level requirements to
ensure that a DPD server delivers up that path a DPV server would have used.
Or are we otherwise comfortable that some ambiguity may emerge? This was an
open question that we as DPV and DPD authors were and are grappling with.

Mike

-----Original Message-----
From: Stephen Kent [mailto:[email-masked]]
Sent: Friday, January 05, 2001 10:29 AM

. . .

I am open to the suggestion that we further separate DPV vs. DPD
requirements, to make each clearer, although my impressions, after
some thinking, are that these two types of servers are more alike
than I had originally imagined.

Received: from mail-fwd.verio-web.com (mail11a.verio-web.com [161.58.16.57]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id RAA16889 for ; Fri, 5 Jan 2001 17:27:18 -0800 (PST)
Received: from 161.58.117.181 (161.58.117.181) by mail11a.verio-web.com (RS ver 1.0.57s) with SMTP id 019607417; Fri, 5 Jan 2001 20:25:49 -0500 (EST)
Received: from caveosystems.com (adsl-141-154-28-165.bostma.adsl.bellatlantic.net [141.154.28.165]) by os390.caveosystems.com (8.9.3/8.9.3) with ESMTP id UAA25996; Fri, 5 Jan 2001 20:25:56 -0500
Message-ID: <[email-masked]>
Date: Fri, 05 Jan 2001 20:29:28 -0500
From: Rich Salz
X-Mailer: Mozilla 4.73 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Stephen Kent
CC: PKIX-List
Subject: Re: DPD & DPV requirements
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Loop-Detect: 1

> Given the problems we have had in OCSP (v1) re referring to a target cert,
> I am not comfortable specifying a target cert other than by providing a copy
> of that cert to the server.

It would be nice if some other folks got their lawyers to check about
infringement against that d--n Micali patent I mentioned here some weeks ago.
/r$

Received: from fw. ([203.75.122.253]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id RAA16755 for ; Fri, 5 Jan 2001 17:14:33 -0800 (PST)
From: [email-masked]
Received: from tw02.tainet.net (unverified [203.75.122.16]) by dnsnet.tainet.net (EMWAC SMTPRS 0.83) with SMTP id ; Sat, 06 Jan 2001 09:22:33 +0800
Received: by tw02.tainet.net(Lotus SMTP MTA v4.6.4 (830.2 3-23-1999)) id 482569CC.000780B7 ; Sat, 6 Jan 2001 09:21:57 +0800
X-Lotus-FromDomain: TAINET
To: [email-masked]
Message-ID: <[email-masked]>
Date: Sat, 6 Jan 2001 09:16:19 +0800
Subject: unsubscribe
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline

unsubscribe

Received: from po1.bbn.com (PO1.BBN.COM [192.1.50.38]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA11518 for ; Fri, 5 Jan 2001 13:10:58 -0800 (PST)
Received: from [171.78.30.107] (comsec.bbn.com [171.78.30.107]) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id QAA17480; Fri, 5 Jan 2001 16:15:33 -0500 (EST)
Mime-Version: 1.0
X-Sender: [email-masked]
Message-Id:
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Date: Fri, 5 Jan 2001 16:10:33 -0500
To: Denis Pinkas
From: Stephen Kent
Subject: Re: DPD & DPV requirements
Cc: PKIX-List
Content-Type: multipart/alternative; boundary="============_-1233393097==_ma============"

--============_-1233393097==_ma============
Content-Type: text/plain; charset="iso-8859-1" ; format="flowed"
Content-Transfer-Encoding: quoted-printable

Denis,

>Steve,
>
>First of all, many thanks for posting this long document.
>
>I will not respond using directly your text, since my arguments
>are fairly different. I will however re-use some of your arguments.
>
>Let us use the concept of "validation policy", that you introduce, which is
>all the set of rules to be followed when validating a certificate. It will
>usually not simply be the rules mentioned in RFC 2459, but these rules with
>additional conditions. Note that in the context of electronic signatures, a
>"signature policy" is a specific example of a "validation policy".

We need to be explicit about what are the parameters that control=20
path validation. The 2459 validation algorithm has a well-defined=20
set, but if there are others, we need to have them specified and=20
agreed upon. One conversation that took place in San Diego noted that=20
one could imagine a lot of parameters that a user might want to=20
express re path validation, but which have not been standardized, and=20
for which we do not have general agreement. A very rich list of this=20
sort, and the associated complexity that would accompany an enhanced=20
validation algorithm that used thise parameters, was thought to be=20
out of scope for now, more an R&D topic vs. a topic for=20
standardization. So we have to be careful here.

>DPV
>=3D=3D=3D
>
>Let us start with DPV first. A DPV client will not necessarily be either
>PKI-aware, nor ASN.1 aware. I thus see two flavors for a DPV protocol:
>
>=20 1) one not using ASN.1 (e.g. using XML),
>=20 2) one using ASN.1.
>
>In both cases the client only supplies an unambiguous reference of the
>certificate (CA name, serial number and a hash of the certificate) or the
>certificate itself and specifies the rules to be followed to validate the
>certificate: an identification of a pre-defined "validation policy" (e.g. a=
n
>OID and/or a URL to find the policy and a hash of that validation policy).

Given the problems we have had in OCSP (v1) re referring to a target=20
cert, I am not comfortable specifying a target cert other than by=20
providing a copy of that cert to the server.

>As a result, the client expects a signed response which reproduces the
>requested parameters and includes a status. The status is not simply:
>"passed validation", "failed validation", or "don't' know" but can also be
>"incomplete validation", meaning that some revocation status information is
>not yet available at the time of processing and a later attempt might
>succeed.

Incomplete validation is a reasonable response. maybe we should=20
include the set of parameters used for the validation, including ones=20
not supplied by the client, e.g., defaults, or overrides imposed by=20
the server, or the values bound to a policy that was specified.

>The response must include the time at which the validation has been
>performed. Allowing to test a certificate "in the past", would place some
>requirements that cannot always be accomplished by a standard PKI: currentl=
y
>we do not mandate CAs to maintain revocation information beyond the end of
>the validity period of a certificate. We should not change that rule. So I
>am very reluctant to autorise validation in the past, e.g. 10 years later.

Good points; we should include the time of the response. I added the=20
"in the past" requirement based on its inclusion in SCVP, but there=20
clearly limits to one's ability to support that feature. However, if=20
the server is uable to verify a cert relative to a prior time, based=20
on unavailability of some revocation data, it can always state that=20
in a response. One might add a requirement to allow the server to be=20
configured to reject requests for validation that cite a time/date=20
prior to some confugured value.

>If a client is interested in a later proof, then it should obtain that
>information from the server at the time the information is still available.
>This means that a client should have the possibility to ask the server to
>optionally return an opaque blob that contains all what has been used to
>validate the certificate (i.e. a certification path and all the CRLs or
>OCSPs needed for each certificate from the path).

=20 We have this requirement already, with a time stamp option.

>A question arises from the requirements 1.5 and 1.6 that you listed: should
>that opaque blob be time-stamped ? If there is a fear that some of the
>issuing keys used in the certification path might later on be compromised,
>then this can be useful. This case should be very seldom and hence this
>service would not always be required. In addition, why should that service
>be embedded in this protocol ? This could be obtained using directly the
>TSP, leaving more possibilities: free choice of the TSAs, time stamp of the
>full blob, time stamp of the certification chain only, time stamp on both
>the certification chain and the revocation information. Thus I do not favor
>to piggy-back the two services.

Yes, one could keep the services separate. I am not hard over on=20
this, and can be persuaded to remove the requirement, or to make=20
server support for it optional.

>In order to simplify the protocol and allow for PKI-ignorant clients, the
>client should NOT be allowed to provide any other element than the
>certificate, that might help to construct the path or the revocation
>information.

I don't see the rationale for this. We already have application=20
protocols where a client that is not PKI-aware might acquire cert=20
paths and/or revocation data that it could pass on to a DPV server.=20
So, I don't think you have made a good argument here for not allowing=20
such data to be transmitted. Also, I don't think we have agreement=20
yet that we are supporting clients that are not PKI-aware. I merely=20
noted that IF we choose to support such clients, then there are=20
implications for the syntax used for the protocol, and for the=20
semantics of what is transmitted. I don't think we have made the next=20
step to agree to support such clients.

>This means that, not only I do not agree with a common list of requirements
>for both DPV and DPD, but also that I do not agree with many of the
>requirements that you listed:
>
>For a DPV client:
>
>1.1. Only a single certificate should be allowed.
>1.2. No revocation items should be allowed.
>1.3. No request in the past should be allowed.
>1.4. Imposing constraints for CRLs or OCSP responses should be hidden
>=20 under the "validation policy" that is selected.
>1.5. and 1.6. Time stamped responses, if needed, should not be part of the
>=20 service.
>1.7. Validation policies are not necessarily "configured at the server",
>=20 but can simply be pre-defined, outside the server. I any case, the
>=20 rules that has been followed - i.e. "validation policy" - must be
>=20 indicated in the response.
>1.8. For DPV, responses must be signed.
>1.9. The policy ID format can/will be specified in the protocol.
>
>For a DPV server:
>
>2.1. A DPV server, will have to do more than RFC 2459, hence why the use
>=20 of a validation policy is needed.
>2.2. An opaque blob MAY be returned.
>2.3. Time stamping is not needed.
>2.4. The concept of policy overriding is too complex: a reference to
>=20 a validation policy is sufficient.
>2.5. No comment.
>2.6. A server must support LDAP for certificate fetching, and EITHER CRL
>=20 fetching OR OSCP (OCSP should not be mandatory).
>2.7. No comment.
>

Given that we no longer agree on the underlying assumptions, it=20
probably is not worthwhile discussing each of your proposed changes=20
above.

>DPD
>=3D=3D=3D
>
>Let us continue with DPD. I agree in general with many of the requirements
>that you listed in that case. In particular, since a DPD client must be bot=
h
>PKI-aware and ASN.1 aware, the protocol should only be described in ASN.1.
>
>The major difference with the previous protocol is that no evaluation of th=
e
>returned chain needs to be done, since the client is supposed to be able to
>perform all the checks himself. Therefor no validation status is returned b=
y
>the server.

I don't think I agree with both of the statements above. No explicit=20
validation status is returned, but I do think the server is=20
performing validation so that only valid chains are returned.

>The service is more a single place for shopping all (?) the needed
>certificates and revocation status information.
>
>In the request, the client could either specify a validation policy or the
>trusted points with, for each level of the chain, the indication whether
>CRLs or OCSP responses are requested.
>
>One or more chains, corresponding to the request may be obtained.
>
>The response does not need to be signed, but only protected by a combined
>integrity and data origin authentication service.
>
>
>CONCLUSION
>=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>
>We could support three protocols:
>
>=20 1=B0 DPV in XML,
>=20 2=B0 DPV in ASN.1,
>=20 3=B0 DPD in ASN.1.

The operative term here is "could." Also, DPV in XML and DPV in ASN.1=20
need not be the same protocol, because of different assumptions about=20
the clients. So I think of it three protocols where 2 & 3 may be very=20
similar, but 1 is quite different.

>ADDITIONAL QUESTION
>=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>
>For the two protocols in ASN.1, should these two protocols be piggy-back on
>OCSP ?

That's one of the proposals, but the answer should be the result of=20
analysis of a revised proposal consistent with the requirements that=20
we adopt.

>Before going at the technical details, it is important to raise the
>following question: which combination(s) of the three basic requests (OCSP,
>DPV and DPD) could make sense ?
>
>If a client requests DPV, then it does not care about OCSP and neither on
>DPD (multiple certification chains to be tested).

>For a PKI-aware client, only OCSP + DPD makes sense.
>
>This means that :
>
>=20 1) DPV does not need to be supported by OCSP.
>=20 2) The only protocol to be piggy-backed to OCSP would be DPD.

I don't understand these comments. You need to provide more substantiation.

Steve

--============_-1233393097==_ma============
Content-Type: text/enriched; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Denis,

Steve,

=46irst of all, many thanks for posting this long document.

I will not respond using directly your text, since my arguments

are fairly different. I will however re-use some of your arguments.

Let us use the concept of "validation policy", that you introduce,
which is

all the set of rules to be followed when validating a certificate. It
will

usually not simply be the rules mentioned in RFC 2459, but these rules
with

additional conditions. Note that in the context of electronic
signatures, a

"signature policy" is a specific example of a "validation policy".

We need to be explicit about what are the parameters that control path
validation. The 2459 validation algorithm has a well-defined set, but
if there are others, we need to have them specified and agreed upon.
One conversation that took place in San Diego noted that one could
imagine a lot of parameters that a user might want to express re path
validation, but which have not been standardized, and for which we do
not have general agreement. A very rich list of this sort, and the
associated complexity that would accompany an enhanced validation
algorithm that used thise parameters, was thought to be out of scope
for now, more an R&D topic vs. a topic for standardization. So we have
to be careful here.

DPV

=3D=3D=3D

Let us start with DPV first. A DPV client will not necessarily be
either

PKI-aware, nor ASN.1 aware. I thus see two flavors for a DPV protocol:

1) one not using ASN.1 (e.g. using XML),

2) one using ASN.1.

In both cases the client only supplies an unambiguous reference of the

certificate (CA name, serial number and a hash of the certificate) or
the

certificate itself and specifies the rules to be followed to validate
the

certificate: an identification of a pre-defined "validation policy"
(e.g. an

OID and/or a URL to find the policy and a hash of that validation
policy).

Given the problems we have had in OCSP (v1) re referring to a target
cert, I am not comfortable specifying a target cert other than by
providing a copy of that cert to the server.

As a result, the client expects a signed response which
reproduces the

requested parameters and includes a status. The status is not simply:

"passed validation", "failed validation", or "don't' know" but can also
be

"incomplete validation", meaning that some revocation status
information is

not yet available at the time of processing and a later attempt might

succeed.

Incomplete validation is a reasonable response. maybe we should include
the set of parameters used for the validation, including ones
not supplied by the client, e.g., defaults, or
overrides imposed by the server, or the values bound to a policy that
was specified.

The response must include the time at which the validation has
been

performed. Allowing to test a certificate "in the past", would place
some

requirements that cannot always be accomplished by a standard PKI:
currently

we do not mandate CAs to maintain revocation information beyond the end
of

the validity period of a certificate. We should not change that rule.
So I

am very reluctant to autorise validation in the past, e.g. 10 years
later.

Good points; we should include the time of the response. I added the
"in the past" requirement based on its inclusion in SCVP, but there
clearly limits to one's ability to support that feature. However, if
the server is uable to verify a cert relative to a prior time, based on
unavailability of some revocation data, it can always state that in a
response. One might add a requirement to allow the server to be
configured to reject requests for validation that cite a time/date
prior to some confugured value.

If a client is interested in a later proof, then it should
obtain that

information from the server at the time the information is still
available.

This means that a client should have the possibility to ask the server
to

optionally return an opaque blob that contains all what has been used
to

validate the certificate (i.e. a certification path and all the CRLs
or

OCSPs needed for each certificate from the path).

We have this requirement already, with a time stamp option.

A question arises from the requirements 1.5 and 1.6 that you
listed: should

that opaque blob be time-stamped ? If there is a fear that some of the

issuing keys used in the certification path might later on be
compromised,

then this can be useful. This case should be very seldom and hence
this

service would not always be required. In addition, why should that
service

be embedded in this protocol ? This could be obtained using directly
the

TSP, leaving more possibilities: free choice of the TSAs, time stamp of
the

full blob, time stamp of the certification chain only, time stamp on
both

the certification chain and the revocation information. Thus I do not
favor

to piggy-back the two services.

Yes, one could keep the services separate. I am not hard over on this,
and can be persuaded to remove the requirement, or to make server
support for it optional.

In order to simplify the protocol and allow for PKI-ignorant
clients, the

client should NOT be allowed to provide any other element than the

certificate, that might help to construct the path or the revocation

information.

I don't see the rationale for this. We already have application
protocols where a client that is not PKI-aware might acquire cert paths
and/or revocation data that it could pass on to a DPV server. So, I
don't think you have made a good argument here for not allowing such
data to be transmitted. Also, I don't think we have agreement yet that
we are supporting clients that are not PKI-aware. I merely noted that
IF we choose to support such clients, then there are implications for
the syntax used for the protocol, and for the semantics of what is
transmitted. I don't think we have made the next step to agree to
support such clients. =20

This means that, not only I do not agree with a common list of
requirements

for both DPV and DPD, but also that I do not agree with many of the

requirements that you listed:

=46or a DPV client:=20

1.1. Only a single certificate should be allowed.

1.2. No revocation items should be allowed.

1.3. No request in the past should be allowed.

1.4. Imposing constraints for CRLs or OCSP responses should be hidden=20

under the "validation policy" that is selected.

1.5. and 1.6. Time stamped responses, if needed, should not be part of
the

service.=20

1.7. Validation policies are not necessarily "configured at the
server",=20

but can simply be pre-defined, outside the server. I any case, the

rules that has been followed - i.e. "validation policy" - must be

indicated in the response.

1.8. For DPV, responses must be signed.

1.9. The policy ID format can/will be specified in the protocol.

=46or a DPV server:

2.1. A DPV server, will have to do more than RFC 2459, hence why the
use=20

of a validation policy is needed.

2.2. An opaque blob MAY be returned.

2.3. Time stamping is not needed.

2.4. The concept of policy overriding is too complex: a reference to=20

a validation policy is sufficient.=20

2.5. No comment.

2.6. A server must support LDAP for certificate fetching, and EITHER
CRL

fetching OR OSCP (OCSP should not be mandatory).

2.7. No comment.

Given that we no longer agree on the underlying assumptions, it
probably is not worthwhile discussing each of your proposed changes
above.

DPD

=3D=3D=3D

Let us continue with DPD. I agree in general with many of the
requirements

that you listed in that case. In particular, since a DPD client must be
both

PKI-aware and ASN.1 aware, the protocol should only be described in
ASN.1.

The major difference with the previous protocol is that no evaluation
of the

returned chain needs to be done, since the client is supposed to be
able to

perform all the checks himself. Therefor no validation status is
returned by

the server.

I don't think I agree with both of the statements above. No explicit
validation status is returned, but I do think the server is performing
validation so that only valid chains are returned.

The service is more a single place for shopping all (?) the
needed

certificates and revocation status information.

In the request, the client could either specify a validation policy or
the

trusted points with, for each level of the chain, the indication
whether

CRLs or OCSP responses are requested.

One or more chains, corresponding to the request may be obtained.=20

The response does not need to be signed, but only protected by a
combined

integrity and data origin authentication service.

CONCLUSION

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

We could support three protocols:

1=B0 DPV in XML,

2=B0 DPV in ASN.1,

3=B0 DPD in ASN.1.

The operative term here is "could." Also, DPV in XML and DPV in ASN.1
need not be the same protocol, because of different assumptions about
the clients. So I think of it three protocols where 2 & 3 may be very
similar, but 1 is quite different.

ADDITIONAL QUESTION

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

=46or the two protocols in ASN.1, should these two protocols be
piggy-back on

OCSP ?

That's one of the proposals, but the answer should be the result of
analysis of a revised proposal consistent with the requirements that we
adopt.=20

Before going at the technical details, it is important to
raise the

following question: which combination(s) of the three basic requests
(OCSP,

DPV and DPD) could make sense ?

If a client requests DPV, then it does not care about OCSP and neither
on

DPD (multiple certification chains to be tested).

For a PKI-aware client, only OCSP + DPD makes sense.

This means that :

1) DPV does not need to be supported by OCSP.

2) The only protocol to be piggy-backed to OCSP would be DPD.

I don't understand these comments. You need to provide more
substantiation.

Steve

--============_-1233393097==_ma============--

Received: from po1.bbn.com (PO1.BBN.COM [192.1.50.38]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA01989 for ; Fri, 5 Jan 2001 10:31:34 -0800 (PST)
Received: from [171.78.30.107] (comsec.bbn.com [171.78.30.107]) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id NAA24785; Fri, 5 Jan 2001 13:35:57 -0500 (EST)
Mime-Version: 1.0
X-Sender: [email-masked]
Message-Id:
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Date: Fri, 5 Jan 2001 13:29:02 -0500
To: Peter Sylvester
From: Stephen Kent
Subject: RE: DPD & DPV requirements - Let us Recurse
Cc: [email-masked]
Content-Type: text/plain; charset="us-ascii" ; format="flowed"

Peter,

I am open to the suggestion that we further separate DPV vs. DPD
requirements, to make each clearer, although my impressions, after
some thinking, are that these two types of servers are more alike
than I had originally imagined.

Returning info that explains why a server believes that the returned
data supports validation is an interesting notion. The first example
of that I saw was in work performed by colleagues here at BBN, on a
project calls IOS, in the early 90s, where servers did that. But, I
think this is still an R&D topic for now, not yet ready for
standardization.

Steve

Received: from po1.bbn.com (PO1.BBN.COM [192.1.50.38]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA01940 for ; Fri, 5 Jan 2001 10:31:28 -0800 (PST)
Received: from [171.78.30.107] (comsec.bbn.com [171.78.30.107]) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id NAA24796; Fri, 5 Jan 2001 13:36:04 -0500 (EST)
Mime-Version: 1.0
X-Sender: [email-masked]
Message-Id:
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Date: Fri, 5 Jan 2001 13:32:08 -0500
To: "Covey, Carlin"
From: Stephen Kent
Subject: RE: DPD & DPV requirements - Let us Recurse
Cc: PKIX-List
Content-Type: multipart/alternative; boundary="============_-1233402667==_ma============"

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

Carlin,

>Steve Kent's DPD/DPV requirements, the SCVP proposal, and the OCSP
>DPD proposal all permit OCSP responses
>to be returned to the client as revocation status data. Presumably
>in each case this refers to OCSP v1 basic responses,
>at least. This is all well and good, but would it not be desirable
>to also permit recursion in the DPD response? That is, the DPD
>response might include an embedded DPD response from another server.
>Among other benefits, this would preserve the
>timestamp (if any) on the embedded DPD response.
>
>- Regards
> Carlin Covey
> Cylink Corp.

Recursion has its attractions, but nested responses seem complex,
syntactically if not semantically. Given the issues you raised about
the 1 level of indirection posed by a DPD or DPV server interacting
with an OCSP server, I am not yet comfortable with making life more
complex in this regard. First I think we need to solve the problem
you identified, and then we can see if that solution will generalize
to allow the recursion to work smoothly and in a readily
understandable manner.

Steve

--============_-1233402667==_ma============
Content-Type: text/enriched; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Carlin,

Arial0000,0000,FFFFSteve
Kent's DPD/DPV requirements, the SCVP proposal, and the OCSP DPD
proposal all permit OCSP responses

to be returned to the client as revocation status data. Presumably in
each case this refers to OCSP v1 basic responses,

at least. This is all well and good, but would it not be desirable to
also permit recursion in the DPD response? That is, the DPD

response might include an embedded DPD response from another server.=20
Among other benefits, this would preserve the

timestamp (if any) on the embedded DPD response.

=20

- Regards

Carlin Covey

Cylink Corp.

Arial0000,0000,FFFF

Recursion has its attractions, but nested
responses seem complex, syntactically if not semantically. Given the
issues you raised about the 1 level of indirection posed by a DPD or
DPV server interacting with an OCSP server, I am not yet comfortable
with making life more complex in this regard. First I think we need to
solve the problem you identified, and then we can see if that solution
will generalize to allow the recursion to work smoothly and in a
readily understandable manner.

Steve

--============_-1233402667==_ma============--

Received: from web3706.mail.yahoo.com (web3706.mail.yahoo.com [204.71.203.135]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id KAA29331 for ; Fri, 5 Jan 2001 10:13:59 -0800 (PST)
Message-ID: <[email-masked]>
Received: from [32.102.78.253] by web3706.mail.yahoo.com; Fri, 05 Jan 2001 10:18:26 PST
Date: Fri, 5 Jan 2001 10:18:26 -0800 (PST)
From: Timothy Fisher
Subject: pkix servers
To: [email-masked]
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii

Does anyone know if there are any publicly available
PKIX servers available for testing PKIX-CMP
messages?

Sincerely,
Timothy Fisher
PricewaterhouseCoopers

Received: from edelweb.fr (edelweb.fr [212.234.46.16]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA14051 for ; Fri, 5 Jan 2001 06:27:13 -0800 (PST)
Received: from champagne.edelweb.fr (localhost.edelweb.fr [127.0.0.1]) by edelweb.fr with ESMTP id PAA22966; Fri, 5 Jan 2001 15:31:48 +0100 (MET)
Received: from champagne.edelweb.fr (champagne.edelweb.fr [193.51.14.161]) by edelweb.fr (nospam/1.3); Fri, 5 Jan 2001 15:31:48 +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 PAA13530; Fri, 5 Jan 2001 15:31:46 +0100 (MET)
From: Peter Sylvester
Received: (sylvest@localhost) by emeriau.edelweb.fr (8.7.6/8.6.6) id PAA15535; Fri, 5 Jan 2001 15:31:46 +0100 (MET)
Date: Fri, 5 Jan 2001 15:31:46 +0100 (MET)
Message-Id: <[email-masked]>
To: [email-masked], [email-masked]
Subject: RE: DPD & DPV requirements - Let us Recurse

>
> Steve Kent's DPD/DPV requirements, the SCVP proposal, and the OCSP DPD
> proposal all permit OCSP responses
> to be returned to the client as revocation status data. Presumably in each
> case this refers to OCSP v1 basic responses,
> at least. This is all well and good, but would it not be desirable to also
> permit recursion in the DPD response? That is, the DPD
> response might include an embedded DPD response from another server. Among
> other benefits, this would preserve the
> timestamp (if any) on the embedded DPD response.
>

I have some feeling that handling DPV and DPD at the same time
is not an extremely good thing, there may be well some
requirements that apply for both, in this case I think that
these are general requirements for almost any secure protocol.
Furthermore DPV and DPD seem to be at different (sub)layers,
e.g.., a DPV layer could run a loop towards a DPD server.

The text mentions several usage environments, public, private
and heterogeneous.

There was a question recently about OCSP mentioning a similar issue:

A DPV server in any environment should be able to delegate part of the
service to another server, it should be possible that the response
delivered to the client include the response of the delegated/relayed
request, and all elements that can be used to determine the
authenticity of the response, e.g., signatures from the
primary server (as a coutersignature or as a parallel signature),

It has been mentioned that the response is to be time stamped and used
in order to validate a long term document etc. It seems important to me
that the client can use the response not only to make a decision, but
also to have all information about why this decision had been made.

Thus, a client can create a statement saying:
" I accept this certificate because my server told me that it is
good, and he provides the following justifications: ..."
instead of:
" I accept this certificate because my server told me that it is
good, if you want to know wy, go ask elsewhere" (how?).

In some contexts this is related to relaying: A company server
tells that a cert is good because a request to a remote server
(from another company or elsewhere) has been made, i.e.: the response
says something like: "We, the humble XXX compnay server think that
the certificate CCC is good because we have this validity
statement from XYZZY according to policy PPP...".

PS

Received: from c1mailgw06.prontomail.com (mailgw.prontomail.com [216.163.184.10] (may be forged)) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id WAA24485 for ; Thu, 4 Jan 2001 22:37:16 -0800 (PST)
From: [email-masked]
Received: from c1web109 (216.163.184.10) by c1mailgw06.prontomail.com (NPlex 5.1.050) id 3A413A6E001D289E for [email-masked]; Thu, 4 Jan 2001 22:41:20 -0800
X-Version: indya 6.3.2329.0
Message-Id:
Date: Fri, 5 Jan 2001 12:10:25 +0530
X-Priority: Normal
Content-Type: text/plain; charset=iso-8859-1
To: [email-masked]
X-Mailer: Web Based Pronto
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit

Hi!
I want to include secrity in my work using shttp.So to do the same is
it necessary to get a certificate issued from Verisign.What r the
other options to do & which is the best method encryption or
signature.Various steps to be followed.If at all i have to fill up
any forms where will i get them.Please give the exact website to
follow the things.
Regds
Nagamani.
U can mail me either to
[email-masked]
OR
[email-masked].

Enjoy being an Indyan at http://www.indya.com

Received: from mail.phaos.com ([206.30.74.234]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA14366 for ; Thu, 4 Jan 2001 14:27:38 -0800 (PST)
Received: from phaos_arik (ruskie.spacerat.com [207.51.38.135]) by mail.phaos.com (8.9.2/8.9.2) with ESMTP id VAA37390 for ; Thu, 4 Jan 2001 21:33:25 -0500 (EST) (envelope-from [email-masked])
Message-Id: <[email-masked]>
X-Sender: [email-masked]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58
Date: Thu, 04 Jan 2001 17:42:53 -0500
To: [email-masked]
From: Ari Kermaier
Subject: draft-ietf-pkix-rfc2510bis-02 syntax question
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed

An inconsistency between the text and the ASN.1 module:

3.3.18 Certificate Confirmation content

CertStatus ::= SEQUENCE {
certHash OCTET STRING,
-- the hash of the certificate, using the same hash algorithm
-- as is used to create and verify the certificate signature
certReqId INTEGER,
-- to match this confirmation with the corresponding req/rep
statusInfo PKIStatusInfo OPTIONAL
}

Appendix F: "Compilable" ASN.1 Module using 1988 Syntax

CertStatus ::= SEQUENCE {
certHash OCTET STRING,
-- the hash of the certificate, using the same hash algorithm
-- as is used to create and verify the certificate signature
statusInfo PKIStatusInfo OPTIONAL
}

Any clarification would be appreciated.

Ari Kermaier
Phaos Technology

Received: from eagle.verisign.com (eagle.verisign.com [208.206.241.105]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA11173 for ; Thu, 4 Jan 2001 13:26:12 -0800 (PST)
Received: from postal-gw2.verisign.com (verisign.com [63.104.27.102]) by eagle.verisign.com (8.9.3/BCH1.7.1) with ESMTP id NAA03588 for ; Thu, 4 Jan 2001 13:32:33 -0800 (PST)
Received: by postal-gw.verisign.com with Internet Mail Service (5.5.2650.21) id ; Thu, 4 Jan 2001 13:30:45 -0800
Message-ID:
From: Ram Austryjak Moskovitz
To: "'RANFORD, Cameron'" , "'PKIX-List'"
Subject: RE: REMOVE
Date: Thu, 4 Jan 2001 13:30:43 -0800
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"

Not likely :-)

-----Original Message-----
From: RANFORD, Cameron [mailto:[email-masked]]
Sent: Friday, January 05, 2001 8:25 AM
To: RANFORD, Cameron; 'PKIX-List'
Subject: REMOVE

this is it!

Received: from mail.westpac.com.au (mail.westpac.com.au [203.24.6.110]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA10957 for ; Thu, 4 Jan 2001 13:23:24 -0800 (PST)
Received: (from smtpuser@localhost) by mail.westpac.com.au (8.9.1a/8.9.1) id IAA08303 for ; Fri, 5 Jan 2001 08:20:50 +1100 (EST)
Message-Id: <[email-masked]>
Received: from inetsvr02(10.10.70.26) by xlprod02 via smap (V2.1+anti-relay+anti-spam) id xma008253; Fri, 5 Jan 01 08:20:36 +1100
Received: from inetsrv02.king77.nsw.westpac.com.au (localhost [127.0.0.1]) by inetsrv02.king77.nsw.westpac.com.au with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2448.0) id C1A6CX9L; Fri, 5 Jan 2001 08:27:13 +1100
Received: from 10.10.70.19 by inetsrv02.king77.nsw.westpac.com.au (InterScan E-Mail VirusWall NT); Fri, 05 Jan 2001 08:27:11 +1100 (Syd2000 Daylight Time)
Received: by exhub04.king77.nsw.westpac.com.au with Internet Mail Service (5.5.2448.0) id ; Fri, 5 Jan 2001 08:27:16 +1100
From: "RANFORD, Cameron"
To: "RANFORD, Cameron" , "'PKIX-List'"
Subject: REMOVE
Date: Sat, 6 Jan 2001 03:24:54 +1100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01C07695.1C335B0A"

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_01C07695.1C335B0A
Content-Type: text/plain;
charset="windows-1252"

this is it!

------_=_NextPart_000_01C07695.1C335B0A
Content-Type: application/ms-tnef
Content-Transfer-Encoding: base64

eJ8+IhEVAQaQCAAEAAAAAAABAAEAAQeQBgAIAAAA5AQAAAAAAADoAAEIgAcAGAAAAElQTS5NaWNy
b3NvZnQgTWFpbC5Ob3RlADEIAQSAAQAHAAAAUkVNT1ZFAM4BAQmAAQAhAAAAQjE4OERFMTQzRDYy
QkE0NzlBOUE5QjA0OERCNTkyQUMAUwcBIIADAA4AAADRBwEABQAIABsAEAAFABYBAQWAAwAOAAAA
0QcBAAYAAwAYADYABgA2AQENgAQAAgAAAAIAAgABA5AGALAEAAArAAAACwACAAEAAAADAC4AAAAA
AEAAOQBgiTEJNHfAAR4AcAABAAAABwAAAFJFTU9WRQAAAgFxAAEAAAAbAAAAAcB2jaGkUl7wH+J7
EdSIlwAA9rkUWQApl/NQAAIBCRABAAAAkwAAAI8AAAAeAQAATFpGdUZclG4DAAoAcmNwZzEyNeIy
A0N0ZXgFQQEDAff/CoACpAPkBxMCgA/zAFAEVj8IVQeyESUOUQMBAgBjaOEKwHNldDIGAAbDESX2
MwRGE7cwEiwRMwjvCfe2OxgfDjA1ESIMYGMAUPMLCQFkMzYWUAumCuMKgJR0aAQAIB1ydCEc9AUc
9H0e0AADAP0/UgMAAB4AQhABAAAALAAAADwyMDAxMDEwNDIwMTkuSEFBMjk1NTlAbWFpbC53ZXN0
cGFjLmNvbS5hdT4AAwDeP+QEAAADAAlZAQAAAAsAA4AIIAYAAAAAAMAAAAAAAABGAAAAAAOFAAAA
AAAAAwAAgAggBgAAAAAAwAAAAAAAAEYAAAAAEIUAAAAAAAADAAeACCAGAAAAAADAAAAAAAAARgAA
AAABhQAAAAAAAAMABIAIIAYAAAAAAMAAAAAAAABGAAAAAFKFAAB9bgEAHgAFgAggBgAAAAAAwAAA
AAAAAEYAAAAAVIUAAAEAAAAEAAAAOS4wAAsAFIAIIAYAAAAAAMAAAAAAAABGAAAAAAaFAAAAAAAA
CwAIgAggBgAAAAAAwAAAAAAAAEYAAAAADoUAAAAAAAADAAmACCAGAAAAAADAAAAAAAAARgAAAAAR
hQAAAAAAAAMACoAIIAYAAAAAAMAAAAAAAABGAAAAABiFAAAAAAAAAwAmAAAAAAADADYAAAAAAB4A
MUABAAAAEAAAAEw4MDA5NDk4RUQ0QkY4QwADABpAAAAAAB4AMEABAAAAEAAAAEw4MDA5NDk4RUQ0
QkY4QwADABlAAAAAAAMAgBD/////AgH5PwEAAABjAAAAAAAAANynQMjAQhAatLkIACsv4YIBAAAA
BgAAAC9PPVdFU1RQQUMvT1U9V0JDL0NOPVJFQ0lQSUVOVFMvQ049TVNNQUlMIEFERFJFU1NFUy9D
Tj1MODAwOTQ5OEVENEJGOEMAAB4A+D8BAAAAEQAAAFJBTkZPUkQsIENhbWVyb24AAAAAHgA4QAEA
AAAQAAAATDgwMDk0OThFRDRCRjhDAAIB+z8BAAAAYwAAAAAAAADcp0DIwEIQGrS5CAArL+GCAQAA
AAYAAAAvTz1XRVNUUEFDL09VPVdCQy9DTj1SRUNJUElFTlRTL0NOPU1TTUFJTCBBRERSRVNTRVMv
Q049TDgwMDk0OThFRDRCRjhDAAAeAPo/AQAAABEAAABSQU5GT1JELCBDYW1lcm9uAAAAAB4AOUAB
AAAAEAAAAEw4MDA5NDk4RUQ0QkY4QwBAAAcwkJJzATR3wAFAAAgwClszHJV2wAEeAD0AAQAAAAEA
AAAAAAAAHgAdDgEAAAAHAAAAUkVNT1ZFAAALACkAAAAAAAsAIwAAAAAAAwAGEGLONzQDAAcQCAAA
AAMAEBAAAAAAAwAREAEAAAAeAAgQAQAAAAkAAABUSElTSVNJVAAAAAD0yw==

------_=_NextPart_000_01C07695.1C335B0A--

Received: from maild.telia.com ([email-masked] [194.22.190.3]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA08467 for ; Thu, 4 Jan 2001 12:48:03 -0800 (PST)
Received: from d1o69.telia.com (d1o69.telia.com [62.20.144.241]) by maild.telia.com (8.9.3/8.9.3) with ESMTP id VAA29025 for ; Thu, 4 Jan 2001 21:52:35 +0100 (CET)
Received: from mega (t7o69p155.telia.com [213.65.46.155]) by d1o69.telia.com (8.10.2/8.10.1) with SMTP id f04KqYl13441 for ; Thu, 4 Jan 2001 21:52:34 +0100 (CET)
Message-ID: <[email-masked]>
From: "Anders Rundgren"
To: "PKIX-List"
Subject: Basic Cert-2-Directory mapping question
Date: Thu, 4 Jan 2001 21:51:00 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
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
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id MAA08470

Basic question from an RDBMS-hack.

Assume you have a directory structure like

/O=Internet/DC=COM/DC=Acme/CN=Users/CN=James A Smith

Now you have a [probably TTP-issued] certificate for this person with a DN

CN=James Adrian Smith + SN=343434

How do you map/match such a "alien" certificate in an efficient and easy-to-adminster way
using directory technology? The solution should support many-to-one mappings
of certificates-to-individuals. To make it simple, ignore the issuer part.

To reduce load on the PKIX-list you may mail me directly.

Anders

Received: from mail.westpac.com.au (mail.westpac.com.au [203.24.6.110]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA06447 for ; Thu, 4 Jan 2001 12:21:56 -0800 (PST)
Received: (from smtpuser@localhost) by mail.westpac.com.au (8.9.1a/8.9.1) id HAA29559 for ; Fri, 5 Jan 2001 07:19:21 +1100 (EST)
Message-Id: <[email-masked]>
Received: from inetsvr02(10.10.70.26) by xlprod02 via smap (V2.1+anti-relay+anti-spam) id xma029548; Fri, 5 Jan 01 07:19:16 +1100
Received: from inetsrv02.king77.nsw.westpac.com.au (localhost [127.0.0.1]) by inetsrv02.king77.nsw.westpac.com.au with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2448.0) id C1A6CV9L; Fri, 5 Jan 2001 07:25:52 +1100
Received: from 10.10.70.19 by inetsrv02.king77.nsw.westpac.com.au (InterScan E-Mail VirusWall NT); Fri, 05 Jan 2001 07:25:52 +1100 (Syd2000 Daylight Time)
Received: by exhub04.king77.nsw.westpac.com.au with Internet Mail Service (5.5.2448.0) id ; Fri, 5 Jan 2001 07:25:57 +1100
From: "RANFORD, Cameron"
To: "'PKIX-List'"
Subject: RE: REMOVE
Date: Sat, 6 Jan 2001 02:23:00 +1100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01C0768C.8ACE3926"

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_01C0768C.8ACE3926
Content-Type: text/plain;
charset="windows-1252"

-----Original Message-----
From: julie whitfield [mailto:[email-masked]]
Sent: Thursday, 4 January 2001 7:06 AM
To: 'PKIX-List'
Subject: REMOVE

=====
Happy Holidays! Ho, ho, ho!!!!

Love,
Julie

"Courage is resistance to fear, mastery of fear - not absence of fear."
Mark Twain (1835 - 1910)

__________________________________________________
Do You Yahoo!?
Yahoo! Photos - Share your holiday photos online!
http://photos.yahoo.com/

------_=_NextPart_000_01C0768C.8ACE3926
Content-Type: application/ms-tnef
Content-Transfer-Encoding: base64

eJ8+IjoUAQaQCAAEAAAAAAABAAEAAQeQBgAIAAAA5AQAAAAAAADoAAEIgAcAGAAAAElQTS5NaWNy
b3NvZnQgTWFpbC5Ob3RlADEIAQSAAQALAAAAUkU6IFJFTU9WRQC/AgEJgAEAIQAAADU0NkQ1NzYx
N0ZBMkI4NEE4NjQ1Qjk5NzZFOTQ0QTQ3AB8HASCAAwAOAAAA0QcBAAUABwAZADgABQA7AQEFgAMA
DgAAANEHAQAGAAIAFwAAAAYA/gABDYAEAAIAAAACAAIAAQOQBgCMBgAAKwAAAAsAAgABAAAAAwAu
AAAAAABAADkAELNqYyt3wAEeAHAAAQAAAAcAAABSRU1PVkUAAAIBcQABAAAAGwAAAAHAdmB5YC7s
A3jiMxHUiJcAAPa5FFkAMrlBcAACAQkQAQAAAAcCAAADAgAAPwMAAExaRnUp8nPUAwAKAHJjcGcx
MjXiMgNDdGV4BUEBAwH3/wqAAqQD5AcTAoAP8wBQBFY/CFUHshElDlEDAQIAY2jhCsBzZXQyBgAG
wxEl9jMERhO3MBIsETMI7wn3tjsYHw4wNREiDGBjAFDzCwkBZDM2FlALpgrjCoTVCoAtHbJPBRBn
C4AHQMMF0AeQc2FnZR2zHPSCRgNhOiBqdWwIkDAgd2hpADAIkGxkDCBbAMADEHRvOmoFANB5IHJA
eWFob+RvLgWgbV0c9AZgAjAJH/BUaAhwc2RheaAsIDQgSgBwdQrABHkgAdAwMSA3OlQwNhDATRz0
VCFwIIAnUEtJWC1MBADEdCcixXViagWQI1HAUkVNT1ZFHPoc9Bsc5RzrPSqCHPRIYXAqcCSgSAbw
aSPRcyHeICuBJAAiQCxiISzhHPqwTG92ZSQAHPRKICKtHPoiCFIe0SAEACAYIDcAkCagAHBjIFAh
YCBmfmUKwCQAAMAmoASQJKBvgmYxQyAtIG5vBUBPAaAUEDDiMjUuIhz0TRUKwGsjcHcLcSAoMQg4
MzUyoTE5MTB6KRz6XzbPN9843Rz0RJ0xMFkIYDpgIjIhPxz0eTq0IFAiQCFgBCAysFM7E+EgUHkI
YSxxK7MgcKc8BAIgIDBuZS0VaAJAUHA6Ly89tC4iJy8FHPR9QOAAAwD9P1IDAAAeAEIQAQAAADIA
AAA8MjAwMTAxMDQxNTA1NDkuNzg1MS5xbWFpbEB3ZWIyMjEubWFpbC55YWhvby5jb20+AAAAAwDe
P+QEAAADAAlZAQAAAAsAA4AIIAYAAAAAAMAAAAAAAABGAAAAAAOFAAAAAAAAAwAAgAggBgAAAAAA
wAAAAAAAAEYAAAAAEIUAAAAAAAADAAeACCAGAAAAAADAAAAAAAAARgAAAAABhQAAAAAAAAMABIAI
IAYAAAAAAMAAAAAAAABGAAAAAFKFAAB9bgEAHgAFgAggBgAAAAAAwAAAAAAAAEYAAAAAVIUAAAEA
AAAEAAAAOS4wAAsAFIAIIAYAAAAAAMAAAAAAAABGAAAAAAaFAAAAAAAACwAIgAggBgAAAAAAwAAA
AAAAAEYAAAAADoUAAAAAAAADAAmACCAGAAAAAADAAAAAAAAARgAAAAARhQAAAAAAAAMACoAIIAYA
AAAAAMAAAAAAAABGAAAAABiFAAAAAAAAAwAmAAAAAAADADYAAAAAAB4AMUABAAAAEAAAAEw4MDA5
NDk4RUQ0QkY4QwADABpAAAAAAB4AMEABAAAAEAAAAEw4MDA5NDk4RUQ0QkY4QwADABlAAAAAAAMA
gBD/////AgH5PwEAAABjAAAAAAAAANynQMjAQhAatLkIACsv4YIBAAAABgAAAC9PPVdFU1RQQUMv
T1U9V0JDL0NOPVJFQ0lQSUVOVFMvQ049TVNNQUlMIEFERFJFU1NFUy9DTj1MODAwOTQ5OEVENEJG
OEMAAB4A+D8BAAAAEQAAAFJBTkZPUkQsIENhbWVyb24AAAAAHgA4QAEAAAAQAAAATDgwMDk0OThF
RDRCRjhDAAIB+z8BAAAAYwAAAAAAAADcp0DIwEIQGrS5CAArL+GCAQAAAAYAAAAvTz1XRVNUUEFD
L09VPVdCQy9DTj1SRUNJUElFTlRTL0NOPU1TTUFJTCBBRERSRVNTRVMvQ049TDgwMDk0OThFRDRC
RjhDAAAeAPo/AQAAABEAAABSQU5GT1JELCBDYW1lcm9uAAAAAB4AOUABAAAAEAAAAEw4MDA5NDk4
RUQ0QkY4QwBAAAcwUOxaXit3wAFAAAgwJjnOiox2wAEeAD0AAQAAAAUAAABSRTogAAAAAB4AHQ4B
AAAABwAAAFJFTU9WRQAACwApAAAAAAALACMAAAAAAAMABhDXqVCbAwAHEDkBAAADABAQAAAAAAMA
ERAAAAAAHgAIEAEAAABlAAAALS0tLS1PUklHSU5BTE1FU1NBR0UtLS0tLUZST006SlVMSUVXSElU
RklFTERNQUlMVE86SkFDWVdISVRAWUFIT09DT01TRU5UOlRIVVJTREFZLDRKQU5VQVJZMjAwMTc6
MDZBTQAAAACDXw==

------_=_NextPart_000_01C0768C.8ACE3926--

Received: from exchange.cylink.com (exchange.cylink.com [192.43.161.25]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA21713 for ; Thu, 4 Jan 2001 08:23:02 -0800 (PST)
Received: by exchange.cylink.com with Internet Mail Service (5.5.2650.21) id ; Thu, 4 Jan 2001 08:19:59 -0800
Message-ID: <[email-masked]>
From: "Covey, Carlin"
To: PKIX-List
Subject: RE: DPD & DPV requirements - Let us Recurse
Date: Thu, 4 Jan 2001 08:19:58 -0800
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0766A.2EA685D0"

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_01C0766A.2EA685D0
Content-Type: text/plain;
charset="iso-8859-1"

Steve Kent's DPD/DPV requirements, the SCVP proposal, and the OCSP DPD
proposal all permit OCSP responses
to be returned to the client as revocation status data. Presumably in each
case this refers to OCSP v1 basic responses,
at least. This is all well and good, but would it not be desirable to also
permit recursion in the DPD response? That is, the DPD
response might include an embedded DPD response from another server. Among
other benefits, this would preserve the
timestamp (if any) on the embedded DPD response.

- Regards
Carlin Covey
Cylink Corp.

------_=_NextPart_001_01C0766A.2EA685D0
Content-Type: text/html;
charset="iso-8859-1"

Steve
Kent's DPD/DPV requirements, the SCVP proposal, and the OCSP DPD proposal all
permit OCSP responses

to be
returned to the client as revocation status data.  Presumably in each case
this refers to OCSP v1 basic responses,

at
least.  This is all well and good, but would it not be desirable to also
permit recursion in the DPD response?  That is, the
DPD

response might include an embedded DPD response
from another server.  Among other benefits, this would preserve the

timestamp (if any) on the embedded DPD
response.

-
Regards

Carlin Covey

Cylink Corp.

------_=_NextPart_001_01C0766A.2EA685D0--

Received: from web221.mail.yahoo.com (web221.mail.yahoo.com [128.11.68.121]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id HAA12852 for ; Thu, 4 Jan 2001 07:01:17 -0800 (PST)
Message-ID: <[email-masked]>
Received: from [216.144.146.62] by web221.mail.yahoo.com; Thu, 04 Jan 2001 07:05:49 PST
Date: Thu, 4 Jan 2001 07:05:49 -0800 (PST)
From: julie whitfield
Subject: REMOVE
To: "'PKIX-List'"
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii

=====
Happy Holidays! Ho, ho, ho!!!!

Love,
Julie

"Courage is resistance to fear, mastery of fear - not absence of fear."
Mark Twain (1835 - 1910)

__________________________________________________
Do You Yahoo!?
Yahoo! Photos - Share your holiday photos online!
http://photos.yahoo.com/

Received: from po1.bbn.com (PO1.BBN.COM [192.1.50.38]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA11770 for ; Thu, 4 Jan 2001 06:40:54 -0800 (PST)
Received: from [171.78.30.107] (comsec.bbn.com [171.78.30.107]) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id JAA29579; Thu, 4 Jan 2001 09:45:24 -0500 (EST)
Mime-Version: 1.0
X-Sender: [email-masked]
Message-Id:
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Date: Thu, 4 Jan 2001 09:37:05 -0500
To: "Covey, Carlin"
From: Stephen Kent
Subject: RE: DPD & DPV requirements - to nonce or not to nonce?
Cc: PKIX-List
Content-Type: multipart/alternative; boundary="============_-1233502899==_ma============"

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

At 5:21 PM -0800 1/3/01, Covey, Carlin wrote:
>To thwart replay attacks, both OCSP and SCVP have provisions for the
>optional inclusion of nonces in requests and responses .
>
>The premise of this is that the requester picks a nonce that it
>hasn't used before, and includes it in its request.
>The server is obligated to return this same nonce, ensuring that the
>response was prepared after the request.
>
>I don't see a provision in the proposed DPD and DPV requirements for
>the optional inclusion of a nonce.
>Is this an intentional omission, or inadvertent? Do we want/need
>nonces in the new DPD/DPV standards?

I didn't want to mandate the use of nonces per se. However, the
security requirement that nonces address is covered in 1.8:

1.8 Either the request/response protocol itself, or a specified
lower layer protocol to be employed for requests and responses, there
must be a provision for data origin authentication and connectionless
integrity for requests and responses, and responses must be matched
to requests. Request authentication & integrity is needed to support
access control to the server, a requirement for public servers.
Responses must be authenticated and integrity-protected to ensure
that they are from the indicated server, and matched to the request
in question. Additional security services may be offered optionally.

>
>I won't venture an opinion, but I will make some observations.
>Since nonces are permitted in OCSP v1 responses,
>nonces may appear in OCSP responses embedded in the requests sent to
>the DPD or DPV server.
>
> "1.2 A client request can contain one or more
>revocation data items,
> to assist the server in path validation." - from
>proposed DPD & DPV requirements
>
>The nonces in the OCSP responses will be of no use to the server,
>because the server did not generate the OCSP
>requests with the matching nonces.
>
>
>
>
>
>Likewise, the responses that a DPD server returns may contain OCSP
>responses with nonces. (To thwart replay attacks,
>the DPD server may have put nonces in the requests that it made to
>OCSP servers.)
>
> "2.2 A server must be able to return one or more
>sets of certification paths and associated
> revocation data as a result of path
>discovery/validation. Each set shall consist of an ordered
> list of certificates and associated CRLs and/or
>OCSP responses." - from proposed DPD &
> DPV requirements
>
>These nonces will be useful to the DPD server, but not to the DPD
>client, since the client did not generate the matching
>OCSP requests. UNLESS ....... the DPD server chooses the same
>nonce that it received from the DPD client. (Contemplating
>this makes me queasy.) Recall that the protection against replay
>attacks was based upon the requester not using the same
>nonce it had used before. This can be done cheaply by generating
>the nonces as a sequence, or as a sizable random number.
>But if the DPD server doesn't generate the nonce, then it must keep
>a record of all the nonces that it has seen (well, perhaps
>only those it has seen within some global time-ambiguity interval).
>Failing to keep track of past nonces renders the DPD
>server vulnerable to conspiracies between the DPD client and another
>agent replaying older OCSP responses to the DPD server.
>But why would a DPD client conspire against itself? It might
>undertake such a conspiracy in order to fool the DPD server
>into attesting to incorrect (or at least out-of-date) certificate
>status, with a view toward later presenting this incorrect
>attestation to someone else. (If the DPD response is timestamped,
>then all the response data, including the incorrect revocation
>data, will have been signed as part of the timestamp.)
>
>An alternative would be for the DPD server to generate its own
>nonces, and then simply attest to the DPD client that all the OCSP
>responses returned in the DPD response are fresh. But this calls
>for some amount of trust in the DPD server, and part of the
>premise for DPD (as opposed to DPV) was that the client might not
>trust the server.

Interesting point re a DPD server returning OCSPv1 responses. i
didn't think about that in detail! I'll have to think more about that
case.

Steve

--============_-1233502899==_ma============
Content-Type: text/enriched; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

At 5:21 PM -0800 1/3/01, Covey, Carlin wrote:

Arial0000,0000,FFFFTo
thwart replay attacks, both OCSP and SCVP have provisions for the
optional inclusion of nonces in requests and responses .

=20

The premise of this is that the requester picks a nonce that it hasn't
used before, and includes it in its request.

The server is obligated to return this same nonce, ensuring that the
response was prepared after the request.

=20

I don't see a provision in the proposed DPD and DPV requirements for
the optional inclusion of a nonce.

Is this an intentional omission, or inadvertent? Do we want/need
nonces in the new DPD/DPV standards?

Arial0000,0000,FFFF

I didn't want to mandate the use of nonces per se.
However, the security requirement that nonces address is covered in
1.8:

1Times.8 Either the
request/response protocol itself, or a specified lower layer protocol
to be employed for requests and responses, there must be a provision
for data origin authentication and connectionless integrity for
requests and responses, and responses must be matched to
requests. Request authentication & integrity is needed to
support access control to the server, a requirement for public servers.
Responses must be authenticated and integrity-protected to ensure that
they are from the indicated server, and matched to the request in
question. Additional security services may be offered optionally.

=20

Arial0000,0000,FFFFI
won't venture an opinion, but I will make some observations. Since
nonces are permitted in OCSP v1 responses,

nonces may appear in OCSP responses embedded in the requests sent to
the DPD or DPV server.=20

"1.2 A client request can contain one or more
revocation data items,=20

to assist the server in path validation." - from
proposed DPD & DPV requirements

0000,0000,FFFFThe nonces in the OCSP responses
will be of no use to the server, because the server did not generate
the OCSP

requests with the matching nonces.

=20

=20

Likewise, the responses that a DPD server returns may contain OCSP
responses with nonces. (To thwart replay attacks,

the DPD server may have put nonces in the requests that it made to OCSP
servers.)=20

"2.2 A server must be able to return one or
more sets of certification paths and associated=20

revocation data as a result of path
discovery/validation. Each set shall consist of an ordered=20

list of certificates and associated CRLs and/or OCSP
responses." - from proposed DPD &

DPV requirements

0000,0000,FFFFThese nonces will be useful to the
DPD server, but not to the DPD client, since the client did not
generate the matching

OCSP requests. UNLESS ....... the DPD server chooses the same nonce
that it received from the DPD client. (Contemplating

this makes me queasy.) Recall that the protection against replay
attacks was based upon the requester not using the same

nonce it had used before. This can be done cheaply by generating the
nonces as a sequence, or as a sizable random number.

But if the DPD server doesn't generate the nonce, then it must keep a
record of all the nonces that it has seen (well, perhaps

only those it has seen within some global time-ambiguity interval).=20
=46ailing to keep track of past nonces renders the DPD

server vulnerable to conspiracies between the DPD client and another
agent replaying older OCSP responses to the DPD server.

But why would a DPD client conspire against itself? It might undertake
such a conspiracy in order to fool the DPD server

into attesting to incorrect (or at least out-of-date) certificate
status, with a view toward later presenting this incorrect

attestation to someone else. (If the DPD response is timestamped, then
all the response data, including the incorrect revocation

data, will have been signed as part of the timestamp.)

An alternative would be for the DPD server to generate its own nonces,
and then simply attest to the DPD client that all the OCSP

responses returned in the DPD response are fresh. But this calls for
some amount of trust in the DPD server, and part of the

premise for DPD (as opposed to DPV) was that the client might not trust
the server.

Arial0000,0000,FFFF

Interesting point re a DPD server returning OCSPv1
responses. i didn't think about that in detail! I'll have to think more
about that case.

Steve

--============_-1233502899==_ma============--

Received: from po1.bbn.com (PO1.BBN.COM [192.1.50.38]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA11131 for ; Thu, 4 Jan 2001 06:20:56 -0800 (PST)
Received: from [171.78.30.107] (comsec.bbn.com [171.78.30.107]) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id JAA26838; Thu, 4 Jan 2001 09:25:26 -0500 (EST)
Mime-Version: 1.0
X-Sender: [email-masked]
Message-Id:
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Date: Thu, 4 Jan 2001 09:21:03 -0500
To: "Covey, Carlin"
From: Stephen Kent
Subject: RE: DPD & DPV requirements - server usage of data proffered by cl ient
Cc: PKIX-List
Content-Type: multipart/alternative; boundary="============_-1233504097==_ma============"

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

At 2:47 PM -0800 1/3/01, Covey, Carlin wrote:

Carlin,

>Steve, I have some questions concerning requirements 1.1 and 1.2
>from your proposed DPD and DPV requirements.
>
>
> "1.1 A client request can contain a single certificate or
>a certificate chain terminating
> in the "target" certificate, to assist the server in
>path construction. "
>
> "1.2 A client request can contain one or more
>revocation data items, to assist the server
> in path validation."
>
>In requirement 1.1, the phrase "...to assist the server in path
>construction. " implies that the client's intent is
>simply to aid the server, rather than to impose constraints on the
>server. This interpretation is supported by
>the absence of a requirement that would obligate the server to
>construct a path using the certificate chain proffered
>by the client. Have I made the correct interpretation?

yes, that was the intent. I expected control over path validation to
be managed by the parameters. The offered cert chain was could have
been supplied as part of a protocol that pushed a purported path to
the client, but the client might not have looked at it at all,
especially a DPV client who might not be PKI aware.

One might make an argument here for two cases, one in which the
client is passing on cert path (and revocation status data) that it
has not examined, and one in which the client is trying to constrain
path processing by mandating use of the supplied data. if folks
agree that support for both flavors of inputs is needed, we can
mandate that. Syntactically it's probably easy to add a flag
indicating which sort of input is being provided, but it will add
complexity to server processing to be able to deal with both cases.

>
>Requirement 1.2 contains the similar phrase "to assist the server in
>path validation." and again there is no requirement
>on the server to make use of this revocation data. But in this
>case, it doesn't seem quite right for the server to ignore
>the proffered revocation data, nor to accept it as verity. For
>example, if the proffered data is an OCSP response that
>indicates that a certificate is revoked**, it does not seem safe for
>the server to ignore this data in favor of a somewhat
>dated CRL that indicates that the certificate is not revoked. On
>the other hand, if the proffered data is an OCSP response
>that indicates that the certificate is not revoked, is the server
>under no obligation to perform any further checks on the
>revocation status? Note that the server may not be able to
>determine the freshness of the proffered OCSP response
>with any exactitude.

As above, the intent was to accommodate clients who might know
nothing of the supplied data and thus were merely passing it on to
the server in case it might help. I'm more concerned here that a
server not be mislead by outdated revocation status data supplied by
a client, maybe an unwitting client, as that could return an
inaccurate, "certificate valid" answer based on bad revocation status
data that would override what the server would otherwise have used.
I'm not comfortable making this sort of change yet.

> (** Of course, it would be silly for the client to proffer an OCSP
>response or CRL that indicates that the target certificate
>is revoked. However, the proffered revocation data may be for some
>other certificate that the client thinks that the server
>might use for constructing a certification path. Another
>possibility is that an XML-literate but ASN.1-illiterate client is
>incapable of parsing the OCSP response or CRL, but wishes the server
>to make use of this revocation data.)

right. that argues for the advisory, but not authoritative, approach
I proposed, or the safe approach you describe below.

> I realize that such issues will eventually be clarified in the
>finite state models for the server actions, but I think these
>points are important, and ought to be captured in the requirements
>that will drive the development of the state models.
>
>I propose the addition of the following clarifications and
>requirements for the server:
>
>
> "The server may use a certificate chain proffered by the
>client, but is not obligated to do so. "
>
> "If revocation data proffered by the client indicates
>that a certificate is revoked, the server must
> reject as invalid any certificate paths containing
>this certificate."
>
> "If revocation data proffered by the client indicates
>that a certificate is not revoked, the server must
> independently verify this data before accepting as
>valid any certificate paths containing this certificate."

This is a reasonable, safe set of clarifications to the current spec
and I'm happy to incorporate them. If folks want to expand the
requirements to include the mandatory use of supplied cert chains, I
could add that, but will not do so yet.

Steve

--============_-1233504097==_ma============
Content-Type: text/enriched; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

At 2:47 PM -0800 1/3/01, Covey, Carlin wrote:

Carlin,

=20

Arial0000,0000,FFFFSteve,
I have some questions concerning requirements 1.1 and 1.2 from your
proposed DPD and DPV requirements.=20

=20

"1.1 A client request can contain a single certificate or a
certificate chain terminating=20

in the "target" certificate, to assist the server in path
construction. "=20

"1.2 A client request can contain one or more revocation
data items, to assist the server=20

in path validation."

In requirement 1.1, the phrase "...to assist the server in path
construction. " implies that the client's intent is

simply to aid the server, rather than to impose constraints on the
server. This interpretation is supported by

the absence of a requirement that would obligate the server to
construct a path using the certificate chain proffered

by the client. Have I made the correct interpretation?=20

Arial0000,0000,FFFF

yes, that was the intent. I expected control over
path validation to be managed by the parameters. The offered cert chain
was could have been supplied as part of a protocol that pushed a
purported path to the client, but the client might not have looked at
it at all, especially a DPV client who might not be PKI aware.=20

One might make an argument here for two cases, one in which the client
is passing on cert path (and revocation status data) that it has not
examined, and one in which the client is trying to constrain path
processing by mandating use of the supplied data. if folks agree that
support for both flavors of inputs is needed, we can mandate that.
Syntactically it's probably easy to add a flag indicating which sort of
input is being provided, but it will add complexity to server
processing to be able to deal with both cases.

=20

Arial0000,0000,FFFFRequirem=
ent
1.2 contains the similar phrase "to assist the server in path
validation." and again there is no requirement

on the server to make use of this revocation data. But in this case,
it doesn't seem quite right for the server to ignore

the proffered revocation data, nor to accept it as verity. For
example, if the proffered data is an OCSP response that

indicates that a certificate is revoked**, it does not seem safe for
the server to ignore this data in favor of a somewhat

dated CRL that indicates that the certificate is not revoked. On the
other hand, if the proffered data is an OCSP response

that indicates that the certificate is not revoked, is the server under
no obligation to perform any further checks on the

revocation status? Note that the server may not be able to determine
the freshness of the proffered OCSP response

with any exactitude.

Arial0000,0000,FFFF

As above, the intent was to accommodate clients
who might know nothing of the supplied data and thus were merely
passing it on to the server in case it might help. I'm more concerned
here that a server not be mislead by outdated revocation status data
supplied by a client, maybe an unwitting client, as that could return
an inaccurate, "certificate valid" answer based on bad revocation
status data that would override what the server would otherwise have
used. I'm not comfortable making this sort of change yet.

Arial0000,0000,FFFF(**
Of course, it would be silly for the client to proffer an OCSP response
or CRL that indicates that the target certificate

is revoked. However, the proffered revocation data may be for some
other certificate that the client thinks that the server

might use for constructing a certification path. Another possibility
is that an XML-literate but ASN.1-illiterate client is

incapable of parsing the OCSP response or CRL, but wishes the server
to make use of this revocation data.)

Arial0000,0000,FFFF

right. that argues for the advisory, but not
authoritative, approach I proposed, or the safe approach you describe
below.

Arial0000,0000,FFFFI
realize that such issues will eventually be clarified in the finite
state models for the server actions, but I think these

points are important, and ought to be captured in the requirements that
will drive the development of the state models.

=20

I propose the addition of the following clarifications and requirements
for the server:

=20

"The server may use a certificate chain proffered by the
client, but is not obligated to do so. "=20

"If revocation data proffered by the client indicates that
a certificate is revoked, the server must

reject as invalid any certificate paths containing this
certificate."

"If revocation data proffered by the client indicates that
a certificate is not revoked, the server must

independently verify this data before accepting as valid
any certificate paths containing this certificate."

Arial0000,0000,FFFF

This is a reasonable, safe set of clarifications
to the current spec and I'm happy to incorporate them. If folks want to
expand the requirements to include the mandatory use of supplied cert
chains, I could add that, but will not do so yet.

Steve

--============_-1233504097==_ma============--

Received: from po1.bbn.com (PO1.BBN.COM [192.1.50.38]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA10406 for ; Thu, 4 Jan 2001 06:11:26 -0800 (PST)
Received: from [171.78.30.107] (comsec.bbn.com [171.78.30.107]) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id JAA25787; Thu, 4 Jan 2001 09:15:56 -0500 (EST)
Mime-Version: 1.0
X-Sender: [email-masked]
Message-Id:
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Date: Thu, 4 Jan 2001 09:09:36 -0500
To: "Covey, Carlin"
From: Stephen Kent
Subject: RE: DPD & DPV requirements
Cc: PKIX-List
Content-Type: multipart/alternative; boundary="============_-1233504667==_ma============"

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

Carlin,

>From Steve's email sent Friday, December 29, 2000 11:25 AM :
>
>
> 2.2 A server must be able to return
>one or more sets of certification paths and associated revocation
>data
> as a result of path discovery/validation.
>Each set shall consist of an ordered list of certificates and
>associated
> CRLs and/or OCSP responses.
>
>The wording concerning an ordered list could use some more
>specifics. Is the response to be an ordered list of certificates,
>followed by an ordered
>list of revocation information (presumably in the same order), or is
>it to be an ordered list of certificate/revocation-information pairs?
>My preference is for the pairs.
>
>
>Although the sort order is intuitive, it should probably be
>declared more explicitly. My preference is for certificate-path
>order, beginning with the target certificate.
>
>I propose the following revised wording:
>
> " ... Each set shall consist of a list of
>pairs of certificates and CRLs and/or OCSP responses, in certificate
>path order.

I'm comfortable with this proposed refinement, if there are no objections.

Steve

--============_-1233504667==_ma============
Content-Type: text/enriched; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Carlin,

Arial0000,0000,FFFFFrom
Steve's email sent Friday, December 29, 2000 11:25 AM :

=20

=20
0000,0000,FFFF 2.2 A
server must be able to return one or more sets of certification paths
and associated revocation data

as a result of path discovery/validation.
Each set shall consist of an ordered list of certificates
and associated Arial=20

CRLs and/or OCSP responses.

ArialFFFF,0000,0000=
The
wording concerning an ordered list could use some more specifics. Is
the response to be an ordered list of certificates, followed by an
ordered

list of revocation information (presumably in the same order), or is it
to be an ordered list of certificate/revocation-information pairs?

My preference is for the pairs.

=20

Although the sort order is intuitive, it should probably be declared
more explicitly. My preference is for certificate-path order, beginning
with the target certificate.=20

0000,0000,FFFFI propose the following
revised wording:

" ... Each set shall consist of a list of pairs
of certificates and CRLs and/or OCSP responses, in certificate path
order.

Arial0000,0000,FFFF

I'm comfortable with this proposed refinement, if
there are no objections.=20

Steve

--============_-1233504667==_ma============--

Received: from po1.bbn.com (PO1.BBN.COM [192.1.50.38]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA10404 for ; Thu, 4 Jan 2001 06:11:26 -0800 (PST)
Received: from [171.78.30.107] (comsec.bbn.com [171.78.30.107]) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id JAA25784; Thu, 4 Jan 2001 09:15:55 -0500 (EST)
Mime-Version: 1.0
X-Sender: [email-masked]
Message-Id:
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Date: Thu, 4 Jan 2001 09:07:44 -0500
To: "Covey, Carlin"
From: Stephen Kent
Subject: RE: DPD & DPV requirements - return one or more sets of certifica tion paths
Cc: PKIX-List
Content-Type: multipart/alternative; boundary="============_-1233504668==_ma============"

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

Carlin,

>Steve and PKIX working group,
>
>I think Steve has done an excellent job is setting forth a proposed
>set of requirements for evaluating DPD and DPV standards.
>
>Thank you Steve. This should help us on the way to reaching closure
>on this important set of standards.
>

Thanks for the compliment, and the help in refining the requirements.

>
>That said, I'd like to weigh in with some suggested revisions to
>Steve's proposal. I'll make each suggestion in a separate posting,
>with a view to generating more, but shorter and more focused
>discussion threads.
>
>From Steve's email sent Friday, December 29, 2000 11:25 AM :
> "2.2 A server must be able to return one or more sets of
>certification paths and associated revocation data as a result of
>path
> discovery/validation.. .."
>
>This requirement is a bit ambiguous. It probably is intended to mean
>that the server must be able to return one or more sets of
>certification paths and associated revocation data related to a
>single target certificate. However, the wording
>could be interpreted as meaning that the server must be able to
>return this information for a set of (possibly unrelated) target
>certificates. My preference is for the former. I suggest the
>following revision:
>
> "2.2 A server must be able to return
>one or more sets of certification paths and associated
> revocation data as a result of path
>discovery/validation related to a single target certificate."

Good point. If the WG wants to require support for multiple target
certificates per request/response, we can add that as a separate
requirement. I will update the spec based on your comments.

Steve

--============_-1233504668==_ma============
Content-Type: text/enriched; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Carlin,

Arial0000,0000,FFFFSteve
and PKIX working group,

I think Steve has done an excellent job is setting forth a proposed set
of requirements for evaluating DPD and DPV standards.

Thank you Steve. This should help us on the way to reaching closure on
this important set of standards.

Arial0000,0000,FFFF

Thanks for the compliment, and the help in
refining the requirements.

Arial0000,0000,FFFFThat
said, I'd like to weigh in with some suggested revisions to Steve's
proposal. I'll make each suggestion in a separate posting,

with a view to generating more, but shorter and more focused discussion
threads.

=46rom Steve's email sent Friday, December 29, 2000 11:25 AM :

"2.2 A server must be able to return one
or more sets of certification paths and associated revocation data as a
result of path=20

discovery/validation.. .."

FFFF,0000,0000This requirement is a bit
ambiguous. It probably is intended to mean that the server must be able
to return one or more sets of

certification paths and associated revocation data related to a
single target certificate. However, the wording

could be interpreted as meaning that the server must be able to return
this information for a set of (possibly unrelated) target

certificates. My preference is for the former. I suggest the following
revision:

"2.2 A server must be able to return one
or more sets of certification paths and associated=20

revocation data as a result of path
discovery/validation related to a single target
certificate."

FFFF,0000,0000

Good point. If the WG wants to require support for multiple
target certificates per request/response, we can add that as a separate
requirement. I will update the spec based on your comments.

Steve

--============_-1233504668==_ma============--

Received: from email.nist.gov (email.nist.gov [129.6.2.7]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id FAA09347 for ; Thu, 4 Jan 2001 05:52:41 -0800 (PST)
Received: from krdp2 (krdp2.ncsl.nist.gov [129.6.54.107]) by email.nist.gov (8.9.3/8.9.3) with ESMTP id IAA05559; Thu, 4 Jan 2001 08:57:03 -0500 (EST)
Message-Id: <[email-masked]>
X-Sender: [email-masked]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2
Date: Thu, 04 Jan 2001 08:56:52 -0500
To: Wu Xiao Ying , "[email-masked]"
From: "David A. Cooper"
Subject: Re: [Fwd: test certificate with full extensions]
In-Reply-To: <[email-masked]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"

Xiaoying,

A few months ago NIST worked with Cygnacom Solutions and Getronics Government Solutions, LLC to develop a set of certification paths for use in testing implementations of the X.509 path validation algorithm. The set of extensions that are included in the test certificates are somewhat limited, but it should work as a very good starting point.

If you are interested, information about the test suite, including documentation and the test data itself, is available from

http://csrc.nist.gov/pki/testing/x509paths.html

I hope this helps,

David Cooper

At 03:20 PM 1/4/01 +0800, Wu Xiao Ying wrote:
>I'd like to see whether my program can read most of the certificate
>extensions (better in full implementation) defined in X.509 and PKIX.
>Are there any certificate samples available at any places? Hope they
>include as many extensions as possible...

Received: from mh.transparity.com (IDENT:root@[203.127.198.235]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id XAA24084 for ; Wed, 3 Jan 2001 23:11:31 -0800 (PST)
Received: from transparity.com (xiaoying.secureage.com [203.127.198.231]) by mh.transparity.com (8.9.3/8.8.7) with ESMTP id PAA12659 for ; Thu, 4 Jan 2001 15:25:04 +0800
Message-ID: <[email-masked]>
Date: Thu, 04 Jan 2001 15:20:26 +0800
From: Wu Xiao Ying
Organization: Transparity Ltd.
X-Mailer: Mozilla 4.73 [en] (WinNT; U)
X-Accept-Language: en,zh
MIME-Version: 1.0
To: "[email-masked]"
Subject: [Fwd: test certificate with full extensions]
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Hi,

I'd like to see whether my program can read most of the certificate
extensions (better in full implementation) defined in X.509 and PKIX.
Are there any certificate samples available at any places? Hope they
include as many extensions as possible...

Please email me privately.
Thanks in advance.

Regards,
Xiaoying

Received: from rmail7.hanmir.com ([128.134.130.167]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id VAA18206 for ; Wed, 3 Jan 2001 21:50:07 -0800 (PST)
Received: (from nobody@localhost) by rmail7.hanmir.com (8.9.3/8.9.3) id OAA19614; Thu, 4 Jan 2001 14:55:08 +0900 (KST)
Date: Thu, 4 Jan 2001 14:55:08 +0900 (KST)
Message-Id: <[email-masked]>
To: [email-masked]
Subject: How can I implement VSD srvice?
From: "±è¿ø¹ü"
Content-Type: text/html; charset=euc-kr
Status: O
Content-Transfer-Encoding: 8bit
X-Mailer: HanMir Mailer
X-IP: 210.182.155.5

How are you?

My name is Wonbeom, Kim. I'm Korean.

I'm engaged in PKI application development job.

Nowadays, I study DVCS protocol.

I have compiled DVCS protocol with ASN compiler.

And then, in generated result, I notice that "message", "messageImprint", and "certs" elements are eveloped with "union" in "data" element of "DVCSRequest" type.

To support VSD service, I think that a requester must send plain text, digital signed hash value of it, and certificate to a respondent. But, I can't send these informations simultaneously, becasue "message", "messageImprint", and "certs" are unionized.

If the C-codes are generated from ASN.1 notations correctly,

how can I handle this problem. Sorry but, I ask your advice.

____________________________________________________________________________

ÇÑ¹Ì¸£ ¸ÞÀÏ(http://mail.hanmir.com/)

¿øÇÏ´Â °Í¸¸ ²À Áý¾î Ã£¾ÆÁÖ´Â ÇÑ¹Ì¸£(http://www.hanmir.com/)

Received: from exchange.cylink.com (exchange.cylink.com [192.43.161.25]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id RAA12980 for ; Wed, 3 Jan 2001 17:24:28 -0800 (PST)
Received: by exchange.cylink.com with Internet Mail Service (5.5.2650.21) id ; Wed, 3 Jan 2001 17:21:24 -0800
Message-ID: <[email-masked]>
From: "Covey, Carlin"
To: PKIX-List
Subject: RE: DPD & DPV requirements - to nonce or not to nonce?
Date: Wed, 3 Jan 2001 17:21:23 -0800
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C075EC.A6A5F6C0"

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_01C075EC.A6A5F6C0
Content-Type: text/plain;
charset="iso-8859-1"

To thwart replay attacks, both OCSP and SCVP have provisions for the
optional inclusion of nonces in requests and responses .

The premise of this is that the requester picks a nonce that it hasn't used
before, and includes it in its request.
The server is obligated to return this same nonce, ensuring that the
response was prepared after the request.

I don't see a provision in the proposed DPD and DPV requirements for the
optional inclusion of a nonce.
Is this an intentional omission, or inadvertent? Do we want/need nonces in
the new DPD/DPV standards?

I won't venture an opinion, but I will make some observations. Since nonces
are permitted in OCSP v1 responses,
nonces may appear in OCSP responses embedded in the requests sent to the DPD
or DPV server.
"1.2 A client request can contain one or more revocation data
items,
to assist the server in path validation." - from
proposed DPD & DPV requirements

The nonces in the OCSP responses will be of no use to the server, because
the server did not generate the OCSP
requests with the matching nonces.

Likewise, the responses that a DPD server returns may contain OCSP responses
with nonces. (To thwart replay attacks,
the DPD server may have put nonces in the requests that it made to OCSP
servers.)

"2.2 A server must be able to return one or more sets of
certification paths and associated
revocation data as a result of path discovery/validation.
Each set shall consist of an ordered
list of certificates and associated CRLs and/or OCSP
responses." - from proposed DPD &
DPV requirements

These nonces will be useful to the DPD server, but not to the DPD client,
since the client did not generate the matching
OCSP requests. UNLESS ....... the DPD server chooses the same nonce that
it received from the DPD client. (Contemplating
this makes me queasy.) Recall that the protection against replay attacks
was based upon the requester not using the same
nonce it had used before. This can be done cheaply by generating the nonces
as a sequence, or as a sizable random number.
But if the DPD server doesn't generate the nonce, then it must keep a record
of all the nonces that it has seen (well, perhaps
only those it has seen within some global time-ambiguity interval). Failing
to keep track of past nonces renders the DPD
server vulnerable to conspiracies between the DPD client and another agent
replaying older OCSP responses to the DPD server.
But why would a DPD client conspire against itself? It might undertake such
a conspiracy in order to fool the DPD server
into attesting to incorrect (or at least out-of-date) certificate status,
with a view toward later presenting this incorrect
attestation to someone else. (If the DPD response is timestamped, then all
the response data, including the incorrect revocation
data, will have been signed as part of the timestamp.)

An alternative would be for the DPD server to generate its own nonces, and
then simply attest to the DPD client that all the OCSP
responses returned in the DPD response are fresh. But this calls for some
amount of trust in the DPD server, and part of the
premise for DPD (as opposed to DPV) was that the client might not trust the
server.

So, to nonce or not to nonce? That is the question.

- Regards,
Carlin Covey
Cylink Corp.

------_=_NextPart_001_01C075EC.A6A5F6C0
Content-Type: text/html;
charset="iso-8859-1"

To thwart replay attacks, both OCSP and
SCVP have provisions for the optional inclusion of nonces in requests and
responses .

The
premise of this is that the requester picks a nonce that it hasn't used before,
and includes it in its request.

The
server is obligated to return this same nonce, ensuring that the
response was prepared after the request.

I
don't see a provision in the proposed DPD and DPV requirements for the optional
inclusion of a nonce.

Is
this an intentional omission, or inadvertent?  Do we want/need nonces in
the new DPD/DPV standards?

I
won't venture an opinion, but I will make some observations.  Since
nonces are permitted in OCSP v1 responses,

nonces
may appear in OCSP responses embedded in the requests sent to the DPD or
DPV server.

"1.2 A client request can contain one or more revocation data
items,

to assist the server in path validation."
-  from proposed DPD & DPV requirements

The
nonces in the OCSP responses will be of no use to the server, because the server
did not generate the OCSP
requests with the matching
nonces.

Likewise, the responses that a DPD server returns may
contain OCSP responses with nonces.  (To thwart replay
attacks,
the DPD server may have put nonces
in the requests that it made to OCSP servers.)

"2.2 A server must be able to return one or more sets of certification
paths and associated

revocation data as a result of path discovery/validation. Each set shall
consist of an ordered

list of certificates and associated CRLs and/or OCSP responses."
-  from proposed DPD &

DPV requirements

These
nonces will be useful to the DPD server, but not to the DPD client, since the
client did not generate the matching
OCSP requests.    UNLESS
.......  the DPD server chooses the same nonce that it received from
the DPD client.  (Contemplating
this makes me queasy.)
Recall that the protection against replay attacks was based upon the requester
not using the same
nonce it had used before.  This can be done
cheaply by generating the nonces as a sequence, or as a sizable random
number.
But if the DPD server doesn't generate the nonce, then it must keep a
record of all the nonces that it has seen (well, perhaps
only those it has
seen within some global time-ambiguity interval).  Failing to keep track of
past nonces renders the DPD
server vulnerable to conspiracies between the DPD
client and another agent replaying older OCSP responses to the DPD
server.
But why would a DPD client conspire against itself?  It might
undertake such a conspiracy in order to fool the DPD server
into attesting to
incorrect (or at least out-of-date) certificate status, with a view toward later
presenting this incorrect
attestation to someone else.  (If
the DPD response is timestamped, then all the response data, including the
incorrect revocation
data, will have been signed as part of the timestamp.)

An
alternative would be for the DPD server to generate its own nonces, and then
simply attest to the DPD client that all the OCSP
responses
returned in the DPD response are fresh.  But this calls for some amount of
trust in the DPD server, and part of the
premise for DPD (as opposed to DPV)
was that the client might not trust the server.

So, to
nonce or not to nonce?  That is the question.

-
Regards,
Carlin Covey
Cylink Corp.

------_=_NextPart_001_01C075EC.A6A5F6C0--

Received: from exchange.cylink.com (exchange.cylink.com [192.43.161.25]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA09887 for ; Wed, 3 Jan 2001 14:50:59 -0800 (PST)
Received: by exchange.cylink.com with Internet Mail Service (5.5.2650.21) id ; Wed, 3 Jan 2001 14:47:39 -0800
Message-ID: <[email-masked]>
From: "Covey, Carlin"
To: "'Stephen Kent'" , PKIX-List
Subject: RE: DPD & DPV requirements - server usage of data proffered by cl ient
Date: Wed, 3 Jan 2001 14:47:36 -0800
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C075D7.2AAD1AE0"

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_01C075D7.2AAD1AE0
Content-Type: text/plain;
charset="iso-8859-1"

Steve, I have some questions concerning requirements 1.1 and 1.2 from your
proposed DPD and DPV requirements.

"1.1 A client request can contain a single certificate or a
certificate chain terminating
in the "target" certificate, to assist the server in path
construction. "

"1.2 A client request can contain one or more revocation data
items, to assist the server
in path validation."

In requirement 1.1, the phrase "...to assist the server in path
construction. " implies that the client's intent is
simply to aid the server, rather than to impose constraints on the server.
This interpretation is supported by
the absence of a requirement that would obligate the server to construct a
path using the certificate chain proffered
by the client. Have I made the correct interpretation?

Requirement 1.2 contains the similar phrase "to assist the server in path
validation." and again there is no requirement
on the server to make use of this revocation data. But in this case, it
doesn't seem quite right for the server to ignore
the proffered revocation data, nor to accept it as verity. For example, if
the proffered data is an OCSP response that
indicates that a certificate is revoked**, it does not seem safe for the
server to ignore this data in favor of a somewhat
dated CRL that indicates that the certificate is not revoked. On the other
hand, if the proffered data is an OCSP response
that indicates that the certificate is not revoked, is the server under no
obligation to perform any further checks on the
revocation status? Note that the server may not be able to determine the
freshness of the proffered OCSP response
with any exactitude.

(** Of course, it would be silly for the client to proffer an OCSP response
or CRL that indicates that the target certificate
is revoked. However, the proffered revocation data may be for some other
certificate that the client thinks that the server
might use for constructing a certification path. Another possibility is
that an XML-literate but ASN.1-illiterate client is
incapable of parsing the OCSP response or CRL, but wishes the server to make
use of this revocation data.)

I realize that such issues will eventually be clarified in the finite state
models for the server actions, but I think these
points are important, and ought to be captured in the requirements that will
drive the development of the state models.

I propose the addition of the following clarifications and requirements for
the server:

"The server may use a certificate chain proffered by the client,
but is not obligated to do so. "

"If revocation data proffered by the client indicates that a
certificate is revoked, the server must
reject as invalid any certificate paths containing this
certificate."

"If revocation data proffered by the client indicates that a
certificate is not revoked, the server must
independently verify this data before accepting as valid any
certificate paths containing this certificate."

Regards,

Carlin Covey
Cylink Corp.

------_=_NextPart_001_01C075D7.2AAD1AE0
Content-Type: text/html;
charset="iso-8859-1"

Steve, I have some
questions concerning requirements 1.1 and
1.2 from your proposed DPD and DPV requirements.

"1.1 A client request can contain a single certificate or a certificate
chain terminating

in the "target" certificate, to assist the server in path
construction. "

"1.2 A client request can contain one or more revocation data items, to
assist the server

in path validation."

In requirement 1.1, the phrase "...to assist the server in path
construction. " implies that
the
client's intent is

simply to
aid the
server, rather than to impose constraints on the server.  This
interpretation is supported by

the absence
of a
requirement that would
obligate
the server to
construct a path using
the certificate chain
proffered

by the client.  Have I
made the correct interpretation?

Requirement 1.2 contains the similar phrase "to assist
the server in path validation."  and
again there is no
requirement

on the server to
make use of this revocation data.  But in this case, it doesn't
seem quite right for the
server to ignore

the proffered revocation data, nor to accept it as
verity.  For example, if the
proffered data is an OCSP response that

indicates that a certificate is revoked**, it does not
seem safe for the server to ignore this data
in favor of a somewhat

dated CRL that indicates that the certificate is not
revoked.  On the other
hand, if the proffered data is an OCSP response

that indicates that the certificate is not revoked, is
the server under no obligation to
perform any further checks on the

revocation status?  Note that the server may not
be able to determine the freshness
of the proffered OCSP response

with any
exactitude.

(** Of course, it would be silly for the client to proffer an OCSP
response or CRL that
indicates that the target certificate

is revoked.
However, the proffered
revocation data may be for some other
certificate that the
client thinks that the server

might use
for constructing a
certification path.  Another possibility is that an XML-literate
but ASN.1-illiterate
client is

incapable of parsing
the OCSP response or CRL,
but wishes the server to make use of this revocation data.)

I realize that such issues will eventually be clarified
in the finite state models for the server actions, but I think
these

points are important, and ought to be captured in the
requirements that will drive the development of the state
models.

I propose the addition of the following clarifications
and requirements for the server:

"The server may use a certificate chain proffered by the client, but is not obligated to do
so. "

"If revocation data proffered by the client indicates that
a certificate is revoked, the server must

reject as invalid any certificate
paths containing this certificate."

"If revocation data proffered by the client indicates that
a certificate is not revoked, the server must
independently
verify this data before
accepting as valid any certificate paths
containing this certificate."

Regards,

Carlin
Covey

Cylink
Corp.

------_=_NextPart_001_01C075D7.2AAD1AE0--

Received: from mail2.microsoft.com (mail2.microsoft.com [131.107.3.124]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id LAA00278 for ; Wed, 3 Jan 2001 11:32:53 -0800 (PST)
Received: from 157.54.9.104 by mail2.microsoft.com (InterScan E-Mail VirusWall NT); Wed, 03 Jan 2001 11:36:49 -0800 (Pacific Standard Time)
Received: by inet-imc-02.redmond.corp.microsoft.com with Internet Mail Service (5.5.2651.58) id ; Wed, 3 Jan 2001 08:26:30 -0800
Message-ID: <[email-masked]>
From: David Cross
To: [email-masked]
Subject: RE: Two questions on delta-CRL
Date: Wed, 3 Jan 2001 08:26:24 -0800
X-Mailer: Internet Mail Service (5.5.2651.58)

It is a problem in any large distributed directory, web farm, or complex CDP
infrastructure. It is more of an issue of the infrastructure design and not
a particular product(s).

It is easy to get multi-MB CRLs if you have large numbers of revocations
(corporate layoffs, etc) that occur from a single CA.

David B. Cross

-----Original Message-----
From: Bob Jueneman [mailto:[email-masked]]
Sent: Wednesday, January 03, 2001 8:20 AM
To: [email-masked]
Cc: [email-masked]
Subject: RE: Two questions on delta-CRL

Simon,

Without intending to set off any vendor bashing, it might be nice to know
the directory you were using, so others could help determine whether
that is a common problem or not.

By "tired" I assume you mean there was a lot of grinding caused by garbage
collection or moving files around when writing the data. In the best of all
worlds
that would be undesirable, of course, but I suppose it could happen. II it
also made retrievals considerably more "painful" (since we are
anthropomorphizing,)
that would be worse, of course. But some data, rather than generalizations,
would be helpful.

Of course a different issue would be why, given the CRLDistributionPoint
facility
which could be use to segment a CRL into a set of more reasonable size
sub-CRLs,
you needed to have a megabyte CRL in the first place?

Bob

Robert R. Jueneman
Security Architect
Novell, Inc. -- the leading provider of Net services software

>>> Simon Tardell 01/03/01 08:21AM >>>
> I don't quite follow this. Little network bandwidth is consumed
> moving a new baseCRL to a CAs directory. I believe that is all that
> is involved in publication of the CRLs.

Some directories we've tried become very tired when you write large objects
to them (megabyte and up) and to some extent when reading the same large
objects. It is not a question of bandwidth, but rather of how the directory
vendors tune their apps (then again, maybe there was a knob to tweak that I
didn't see).

Simon.

Simon Tardell, Software Architect, SmartTrust
voice +46 8 7755225, fax +46 8 7267912, cell +46 70 3198319
[email-masked]
Work smarter! http://www.smarttrust.com/career

Received: from prv-mail20.provo.novell.com (prv-mail20.provo.novell.com [137.65.81.122]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id IAA16762 for ; Wed, 3 Jan 2001 08:16:07 -0800 (PST)
Received: from INET-PRV-Message_Server by prv-mail20.provo.novell.com with Novell_GroupWise; Wed, 03 Jan 2001 09:19:54 -0700
Message-Id:
X-Mailer: Novell GroupWise Internet Agent 5.5.5.1
Date: Wed, 03 Jan 2001 09:19:52 -0700
From: "Bob Jueneman"
To:
Cc:
Subject: RE: Two questions on delta-CRL
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id IAA16763

Simon,

Without intending to set off any vendor bashing, it might be nice to know
the directory you were using, so others could help determine whether
that is a common problem or not.

By "tired" I assume you mean there was a lot of grinding caused by garbage
collection or moving files around when writing the data. In the best of all worlds
that would be undesirable, of course, but I suppose it could happen. II it
also made retrievals considerably more "painful" (since we are anthropomorphizing,)
that would be worse, of course. But some data, rather than generalizations,
would be helpful.

Of course a different issue would be why, given the CRLDistributionPoint facility
which could be use to segment a CRL into a set of more reasonable size sub-CRLs,
you needed to have a megabyte CRL in the first place?

Bob

Robert R. Jueneman
Security Architect
Novell, Inc. -- the leading provider of Net services software

>>> Simon Tardell 01/03/01 08:21AM >>>
> I don't quite follow this. Little network bandwidth is consumed
> moving a new baseCRL to a CAs directory. I believe that is all that
> is involved in publication of the CRLs.

Some directories we've tried become very tired when you write large objects
to them (megabyte and up) and to some extent when reading the same large
objects. It is not a question of bandwidth, but rather of how the directory
vendors tune their apps (then again, maybe there was a knob to tweak that I
didn't see).

Simon.

Simon Tardell, Software Architect, SmartTrust
voice +46 8 7755225, fax +46 8 7267912, cell +46 70 3198319
[email-masked]
Work smarter! http://www.smarttrust.com/career

Received: from dymwsm08.mailwatch.com (dymwsm08.mailwatch.com [204.253.83.44]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA11317 for ; Wed, 3 Jan 2001 07:24:48 -0800 (PST)
Received: from dymw0119.mailwatch.com (dymw0119.allegro.net [204.253.83.139]) by dymwsm08.mailwatch.com (8.11.0/8.11.0) with SMTP id f03FSjU25608 for ; Wed, 3 Jan 2001 10:28:45 -0500
Received: from 204.253.83.34 by dymw0119.mailwatch.com with ESMTP ( WorldSecure Server SMTP Relay(WSS) v4.3); Wed, 03 Jan 01 10:28:44 -0500
X-Server-Uuid: a8a70c28-5efd-11d4-a0eb-00508bd30591
Received: from exchsvr1.entegrity.com (exchsvr1.entegrity.com [207.215.19.3]) by dymwsm12.mailwatch.com (8.11.0/8.11.0) with ESMTP id f03FSis12938; Wed, 3 Jan 2001 10:28:44 -0500
Received: from dharter (213-123-72-112.btconnect.com [213.123.72.112]) by exchsvr1.entegrity.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id ZWLNKCKH; Wed, 3 Jan 2001 07:26:03 -0800
From: "Darren Harter"
To: "'David A. Cooper'" , "'PKIX-List'"
Subject: RE: Very Basic DN question
Date: Wed, 3 Jan 2001 15:26:24 -0000
Message-ID: <[email-masked]>
MIME-Version: 1.0
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Importance: Normal
In-Reply-To: <[email-masked]>
X-WSS-ID: 164D9AA617248-01-01
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 7bit

Thanks for the RFC2253 quote Dave.

I agree completely. Unfortunately, in my experience not all applications
conform to it - hence me describing both orderings.

Darren

-----Original Message-----
From: David A. Cooper [mailto:[email-masked]]
Sent: 03 January 2001 15:12
To: 'PKIX-List'
Subject: RE: Very Basic DN question

Darren,

I would differ with your interpretation slightly. RFC 2253 (UTF-8 String
Representation of Distinguished Names) states that "the output consists of
the string encodings of each RelativeDistinguishedName ... starting with the
last element of the sequence and moving backwards toward the first." Thus,
if DN1 were properly encoded according to RFC 2253, it should be interpreted
as a SEQUENCE of 3 RDNs with SN being the first element in the
SEQUENCE(i.e., the top of the tree) and CN being the last element (i.e., the
the bottom of the tree).

In the case of DN2, the plus sign as a separator indicates that DN2 consists
of one multi-valued RDN. Since an RDN is a SET of attribute type and value
pairs (as opposed to a SEQUENCE), the elements are unordered (i.e., they are
all at the same level).

Dave

At 02:52 PM 1/3/01 +0000, Darren Harter wrote:
>Anders,
>
>The simple answer is yes.
>
>In the first case you have one Distinguished Name (DN) that contains three
>Relative Distinguished Names (RDNs) where each RDN has one Attribute Type
>and Value (ATV). If the order of the RDNs in your string representaion is
>the same as the order in the RDN's in the ASN.1 encoding, then yes the CN
is
>the top of the tree. If they are shown reverse of the ASN.1 encoding (and
>some applications do show DNs the other way around), then SN is the top of
>the tree. It all depends on the directory schema used by your
application.
>
>In the second case, you have one DN that has one RDN, where the RDN has
>three ATVs; all at the same level in the tree - the top.
>
>Hope this helps,
>
>Darren
>
>-----Original Message-----
>From: Anders Rundgren [mailto:[email-masked]]
>Sent: 03 January 2001 14:33
>To: PKIX-List
>Subject: Very Basic DN question
>
>
>Sorry for bringing a very basic question to the table but I could not find
>this information anywhere.
>
>DN1 CN=John Doe, C=US, SN=6767
>DN2 CN=John Doe + C=US + SN=6767
>
>The latter is what *some* (not all!) certificate viewers show when the SET
>contains
>multiple items.
>
>Q: Does the former indicate a tree (with CN at the top?) , while the latter
>indicate
>that all elements belong to the same level? We RDBMS-oriented developers
>do seldom utilize this information but it is always nice to know. :-)
>
>/anders
>

Received: from internet.across ([213.212.5.232]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id HAA09900 for ; Wed, 3 Jan 2001 07:19:55 -0800 (PST)
Received: FROM acrossw01.across BY internet.across ; Wed Jan 03 16:26:48 2001 +0100
Received: by acrossw01.acrosswireless.com with Internet Mail Service (5.5.2650.21) id ; Wed, 3 Jan 2001 16:21:14 +0100
Message-ID:
From: Simon Tardell
To: "'Mione, Tony'" , "'David Cross'" , "'Denis Pinkas'" , Sam Schaen
Cc: IETF-PXIX
Subject: RE: Two questions on delta-CRL
Date: Wed, 3 Jan 2001 16:21:13 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"

> I don't quite follow this. Little network bandwidth is consumed
> moving a new baseCRL to a CAs directory. I believe that is all that
> is involved in publication of the CRLs.

Some directories we've tried become very tired when you write large objects
to them (megabyte and up) and to some extent when reading the same large
objects. It is not a question of bandwidth, but rather of how the directory
vendors tune their apps (then again, maybe there was a knob to tweak that I
didn't see).

Simon.

Simon Tardell, Software Architect, SmartTrust
voice +46 8 7755225, fax +46 8 7267912, cell +46 70 3198319
[email-masked]
Work smarter! http://www.smarttrust.com/career

Received: from ntserver2.chrysalis-its.com ([209.47.245.163]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA09150 for ; Wed, 3 Jan 2001 07:17:38 -0800 (PST)
From: [email-masked]
Received: by NTSERVER2 with Internet Mail Service (5.5.2650.21) id ; Wed, 3 Jan 2001 10:22:38 -0500
Message-ID: <[email-masked]>
To: [email-masked], [email-masked]
Subject: RE: Two questions on delta-CRL
Date: Wed, 3 Jan 2001 10:22:37 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C07599.015074F0"

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_01C07599.015074F0
Content-Type: text/plain;
charset="iso-8859-1"

Hi Denis,

If you look at Annex C of X.509 (2000) on Examples of Delta CRL Issuance,
you will see that a full CRL does NOT need to be issued with each Delta CRL.

Cheers,

Francois
___________________________________
Francois Rousseau
Director of Standards and Conformance
Chrysalis-ITS
1688 Woodward Drive
Ottawa, Ontario, CANADA, K2C 3R7
[email-masked] Tel. (613) 723-5076 ext. 419
http://www.chrysalis-its.com Fax. (613) 723-5078

-----Original Message-----
From: Denis Pinkas [mailto:[email-masked]]
Sent: Tuesday, January 02, 2001 6:25 AM
To: IETF-PXIX
Subject: Two questions on delta-CRL

In section 5.2.4 (Delta CRL Indicator), RFC 2459 states:

The delta CRL indicator is a critical CRL extension that identifies a
delta-CRL. The use of delta-CRLs can significantly improve
processing time for applications which store revocation information
in a format other than the CRL structure. This allows changes to be
added to the local database while ignoring unchanged information that
is already in the local database.

When a delta-CRL is issued, the CAs MUST also issue a complete CRL.

(...) Again, a delta-CRL MUST NOT be issued without a corresponding
complete CRL.

The two questions are the following:

1) What is the rational for mandating the issuance of a complete CRL each
time a delta-CRL is issued ?
2) Under which conditions could this requirement be relaxed ?

Denis

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

RE: Two questions on delta-CRL

Hi Denis,

If you look at Annex C of X.509 (2000) on Examples of =
Delta CRL Issuance, you will see that a full CRL does NOT need to be =
issued with each Delta CRL.

Cheers,

Francois

___________________________________

Francois Rousseau

Director of Standards and Conformance

Chrysalis-ITS

1688 Woodward Drive

Ottawa, Ontario, CANADA, K2C 3R7

[email-masked]      Tel. =
(613) 723-5076 ext. 419

http://www.chrysalis-its.com   &nbs=
p; Fax. (613) 723-5078

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

From: Denis Pinkas [mailto:[email-masked]]<=
/FONT>

Sent: Tuesday, January 02, 2001 6:25 AM

To: IETF-PXIX

Subject: Two questions on delta-CRL

In section 5.2.4 (Delta CRL Indicator), RFC 2459 =
states:

The delta CRL indicator is a critical CRL =
extension that identifies a

delta-CRL.  The use of delta-CRLs can =
significantly improve

processing time for applications which store =
revocation information

in a format other than the CRL =
structure.  This allows changes to be

added to the local database while ignoring =
unchanged information that

is already in the local database.

When a delta-CRL is issued, the CAs MUST also =
issue a complete CRL.

(...) Again, a delta-CRL MUST NOT be issued =
without a corresponding

complete CRL.

The two questions are the following:

1) What is the rational for mandating the issuance of =
a complete CRL each

time a delta-CRL is issued ?

2) Under which conditions could this requirement be =
relaxed ?

Denis

------_=_NextPart_001_01C07599.015074F0--

Received: from euryale.inf.ufsc.br (euryale.inf.ufsc.br [150.162.60.23]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA08638 for ; Wed, 3 Jan 2001 07:15:41 -0800 (PST)
Received: from safeweb (inf242.inf.ufsc.br [150.162.60.242]) by euryale.inf.ufsc.br (8.11.1/8.11.1) with SMTP id f03GL1Q31420 for ; Wed, 3 Jan 2001 13:21:01 -0300
Message-ID: <[email-masked]>
From: "Augusto Jun Devegili"
To: "ietf pkix"
References: <[email-masked]>
Subject: Re: Question to
Date: Wed, 3 Jan 2001 13:20:51 -0200
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

Datum is single, data is plural.

----- Original Message -----
From: "Bernd Matthes"
To: "ietf pkix"
Sent: Wednesday, January 03, 2001 1:08 PM
Subject: Question to

> What is the meaning of 'datum'?
> Should it be 'data' instead of 'datum'?

Received: from email.nist.gov (email.nist.gov [129.6.2.7]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA08203 for ; Wed, 3 Jan 2001 07:07:40 -0800 (PST)
Received: from krdp2 (krdp2.ncsl.nist.gov [129.6.54.107]) by email.nist.gov (8.9.3/8.9.3) with ESMTP id KAA09240 for ; Wed, 3 Jan 2001 10:12:06 -0500 (EST)
Message-Id: <[email-masked]>
X-Sender: [email-masked]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2
Date: Wed, 03 Jan 2001 10:11:54 -0500
To: "'PKIX-List'"
From: "David A. Cooper"
Subject: RE: Very Basic DN question
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"

Darren,

I would differ with your interpretation slightly. RFC 2253 (UTF-8 String Representation of Distinguished Names) states that "the output consists of the string encodings of each RelativeDistinguishedName ... starting with the last element of the sequence and moving backwards toward the first." Thus, if DN1 were properly encoded according to RFC 2253, it should be interpreted as a SEQUENCE of 3 RDNs with SN being the first element in the SEQUENCE(i.e., the top of the tree) and CN being the last element (i.e., the the bottom of the tree).

In the case of DN2, the plus sign as a separator indicates that DN2 consists of one multi-valued RDN. Since an RDN is a SET of attribute type and value pairs (as opposed to a SEQUENCE), the elements are unordered (i.e., they are all at the same level).

Dave

At 02:52 PM 1/3/01 +0000, Darren Harter wrote:
>Anders,
>
>The simple answer is yes.
>
>In the first case you have one Distinguished Name (DN) that contains three
>Relative Distinguished Names (RDNs) where each RDN has one Attribute Type
>and Value (ATV). If the order of the RDNs in your string representaion is
>the same as the order in the RDN's in the ASN.1 encoding, then yes the CN is
>the top of the tree. If they are shown reverse of the ASN.1 encoding (and
>some applications do show DNs the other way around), then SN is the top of
>the tree. It all depends on the directory schema used by your application.
>
>In the second case, you have one DN that has one RDN, where the RDN has
>three ATVs; all at the same level in the tree - the top.
>
>Hope this helps,
>
>Darren
>
>-----Original Message-----
>From: Anders Rundgren [mailto:[email-masked]]
>Sent: 03 January 2001 14:33
>To: PKIX-List
>Subject: Very Basic DN question
>
>
>Sorry for bringing a very basic question to the table but I could not find
>this information anywhere.
>
>DN1 CN=John Doe, C=US, SN=6767
>DN2 CN=John Doe + C=US + SN=6767
>
>The latter is what *some* (not all!) certificate viewers show when the SET
>contains
>multiple items.
>
>Q: Does the former indicate a tree (with CN at the top?) , while the latter
>indicate
>that all elements belong to the same level? We RDBMS-oriented developers
>do seldom utilize this information but it is always nice to know. :-)
>
>/anders
>

Received: from brot.celocom.de (brot.celocom.de [212.78.104.200]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA07911 for ; Wed, 3 Jan 2001 07:04:35 -0800 (PST)
Received: from frolic.celocom.de (frolic.celocom.de [212.78.104.90]) by brot.celocom.de (Postfix) with ESMTP id E54072FD2 for ; Wed, 03 Jan 2001 16:09:01 +0100 (CET)
Received: from celocom.de (bernd.celocom.de [212.78.104.41]) by frolic.celocom.de (Postfix) with ESMTP id D637C108003 for ; Wed, 3 Jan 2001 16:09:01 +0100 (CET)
Message-ID: <[email-masked]>
Date: Wed, 03 Jan 2001 16:08:59 +0100
From: Bernd Matthes
Reply-To: [email-masked]
Organization: Celo Communications -- http://www.celocom.com
X-Mailer: Mozilla 4.75 [en] (WinNT; U)
X-Accept-Language: de,en
MIME-Version: 1.0
To: ietf pkix
Subject: Question to
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------msD6F76CBCE8ECFF095FFD13A4"

This is a cryptographically signed message in MIME format.

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

Hi!

I have a question to the following sentence
from section 2.4.1. Request Format:

"The messageImprint field SHOULD contain the hash of the datum to be
time stamped."

What is the meaning of 'datum'?
Should it be 'data' instead of 'datum'?

Thanks for any comments.

with kind regards
--
Mors certa, hora incerta. In dubio pro mille.
--------------------------------------------------------------------
Bernd Matthes Celo Communications GmbH
Senior Software Engineer Weissenfelser Strasse 46a
Nachrichtentechniker D 06217 Merseburg
Dipl.-Ing.(FH) http://www.celocom.com
f. technische Informatik mailto:[email-masked]
http://www.worldbug.de Tel.: +49 3461/3318-0
mailto:[email-masked] Fax: +49 3461/415072
--------------------------------------------------------------------
"When in doubt, use brute force." (Ken Thompson)
--------------msD6F76CBCE8ECFF095FFD13A4
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

MIIKSgYJKoZIhvcNAQcCoIIKOzCCCjcCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC
B9YwggSgMIIECaADAgECAhBsOnTzXfzOOQkJistWSC3oMA0GCSqGSIb3DQEBBAUAMIHMMRcw
FQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y
azFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5
IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRp
dmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTAwMDEyNzAwMDAw
MFoXDTAxMDIwOTIzNTk1OVowggESMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UE
CxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9y
ZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMV
UGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBO
ZXRzY2FwZSBGdWxsIFNlcnZpY2UxFjAUBgNVBAMUDUJlcm5kIE1hdHRoZXMxITAfBgkqhkiG
9w0BCQEWEm1haW5idWdAY2Vsb2NvbS5kZTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA
5XDGxWjDOe+gHZygtVsNACVkbiY27ug06wI9DGzn4+ibdyEoqNnMlqe7dHSHsLG5f9Fl8gBa
ZgwOUnNClgnjCbqoByj4In82wWwUG97DndueKQhN78pYDRBWhGXKo/YSGI2l5rw7fjYnlTlw
6QQF0OGpFNBXzkNCBC4muSaI2YUCAwEAAaOCATgwggE0MAkGA1UdEwQCMAAwgawGA1UdIASB
pDCBoTCBngYLYIZIAYb4RQEHAQEwgY4wKAYIKwYBBQUHAgEWHGh0dHBzOi8vd3d3LnZlcmlz
aWduLmNvbS9DUFMwYgYIKwYBBQUHAgIwVjAVFg5WZXJpU2lnbiwgSW5jLjADAgEBGj1WZXJp
U2lnbidzIENQUyBpbmNvcnAuIGJ5IHJlZmVyZW5jZSBsaWFiLiBsdGQuIChjKTk3IFZlcmlT
aWduMBEGCWCGSAGG+EIBAQQEAwIHgDAwBgpghkgBhvhFAQYHBCIWIDFjNzhjMGNiYWZjMzg2
YzQzYzFmMWFjYTY5NzY4Nzk3MDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNp
Z24uY29tL2NsYXNzMS5jcmwwDQYJKoZIhvcNAQEEBQADgYEAsvJl1q8TirOQUfjbbyZKmVdi
k+2YQmQr64uvnEGf0Vp/laotPE49SR5Vu9GwGA2cPY/CPrb9v/bc3mOnCBlJ2m/xQIITJRxv
A66enfch2KSRLjl+VyU5BeIkq3UZekTAy76DPozOEwd6Azf4fLJy6AIh/DRS0GS9w/l2sLYQ
FAAwggMuMIICl6ADAgECAhEA0nYujRQMPX2yqCVdr+4NdTANBgkqhkiG9w0BAQIFADBfMQsw
CQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xNzA1BgNVBAsTLkNsYXNzIDEg
UHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkwHhcNOTgwNTEyMDAwMDAw
WhcNMDgwNTEyMjM1OTU5WjCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsT
FlZlcmlTaWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVw
b3NpdG9yeS9SUEEgSW5jb3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1Zl
cmlTaWduIENsYXNzIDEgQ0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZh
bGlkYXRlZDCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAu1pEigQWu1X9A3qKLZRPFXg2
uA1Ksm+cVL+86HcqnbnwaLuV2TFBcHqBS7lIE1YtxwjhhEKrwKKSq0RcqkLwgg4C6S/7wju7
vsknCl22sDZCM7VuVIhPh0q/Gdr5FegPh7Yc48zGmo5/aiSS4/zgZbqnsX7vyds3ashKyAkG
5JkCAwEAAaN8MHowEQYJYIZIAYb4QgEBBAQDAgEGMEcGA1UdIARAMD4wPAYLYIZIAYb4RQEH
AQEwLTArBggrBgEFBQcCARYfd3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQTAPBgNV
HRMECDAGAQH/AgEAMAsGA1UdDwQEAwIBBjANBgkqhkiG9w0BAQIFAAOBgQCIuDc73dqUNwCt
qp/hgQFxHpJqbS/28Z3TymQ43BuYDAeGW4UVag+5SYWklfEXfWe0fy0s3ZpCnsM+tI6q5QsG
3vJWKvozx74Z11NMw73I4xe1pElCY+zCphcPXVgaSTyQXFWjZSAA/Rgg5V+CprGoksVYasGN
Azzrw80FopCubjGCAjwwggI4AgEBMIHhMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEf
MB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWdu
LmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYG
A1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29u
YSBOb3QgVmFsaWRhdGVkAhBsOnTzXfzOOQkJistWSC3oMAkGBSsOAwIaBQCggbEwGAYJKoZI
hvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDEwMTAzMTUwOTAxWjAjBgkq
hkiG9w0BCQQxFgQUyimHrQxEZTeSEHUdHzmMbDA2CBgwUgYJKoZIhvcNAQkPMUUwQzAKBggq
hkiG9w0DBzAOBggqhkiG9w0DAgICAIAwBwYFKw4DAgcwDQYIKoZIhvcNAwICAUAwDQYIKoZI
hvcNAwICASgwDQYJKoZIhvcNAQEBBQAEgYBQAxQBP5d5P7bV4UcAMlb3bWIukUBl7UIoN2lb
H/HZX7Dl3xkDnEGVS63ZJ00QeH7E+KSQCmZgfUH1gofHeaSvJzbe8M1srjMovf1KYwE/1hhn
6vBVSJgRBcV0QswCFzVo/3WezfAboTGqdajBqf1V9P8LdEmeH7shL6ZhGyYUFA==
--------------msD6F76CBCE8ECFF095FFD13A4--

Received: from dymwsm05.mailwatch.com (dymwsm05.mailwatch.com [204.253.83.41]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA06471 for ; Wed, 3 Jan 2001 06:50:57 -0800 (PST)
Received: from dymw0125.mailwatch.com (dymw0125.allegro.net [204.253.83.81]) by dymwsm05.mailwatch.com (8.11.0/8.11.0) with SMTP id f03Ess713936 for ; Wed, 3 Jan 2001 09:54:54 -0500
Received: from 204.253.83.26 by dymw0125.mailwatch.com with ESMTP ( WorldSecure Server SMTP Relay(WSS) v4.3); Wed, 03 Jan 01 09:54:51 -0500
X-Server-Uuid: 8014d96c-8cb5-11d4-814d-00508bd934cf
Received: from exchsvr1.entegrity.com (exchsvr1.entegrity.com [207.215.19.3]) by dymwsm11.mailwatch.com (8.11.0/8.11.0) with ESMTP id f03Esof10885; Wed, 3 Jan 2001 09:54:50 -0500
Received: from dharter (213-123-72-112.btconnect.com [213.123.72.112]) by exchsvr1.entegrity.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id ZWLNKC1Q; Wed, 3 Jan 2001 06:52:09 -0800
From: "Darren Harter"
To: "'Anders Rundgren'" , "'PKIX-List'"
Subject: RE: Very Basic DN question
Date: Wed, 3 Jan 2001 14:52:30 -0000
Message-ID: <[email-masked]>
MIME-Version: 1.0
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Importance: Normal
In-Reply-To: <[email-masked]>
X-WSS-ID: 164DE2B12243-01-01
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 7bit

Anders,

The simple answer is yes.

In the first case you have one Distinguished Name (DN) that contains three
Relative Distinguished Names (RDNs) where each RDN has one Attribute Type
and Value (ATV). If the order of the RDNs in your string representaion is
the same as the order in the RDN's in the ASN.1 encoding, then yes the CN is
the top of the tree. If they are shown reverse of the ASN.1 encoding (and
some applications do show DNs the other way around), then SN is the top of
the tree. It all depends on the directory schema used by your application.

In the second case, you have one DN that has one RDN, where the RDN has
three ATVs; all at the same level in the tree - the top.

Hope this helps,

Darren

-----Original Message-----
From: Anders Rundgren [mailto:[email-masked]]
Sent: 03 January 2001 14:33
To: PKIX-List
Subject: Very Basic DN question

Sorry for bringing a very basic question to the table but I could not find
this information anywhere.

DN1 CN=John Doe, C=US, SN=6767
DN2 CN=John Doe + C=US + SN=6767

The latter is what *some* (not all!) certificate viewers show when the SET
contains
multiple items.

Q: Does the former indicate a tree (with CN at the top?) , while the latter
indicate
that all elements belong to the same level? We RDBMS-oriented developers
do seldom utilize this information but it is always nice to know. :-)

/anders

Received: from mailc.telia.com (mailc.telia.com [194.22.190.4]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA05871 for ; Wed, 3 Jan 2001 06:30:25 -0800 (PST)
Received: from d1o69.telia.com (d1o69.telia.com [62.20.144.241]) by mailc.telia.com (8.11.0/8.11.0) with ESMTP id f03EYp628919 for ; Wed, 3 Jan 2001 15:34:51 +0100 (CET)
Received: from mega (t4o69p77.telia.com [62.20.145.197]) by d1o69.telia.com (8.10.2/8.10.1) with SMTP id f03EYol20528 for ; Wed, 3 Jan 2001 15:34:50 +0100 (CET)
Message-ID: <[email-masked]>
From: "Anders Rundgren"
To: "PKIX-List"
Subject: Very Basic DN question
Date: Wed, 3 Jan 2001 15:33:15 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
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
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id GAA05872

Sorry for bringing a very basic question to the table but I could not find
this information anywhere.

DN1 CN=John Doe, C=US, SN=6767
DN2 CN=John Doe + C=US + SN=6767

The latter is what *some* (not all!) certificate viewers show when the SET contains
multiple items.

Q: Does the former indicate a tree (with CN at the top?) , while the latter indicate
that all elements belong to the same level? We RDBMS-oriented developers
do seldom utilize this information but it is always nice to know. :-)

/anders

Received: from ietf.org (odin.ietf.org [132.151.1.176]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id EAA26531 for ; Wed, 3 Jan 2001 04:15:17 -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 HAA18634; Wed, 3 Jan 2001 07:19:42 -0500 (EST)
Message-Id: <[email-masked]>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-pkix-technr-03.txt
Date: Wed, 03 Jan 2001 07:19:41 -0500
Sender: [email-masked]

--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 Technical
Requirements for a non-Repudiation Service
Author(s) : T. Gindin
Filename : draft-ietf-pkix-technr-03.txt
Pages : 8
Date : 02-Jan-01

This document describes those features of a service which processes
signed documents which must be present in order for that service to
constitute a 'technical non-repudiation' service. A technical
non-repudiation service must permit an independent verifier to
determine whether a given signature was applied to a given data
object by the private key associated with a given valid certificate,
at a time later than the signature. The features of a technical non-
repudiation service are expected to be necessary for a full non-
repudiation service, although they may not be sufficient.
This document is intended to clarify the definition of the
'non-repudiation' service in RFC 2459. It should thus serve as a
guide to when the nonRepudiation bit of the keyUsage extension should
be set and to when a Certificate Authority is required to archive
CRL's.

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

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-ietf-pkix-technr-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:
[email-masked].
In the body type:
"FILE /internet-drafts/draft-ietf-pkix-technr-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="[email-masked]"

Content-Type: text/plain
Content-ID: <[email-masked]>

ENCODING mime
FILE /internet-drafts/draft-ietf-pkix-technr-03.txt

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

Content-Type: text/plain
Content-ID: <[email-masked]>

--OtherAccess--

--NextPart--

Received: from femail5.sdc1.sfba.home.com (femail5.sdc1.sfba.home.com [24.0.95.85]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id DAA24439 for ; Wed, 3 Jan 2001 03:37:05 -0800 (PST)
Received: from revelation ([65.4.166.11]) by femail5.sdc1.sfba.home.com (InterMail vM.4.01.03.00 201-229-121) with SMTP id <20010103114131.UENM29808.femail5.sdc1.sfba.home.com@revelation>; Wed, 3 Jan 2001 03:41:31 -0800
Reply-To:
From: "Jim Schaad"
To: ,
Subject: RE: RFC2630: Need clarification
Date: Wed, 3 Jan 2001 03:40:22 -0800
Message-ID: <[email-masked]>
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)
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Importance: Normal
In-Reply-To: <[email-masked]>

First - Questions on CMS should be directed to the S/MIME mailing list not
the PKIX mailing list.

Authenticated and Unauthenticated attributes occur in the AuthenticatedData
structure (section 9). The statement is just being made that a counter
signature is not present in the AuthenticatedData structure.

jim schaad

-----Original Message-----
From: Bernd Matthes [mailto:[email-masked]]
Sent: Wednesday, January 03, 2001 3:36 AM
To: [email-masked]
Subject: RFC2630: Need clarification

Hi!
At first a happy new year to all!

I need a clarification to following sentence from RFC 2630,
section 11.4, Countersignature:
"The countersignature attribute must be an unsigned attribute; it
cannot be a signed attribute, an authenticated attribute, or an
unauthenticated attribute."

What is the difference between:
a) signed attribute <-> authenticated attribute
b) unsigned attribute <-> unauthenticated attribute
to relate to CMS?

Where is located a (un)authenticated attribute in an
signed-data CMS?
I thought, it exist as (un)signed attribute in the SignerInfo,
or is this complete beside them?

Thanks in advance
with kind regards
--
Mors certa, hora incerta. In dubio pro mille.
--------------------------------------------------------------------
Bernd Matthes Celo Communications GmbH
Senior Software Engineer Weissenfelser Strasse 46a
Nachrichtentechniker D 06217 Merseburg
Dipl.-Ing.(FH) http://www.celocom.com
f. technische Informatik mailto:[email-masked]
http://www.worldbug.de Tel.: +49 3461/3318-0
mailto:[email-masked] Fax: +49 3461/415072
--------------------------------------------------------------------
"When in doubt, use brute force." (Ken Thompson)

Received: from brot.celocom.de (brot.celocom.de [212.78.104.200]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id DAA23971 for ; Wed, 3 Jan 2001 03:31:18 -0800 (PST)
Received: from frolic.celocom.de (frolic.celocom.de [212.78.104.90]) by brot.celocom.de (Postfix) with ESMTP id DAC292FD2 for ; Wed, 03 Jan 2001 12:35:43 +0100 (CET)
Received: from celocom.de (bernd.celocom.de [212.78.104.41]) by frolic.celocom.de (Postfix) with ESMTP id 9B05C108003; Wed, 3 Jan 2001 12:35:43 +0100 (CET)
Message-ID: <[email-masked]>
Date: Wed, 03 Jan 2001 12:35:37 +0100
From: Bernd Matthes
Reply-To: [email-masked]
Organization: Celo Communications GmbH http://www.celocom.de
X-Mailer: Mozilla 4.75 [en] (WinNT; U)
X-Accept-Language: de,en
MIME-Version: 1.0
To: "[email-masked]"
Subject: RFC2630: Need clarification
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms0F6717299EE167242E6870E4"

This is a cryptographically signed message in MIME format.

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

Hi!
At first a happy new year to all!

I need a clarification to following sentence from RFC 2630,
section 11.4, Countersignature:
"The countersignature attribute must be an unsigned attribute; it
cannot be a signed attribute, an authenticated attribute, or an
unauthenticated attribute."

What is the difference between:
a) signed attribute <-> authenticated attribute
b) unsigned attribute <-> unauthenticated attribute
to relate to CMS?

Where is located a (un)authenticated attribute in an
signed-data CMS?
I thought, it exist as (un)signed attribute in the SignerInfo,
or is this complete beside them?

Thanks in advance
with kind regards
--
Mors certa, hora incerta. In dubio pro mille.
--------------------------------------------------------------------
Bernd Matthes Celo Communications GmbH
Senior Software Engineer Weissenfelser Strasse 46a
Nachrichtentechniker D 06217 Merseburg
Dipl.-Ing.(FH) http://www.celocom.com
f. technische Informatik mailto:[email-masked]
http://www.worldbug.de Tel.: +49 3461/3318-0
mailto:[email-masked] Fax: +49 3461/415072
--------------------------------------------------------------------
"When in doubt, use brute force." (Ken Thompson)
--------------ms0F6717299EE167242E6870E4
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

MIIKSgYJKoZIhvcNAQcCoIIKOzCCCjcCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC
B9YwggSgMIIECaADAgECAhBsOnTzXfzOOQkJistWSC3oMA0GCSqGSIb3DQEBBAUAMIHMMRcw
FQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y
azFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5
IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRp
dmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTAwMDEyNzAwMDAw
MFoXDTAxMDIwOTIzNTk1OVowggESMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UE
CxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9y
ZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMV
UGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBO
ZXRzY2FwZSBGdWxsIFNlcnZpY2UxFjAUBgNVBAMUDUJlcm5kIE1hdHRoZXMxITAfBgkqhkiG
9w0BCQEWEm1haW5idWdAY2Vsb2NvbS5kZTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA
5XDGxWjDOe+gHZygtVsNACVkbiY27ug06wI9DGzn4+ibdyEoqNnMlqe7dHSHsLG5f9Fl8gBa
ZgwOUnNClgnjCbqoByj4In82wWwUG97DndueKQhN78pYDRBWhGXKo/YSGI2l5rw7fjYnlTlw
6QQF0OGpFNBXzkNCBC4muSaI2YUCAwEAAaOCATgwggE0MAkGA1UdEwQCMAAwgawGA1UdIASB
pDCBoTCBngYLYIZIAYb4RQEHAQEwgY4wKAYIKwYBBQUHAgEWHGh0dHBzOi8vd3d3LnZlcmlz
aWduLmNvbS9DUFMwYgYIKwYBBQUHAgIwVjAVFg5WZXJpU2lnbiwgSW5jLjADAgEBGj1WZXJp
U2lnbidzIENQUyBpbmNvcnAuIGJ5IHJlZmVyZW5jZSBsaWFiLiBsdGQuIChjKTk3IFZlcmlT
aWduMBEGCWCGSAGG+EIBAQQEAwIHgDAwBgpghkgBhvhFAQYHBCIWIDFjNzhjMGNiYWZjMzg2
YzQzYzFmMWFjYTY5NzY4Nzk3MDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNp
Z24uY29tL2NsYXNzMS5jcmwwDQYJKoZIhvcNAQEEBQADgYEAsvJl1q8TirOQUfjbbyZKmVdi
k+2YQmQr64uvnEGf0Vp/laotPE49SR5Vu9GwGA2cPY/CPrb9v/bc3mOnCBlJ2m/xQIITJRxv
A66enfch2KSRLjl+VyU5BeIkq3UZekTAy76DPozOEwd6Azf4fLJy6AIh/DRS0GS9w/l2sLYQ
FAAwggMuMIICl6ADAgECAhEA0nYujRQMPX2yqCVdr+4NdTANBgkqhkiG9w0BAQIFADBfMQsw
CQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xNzA1BgNVBAsTLkNsYXNzIDEg
UHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkwHhcNOTgwNTEyMDAwMDAw
WhcNMDgwNTEyMjM1OTU5WjCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsT
FlZlcmlTaWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVw
b3NpdG9yeS9SUEEgSW5jb3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1Zl
cmlTaWduIENsYXNzIDEgQ0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZh
bGlkYXRlZDCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAu1pEigQWu1X9A3qKLZRPFXg2
uA1Ksm+cVL+86HcqnbnwaLuV2TFBcHqBS7lIE1YtxwjhhEKrwKKSq0RcqkLwgg4C6S/7wju7
vsknCl22sDZCM7VuVIhPh0q/Gdr5FegPh7Yc48zGmo5/aiSS4/zgZbqnsX7vyds3ashKyAkG
5JkCAwEAAaN8MHowEQYJYIZIAYb4QgEBBAQDAgEGMEcGA1UdIARAMD4wPAYLYIZIAYb4RQEH
AQEwLTArBggrBgEFBQcCARYfd3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQTAPBgNV
HRMECDAGAQH/AgEAMAsGA1UdDwQEAwIBBjANBgkqhkiG9w0BAQIFAAOBgQCIuDc73dqUNwCt
qp/hgQFxHpJqbS/28Z3TymQ43BuYDAeGW4UVag+5SYWklfEXfWe0fy0s3ZpCnsM+tI6q5QsG
3vJWKvozx74Z11NMw73I4xe1pElCY+zCphcPXVgaSTyQXFWjZSAA/Rgg5V+CprGoksVYasGN
Azzrw80FopCubjGCAjwwggI4AgEBMIHhMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEf
MB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWdu
LmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYG
A1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29u
YSBOb3QgVmFsaWRhdGVkAhBsOnTzXfzOOQkJistWSC3oMAkGBSsOAwIaBQCggbEwGAYJKoZI
hvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDEwMTAzMTEzNTQzWjAjBgkq
hkiG9w0BCQQxFgQU340tlzmcw3r0o9Hv6rQe4B0wqlUwUgYJKoZIhvcNAQkPMUUwQzAKBggq
hkiG9w0DBzAOBggqhkiG9w0DAgICAIAwBwYFKw4DAgcwDQYIKoZIhvcNAwICAUAwDQYIKoZI
hvcNAwICASgwDQYJKoZIhvcNAQEBBQAEgYDJQYcEBWa957+6bszKR0wnrEMy/SreRy5SD/Pl
V2IkNiK37jCtYNU7hkmNpp2gB3qua2NQWNZelaa2KRj8ZRWq1bgcO3chcESv3xc2ts5LoHRi
iwvty+ci0MqWus5JURQsTifod8wa9WUTq1QBsr7Lcu3nvxI4pSL22RUGHntDUw==
--------------ms0F6717299EE167242E6870E4--

Received: from mailf.telia.com ([email-masked] [194.22.194.25]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id BAA11399 for ; Wed, 3 Jan 2001 01:39:29 -0800 (PST)
Received: from d1o69.telia.com (d1o69.telia.com [62.20.144.241]) by mailf.telia.com (8.9.3/8.9.3) with ESMTP id KAA19048; Wed, 3 Jan 2001 10:43:44 +0100 (CET)
Received: from mega (t6o69p90.telia.com [213.64.110.210]) by d1o69.telia.com (8.10.2/8.10.1) with SMTP id f039hhl12269; Wed, 3 Jan 2001 10:43:43 +0100 (CET)
Message-ID: <[email-masked]>
From: "Anders Rundgren"
To: , "Ietf-Pkix" , "Stefan Santesson"
References: <[email-masked]>
Subject: Re: Why don't using Permanent Identifier on QC certificates?
Date: Wed, 3 Jan 2001 10:42:08 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
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
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id BAA11403

Stefan,

> The PI draft defines another attribute/mechanism to create a complete new
> way of assigning a unique identifier for a person. I.e. to my knowledge you
> can't use it to store an existing code (such as SSN).

The PI draft does as you say introduce a a completely new way of assigning
a unique identifier to an entity (although the current draft mention individuals, I consider that
just a typo...), but does not prohibit (or recommend) this identifier in any way. I.e. PI
should work with any existing UID scheme.

> I would though be careful before I start using PI in a wide scale because I
> fear that it may not scale as well as we would like. In Sweden you have to
> go to the national standards body to get an OID. Since OID is only designed
> to define objects in standards, the current schema in Sweden are to my
> knowledge just dimensioned to register more than just above 16000
> organizations under the Swedish root. They have just used up about 500 + so
> that is not a problem right now. But imagine what would happen if every
> organization asks for its own OID structure to register peoples/employees,
> then the standards body would have to create a new sub structure for this.

I think this is slightly wrong. The OID you mention refer to a registered naming authority
which is essentially only applicable to a few useful external schemes that exists
today. Like DUNS, the Swedish citizen registry etc. Organizations acting as CAs
would typically not specify this optional element as their naming domain = CA.

> I have not made my homework to well so I can be wrong here but I think this
> should be overlooked more carefully before we jump to fast into approving
> the PI concept.

I believe that the PI concept has some problems like competing with DN and
maybe worse: If the PI-thing is going to automate the mapping processes
we use today I have some serious doubts on the current semantics like:

- Is a single CA (cert) supposed to support an arbitrary set of naming domains?

- What happens if a CA generates some certs with and some without PI? Syntax error?

IMO it had been better if PI had supported DN mapping and was a part of a CA cert only.
That would restrict PI naming domains to one / CA but that is IMO a much more
practical solution.

/anders

Received: from popmail2.inbox.se ([email-masked] [212.28.208.210]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id AAA06453 for ; Wed, 3 Jan 2001 00:58:20 -0800 (PST)
Received: from santesson.accurata.se (slip-202-135-193-215.sg.sg.prserv.net [202.135.193.215]) by popmail2.inbox.se (8.10.1/8.10.1) with ESMTP id f0390Mi23319; Wed, 3 Jan 2001 10:00:51 +0100
Message-Id: <[email-masked]>
X-Sender: [email-masked]
X-Mailer: QUALCOMM Windows Eudora Version 5.0
Date: Wed, 03 Jan 2001 10:01:40 +0100
To: , "Ietf-Pkix"
From: Stefan Santesson
Subject: Re: Why don't using Permanent Identifier on QC certificates?
In-Reply-To:
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"; format=flowed
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id AAA06458

Juan Carlos,

After reading the trailing answers to your mail I choose to answer yours
directly since I don't want to get involved in the best identifier system
for US.

The QC standard (approved 5 Nov 2000) gives you a set of attributes to
express an identity in the form of a DN.
You can choose to include another attribute at your selection but then this
attribute must NOT be necessary to identify the person.

So if you choose to follow the QC RFC, you should definitely use the SN
attribute to store a national registration code (such as SSN), IF you have
made the decision that you want to include this code at all.

The PI draft defines another attribute/mechanism to create a complete new
way of assigning a unique identifier for a person. I.e. to my knowledge you
can't use it to store an existing code (such as SSN).

So if you have an existing code structure, use SN and if you want to use
the PI concept then use that but only as a complement to a complete DN.

I would though be careful before I start using PI in a wide scale because I
fear that it may not scale as well as we would like. In Sweden you have to
go to the national standards body to get an OID. Since OID is only designed
to define objects in standards, the current schema in Sweden are to my
knowledge just dimensioned to register more than just above 16000
organizations under the Swedish root. They have just used up about 500 + so
that is not a problem right now. But imagine what would happen if every
organization asks for its own OID structure to register peoples/employees,
then the standards body would have to create a new sub structure for this.

I have not made my homework to well so I can be wrong here but I think this
should be overlooked more carefully before we jump to fast into approving
the PI concept.

/Stefan

At 16:25 2000-12-19 -0400, Juan Carlos Pérez Aguayo wrote:
>In the QC draft is stated:
>
>"...The serialNumber attribute type SHALL, when present, be used to
> differentiate between names where the subject field would otherwise
> be identical. This attribute has no defined semantics beyond
> ensuring uniqueness of subject names. It MAY contain a number or
> code assigned by the CA or an identifier assigned by a government or
> civil authority. It is the CA's responsibility to ensure that the
> serialNumber is sufficient to resolve any subject name collisions..."
>
>and on the Permanet Identifier drfat;
>Sorry if this discussion has happened before, but I don't know if there are
>some final statement:
>
>"... A serialNumber attribute may be used for two
> different purposes in the DN of a person:
>
> 1) In a DN or a SubjectAltName to differentiate between
> two names (for two different individuals) that otherwise
> would not be different.
>
> 2) In the identifier field from a permanent identifier.
> This is the recommended use for national ID's and
> employee ID's, for example. ..."
>
>Now, consider this:
>
>a person has a unique identifier, assigned by a goverment authority, wich is
>guaranteed to be unique on a national scope (country domain)
>
>How to incorporate this identifier into a certificate?.
>
>SerialNumber or SubjevctAltname field? When I read the QC profile
>"..identifier assigned by a goverment o civil authority...", and then the PI
>draft say "... This is recommended use for national ID's...", I am confused.
>
>Why the QC does not use Permanent Identifier?
>
>Thera are some application wich need incorporate this class of personal
>identifier. By example, in my country (CHILE) each people ha an unique ID
>stamped in a card (this card has the photography and handwritting too), and
>this is broadly recognized for identification. One can to do many
>transactions wich need this ID for proceed.
>
>Thanks in advance
>
>Juan Carlos Pérez A.
>Acepta.com

Received: from fs3.ece.ubc.ca (fs3.ece.ubc.ca [137.82.52.241]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id UAA10075 for ; Tue, 2 Jan 2001 20:02:16 -0800 (PST)
Received: from rwd6.ece.ubc.ca (rwd6.ece.ubc.ca [137.82.57.203]) by fs3.ece.ubc.ca (8.9.0/8.9.0) with SMTP id UAA04947; Tue, 2 Jan 2001 20:04:08 -0800 (PST)
Received: from localhost by rwd6.ece.ubc.ca (5.61/SMI-4.0) id AA18999; Tue, 2 Jan 01 20:00:35 -0800
Date: Tue, 2 Jan 2001 20:00:34 -0800 (PST)
From: hansen wang
To: David Cross
Cc: "'Rich Salz'" , Ambarish Malpani , IETF-PXIX
Subject: RE: Two questions on delta-CRL
In-Reply-To: <[email-masked]>
Message-Id:
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

On Tue, 2 Jan 2001, David Cross wrote:

> I have to disagree. Everyone should continue to publish base CRLs as often
> as they do today. If you have the capability and clients that understand
> delta CRLs, then you can take advantage of the technology and publish delta
> CRLs much more frequently.

Agree.
Seems to me that some are mistaking "publishing" for "need to download".
When the CA issues both a Base CRL and a Delta CRL, the clients have an
option _at_all_times_ to download either:

1. the current Base if they cannot handle Deltas or if the Base
(or Full) CRL that they're holding cannot be updated by the current
Delta CRL because it is too old,
2. the current Delta if the Base (or Full) CRL that they're hold _CAN_
be updated by the current Delta CRL.

There's no need for each client to download both just because they're
published. Both can bring the client upto the Current CRL.

> Even if a base CRL were published every time a delta CRL was published, many
> clients will not retrieve a new base because many clients cache a base CRL
> locally until it expires. The benefit goes away and the issues with
> frequent publication of a base CRL increase.

Agree here too. Most clients can make use of the Delta but there will
always be some small percentage of clients that will have to suffer the
penalty of needing to download a Base CRL for reason listed above.
Publishing both a Current Base and Delta CRL does not require an
out-of-date client to have to download both an older Base CRL and an
additional Current Delta CRL to bring it up to the Current Full CRL.
Optionally, the Delta CRL may also include the hash signature of the
Current Full CRL to use as an integrity check to see that it has an exact
copy of the Current Full CRL that was published by the CA.

--
***************************************************************
Hansen Wang Office: CICSR381
M.A.Sc Candidate Room: MCLD 458/CICSR388
Communications Group Tel: (604)822-4985 (Lab)
ECE, UBC (604)822-5084 (Lab)
2356 Main Mall Fax: (604)822-5949
Vancouver, BC email: [email-masked]
V6T 1Z4
************* http://www.ee.ubc.ca/~hansenw *****************

Received: from mail2.microsoft.com (mail2.microsoft.com [131.107.3.124]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id TAA09318 for ; Tue, 2 Jan 2001 19:37:59 -0800 (PST)
Received: from 157.54.9.104 by mail2.microsoft.com (InterScan E-Mail VirusWall NT); Tue, 02 Jan 2001 19:41:53 -0800 (Pacific Standard Time)
Received: by inet-imc-02.redmond.corp.microsoft.com with Internet Mail Service (5.5.2651.58) id ; Tue, 2 Jan 2001 19:41:40 -0800
Message-ID: <[email-masked]>
From: David Cross
To: "'Rich Salz'" , Ambarish Malpani
Cc: IETF-PXIX
Subject: RE: Two questions on delta-CRL
Date: Tue, 2 Jan 2001 19:41:47 -0800
X-Mailer: Internet Mail Service (5.5.2651.58)

I have to disagree. Everyone should continue to publish base CRLs as often
as they do today. If you have the capability and clients that understand
delta CRLs, then you can take advantage of the technology and publish delta
CRLs much more frequently.

Even if a base CRL were published every time a delta CRL was published, many
clients will not retrieve a new base because many clients cache a base CRL
locally until it expires. The benefit goes away and the issues with
frequent publication of a base CRL increase.

David B. Cross

-----Original Message-----
From: Rich Salz [mailto:[email-masked]]
Sent: Tuesday, January 02, 2001 7:41 PM
To: Ambarish Malpani
Cc: IETF-PXIX
Subject: Re: Two questions on delta-CRL

> I, too, would like to see the requirement relaxed to a full CRL SHOULD
> be published when a delta CRL is issued.

This would essentially force everyone to understand deltaCRL's.

I do not think the world is ready for that yet.
/r$

Received: from mail-fwd.verio-web.com (mail11a.verio-web.com [161.58.16.57]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id TAA08920 for ; Tue, 2 Jan 2001 19:32:09 -0800 (PST)
Received: from 161.58.117.181 (161.58.117.181) by mail11a.verio-web.com (RS ver 1.0.57s) with SMTP id 018833676; Tue, 2 Jan 2001 22:37:15 -0500 (EST)
Received: from caveosystems.com (adsl-141-154-118-176.bostma.adsl.bellatlantic.net [141.154.118.176]) by os390.caveosystems.com (8.9.3/8.9.3) with ESMTP id WAA12759; Tue, 2 Jan 2001 22:37:17 -0500
Message-ID: <[email-masked]>
Date: Tue, 02 Jan 2001 22:40:57 -0500
From: Rich Salz
X-Mailer: Mozilla 4.73 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Ambarish Malpani
CC: IETF-PXIX
Subject: Re: Two questions on delta-CRL
References: <[email-masked]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Loop-Detect: 1

> I, too, would like to see the requirement relaxed to a full CRL
> SHOULD be published when a delta CRL is issued.

This would essentially force everyone to understand deltaCRL's.

I do not think the world is ready for that yet.
/r$

Received: from mail2.microsoft.com (mail2.microsoft.com [131.107.3.124]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id SAA07364 for ; Tue, 2 Jan 2001 18:22:32 -0800 (PST)
Received: from 157.54.9.104 by mail2.microsoft.com (InterScan E-Mail VirusWall NT); Tue, 02 Jan 2001 18:26:27 -0800 (Pacific Standard Time)
Received: by inet-imc-02.redmond.corp.microsoft.com with Internet Mail Service (5.5.2651.58) id ; Tue, 2 Jan 2001 18:26:14 -0800
Message-ID: <[email-masked]>
From: David Cross
To: IETF-PXIX
Subject: RE: Two questions on delta-CRL
Date: Tue, 2 Jan 2001 18:26:17 -0800
X-Mailer: Internet Mail Service (5.5.2651.58)

If a full CRL MUST be published every time a delta CRL is published, it
diminishes the value of publishing delta CRLs. Replicating full CRLs can be
an expensive process depending on the size of the CRL and delta CRLs were a
solution to alleviate that.

Saying that both the delta aware and non-delta aware clients should have the
same information is an invalid argument. That would mean that OCSP and
non-OCSP aware clients should have the same info which is simply not true.

The requirement should be relaxed.

David B. Cross

-----Original Message-----
From: Ambarish Malpani [mailto:[email-masked]]
Sent: Tuesday, January 02, 2001 6:05 PM
To: 'Denis Pinkas'; Sam Schaen
Cc: IETF-PXIX
Subject: RE: Two questions on delta-CRL

I, too, would like to see the requirement relaxed to a full CRL SHOULD be
published when a delta CRL is issued.

If I remember correctly, this was discussed on the list. I believe PKIX has
it because X.509 had it. Also, in the past, the discussion indicated that a
CA might publish a new full CRL and then send it to /dev/null, so the full
CRL was only published in principal.

It would be good to get a definitive answer to how real the requirement for
the full CRL is.

Ambarish

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

> -----Original Message-----
> From: Denis Pinkas [mailto:[email-masked]]
> Sent: Tuesday, January 02, 2001 6:37 AM
> To: Sam Schaen
> Cc: IETF-PXIX
> Subject: Re: Two questions on delta-CRL
>
>
> Sam,
>
> Thanks for attempting to answer the question. One possible
> answer would be
> to prevent people using delta-CRLs to get an advantage over
> people using
> regular CRLs. The text used to write RFC 2459 was written at
> a time where
> OCSP servers did not existed. However, clients now using OCSP
> servers may
> get such an advantage, i.e. fresher information about
> revocation status.
>
> Would the following scenario (currently forbidden by RFC
> 2459) makes sense ?
>
> The full CRL is issued every day, and a delta CRL is issued
> every hour.
>
> I was wondering whether it would be possible to relax this
> rule, and thus
> have e.g.:
>
> When a delta-CRL is issued, the CAs SHOULD also issue a complete CRL.
>
> However, before doing so, we must understand the original
> rational and all
> the implications. To understand the original rational I would expect a
> response from one of the authors of RFC 2459. However, for
> the second part
> of the question (i.e. all the implications) the discussion is open.
>
> Denis
>
>
> > I believe the requirement for issuing a complete CRL when a
> delta CRL is
> > released makes sense. It permits applications that don't
> understand delta
> > CRLs to obtain the most recent information. Overall
> network bandwidth usage
> > is still reduced to the extent that other delta-CRL-capable
> applications do
> > make use of the delta CRL rather than retrieving a full CRL. The
> > availability of a current full CRL also allows an application to
> > resynchronize at any point.
> >
> > Denis Pinkas wrote:
> >
> > > In section 5.2.4 (Delta CRL Indicator), RFC 2459 states:
> > >
> > > The delta CRL indicator is a critical CRL extension
> that identifies a
> > > delta-CRL. The use of delta-CRLs can significantly improve
> > > processing time for applications which store revocation
> information
> > > in a format other than the CRL structure. This allows
> changes to be
> > > added to the local database while ignoring unchanged
> information that
> > > is already in the local database.
> > >
> > > When a delta-CRL is issued, the CAs MUST also issue a
> complete CRL.
> > >
> > > (...) Again, a delta-CRL MUST NOT be issued without a
> corresponding
> > > complete CRL.
> > >
> > > The two questions are the following:
> > >
> > > 1) What is the rational for mandating the issuance of a
> complete CRL each
> > > time a delta-CRL is issued ?
> > > 2) Under which conditions could this requirement be relaxed ?
> > >
> > > Denis
>

Received: from venus.initech.com ([203.238.37.132]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id SAA07042 for ; Tue, 2 Jan 2001 18:18:21 -0800 (PST)
Received: from sigma (sigma.initech.com [203.238.37.133]) by venus.initech.com (8.11.0/8.11.0) with SMTP id f032Isj09873; Wed, 3 Jan 2001 11:18:54 +0900 (KST)
From: "Kwon, YongChul"
To: "'Ari Kermaier'"
Cc:
Subject: RE: CRMF/CMP question
Date: Wed, 3 Jan 2001 11:23:54 +0900
Message-ID: <[email-masked]>
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.2910.0)
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.3018.1300
Importance: Normal
In-Reply-To: <[email-masked]>

> As far as IssuerAltName goes, the syntax is a SEQUENCE of
> GeneralName,
> where one of the choices is otherName which is defined as a
> sequence of OID
> and value (similar to AttributeTypeAndValue). The description for
> SubjectAltName (draft-ietf-pkix-new-part1-03) explicitly
> allows multiple
> GeneralName entries of the same name form; presumably this includes
> multiple otherName instances with the same OIDs. These
> semantics make sense
> in the context of a sequence of GeneralName, but not necessarily for
> AttributeTypeAndValue in general. Witness son-of-rfc2459's explicit
> instruction that "Only one instance of a particular extension
> may appear in
> a particular certificate"; but no similar language appears in
> rfc2510bis or rfc2511bis.)

you're right. :-)

> There's a lot more to this question than regInfo. For
> example, registration
> Controls (in CRMF CertRequest) includes such defined types as
> id-regCtrl-oldCertID and id-regCtrl-pkiPublicationInfo. For
> oldCertID,
> clearly it makes no sense to have more than one such control
> in a singe
> CertRequest, but nothing in the spec prohibits it or says
> what to do if you
> encounter such a situation (e.g, take the first one, or the
> last one, or
> ignore both, or reject the whole thing). For
> pkiPublicationInfo, there is
> no logical contradiction in having more than one such
> control, but the
> syntax for the control explicitly provides a mechanism to
> include multiple
> pubInfos in a single control. This would seem to imply that multiple
> controls with the same OID are discouraged. But are they illegal?
> Other places where this question arises incude, in CMP (rfc2510bis):
> PKIHeader.generalInfo (section 3.1.1), the GenMsgContent PKIBody type
> (3.3.19) and GenRepContent (3.3.20).

I agree. yeah, they're not illegal. but, I think
if a control(or extension) structure can include all related
informations, then that informations should exist in one
control(extension).

It makes things more clearer and better, doesn't it? :-)
and it is a kind of canonicalization.

What I exampled - IssureAltName was not good example. :-(
What I said was that it could be ... not about the clearity of
RFC and draft. at this point I missed the track.

I agree with you. RFC-2511 and bis and RFC-2510 will be better
if they have verbose comments(that's what I always want!)

Received: from ext-mail.valicert.com (ns1.valicert.com [63.65.221.10]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id SAA06522 for ; Tue, 2 Jan 2001 18:04:19 -0800 (PST)
Received: from CONVERSION-DAEMON by ext-mail.valicert.com (PMDF V5.2-33 #46613) id <[email-masked]> for [email-masked]; Tue, 2 Jan 2001 18:08:43 -0800 (PST)
Received: from polaris.valicert.com ([192.168.2.34]) by ext-mail.valicert.com (PMDF V5.2-33 #46613) with ESMTP id <[email-masked]>; Tue, 02 Jan 2001 18:08:42 -0800 (PST)
Received: by exchange.valicert.com with Internet Mail Service (5.5.2650.21) id ; Tue, 02 Jan 2001 18:04:58 -0800
Content-return: allowed
Date: Tue, 02 Jan 2001 18:04:57 -0800
From: Ambarish Malpani
Subject: RE: Two questions on delta-CRL
To: "'Denis Pinkas'" , Sam Schaen
Cc: IETF-PXIX
Message-id: <[email-masked]>
MIME-version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-type: text/plain; charset="iso-8859-1"

I, too, would like to see the requirement relaxed to a full CRL
SHOULD be published when a delta CRL is issued.

If I remember correctly, this was discussed on the list. I believe
PKIX has it because X.509 had it. Also, in the past, the discussion
indicated that a CA might publish a new full CRL and then send it
to /dev/null, so the full CRL was only published in principal.

It would be good to get a definitive answer to how real the
requirement for the full CRL is.

Ambarish

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

> -----Original Message-----
> From: Denis Pinkas [mailto:[email-masked]]
> Sent: Tuesday, January 02, 2001 6:37 AM
> To: Sam Schaen
> Cc: IETF-PXIX
> Subject: Re: Two questions on delta-CRL
>
>
> Sam,
>
> Thanks for attempting to answer the question. One possible
> answer would be
> to prevent people using delta-CRLs to get an advantage over
> people using
> regular CRLs. The text used to write RFC 2459 was written at
> a time where
> OCSP servers did not existed. However, clients now using OCSP
> servers may
> get such an advantage, i.e. fresher information about
> revocation status.
>
> Would the following scenario (currently forbidden by RFC
> 2459) makes sense ?
>
> The full CRL is issued every day, and a delta CRL is issued
> every hour.
>
> I was wondering whether it would be possible to relax this
> rule, and thus
> have e.g.:
>
> When a delta-CRL is issued, the CAs SHOULD also issue a complete CRL.
>
> However, before doing so, we must understand the original
> rational and all
> the implications. To understand the original rational I would expect a
> response from one of the authors of RFC 2459. However, for
> the second part
> of the question (i.e. all the implications) the discussion is open.
>
> Denis
>
>
> > I believe the requirement for issuing a complete CRL when a
> delta CRL is
> > released makes sense. It permits applications that don't
> understand delta
> > CRLs to obtain the most recent information. Overall
> network bandwidth usage
> > is still reduced to the extent that other delta-CRL-capable
> applications do
> > make use of the delta CRL rather than retrieving a full CRL. The
> > availability of a current full CRL also allows an application to
> > resynchronize at any point.
> >
> > Denis Pinkas wrote:
> >
> > > In section 5.2.4 (Delta CRL Indicator), RFC 2459 states:
> > >
> > > The delta CRL indicator is a critical CRL extension
> that identifies a
> > > delta-CRL. The use of delta-CRLs can significantly improve
> > > processing time for applications which store revocation
> information
> > > in a format other than the CRL structure. This allows
> changes to be
> > > added to the local database while ignoring unchanged
> information that
> > > is already in the local database.
> > >
> > > When a delta-CRL is issued, the CAs MUST also issue a
> complete CRL.
> > >
> > > (...) Again, a delta-CRL MUST NOT be issued without a
> corresponding
> > > complete CRL.
> > >
> > > The two questions are the following:
> > >
> > > 1) What is the rational for mandating the issuance of a
> complete CRL each
> > > time a delta-CRL is issued ?
> > > 2) Under which conditions could this requirement be relaxed ?
> > >
> > > Denis
>

Received: from mail.phaos.com ([206.30.74.234]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id RAA06049 for ; Tue, 2 Jan 2001 17:52:44 -0800 (PST)
Received: from phaos_arik (ruskie.spacerat.com [207.51.38.135]) by mail.phaos.com (8.9.2/8.9.2) with ESMTP id AAA31713; Wed, 3 Jan 2001 00:57:56 -0500 (EST) (envelope-from [email-masked])
Message-Id: <[email-masked]>
X-Sender: [email-masked]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58
Date: Tue, 02 Jan 2001 21:07:43 -0500
To: "Kwon, YongChul"
From: Ari Kermaier
Subject: RE: CRMF/CMP question
Cc:
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed

> > concerning duplicate elements. Also, for purposes of CMP,
> > using "SET OF"
> > would be problematic because the order of elements must be
> > determinable in
> > order to verify signatures and MACs.
>
> it's true.
>
> but in this case, RFC-2511 and it's son defines 2 possiblities
> - one is utf8Pairs and CertReq.

Does this mean that other AttributeTypeAndValue pairs (i.e., ones not
specified in rfc2511 as registration controls) are prohibited? I assumed
not, though I could be wrong.

> in case of utf8Pairs, I think the informations should not be
> spread to 2 or more regInfo-utf8Pairs(because utf8Pairs already
> express all informations in one reginfo) - same as IssureAltNames.
> so I think it can't be a problem.

UTF8Pairs is different, because a method is specified for concatenating
multiple UTF8String values for the one OID. The same cannot be said for
AttributeTypeAndValue in general.

As far as IssuerAltName goes, the syntax is a SEQUENCE of GeneralName,
where one of the choices is otherName which is defined as a sequence of OID
and value (similar to AttributeTypeAndValue). The description for
SubjectAltName (draft-ietf-pkix-new-part1-03) explicitly allows multiple
GeneralName entries of the same name form; presumably this includes
multiple otherName instances with the same OIDs. These semantics make sense
in the context of a sequence of GeneralName, but not necessarily for
AttributeTypeAndValue in general. Witness son-of-rfc2459's explicit
instruction that "Only one instance of a particular extension may appear in
a particular certificate"; but no similar language appears in rfc2510bis or
rfc2511bis.)

> then let's think about the CertRequest conveyed in regInfo.
> yes... I agree with you. I think It could be a problem.

There's a lot more to this question than regInfo. For example, registration
Controls (in CRMF CertRequest) includes such defined types as
id-regCtrl-oldCertID and id-regCtrl-pkiPublicationInfo. For oldCertID,
clearly it makes no sense to have more than one such control in a singe
CertRequest, but nothing in the spec prohibits it or says what to do if you
encounter such a situation (e.g, take the first one, or the last one, or
ignore both, or reject the whole thing). For pkiPublicationInfo, there is
no logical contradiction in having more than one such control, but the
syntax for the control explicitly provides a mechanism to include multiple
pubInfos in a single control. This would seem to imply that multiple
controls with the same OID are discouraged. But are they illegal?

Other places where this question arises incude, in CMP (rfc2510bis):
PKIHeader.generalInfo (section 3.1.1), the GenMsgContent PKIBody type
(3.3.19) and GenRepContent (3.3.20).

Received: from venus.initech.com ([203.238.37.132]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id QAA03946 for ; Tue, 2 Jan 2001 16:38:19 -0800 (PST)
Received: from sigma (sigma.initech.com [203.238.37.133]) by venus.initech.com (8.11.0/8.11.0) with SMTP id f030cqj08574; Wed, 3 Jan 2001 09:38:52 +0900 (KST)
From: "Kwon, YongChul"
To: "'Ari Kermaier'"
Cc:
Subject: RE: CRMF/CMP question
Date: Wed, 3 Jan 2001 09:43:51 +0900
Message-ID: <[email-masked]>
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.2910.0)
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.3018.1300
Importance: Normal
In-Reply-To: <[email-masked]>

> I'm pretty sure the ASN.1 notation "SEQUENCE OF" implies no
> requirements

yes. you're right. I mean that I think the concept of X.509 Extension
structure would be applied. sorry for ambiguous expression. :-)

> concerning duplicate elements. Also, for purposes of CMP,
> using "SET OF"
> would be problematic because the order of elements must be
> determinable in
> order to verify signatures and MACs.

it's true.

but in this case, RFC-2511 and it's son defines 2 possiblities
- one is utf8Pairs and CertReq.

in case of utf8Pairs, I think the informations should not be
spread to 2 or more regInfo-utf8Pairs(because utf8Pairs already
express all informations in one reginfo) - same as IssureAltNames.
so I think it can't be a problem.

then let's think about the CertRequest conveyed in regInfo.
yes... I agree with you. I think It could be a problem.

RFC-2511bis said

Information directly related to certificate content SHOULD be
included in the certReq content. However, inclusion of additional
certReq content by RAs may invalidate the pop field. Data therefore
intended for certificate content MAY be provided in regInfo.

Hmm... it sounds the case when RAVerified POP used, right?
at that time, RFC-2510(Appendix B4) requires 1-2 CertReqMessages
in CertReqMessages. and if 2 requests exists, the second one
have no proof of possession so in this case, the CertRequest
in regInfo implies the first one - POP invalidated by RA.

Hmm.. so I think it's not a problem neither.

I can't be quite sure. but What do you think about my opinion?
If there are any missing points, please let me know them.

Received: from mail.phaos.com ([206.30.74.234]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id QAA02968 for ; Tue, 2 Jan 2001 16:02:59 -0800 (PST)
Received: from phaos_arik (ruskie.spacerat.com [207.51.38.135]) by mail.phaos.com (8.9.2/8.9.2) with ESMTP id XAA31554; Tue, 2 Jan 2001 23:07:55 -0500 (EST) (envelope-from [email-masked])
Message-Id: <[email-masked]>
X-Sender: [email-masked]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58
Date: Tue, 02 Jan 2001 19:17:43 -0500
To: "Kwon, YongChul"
From: Ari Kermaier
Subject: RE: CRMF/CMP question
Cc: , [email-masked]
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed

>Hi.
>
> > There are several places in CMP/CRMF where a definition such as the
> > following appears:
> > CertReqMsg ::= SEQUENCE {
> > (...)
> > regInfo SEQUENCE SIZE(1..MAX) of AttributeTypeAndValue
> > OPTIONAL }
> > In such a field, is it permissible for more than one
> > AttributeTypeAndValue
> > having the same type OID to be present?
>
> I think SEQUENCE OF implicitly requires no duplicated
> occurrence of same oid.
>
> If it permits, then I think that it should be SET OF.
>
> Same concept applied to the X.509 Extension and X.500 Name
> structure.

I'm pretty sure the ASN.1 notation "SEQUENCE OF" implies no requirements
concerning duplicate elements. Also, for purposes of CMP, using "SET OF"
would be problematic because the order of elements must be determinable in
order to verify signatures and MACs.

Received: from venus.initech.com ([203.238.37.132]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA02535 for ; Tue, 2 Jan 2001 15:56:42 -0800 (PST)
Received: from sigma (sigma.initech.com [203.238.37.133]) by venus.initech.com (8.11.0/8.11.0) with SMTP id f02Nv7j08015; Wed, 3 Jan 2001 08:57:07 +0900 (KST)
From: "Kwon, YongChul"
To: "'Ari Kermaier'"
Cc:
Subject: RE: CRMF/CMP question
Date: Wed, 3 Jan 2001 09:02:07 +0900
Message-ID: <[email-masked]>
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.2910.0)
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.3018.1300
Importance: Normal
In-Reply-To: <[email-masked]>

Hi.

> There are several places in CMP/CRMF where a definition such as the
> following appears:
> CertReqMsg ::= SEQUENCE {
> (...)
> regInfo SEQUENCE SIZE(1..MAX) of AttributeTypeAndValue
> OPTIONAL }
> In such a field, is it permissible for more than one
> AttributeTypeAndValue
> having the same type OID to be present?

I think SEQUENCE OF implicitly requires no duplicated
occurrence of same oid.

If it permits, then I think that it should be SET OF.

Same concept applied to the X.509 Extension and X.500 Name
structure.

Received: from mail.phaos.com ([206.30.74.234]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA01976 for ; Tue, 2 Jan 2001 15:44:37 -0800 (PST)
Received: from phaos_arik (ruskie.spacerat.com [207.51.38.135]) by mail.phaos.com (8.9.2/8.9.2) with ESMTP id WAA31514; Tue, 2 Jan 2001 22:49:55 -0500 (EST) (envelope-from [email-masked])
Message-Id: <[email-masked]>
X-Sender: [email-masked]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58
Date: Tue, 02 Jan 2001 18:59:43 -0500
To: [email-masked]
From: Ari Kermaier
Subject: CRMF/CMP question
Cc: [email-masked]
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed

There are several places in CMP/CRMF where a definition such as the
following appears:

CertReqMsg ::= SEQUENCE {
(...)
regInfo SEQUENCE SIZE(1..MAX) of AttributeTypeAndValue OPTIONAL }

In such a field, is it permissible for more than one AttributeTypeAndValue
having the same type OID to be present?

If yes, how should the multiple entries be processed?

If no, shouldn't there be a comment to that effect, or perhaps a new
production defined (such as AttrTypeAndValueSequence ::= SEQUENCE
SIZE(1..MAX) of AttributeTypeAndValue)) with a comment included?

Ari Kermaier
Phaos Technology

Received: from exchange.cylink.com (exchange.cylink.com [192.43.161.25]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA22014 for ; Tue, 2 Jan 2001 12:16:35 -0800 (PST)
Received: by exchange.cylink.com with Internet Mail Service (5.5.2650.21) id ; Tue, 2 Jan 2001 12:13:28 -0800
Message-ID: <[email-masked]>
From: "Covey, Carlin"
To: PKIX-List
Subject: RE: DPD & DPV requirements
Date: Tue, 2 Jan 2001 12:13:23 -0800
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C074F8.755F1190"

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_01C074F8.755F1190
Content-Type: text/plain;
charset="iso-8859-1"

>From Steve's email sent Friday, December 29, 2000 11:25 AM :

2.2 A server must be able to return one or
more sets of certification paths and associated revocation data
as a result of path discovery/validation. Each
set shall consist of an ordered list of certificates and associated
CRLs and/or OCSP responses.

The wording concerning an ordered list could use some more specifics. Is the
response to be an ordered list of certificates, followed by an ordered
list of revocation information (presumably in the same order), or is it to
be an ordered list of certificate/revocation-information pairs?
My preference is for the pairs.

Although the sort order is intuitive, it should probably be declared more
explicitly. My preference is for certificate-path order, beginning with the
target certificate.

I propose the following revised wording:

" ... Each set shall consist of a list of pairs of
certificates and CRLs and/or OCSP responses, in certificate path order.

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

From =
Steve's email=20
sent Friday, December 29, 2000 11:25 AM :
&nb=
sp;

=
;            =
;    =20
2.2     A server must be able to return one =
or more=20
sets of certification paths and associated revocation data=20

&n=
bsp;           &n=
bsp;  =20
as a result of path discovery/validation. Each=20
set shall consist of an ordered list of certificates =
and=20
associated
=
;            =
;     =20
CRLs and/or OCSP responses.

The wording concerning =
an ordered=20
list could use some more =
specifics.=20
Is the response to be an ordered list of certificates, followed by an =
ordered=20

list of revocation information (presumably in the same order), or =
is it to=20
be an ordered list of certificate/revocation-information pairs?
My =
preference=20
is for the pairs.

Although  the sort order  is intuitive, =
it should probably be declared more =
explicitly. My=20
preference is for certificate-path order, beginning with the target=20
certificate.
=

I propose the following=20
revised wording:

&nb=
sp;           &nb=
sp;  =20
" ...  Each set shall consist of a list of =
pairs of=20
certificates and CRLs and/or OCSP responses, in certificate path=20
order.

------_=_NextPart_001_01C074F8.755F1190--

Received: from exchange.cylink.com (exchange.cylink.com [192.43.161.25]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA19310 for ; Tue, 2 Jan 2001 11:28:41 -0800 (PST)
Received: by exchange.cylink.com with Internet Mail Service (5.5.2650.21) id ; Tue, 2 Jan 2001 11:25:34 -0800
Message-ID: <[email-masked]>
From: "Covey, Carlin"
To: "'Stephen Kent'" , PKIX-List
Subject: RE: DPD & DPV requirements - return one or more sets of certifica tion paths
Date: Tue, 2 Jan 2001 11:25:26 -0800
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C074F1.C24D9AA0"

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_01C074F1.C24D9AA0
Content-Type: text/plain;
charset="iso-8859-1"

Steve and PKIX working group,

I think Steve has done an excellent job is setting forth a proposed set of
requirements for evaluating DPD and DPV standards.

Thank you Steve. This should help us on the way to reaching closure on this
important set of standards.

That said, I'd like to weigh in with some suggested revisions to Steve's
proposal. I'll make each suggestion in a separate posting,
with a view to generating more, but shorter and more focused discussion
threads.

>From Steve's email sent Friday, December 29, 2000 11:25 AM :
"2.2 A server must be able to return one or more sets of
certification paths and associated revocation data as a result of path
discovery/validation.. .."

This requirement is a bit ambiguous. It probably is intended to mean that
the server must be able to return one or more sets of
certification paths and associated revocation data related to a single
target certificate. However, the wording
could be interpreted as meaning that the server must be able to return this
information for a set of (possibly unrelated) target
certificates. My preference is for the former. I suggest the following
revision:

"2.2 A server must be able to return one or
more sets of certification paths and associated
revocation data as a result of path
discovery/validation related to a single target certificate."

.Regards to all, and Happy New Year!

- Carlin Covey

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

Steve=20
and PKIX working group,

I think=20
Steve has done an excellent job is setting forth a proposed set of =
requirements=20
for evaluating DPD and DPV standards.

Thank=20
you Steve.  This should help us on the way to reaching closure on =
this=20
important set of standards.

That=20
said, I'd like to weigh in with some suggested revisions to Steve's=20
proposal.  I'll make each suggestion in a separate =
posting,
with a view=20
to generating more, but shorter and more focused discussion=20
threads.

From=20
Steve's email sent Friday, December 29, 2000 11:25 AM =
:
&nb=
sp; =20
"2.2 A server must be able to return one or more sets of =
certification=20
paths and associated revocation data as a result of path
&nb=
sp;  =20
discovery/validation..     .."

This requirement is a bit ambiguous. It =
probably is=20
intended to mean that the server must be able to return one or more =
sets of=20

certification paths and associated revocation data related to a =
single=20
target certificate. However, the wording
could be interpreted as =
meaning=20
that the server must be able to return this information for a set of =
(possibly=20
unrelated) target
certificates. My preference is for the former. I =
suggest=20
the following revision:

&nb=
sp;           &nb=
sp;          =20
"2.2 A server must be able to return one or more sets of =
certification=20
paths and associated
&nb=
sp;           &nb=
sp;           &nb=
sp; revocation=20
data as a result of path discovery/validation related to a single =
target=20
certificate."

.Regards to =
all, and Happy=20
New Year!

- Carlin=20
Covey

------_=_NextPart_001_01C074F1.C24D9AA0--

Received: from tholian.securitydynamics.com (tholian.securid.com [204.167.112.129]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id JAA11232 for ; Tue, 2 Jan 2001 09:54:57 -0800 (PST)
Received: from [192.168.7.5] by tholian.securitydynamics.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 2 Jan 2001 17:58:32 UT
Received: from exrsa01.rsa.com (exrsa01.securitydynamics.com [10.81.217.7]) by sdtihq24.securid.com (Pro-8.9.3/Pro-8.9.3) with ESMTP id MAA14863; Tue, 2 Jan 2001 12:59:11 -0500 (EST)
Received: by exrsa01.rsa.com with Internet Mail Service (5.5.2650.21) id ; Tue, 2 Jan 2001 09:59:10 -0800
Message-ID:
From: "Mione, Tony"
To: "'David Cross'" , "'Denis Pinkas'" , Sam Schaen
Cc: IETF-PXIX
Subject: RE: Two questions on delta-CRL
Date: Tue, 2 Jan 2001 09:59:08 -0800
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"

I am not sure what the concern is over needing to publish a
new base crl with each delta. This makes perfect sense to me.

I think the point of publishing both is so that clients that only
process full CRLs can always come up with the same results as a client
that can process deltaCRLs. Otherwise, the results of a revocation
check will be non-trivial to predict and will vary depending on the
client capability and what the CA is willing to support in terms of
baseCRL availability.

Consider the following:

Time CA Publishes

t1 baseCRL1

t2 baseCRL1a, deltaCRL1a (baseCRL1a = baseCRL1+deltaCRL1a)

t3 baseCRL1b, deltaCRL1b (baseCRL1b = baseCRL1+deltaCRL1b)

t4 baseCRL1c, deltaCRL1c (baseCRL1c = baseCRL1+deltaCRL1c)

t5 baseCRL2, deltaCRL2 (baseCRL2 = baseCRL1+deltaCRL2)

t6 baseCRL2a, deltaCRL2a (baseCRL2a = baseCRL2+deltaCRL2a)

etc.

Now client1 that needs the latest crl at time t3 <= t <= t4 retrieves
baseCRL1b (since they can't handle deltaCRLs). client2 fetches
deltaCRL1b and adds its contents to baseCRL1 (since it CAN handle
deltaCRLs). This saves bandwidth when client2 needs a crl. However,
both clients come up with the same answer.

> -----Original Message-----
> From: David Cross [mailto:[email-masked]]
> Sent: Tuesday, January 02, 2001 8:36 AM
> To: 'Denis Pinkas'; Sam Schaen
> Cc: IETF-PXIX
> Subject: RE: Two questions on delta-CRL
>
>
> I think the important distinction is to ensure that a valid
> base CRL always
> exists. A client 1) may not understand a dCRL or 2) a client may not
> already have the base CRL that the dCRL is derived from.
>
> The way I read the RFC is that a valid base CRL must exist
> when the dCRL is
> published. This does not necessarily mean that the base CRL must be
> re-published every time a dCRL is published.
>

Actually, I think it means a revised baseCRL (which consists of the
contents of the deltaCRL added to the original baseCRL) should be published.
The baseCRL on which the delta is based should also be available from the CA
but does not get republished. My understanding of publishing CRLs is that
the CA makes them available in a directory.

> If a base CRL is re-published at the same interval as the
> dCRL, the value of
> dCRLs diminishes as the cost and latency of base CRL
> publication is much
> higher for the network.
>

I don't quite follow this. Little network bandwidth is consumed
moving a new baseCRL to a CAs directory. I believe that is all that
is involved in publication of the CRLs.

> David B. Cross

Take care.

Tony Mione Senior Software Engineer
RSA Security, Inc, 2955 Campus Dr. Suite 400, San Mateo, Ca.
+1 650/295-7585 [email-masked]

Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA09343 for ; Tue, 2 Jan 2001 09:02:49 -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 SAA43712; Tue, 2 Jan 2001 18:13: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 SAA18212; Tue, 2 Jan 2001 18:06:39 +0100
Message-ID: <[email-masked]>
Date: Tue, 02 Jan 2001 18:06:39 +0100
From: Denis Pinkas
Organization: Bull
X-Mailer: Mozilla 4.7 [fr] (Win98; I)
X-Accept-Language: fr
MIME-Version: 1.0
To: David Cross
CC: IETF-PXIX
Subject: Re: Two questions on delta-CRL
References: <[email-masked]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

David,

Thanks for paying interest to this topic.

> I think the important distinction is to ensure that a valid base CRL always
> exists. A client 1) may not understand a dCRL or 2) a client may not
> already have the base CRL that the dCRL is derived from.
>
> The way I read the RFC is that a valid base CRL must exist when the dCRL is
> published. This does not necessarily mean that the base CRL must be
> re-published every time a dCRL is published.

I have difficulties to understand your last sentence, since the text says:
"When a delta-CRL is issued, the CAs MUST also issue a complete CRL".

> If a base CRL is re-published at the same interval as the dCRL, the value of
> dCRLs diminishes

Agreed.

> as the cost and latency of base CRL publication is much
> higher for the network.

Denis

> David B. Cross
>
> -----Original Message-----
> From: Denis Pinkas [mailto:[email-masked]]
> Sent: Tuesday, January 02, 2001 6:37 AM
> To: Sam Schaen
> Cc: IETF-PXIX
> Subject: Re: Two questions on delta-CRL
>
> Sam,
>
> Thanks for attempting to answer the question. One possible answer would be
> to prevent people using delta-CRLs to get an advantage over people using
> regular CRLs. The text used to write RFC 2459 was written at a time where
> OCSP servers did not existed. However, clients now using OCSP servers may
> get such an advantage, i.e. fresher information about revocation status.
>
> Would the following scenario (currently forbidden by RFC 2459) makes sense ?
>
> The full CRL is issued every day, and a delta CRL is issued every hour.
>
> I was wondering whether it would be possible to relax this rule, and thus
> have e.g.:
>
> When a delta-CRL is issued, the CAs SHOULD also issue a complete CRL.
>
> However, before doing so, we must understand the original rational and all
> the implications. To understand the original rational I would expect a
> response from one of the authors of RFC 2459. However, for the second part
> of the question (i.e. all the implications) the discussion is open.
>
> Denis
>
>
> > I believe the requirement for issuing a complete CRL when a delta CRL is
> > released makes sense. It permits applications that don't understand delta
> > CRLs to obtain the most recent information. Overall network bandwidth
> usage
> > is still reduced to the extent that other delta-CRL-capable applications
> do
> > make use of the delta CRL rather than retrieving a full CRL. The
> > availability of a current full CRL also allows an application to
> > resynchronize at any point.
> >
> > Denis Pinkas wrote:
> >
> > > In section 5.2.4 (Delta CRL Indicator), RFC 2459 states:
> > >
> > > The delta CRL indicator is a critical CRL extension that identifies a
> > > delta-CRL. The use of delta-CRLs can significantly improve
> > > processing time for applications which store revocation information
> > > in a format other than the CRL structure. This allows changes to be
> > > added to the local database while ignoring unchanged information that
> > > is already in the local database.
> > >
> > > When a delta-CRL is issued, the CAs MUST also issue a complete CRL.
> > >
> > > (...) Again, a delta-CRL MUST NOT be issued without a corresponding
> > > complete CRL.
> > >
> > > The two questions are the following:
> > >
> > > 1) What is the rational for mandating the issuance of a complete CRL
> each
> > > time a delta-CRL is issued ?
> > > 2) Under which conditions could this requirement be relaxed ?
> > >
> > > Denis

Received: from mail2.microsoft.com (mail2.microsoft.com [131.107.3.124]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id IAA07595 for ; Tue, 2 Jan 2001 08:31:55 -0800 (PST)
Received: from 157.54.9.104 by mail2.microsoft.com (InterScan E-Mail VirusWall NT); Tue, 02 Jan 2001 08:35:47 -0800 (Pacific Standard Time)
Received: by inet-imc-02.redmond.corp.microsoft.com with Internet Mail Service (5.5.2651.58) id ; Tue, 2 Jan 2001 08:35:34 -0800
Message-ID: <[email-masked]>
From: David Cross
To: "'Denis Pinkas'" , Sam Schaen
Cc: IETF-PXIX
Subject: RE: Two questions on delta-CRL
Date: Tue, 2 Jan 2001 08:35:37 -0800
X-Mailer: Internet Mail Service (5.5.2651.58)

I think the important distinction is to ensure that a valid base CRL always
exists. A client 1) may not understand a dCRL or 2) a client may not
already have the base CRL that the dCRL is derived from.

The way I read the RFC is that a valid base CRL must exist when the dCRL is
published. This does not necessarily mean that the base CRL must be
re-published every time a dCRL is published.

If a base CRL is re-published at the same interval as the dCRL, the value of
dCRLs diminishes as the cost and latency of base CRL publication is much
higher for the network.

David B. Cross

-----Original Message-----
From: Denis Pinkas [mailto:[email-masked]]
Sent: Tuesday, January 02, 2001 6:37 AM
To: Sam Schaen
Cc: IETF-PXIX
Subject: Re: Two questions on delta-CRL

Sam,

Thanks for attempting to answer the question. One possible answer would be
to prevent people using delta-CRLs to get an advantage over people using
regular CRLs. The text used to write RFC 2459 was written at a time where
OCSP servers did not existed. However, clients now using OCSP servers may
get such an advantage, i.e. fresher information about revocation status.

Would the following scenario (currently forbidden by RFC 2459) makes sense ?

The full CRL is issued every day, and a delta CRL is issued every hour.

I was wondering whether it would be possible to relax this rule, and thus
have e.g.:

When a delta-CRL is issued, the CAs SHOULD also issue a complete CRL.

However, before doing so, we must understand the original rational and all
the implications. To understand the original rational I would expect a
response from one of the authors of RFC 2459. However, for the second part
of the question (i.e. all the implications) the discussion is open.

Denis

> I believe the requirement for issuing a complete CRL when a delta CRL is
> released makes sense. It permits applications that don't understand delta
> CRLs to obtain the most recent information. Overall network bandwidth
usage
> is still reduced to the extent that other delta-CRL-capable applications
do
> make use of the delta CRL rather than retrieving a full CRL. The
> availability of a current full CRL also allows an application to
> resynchronize at any point.
>
> Denis Pinkas wrote:
>
> > In section 5.2.4 (Delta CRL Indicator), RFC 2459 states:
> >
> > The delta CRL indicator is a critical CRL extension that identifies a
> > delta-CRL. The use of delta-CRLs can significantly improve
> > processing time for applications which store revocation information
> > in a format other than the CRL structure. This allows changes to be
> > added to the local database while ignoring unchanged information that
> > is already in the local database.
> >
> > When a delta-CRL is issued, the CAs MUST also issue a complete CRL.
> >
> > (...) Again, a delta-CRL MUST NOT be issued without a corresponding
> > complete CRL.
> >
> > The two questions are the following:
> >
> > 1) What is the rational for mandating the issuance of a complete CRL
each
> > time a delta-CRL is issued ?
> > 2) Under which conditions could this requirement be relaxed ?
> >
> > Denis

Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA25920 for ; Tue, 2 Jan 2001 06:32:40 -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 PAA43056; Tue, 2 Jan 2001 15:43: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 PAA16934; Tue, 2 Jan 2001 15:36:28 +0100
Message-ID: <[email-masked]>
Date: Tue, 02 Jan 2001 15:36:31 +0100
From: Denis Pinkas
Organization: Bull
X-Mailer: Mozilla 4.7 [fr] (Win98; I)
X-Accept-Language: fr
MIME-Version: 1.0
To: Sam Schaen
CC: IETF-PXIX
Subject: Re: Two questions on delta-CRL
References: <[email-masked]> <[email-masked]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Sam,

Thanks for attempting to answer the question. One possible answer would be
to prevent people using delta-CRLs to get an advantage over people using
regular CRLs. The text used to write RFC 2459 was written at a time where
OCSP servers did not existed. However, clients now using OCSP servers may
get such an advantage, i.e. fresher information about revocation status.

Would the following scenario (currently forbidden by RFC 2459) makes sense ?

The full CRL is issued every day, and a delta CRL is issued every hour.

I was wondering whether it would be possible to relax this rule, and thus
have e.g.:

When a delta-CRL is issued, the CAs SHOULD also issue a complete CRL.

However, before doing so, we must understand the original rational and all
the implications. To understand the original rational I would expect a
response from one of the authors of RFC 2459. However, for the second part
of the question (i.e. all the implications) the discussion is open.

Denis

> I believe the requirement for issuing a complete CRL when a delta CRL is
> released makes sense. It permits applications that don't understand delta
> CRLs to obtain the most recent information. Overall network bandwidth usage
> is still reduced to the extent that other delta-CRL-capable applications do
> make use of the delta CRL rather than retrieving a full CRL. The
> availability of a current full CRL also allows an application to
> resynchronize at any point.
>
> Denis Pinkas wrote:
>
> > In section 5.2.4 (Delta CRL Indicator), RFC 2459 states:
> >
> > The delta CRL indicator is a critical CRL extension that identifies a
> > delta-CRL. The use of delta-CRLs can significantly improve
> > processing time for applications which store revocation information
> > in a format other than the CRL structure. This allows changes to be
> > added to the local database while ignoring unchanged information that
> > is already in the local database.
> >
> > When a delta-CRL is issued, the CAs MUST also issue a complete CRL.
> >
> > (...) Again, a delta-CRL MUST NOT be issued without a corresponding
> > complete CRL.
> >
> > The two questions are the following:
> >
> > 1) What is the rational for mandating the issuance of a complete CRL each
> > time a delta-CRL is issued ?
> > 2) Under which conditions could this requirement be relaxed ?
> >
> > Denis

Received: from smtpproxy1.mitre.org (mb-20-100.mitre.org [129.83.20.100]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA25302 for ; Tue, 2 Jan 2001 06:12:39 -0800 (PST)
Received: from avsrv1.mitre.org (avsrv1.mitre.org [129.83.20.58]) by smtpproxy1.mitre.org (8.9.3/8.9.3) with ESMTP id JAA24507; Tue, 2 Jan 2001 09:15:38 -0500 (EST)
Received: from MAILHUB1 (mailhub1.mitre.org [129.83.20.31]) by smtpsrv1.mitre.org (8.9.3/8.9.3) with ESMTP id JAA12445; Tue, 2 Jan 2001 09:15:37 -0500 (EST)
Received: from schaen-pc.mitre.org (128.29.162.49) by mailhub1.mitre.org with SMTP id 5216119; Tue, 02 Jan 2001 09:14:43 -0500
Message-ID: <[email-masked]>
Date: Tue, 02 Jan 2001 09:16:47 -0500
From: Sam Schaen
Organization: The MITRE Corporation
X-Mailer: Mozilla 4.75 [en]C-20000818M (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Denis Pinkas
CC: IETF-PXIX
Subject: Re: Two questions on delta-CRL
References: <[email-masked]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

I believe the requirement for issuing a complete CRL when a delta CRL is
released makes sense. It permits applications that don't understand delta
CRLs to obtain the most recent information. Overall network bandwidth usage
is still reduced to the extent that other delta-CRL-capable applications do
make use of the delta CRL rather than retrieving a full CRL. The
availability of a current full CRL also allows an application to
resynchronize at any point.

Denis Pinkas wrote:

> In section 5.2.4 (Delta CRL Indicator), RFC 2459 states:
>
> The delta CRL indicator is a critical CRL extension that identifies a
> delta-CRL. The use of delta-CRLs can significantly improve
> processing time for applications which store revocation information
> in a format other than the CRL structure. This allows changes to be
> added to the local database while ignoring unchanged information that
> is already in the local database.
>
> When a delta-CRL is issued, the CAs MUST also issue a complete CRL.
>
> (...) Again, a delta-CRL MUST NOT be issued without a corresponding
> complete CRL.
>
> The two questions are the following:
>
> 1) What is the rational for mandating the issuance of a complete CRL each
> time a delta-CRL is issued ?
> 2) Under which conditions could this requirement be relaxed ?
>
> Denis

Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id DAA13547 for ; Tue, 2 Jan 2001 03:20: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 MAA30054 for ; Tue, 2 Jan 2001 12:31:58 +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 MAA20058 for ; Tue, 2 Jan 2001 12:24:39 +0100
Message-ID: <[email-masked]>
Date: Tue, 02 Jan 2001 12:24:43 +0100
From: Denis Pinkas
Organization: Bull
X-Mailer: Mozilla 4.7 [fr] (Win98; I)
X-Accept-Language: fr
MIME-Version: 1.0
To: IETF-PXIX
Subject: Two questions on delta-CRL
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

In section 5.2.4 (Delta CRL Indicator), RFC 2459 states:

The delta CRL indicator is a critical CRL extension that identifies a
delta-CRL. The use of delta-CRLs can significantly improve
processing time for applications which store revocation information
in a format other than the CRL structure. This allows changes to be
added to the local database while ignoring unchanged information that
is already in the local database.

When a delta-CRL is issued, the CAs MUST also issue a complete CRL.

(...) Again, a delta-CRL MUST NOT be issued without a corresponding
complete CRL.

The two questions are the following:

1) What is the rational for mandating the issuance of a complete CRL each
time a delta-CRL is issued ?
2) Under which conditions could this requirement be relaxed ?

Denis

Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id CAA08556 for ; Tue, 2 Jan 2001 02:46:21 -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 LAA21862; Tue, 2 Jan 2001 11:57:25 +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 LAA19920; Tue, 2 Jan 2001 11:50:01 +0100
Message-ID: <[email-masked]>
Date: Tue, 02 Jan 2001 11:50:05 +0100
From: Denis Pinkas
Organization: Bull
X-Mailer: Mozilla 4.7 [fr] (Win98; I)
X-Accept-Language: fr
MIME-Version: 1.0
To: Stephen Kent
CC: PKIX-List
Subject: Re: DPD & DPV requirements
References: <[email-masked]> <[email-masked]> <[email-masked]>
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id CAA08558

Steve,

First of all, many thanks for posting this long document.

I will not respond using directly your text, since my arguments
are fairly different. I will however re-use some of your arguments.

Let us use the concept of "validation policy", that you introduce, which is
all the set of rules to be followed when validating a certificate. It will
usually not simply be the rules mentioned in RFC 2459, but these rules with
additional conditions. Note that in the context of electronic signatures, a
"signature policy" is a specific example of a "validation policy".

DPV
===

Let us start with DPV first. A DPV client will not necessarily be either
PKI-aware, nor ASN.1 aware. I thus see two flavors for a DPV protocol:

1) one not using ASN.1 (e.g. using XML),
2) one using ASN.1.

In both cases the client only supplies an unambiguous reference of the
certificate (CA name, serial number and a hash of the certificate) or the
certificate itself and specifies the rules to be followed to validate the
certificate: an identification of a pre-defined "validation policy" (e.g. an
OID and/or a URL to find the policy and a hash of that validation policy).

As a result, the client expects a signed response which reproduces the
requested parameters and includes a status. The status is not simply:
"passed validation", "failed validation", or "don't' know" but can also be
"incomplete validation", meaning that some revocation status information is
not yet available at the time of processing and a later attempt might
succeed.

The response must include the time at which the validation has been
performed. Allowing to test a certificate "in the past", would place some
requirements that cannot always be accomplished by a standard PKI: currently
we do not mandate CAs to maintain revocation information beyond the end of
the validity period of a certificate. We should not change that rule. So I
am very reluctant to autorise validation in the past, e.g. 10 years later.

If a client is interested in a later proof, then it should obtain that
information from the server at the time the information is still available.
This means that a client should have the possibility to ask the server to
optionally return an opaque blob that contains all what has been used to
validate the certificate (i.e. a certification path and all the CRLs or
OCSPs needed for each certificate from the path).

A question arises from the requirements 1.5 and 1.6 that you listed: should
that opaque blob be time-stamped ? If there is a fear that some of the
issuing keys used in the certification path might later on be compromised,
then this can be useful. This case should be very seldom and hence this
service would not always be required. In addition, why should that service
be embedded in this protocol ? This could be obtained using directly the
TSP, leaving more possibilities: free choice of the TSAs, time stamp of the
full blob, time stamp of the certification chain only, time stamp on both
the certification chain and the revocation information. Thus I do not favor
to piggy-back the two services.

In order to simplify the protocol and allow for PKI-ignorant clients, the
client should NOT be allowed to provide any other element than the
certificate, that might help to construct the path or the revocation
information.

This means that, not only I do not agree with a common list of requirements
for both DPV and DPD, but also that I do not agree with many of the
requirements that you listed:

For a DPV client:

1.1. Only a single certificate should be allowed.
1.2. No revocation items should be allowed.
1.3. No request in the past should be allowed.
1.4. Imposing constraints for CRLs or OCSP responses should be hidden
under the "validation policy" that is selected.
1.5. and 1.6. Time stamped responses, if needed, should not be part of the
service.
1.7. Validation policies are not necessarily "configured at the server",
but can simply be pre-defined, outside the server. I any case, the
rules that has been followed - i.e. "validation policy" - must be
indicated in the response.
1.8. For DPV, responses must be signed.
1.9. The policy ID format can/will be specified in the protocol.

For a DPV server:

2.1. A DPV server, will have to do more than RFC 2459, hence why the use
of a validation policy is needed.
2.2. An opaque blob MAY be returned.
2.3. Time stamping is not needed.
2.4. The concept of policy overriding is too complex: a reference to
a validation policy is sufficient.
2.5. No comment.
2.6. A server must support LDAP for certificate fetching, and EITHER CRL
fetching OR OSCP (OCSP should not be mandatory).
2.7. No comment.

DPD
===

Let us continue with DPD. I agree in general with many of the requirements
that you listed in that case. In particular, since a DPD client must be both
PKI-aware and ASN.1 aware, the protocol should only be described in ASN.1.

The major difference with the previous protocol is that no evaluation of the
returned chain needs to be done, since the client is supposed to be able to
perform all the checks himself. Therefor no validation status is returned by
the server.

The service is more a single place for shopping all (?) the needed
certificates and revocation status information.

In the request, the client could either specify a validation policy or the
trusted points with, for each level of the chain, the indication whether
CRLs or OCSP responses are requested.

One or more chains, corresponding to the request may be obtained.

The response does not need to be signed, but only protected by a combined
integrity and data origin authentication service.

CONCLUSION
==========

We could support three protocols:

1° DPV in XML,
2° DPV in ASN.1,
3° DPD in ASN.1.

ADDITIONAL QUESTION
===================

For the two protocols in ASN.1, should these two protocols be piggy-back on
OCSP ?

Before going at the technical details, it is important to raise the
following question: which combination(s) of the three basic requests (OCSP,
DPV and DPD) could make sense ?

If a client requests DPV, then it does not care about OCSP and neither on
DPD (multiple certification chains to be tested).

For a PKI-aware client, only OCSP + DPD makes sense.

This means that :

1) DPV does not need to be supported by OCSP.
2) The only protocol to be piggy-backed to OCSP would be DPD.

Denis

> As promised, here is the strawman requirements specification for DPV and DPD. Questions that the WG needs to address as part of deciding on the scope of these requirements are in boldface.
>
> Happy Holidays,
>
> Steve
> --------
>
> The WG has already decided to purse standardization of a protocol (or protocols) for delegated path discovery (DPD) and delegated path validation (DPV). This memo revisits and expands on the rationale for offering these services, notes the overlap in server functionality required for each, and proposes requirements for candidate protocols that will be considered for standardization by PKIX. The goal of the memo is to provide a strawman set of requirements and evaluation criteria that will be used to select PKIX standards.
>
> A DPD or a DPV server may operate in either a public or private context. In the former case, clients are assumed to be from a broad community with no common organizational affiliation and the service may be offered for a fee. In the latter case, the service may be offered to a closed community under a common organizational structure, where there is an expectation that the server falls under the same administrative control as the clients and no explicit fee may be involved. Intermediate or hybrid models also may exist, but are not specifically identified here nor required as part of proposed solutions.
>
> DPD allows a client to offload the communications and processing associated with retrieval of certificates and CRLs (or OCSP responses) to create a certification path terminating in a target certificate. The client supplies this target certificate, or it may supply a partial path, or a complete path (the latter two may have been acquired as part of a protocol exchange). In the last case, the DPD server assists the client by acquiring relevant revocation status information. The client might also supply some revocation status data, to aid the path discovery process, just as it may provide a partial or complete certification path. This might make sense if this revocation status data was supplied to the client as part of a protocol exchange, e.g., IKE and S/MIME make provisions for send such data.
>
> The client may be bandwidth constrained and thus would benefit from having a server interact with repositories and other servers to acquire the requisite certification path and/or revocation status data. The client may be storage constrained, and thus can benefit from a server that caches certificates, CRLs and OCSP responses. Because multiple protocols may have to be employed in communicating with various servers (e.g., OCSP, LDAP, etc.) in performing path discovery, the size and complexity of client code may be reduced by reliance on a DPD server. Because the server can have more storage, a faster processor, and higher speed communications paths to these servers, the client may gain a performance advantage by delegating the task of path discovery.
>
> DPV offloads all aspects of path validation to a server, which returns to the client, at a minimum, an indication of status of the target certificate. This status may be relative to the current time, or it might be a request to verify status at some previous time, e.g., as an aid to checking non-repudiation evidence. As above, the client may provide a partial or complete candidate path for validation, or may provide just the target certificate, and the client may provide some or all of the associated revocation status data. Also, the parameters for path validation must be provided, either explicitly in the request or via server configuration. As well as the benefits noted above (reduced bandwidth, storage and processing requirements and reduced client code size and complexity), DPV allows an administrator to centrally manage (via server configuration) some or all of the path validation parameters. Similar controls on path discovery could be present in a DPD server. Central
> management controls are viewed as especially attractive in closed, organizational environments as they mitigate configuration management problems for individual clients. For a public DPV service this is not an issue because there is no single, central authority responsible for configuration management of all clients.
>
> A DPD client is assumed capable of performing path validation on the returned certificate chain(s), which implies that the client embodies validation software consistent with RFC 2459 (which is non-trivial in size and complexity) and thus is capable of parsing certificates, CRLs, and OCSP responses. Such a client may be termed "PKI-aware," i.e., it can parse ASN.1, verify digital signatures, perform path validation, and is cognizant of validation parameters. Thus, no apparent, significant benefit accrues from using a syntax other than ASN.1 for DPD queries and responses.
>
> Because a DPD client is PKI-aware, it is capable of specifying the validation parameters used by a DPD server in constructing a candidate path. The goal of DPD is to return one or more chains that will be acceptable to the client, so it is important that the client be able to specify, e.g., via a DPD request, the set of validation processing parameters that it will use for local validation. Only by making the DPD server aware of these parameters can the server return a path (and supporting revocation status data) that will have a very high likelihood of being acceptable to the client. It may be desirable, especially in a closed environment, to assert centralized control over the validation processing parameters used by the server, even though such control is less stringent than that imposed in a DPV context. This suggests there should be provisions for configuring validation processing parameters into the server, and for allowing a client to select from among several possible
> parameter sets. See the discussion immediately below for a further examination of this issue.
>
> DPV also requires a means to control the validation parameters defined in RFC 2459. If we assume that a DPV protocol will operate in both open and closed environments, and if we wish to accommodate PKI-aware clients, then there must be a means for a client to specify all of these parameters, or to specify a subset of them. The former requirement arises in the simplest, open server contexts; the latter may arise in such contexts if there is some other way to signal a default set of parameters for validation control, e.g., via reference to one of several validation policies configured in a server, as a basis for these parameter values. In a closed environment, it is still important that a client be able to specify validation parameters, e.g., as a means of selecting from among a set of parameters allowed by administrative controls managed at the server. For example, a server in an organizational environment may have a configured set of trust points, but a client may be permitted to
> select from a subset of these when requesting validation for a specific certificate. Such flexibility is needed because the validation parameters are a function of several variables that are context specific.
>
> It seems reasonable to require a DPV or DPD client to be able to control validation via two means: specification of a validation policy configured at a server, or via client-specified parameters. These means are not mutually exclusive, and a server should support combinations of them, e.g., client-specified parameters constrained by reference to a server-configured validation policy. We need to refine the semantics here, e.g., can the server be configured with path validation parameters that CANNOT be overridden by a client, and if so, does the server have to inform the client when its explicitly-specified parameters were ignored, as part of response, or does the server just reject the request, note the offending parameters, and let the client try again?
>
> It is tempting to suggest support for multiple policies specified in a request, but I'm not sure how one would make use of this. For example, is the server required to try to construct paths based on each of the policies, in succession, and to return all successful results, or is the server free to choose any one of the policies? Does the order in which the policies are specified indicative of preference? To keep life simple, for now, I suggest that we allow specifying only one policy in a request, but I am open to suggestions.
>
> At a minimum, the parameters for server-configured policies must be those specified by the certificate path validation algorithm in RFC 2459. It is tempting to suggest that a vendor may elect to augment this set and provide a means by which a client can specify additional controls. The motivation here is that, over time, we may identify additional controls to provide "fuzzier" evaluation. For example, a client might be willing to accept a certificate if the server asserts that although the current CRL for the target certificate is not available, the certificate is not on the most recent CRL available to the server at the time of the request. This area is quite complex and does not yet appear suitable for standardization. The WG must decide if we wish to require (or discourage) such extensibility. Note that extensibility usually leads to added complexity, and possible non-interoperabilty, e.g., if private extensions are supported. Personally, I would recommend against such extensions
> at this time.
>
> It has been suggested that a DPV server also should be capable of returning time-stamped certification path(s) and revocation data, for later use as evidence in a non-repudiation dispute. If so, then the data returned by a DPV server is potentially quite close to that provided by a DPD server. One could argue that a DPD server could provide an option for return of time-stamped path and revocation status data, also in support of non-repudiation, for the same reasons, which would make the responses for both types of servers even more similar.
>
> It is important to ask to what extent should we assume that a DPV client is PKI aware? At one extreme one can imagine that the client is PKI-aware and that it should be able to specify all of the path validation parameters required in 2459. For such a client, returning a certificate and an indication of its validity seems appropriate. Alternatively, a DPV client may not be PKI-aware, but may still be ASN.1-capable. The client could parse a certificate returned to it, but it does not implement nor understand path validation. For such a client, it seems appropriate to control path validation only via reference to a policy, not by specifying individual path validation parameters. In the extreme case, a DPV client may not even be ASN.1-capable.
>
> For a non-PKI aware, non-ASN.1-capable client, the results returned by the DPV protocol should not be merely a certificate and a status indication. Rather, the contents of a certificate that are relevant to the client application should be returned as distinct values, in a syntax appropriate for the client. For example, the public key and associated algorithm, the subject name (and/or alternate names) and the issuer name (and alternate names), the key usage bits, and the extended key usage field are all candidate values to be returned as distinct objects to the client. An argument could be made for using XML to represent some of these values, and to represent the syntax of the protocol messages. But, some of the certificate contents, specifically the issuer name and subject name, are intrinsically ASN.1 objects themselves, so these values would have to be decoded even further for use by a non-ASN.1-aware client. (There are scenarios that motivate return of ASN.1-encoded data, e.g.,
> certification paths and revocation data, as an opaque blob, e.g., for later use in a non-repudiation dispute. But this does not imply that the client is ASN.1-aware.)
>
> If we wish to support DPV clients that are not ASN.1-capable, the WG is faced with a question; Shall we mandate support for another syntax in addition to (or in lieu of) ASN.1, for a DPV protocol? This question must be resolved soon, as it becomes an important input to DPV protocol requirements. In informal discussions at the IETF meeting, some folks suggested that the scope of issues associated with supporting non-ASN.1-capable clients (in the DPV context) is potentially very broad and that we should defer such support for now. But, the WG needs to weigh in on this question.
>
> Finally, this analysis suggests that there are relatively few differences between a DPD and a DPV server. Both must be capable of constructing and returning certification paths and supporting revocation data, under the control of parameters that are either explicitly specified by a client or referenced via a server-configured policy. Both accept a range of inputs in the form of certificates or certificate chains, and revocation data "hints." Thus, the WG must decide if two distinct protocol formats, with different syntax are warranted, of if a single (slightly more complex) format for requests and responses is appropriate.
>
> Based on the preceding analysis, I propose the following requirements for DPD and DVP protocols, based on the assumption of ASN.1 aware clients. Remember that the protocol specs will encompass not only the syntax of the bits on the wire, but also the processing that will be performed by clients and servers.
>
> Unless otherwise qualified, he following requirements are proposed for both DPD and DPV protocols:
>
> Client requirements:
>
> 1.1 A client request can contain a single certificate or a certificate chain terminating in the "target" certificate, to assist the server in path construction.
>
> 1.2 A client request can contain one or more revocation data items, to assist the server in path validation.
>
> 1.3 A client request to a DPV server can specify the time relative to which the validation is to be performed. If omitted, the current time is assumed.
>
> 1.4 A DPD client request must be able to specify whether only CRLs, only OCSP responses, or either, are acceptable forms of revocation status data to be returned. (We could apply this requirement to DPV requests as well, if the content of returned, substantiating evidence for non-repudiation needs to be similarly constrained.) [Shall we also allow the request to also impose constraints on the forms of OCSP responses that are acceptable, by type, and if the basic type is specified shall we require an ability to specify a time before which a pre-produced OCSP response is considered too old?]
>
> 1.5 A DPV client request must be able to specify whether a certification path and revocation status data, plus a TSP response (for each returned certification path and revocation data set) should be returned by a server, in support of non-repudiation.
>
> 1.6 A DPD client request must be able to specify whether a TSP response should be returned by a server (for each returned certification path and revocation data set), in support of non-repudiation.
>
> 1.7 A client request must be able to specify validation processing parameter values both via reference to policies configured at a server and via specification of values for individual parameters. If no policy is specified and no parameters are specified, a default parameter value set, configured at the server, will be employed. If a policy is specified but no parameter values are specified by the client, then the parameter values associated with that policy are employed. If only client-supplied parameter values are present in the request, then they are employed. Any parameters not specified by the client will be supplied by the default set configured in the server. Also, if any of these default parameters are marked as not capable of being overridden by user-specified parameter values, then the default parameter values shall be employed. If a policy is specified and there are client-supplied parameter values, the policy is employed to select parameter values, and then the
> user-supplied parameter values are applied, overriding the policy-specified parameter values, except for any policy-specified parameters that are marked as not subject to user override. [whew!]
>
> 1.8 Either the request/response protocol itself, or a specified lower layer protocol to be employed for requests and responses, there must be a provision for data origin authentication and connectionless integrity for requests and responses, and responses must be matched to requests. Request authentication & integrity is needed to support access control to the server, a requirement for public servers. Responses must be authenticated and integrity-protected to ensure that they are from the indicated server, and matched to the request in question. Additional security services may be offered optionally.
>
> 1.9 The client must be able to query a server and request path validation policy parameter values for any policy configured on the server. The client must be able to specify policies by an ID (e.g., an OID) or to refer to the default policy. [A standard will have to specify the policy ID format.]
>
> Server Requirements:
>
> 2.1 A server must be able to process client requests invoking any of the features defined above for clients. Thus it must implement RFC 2459-compliant certificate validation procedures in support of both DPD and DPV. The path discovery process implemented by a DPD server operates under the same set of controls as path validation, and thus a DPD server returns paths only if they are valid with respect to the specified path validation parameter values.
>
> 2.2 A server must be able to return one or more sets of certification paths and associated revocation data as a result of path discovery/validation. Each set shall consist of an ordered list of certificates and associated CRLs and/or OCSP responses.
>
> 2.3 A server must be capable of returning a time stamp response (consistent with the TSP RFC that will soon be issued) covering each returned certification path and revocation data set. (See 1.4 & 1.5 above)
>
> 2.4 A server must be configurable to support multiple sets of path validation parameters, each identified by a policy identifier. One such set, which must include values for all validation parameters, must be designated as the default policy. Each parameter in any policy must be capable of being marked as not subject to override by corresponding, client-specified parameters. (It is TBD whether the default policy supercedes other configured policies if there are conflicts in parameters that are marked as not being subject to override.)
>
> 2.5 The means by which validation policy parameter values are configured will not be part of the standard.
>
> 2.6 A server must be able to access both LDAP servers and OCSP servers in support of path discovery and revocation data acquisition.
>
> 2.7 A server must be able to respond to a request from a client for the path validation policy parameters for the default policy, or for any identified policy. However, a server may impose access controls with regard to such requests so that it may reject a query if the client is not authorized to invoke the path validation policy in question.
> ------------------------------------------------------------------------------------------------------------------
>
> My examination of both SCVP and the proposed OCSPv2 extensions suggests that neither meet the strawman requirements I set forth above. Of course, the WG also has to review these requirements and determine if there is consensus on them, or if they need to be modified (pruned or extended). The time table in my pre-Christmas message says that we have the next moth to reach closure on this.
>
> Finally, one criteria for selecting a standard which seems important to many WG participants is the complexity of the client and server implementations. Arguments about simplicity based on extending an existing protocol are not objective in the absence of substantiating data. Thus, to create a level playing field, all proposed protocols must be accompanied by algorithmic descriptions of the processing by both client and server. Remember that a protocol is not just the syntax of the bits on the wire, but also encompasses the processing and semantics associated with the protocol. I have tried to allude to aspects of such processing in the requirements above, but more work remains. IETF standards have often failed to do a good job in this regard. Our recent experience with varying interpretations of OCSP (v1) responses demonstrate the importance of such specification. The level of detail required here is open for discussion, but it must be sufficient to allow WG members to create
> independent, interoperable implementations, and to allow prospective evaluation of the relative complexity of each candidate.